ಎರಡು DGX Spark-ವರ್ಗದ ಬಾಕ್ಸ್‌ಗಳು, ಒಂದೇ ಮಾದರಿ: ಪ್ರತಿಯೊಂದರ ಮೇಲೆ ಒಂದು ನಕಲು, ವಿಭಜನೆಯನ್ನು ಸೋಲಿಸುತ್ತದೆ

ಆಪ್ಸ್2026-10-31

ಏಳು ವಾರಗಳ ಕಾಲ, ನಮ್ಮ ಸ್ಥಳೀಯ ಭಾಷಾ ಮಾದರಿಯು ಟೆನ್ಸರ್ ಪ್ಯಾರಲಲಿಸಂ ಮೂಲಕ ಎರಡು NVIDIA GB10 ಯಂತ್ರಗಳಲ್ಲಿ ವಿಭಜಿತವಾಗಿ ಚಲಿಸಿತು. 22 ಅಕ್ಟೋಬರ್‌ನಲ್ಲಿ, ನಾವು ಅದನ್ನು ಪ್ರತಿಯೊಂದು ಯಂತ್ರದ ಮೇಲೆ ಮಾದರಿಯ ಪೂರ್ಣ ನಕಲು ಮತ್ತು ಮುಂದೆ ಒಂದು ಲೀಸ್ಟ್-ಕನೆಕ್ಷನ್ ಪ್ರಾಕ್ಸಿ ಇರುವಂತೆ ಬದಲಾಯಿಸಿದೆವು. ಥ್ರೂಪುಟ್ ಸೆಕೆಂಡಿಗೆ ಸುಮಾರು 180 ರಿಂದ 210 ಟೋಕನ್‌ಗಳಿಗೆ ಹೆಚ್ಚಾಯಿತು, ಮತ್ತು ಯಾವುದೇ ಯಂತ್ರವು ಮಾದರಿಯನ್ನು ತೆಗೆದುಹಾಕದೆ ಈಗ ಪುನರಾರಂಭಗೊಳ್ಳಬಹುದು.

ನಾವು ಅದನ್ನು ಏಕೆ ವಿಭಜಿಸಿದ್ದೆವು

ಪ್ರತಿ ಯಂತ್ರವು CPU ಮತ್ತು GPU ಹಂಚಿಕೊಳ್ಳುವ 128 GB ಮೆಮೊರಿ ಹೊಂದಿದೆ. ಸೆಪ್ಟೆಂಬರ್‌ನಲ್ಲಿ ಮಾದರಿಯು ಒಂದು ಯಂತ್ರದ ಮೇಲೆ ಹೊಂದಿಕೊಂಡಿತು, ಆದರೆ ಅದರ ಕ್ಯಾಶ್ ಕಷ್ಟಪಟ್ಟು ಹೊಂದಿಕೊಂಡಿತು: ನಾವು ಬಳಸಿದ vLLM ಬಿಲ್ಡ್ ಈ ಮಾದರಿಯ KV ಕ್ಯಾಶ್ ಅನ್ನು FP8 ನಲ್ಲಿ ಇಡಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ, ಆದ್ದರಿಂದ ಕ್ಯಾಶ್ BF16 ನಲ್ಲಿತ್ತು, ಮತ್ತು ಒಂದು ಯಂತ್ರದಲ್ಲಿ ಅದಕ್ಕೆ 499,110 ಟೋಕನ್‌ಗಳ ಜಾಗ ಮಾತ್ರ ಇತ್ತು. ಮಾದರಿಯ ಪೂರ್ಣ ಸಂದರ್ಭದ 262,144 ಟೋಕನ್‌ಗಳಲ್ಲಿ ಇದು ಎರಡಕ್ಕಿಂತ ಕಡಿಮೆ ವಿನಂತಿಗಳಿಗೆ ಸಮಾನವಾಗಿದೆ. ಅವುಗಳ ನೇರ ನೆಟ್‌ವರ್ಕ್ ಲಿಂಕ್ ಮೂಲಕ ಟೆನ್ಸರ್ ಪ್ಯಾರಲಲಿಸಂನೊಂದಿಗೆ ಎರಡು ಯಂತ್ರಗಳಲ್ಲಿ ವಿಭಜಿಸಿದಾಗ, ಕ್ಯಾಶ್ ಮೂರು ದಶಲಕ್ಷಕ್ಕಿಂತ ಹೆಚ್ಚು ಟೋಕನ್‌ಗಳಿಗೆ ಬೆಳೆಯಿತು. ನಾವು ಮಾದರಿಯನ್ನು ವೇಗಕ್ಕಾಗಿ ಅಲ್ಲ, ಜಾಗಕ್ಕಾಗಿ ವಿಭಜಿಸಿದ್ದೆವು.

ಏನು ಬದಲಾಗಿದೆ

ಅದೇ ಮಾದರಿಯ ಹೊಸ 4-ಬಿಟ್ ಬಿಲ್ಡ್ (NVFP4, ಕ್ವಾಂಟೈಸೇಶನ್-ಅವೇರ್ ಡಿಸ್ಟಿಲ್ಲೇಶನ್ ಮೂಲಕ ತಯಾರಿಸಲಾಗಿದೆ) ಸುಮಾರು 71 GiB ಮೆಮೊರಿ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು GB10 ಗಾಗಿ ಒಂದು ಸಮುದಾಯ vLLM ಬಿಲ್ಡ್ (eugr/spark-vllm-b12x) ಅದರ ಕ್ಯಾಶ್ ಅನ್ನು FP8 ನಲ್ಲಿ ಚಲಿಸುತ್ತದೆ. ಈಗ ಒಂದು ಯಂತ್ರವು ಇಡೀ ಮಾದರಿ ಮತ್ತು 0.76 ರಿಂದ 1.08 ದಶಲಕ್ಷ ಟೋಕನ್‌ಗಳ ಕ್ಯಾಶ್ ಅನ್ನು ಹೊಂದಿದೆ, ಯಂತ್ರವು ಎಷ್ಟು ಮೆಮೊರಿ ನೀಡುತ್ತದೆ ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ ಪೂರ್ಣ ಸಂದರ್ಭದಲ್ಲಿ 2.9 ರಿಂದ 4.1 ವಿನಂತಿಗಳಿಗೆ ಜಾಗವಿದೆ. ಎರಡು ನಕಲುಗಳು ಮಾದರಿಯ ಸ್ವಂತ ಸ್ಪೆಕ್ಯುಲೇಟಿವ್ ಡಿಕೋಡಿಂಗ್ (MTP, ನಾಲ್ಕು ಡ್ರಾಫ್ಟ್ ಟೋಕನ್‌ಗಳು) ಬಳಸುತ್ತವೆ. ಬದಲಾಯಿಸುವ ಮೊದಲು ನಾವು ಹೊಸ ಬಿಲ್ಡ್‌ನಲ್ಲಿ ನಮ್ಮ ಟೂಲ್-ಕಾಲಿಂಗ್ ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸಿದೆವು: ಅದು 86 ಅಂಕಗಳನ್ನು ಪಡೆಯಿತು, ಅದು ಬದಲಾಯಿಸಿದ ಬಿಲ್ಡ್ 75 ಅಂಕಗಳನ್ನು ಪಡೆಯಿತು.

ನಾವು ಏನನ್ನು ಅಳತೆ ಮಾಡಿದೆವು

ಒಂದು ಪ್ರತಿಯು, ಏಕಕಾಲದಲ್ಲಿ ಅದು ಸೇವಿಸುವ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯ ಆಧಾರದ ಮೇಲೆ ಸ್ವತಂತ್ರವಾಗಿರುತ್ತದೆ: ಕಿರು ಪ್ರಾಂಪ್ಟ್‌ಗಳೊಂದಿಗೆ, 1 ವಿನಂತಿಯು ಸೆಕೆಂಡಿಗೆ 36 ಟೋಕನ್‌ಗಳನ್ನು ನೀಡಿತು, 4 ನೀಡಿದರೆ 82, 8 ನೀಡಿದರೆ 109 ಮತ್ತು 16 ನೀಡಿದರೆ 150. ನಮ್ಮ ಇಮೇಲ್ ಏಜೆಂಟ್‌ನ ದೀರ್ಘ ಪ್ರಾಂಪ್ಟ್‌ಗಳೊಂದಿಗೆ, 4 ನೀಡಿದರೆ 81, 8 ನೀಡಿದರೆ 113 ಮತ್ತು 16 ನೀಡಿದರೆ ಕೇವಲ 87: ಎಂಟಕ್ಕಿಂತ ಹೆಚ್ಚು ವಿನಂತಿಗಳಾದರೆ, ಹೆಚ್ಚಿನವು ಅದನ್ನು ನಿಧಾನಗೊಳಿಸಿದವು.

ಒಂದು ಸಂಜೆಗೆ, ಒಂದು ಪ್ರತಿಯು ಗರಿಷ್ಠ 12 ವಿನಂತಿಗಳನ್ನು ಏಕಕಾಲದಲ್ಲಿ ತೆಗೆದುಕೊಂಡರೆ, ಇನ್ನೊಂದು 8 ತೆಗೆದುಕೊಂಡಿತು. ಮೊದಲನೆಯದು ಸೆಕೆಂಡಿಗೆ 91 ರಿಂದ 93 ಟೋಕನ್‌ಗಳನ್ನು ಉತ್ಪಾದಿಸಿತು ಮತ್ತು ನಿಮಿಷಕ್ಕೆ 26 ರಿಂದ 27 ವಿನಂತಿಗಳನ್ನು ಪೂರ್ಣಗೊಳಿಸಿತು; ಎರಡನೆಯದು ಸೆಕೆಂಡಿಗೆ 81 ರಿಂದ 83 ಟೋಕನ್‌ಗಳನ್ನು ಮತ್ತು ನಿಮಿಷಕ್ಕೆ 22 ವಿನಂತಿಗಳನ್ನು ಪೂರ್ಣಗೊಳಿಸಿತು. ಈಗ ಎರಡೂ 12 ತೆಗೆದುಕೊಳ್ಳುತ್ತವೆ.

ನಾವು ಏನನ್ನು ತ್ಯಜಿಸಿದೆವು

ಸ್ಥಳಾವಕಾಶ. ವಿಭಜಿತ ಮಾದರಿಯು ಮೂರು ದಶಲಕ್ಷಕ್ಕಿಂತ ಹೆಚ್ಚು ಟೋಕನ್‌ಗಳ ಒಂದು ಕ್ಯಾಶ್ ಅನ್ನು ಹೊಂದಿತ್ತು; ಪ್ರತಿಗಳು ಎರಡು ಸಣ್ಣ ಕ್ಯಾಶ್‌ಗಳನ್ನು ಹೊಂದಿವೆ, ಮತ್ತು ಒಂದು ವಿನಂತಿಯು ಅದನ್ನು ಸೇವಿಸುವ ಪ್ರತಿಯ ಕ್ಯಾಶ್ ಅನ್ನು ಮಾತ್ರ ಬಳಸಬಹುದು. ನಮ್ಮ ಏಜೆಂಟ್‌ಗಳು ಅನೇಕ ಕಿರು ಮತ್ತು ಮಧ್ಯಮ ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸುತ್ತವೆ, ಮತ್ತು ಅವುಗಳಿಗೆ ಥ್ರೂಪುಟ್ ಹೆಚ್ಚು ಮಹತ್ವದ್ದಾಗಿತ್ತು. ನೀವು ಕೆಲವು ಅತ್ಯಂತ ದೀರ್ಘ ಸಂದರ್ಭಗಳನ್ನು ಏಕಕಾಲದಲ್ಲಿ ಸೇವಿಸಿದರೆ, ವಿಭಜನೆಯು ಇನ್ನೂ ಉತ್ತಮ ಆಯ್ಕೆಯಾಗಿರಬಹುದು. ನಾವು ವಿಭಜಿತ ಸೆಟಪ್ ಅನ್ನು ಉಳಿಸಿಕೊಂಡಿದ್ದೇವೆ, ಮತ್ತು ಹಿಂದಕ್ಕೆ ಬದಲಾಯಿಸುವುದು ಒಂದು ಸ್ಕ್ರಿಪ್ಟ್ ಆಗಿದೆ.

ಬದಲಾವಣೆಯ ಸಮಯದಲ್ಲಿ ಏನು ತಪ್ಪಾಯಿತು

1. ಮಾದರಿಯಿಲ್ಲದೆ ಹನ್ನೊಂದು ನಿಮಿಷಗಳು, ನಂತರ 502ಗಳ 30 ಸೆಕೆಂಡುಗಳು. ವಿಭಜಿತ ಮಾದರಿಯು ಅದೇ ಯಂತ್ರಗಳಲ್ಲಿ ಪ್ರತಿಯು ಲೋಡ್ ಆಗುವ ಮೊದಲು ನಿಲ್ಲಬೇಕಾಗಿತ್ತು, ಆದ್ದರಿಂದ ನಮ್ಮ ಏಜೆಂಟ್‌ಗಳು ಸುಮಾರು ಹನ್ನೊಂದು ನಿಮಿಷಗಳು ಕಾಯಬೇಕಾಯಿತು. ಮೊದಲ ಪ್ರತಿಯು ಬಂದಾಗ, ಪ್ರಾಕ್ಸಿಯು ಸುಮಾರು 30 ಸೆಕೆಂಡುಗಳ ಕಾಲ "502 no live upstreams" ಎಂದು ಉತ್ತರಿಸುತ್ತಲೇ ಇತ್ತು: ಅದು ಬ್ಯಾಕೆಂಡ್‌ಗಳನ್ನು ಅವು ಕೆಳಗಿದ್ದಾಗ ವಿಫಲವೆಂದು ಗುರುತಿಸಿತ್ತು (max_fails=3, fail_timeout=30s) ಮತ್ತು ಆ ಸಮಯ ಮುಗಿಯುವವರೆಗೆ ಅವುಗಳನ್ನು ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಲಿಲ್ಲ.
2. ಪ್ರಾಕ್ಸಿಯನ್ನು ಬಿಟ್ಟುಹೋದ ಕ್ಲೈಂಟ್. ನಮ್ಮ ಬ್ಯಾಚ್ ಜಾಬ್‌ಗಳಲ್ಲಿ ಒಂದು, ಮೊದಲ ಯಂತ್ರದ ವಿಳಾಸವನ್ನು ತನ್ನ ಕಾನ್ಫಿಗ್‌ನಲ್ಲಿ ಹೊಂದಿತ್ತು, ಆದ್ದರಿಂದ ಅದರ ಪೂರ್ಣ ಲೋಡ್ ಒಂದು ಪ್ರತಿಗೆ ಹೋಯಿತು, ಇನ್ನೊಂದು ಸಾಮರ್ಥ್ಯವನ್ನು ಉಳಿಸಿಕೊಂಡಿತ್ತು. ಈಗ ಪ್ರತಿ ಕ್ಲೈಂಟ್ ಪ್ರಾಕ್ಸಿ ಮೂಲಕ ಹೋಗುತ್ತದೆ; ಯಂತ್ರಗಳ ಸ್ವಂತ ವಿಳಾಸಗಳು ಆರೋಗ್ಯ ಪರಿಶೀಲನೆಗಳಿಗಾಗಿ ಮಾತ್ರ ಇರುತ್ತವೆ.
3. ಜಿಗ್ಗಿದ ಮೆಟ್ರಿಕ್ಸ್. ನಮ್ಮ ಥ್ರೂಪುಟ್ ಮಾನಿಟರ್ ಪ್ರಾಕ್ಸಿ ಮೂಲಕ vLLM ನ /metrics ಅನ್ನು ಓದುತ್ತಿತ್ತು. ಎರಡು ಬ್ಯಾಕೆಂಡ್‌ಗಳೊಂದಿಗೆ, ಅನುಕ್ರಮ ಓದುಗಳು ವಿಭಿನ್ನ ಪ್ರತಿಗಳಿಂದ ಬಂದವು, ಕೌಂಟರ್‌ಗಳು ಮುಂದೆ ಮತ್ತು ಹಿಂದೆ ಜಿಗಿದವು, ಮತ್ತು ಮಾನಿಟರ್ ಮಾದರಿಯು ನಿರ್ಗತಿಕೆಯಾಗಿದೆ ಎಂದು ವರದಿ ಮಾಡಿತು. ಈಗ ಅದು ಪ್ರತಿ ಪ್ರತಿಯನ್ನು ನೇರವಾಗಿ ಓದುತ್ತದೆ ಮತ್ತು ಅವುಗಳನ್ನು ಕೂಡಿಸುತ್ತದೆ.
4. ಹೊಸ ಪ್ರತಿಯನ್ನು ನಿಲ್ಲಿಸಬಹುದಾದ ಹಳೆಯ ವಾಚ್‌ಡಾಗ್. ವಿಭಜಿತ ಸೆಟಪ್‌ನಲ್ಲಿ, ಮಾಡೆಲ್ ಉತ್ತರಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದಾಗ ಅದರ ಸೇವೆಯನ್ನು ಮರುಪ್ರಾರಂಭಿಸುವ ವಾಚ್‌ಡಾಗ್ ಇತ್ತು. ಹೊಸ ಸೇವೆಯು ಹಳೆಯದರೊಂದಿಗೆ Conflicts= ಅನ್ನು ಘೋಷಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಆ ಮರುಪ್ರಾರಂಭವು ಹೊಸ ಪ್ರತಿಯನ್ನು ನಿಲ್ಲಿಸಬೇಕಾಗಿತ್ತು. ಇದನ್ನು ಕೇವಲ ನಿಲ್ಲಿಸದೆ, systemctl disable --now ಬಳಸಿ ಆಫ್ ಮಾಡಬೇಕಾಗಿತ್ತು, ಏಕೆಂದರೆ ನಮ್ಮ ಆಪ್ಸ್ ಲೇಯರ್ ಎನೆಬಲ್ ಆದರೂ ರನ್ ಆಗದ ಯೂನಿಟ್‌ಗಳನ್ನು ಮರುಪ್ರಾರಂಭಿಸುತ್ತದೆ.
5. ಇತರ ಕೆಲಸಗಳನ್ನು ಮಾಡುವ ಯಂತ್ರದ ಮೇಲಿನ ಮೆಮೊರಿ. ಒಂದು ಯಂತ್ರವು ನಮ್ಮ ಡೇಟಾಬೇಸ್‌ಗಳು ಮತ್ತು ಸೈಟ್ ಬಿಲ್ಡ್‌ಗಳನ್ನೂ ನಡೆಸುತ್ತದೆ. vLLM ನ gpu-memory-utilization 0.78 ಆಗಿದ್ದಾಗ, ಉಳಿದ ಎಲ್ಲಕ್ಕೂ ಕೇವಲ 5 GiB ಉಳಿದಿತ್ತು, ಆದ್ದರಿಂದ ನಾವು ಅದನ್ನು 0.74 ಗೆ ಇಳಿಸಿ, ಇನ್ನೊಂದು ಪ್ರತಿಯು ಲೋಡ್ ಹೊರುವಾಗ ಆ ಪ್ರತಿಯನ್ನು ಮಾತ್ರ ಮರುಪ್ರಾರಂಭಿಸಿದೆವು. ಈ ಯಂತ್ರಗಳಲ್ಲಿ, ನೀವು vLLM ಗೆ ನೀಡುವ ಪಾಲು ಇತರ ಎಲ್ಲದಕ್ಕೂ ಬಳಸುವ ಅದೇ ಮೆಮೊರಿಯಿಂದ ಬರುತ್ತದೆ.

ನಿಮ್ಮ ಬಳಿ ಇಂತಹ ಎರಡು ಯಂತ್ರಗಳಿದ್ದರೆ

• ನಿಮಗೆ ಬೇಕಾದ ಮಾಡೆಲ್ ಮತ್ತು ಕ್ಯಾಶ್ ಒಂದೇ ಯಂತ್ರದಲ್ಲಿ ಸಿಗುತ್ತಿದ್ದರೆ, ಪ್ರತಿಯೊಂದರ ಹಿಂದೆ ಲೀಸ್ಟ್-ಕನೆಕ್ಷನ್ ಪ್ರಾಕ್ಸಿ ಇಟ್ಟು ಪ್ರತಿಯೊಂದರ ಪ್ರತಿಯನ್ನು ನಡೆಸಿ. ಒಂದು ಯಂತ್ರವು ನಿಮಗೆ ಬೇಕಾದ ಕ್ಯಾಶ್ ಅನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳಲಾಗದಾಗ ಮಾತ್ರ ಮಾಡೆಲ್ ಅನ್ನು ವಿಭಜಿಸಿ.
• ಬ್ಯಾಚ್ ಜಾಬ್‌ಗಳು ಮತ್ತು ಹಳೆಯ ಕಾನ್ಫಿಗ್‌ಗಳನ್ನು ಒಳಗೊಂಡಂತೆ ಪ್ರತಿಯೊಂದು ಕ್ಲೈಂಟ್ ಅನ್ನು ಪ್ರಾಕ್ಸಿಗೆ ನಿರ್ದೇಶಿಸಿ.
• ಪ್ರತಿಯೊಂದು ಪ್ರತಿಯಿಂದ ನೇರವಾಗಿ ಮೆಟ್ರಿಕ್ಸ್ ಅನ್ನು ಓದಿ.
• ಅದರ ಮೇಲೆ ಇನ್ನೇನು ನಡೆಯುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಪ್ರತಿಯೊಂದು ಯಂತ್ರಕ್ಕೆ ಅದರದ್ದೇ ಆದ ಮೆಮೊರಿ ಪಾಲನ್ನು ನೀಡಿ.
• ನಿಮ್ಮದೇ ಆದ ಟ್ರಾಫಿಕ್‌ನೊಂದಿಗೆ ಒಂದು ಪ್ರತಿಯು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಎಷ್ಟು ವಿನಂತಿಗಳನ್ನು ಸೇವೆ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಹೊಂದಿಸಿ: ನಮ್ಮ ಮಿಶ್ರಣಕ್ಕೆ, 12 ಎಂಬುದು 8 ಕ್ಕಿಂತ ಉತ್ತಮವಾಗಿದೆ.
• ಒಂದು ಪ್ರತಿಯು ಪ್ರಾರಂಭವಾಗಲು ತೆಗೆದುಕೊಳ್ಳುವಷ್ಟು ಸಮಯ ಮಾಡೆಲ್ ಅನ್ನು ತೆಗೆದುಹಾಕಲು ಸ್ವಿಚ್ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ನಿರೀಕ್ಷಿಸಿ ಮತ್ತು ಅದಕ್ಕಾಗಿ ಯೋಜಿಸಿ.

Factory Floor ಒಂದು ಅಥವಾ ಎರಡು ಯಂತ್ರಗಳಿಗೆ ಪ್ರಾಕ್ಸಿ ಮತ್ತು ಲಾಂಚ್ ಕಾನ್ಫಿಗ್‌ಗಳನ್ನು, ಮಾಡೆಲ್‌ಗಳನ್ನು ಬದಲಾಯಿಸುವ ಮೊದಲು ನಾವು ನಡೆಸುವ ಹೆಲ್ತ್ ಚೆಕ್ ಮತ್ತು ಟೂಲ್-ಯೂಸ್ ಟೆಸ್ಟ್ ಅನ್ನು, ಯಂತ್ರದ ಉಳಿದ ಭಾಗಕ್ಕೆ ವಾಚ್‌ಡಾಗ್‌ಗಳು ಮತ್ತು ಮೆಮೊರಿ ಗಾರ್ಡ್‌ಗಳೊಂದಿಗೆ ಒದಗಿಸುತ್ತದೆ.