ਦੋ DGX Spark-ਕਲਾਸ ਬਕਸੇ, ਇੱਕ ਮਾਡਲ: ਹਰੇਕ 'ਤੇ ਇੱਕ ਕਾਪੀ, ਵੰਡ ਨੂੰ ਹਰਾਉਂਦੀ ਹੋਈ

Ops2026-10-31

ਸੱਤ ਹਫ਼ਤਿਆਂ ਤੱਕ ਸਾਡਾ ਲੋਕਲ ਭਾਸ਼ਾ ਮਾਡਲ ਦੋ NVIDIA GB10 ਮਸ਼ੀਨਾਂ ਵਿੱਚ ਟੈਂਸਰ ਪੈਰਲਲਿਜ਼ਮ ਨਾਲ ਵੰਡਿਆ ਹੋਇਆ ਚੱਲਿਆ। 22 ਅਕਤੂਬਰ ਨੂੰ ਅਸੀਂ ਉਸਦੀ ਥਾਂ ਹਰੇਕ ਮਸ਼ੀਨ 'ਤੇ ਮਾਡਲ ਦੀ ਪੂਰੀ ਕਾਪੀ ਅਤੇ ਅੱਗੇ ਇੱਕ ਲੀਸਟ-ਕਨੈਕਸ਼ਨ ਪ੍ਰਾਕਸੀ ਨਾਲ ਬਦਲ ਦਿੱਤਾ। ਥ੍ਰੂਪੁੱਟ ਲਗਭਗ 180 ਤੋਂ ਵਧ ਕੇ 210 ਟੋਕਨ ਪ੍ਰਤੀ ਸਕਿੰਟ ਹੋ ਗਈ, ਅਤੇ ਹੁਣ ਹਰੇਕ ਮਸ਼ੀਨ ਬਿਨਾਂ ਮਾਡਲ ਬੰਦ ਕੀਤੇ ਰੀਸਟਾਰਟ ਹੋ ਸਕਦੀ ਹੈ।

ਅਸੀਂ ਇਸਨੂੰ ਕਿਉਂ ਵੰਡਿਆ ਸੀ

ਹਰੇਕ ਮਸ਼ੀਨ ਵਿੱਚ 128 GB ਮੈਮੋਰੀ ਹੈ ਜੋ CPU ਅਤੇ GPU ਸਾਂਝੀ ਕਰਦੇ ਹਨ। ਸਤੰਬਰ ਵਿੱਚ ਮਾਡਲ ਇੱਕ ਮਸ਼ੀਨ 'ਤੇ ਫਿੱਟ ਹੋ ਗਿਆ, ਪਰ ਉਸਦਾ ਕੈਸ਼ ਮੁਸ਼ਕਲ ਨਾਲ ਫਿੱਟ ਹੋਇਆ: ਅਸੀਂ ਜੋ 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 ਨੂੰ ਪੜ੍ਹਦਾ ਸੀ। ਦੋ ਬੈਕਐਂਡਸ ਦੇ ਨਾਲ, ਲਗਾਤਾਰ ਪੜ੍ਹਨ ਵੱਖ-ਵੱਖ ਕਾਪੀਆਂ ਤੋਂ ਆਉਂਦੇ ਸਨ, ਕਾਊਂਟਰ ਅੱਗੇ-ਪਿੱਛੇ ਉਛਲਦੇ ਸਨ, ਅਤੇ ਮਾਨੀਟਰ ਮਾਡਲ ਨੂੰ ਸਟਾਰਵਡ (starved) ਦੱਸਦਾ ਸੀ। ਹੁਣ ਇਹ ਹਰ ਕਾਪੀ ਨੂੰ ਸਿੱਧਾ ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਜੋੜਦਾ ਹੈ।
4. ਇੱਕ ਪੁਰਾਣਾ ਵਾਚਡੌਗ ਜੋ ਨਵੀਂ ਕਾਪੀ ਨੂੰ ਰੋਕ ਸਕਦਾ ਸੀ। ਸਪਲਿਟ ਸੈੱਟਅੱਪ ਵਿੱਚ ਇੱਕ ਵਾਚਡੌਗ ਸੀ ਜੋ ਮਾਡਲ ਦੇ ਜਵਾਬ ਦੇਣਾ ਬੰਦ ਕਰਨ 'ਤੇ ਆਪਣੀ ਸੇਵਾ ਨੂੰ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦਾ ਸੀ। ਨਵੀਂ ਸੇਵਾ ਪੁਰਾਣੀ ਵਾਲੀ ਨਾਲ Conflicts= ਘੋਸ਼ਿਤ ਕਰਦੀ ਹੈ, ਇਸ ਲਈ ਉਹ ਰੀਸਟਾਰਟ ਨਵੀਂ ਕਾਪੀ ਨੂੰ ਰੋਕ ਸਕਦਾ ਸੀ। ਇਸ ਨੂੰ ਸਿਰਫ਼ ਰੋਕਣ ਦੀ ਬਜਾਏ systemctl disable --now ਨਾਲ ਬੰਦ ਕਰਨਾ ਪਿਆ, ਕਿਉਂਕਿ ਸਾਡਾ ਓਪਸ ਲੇਅਰ ਉਹਨਾਂ ਯੂਨਿਟਸ ਨੂੰ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦਾ ਹੈ ਜੋ ਇਨੇਬਲਡ ਹਨ ਪਰ ਚੱਲ ਨਹੀਂ ਰਹੇ।
5. ਉਸ ਮਸ਼ੀਨ 'ਤੇ ਮੈਮੋਰੀ ਜੋ ਹੋਰ ਕੰਮ ਵੀ ਕਰਦੀ ਹੈ। ਇੱਕ ਮਸ਼ੀਨ ਸਾਡੇ ਡੇਟਾਬੇਸ ਅਤੇ ਸਾਈਟ ਬਿਲਡ ਵੀ ਚਲਾਉਂਦੀ ਹੈ। vLLM ਦੇ gpu-memory-utilization ਨੂੰ 0.78 'ਤੇ ਰੱਖਣ ਨਾਲ, ਬਾਕੀ ਸਾਰੇ ਕੰਮਾਂ ਲਈ ਸਿਰਫ਼ 5 GiB ਬਚੇ ਸਨ, ਇਸ ਲਈ ਅਸੀਂ ਇਸ ਨੂੰ 0.74 'ਤੇ ਘਟਾ ਦਿੱਤਾ ਅਤੇ ਸਿਰਫ਼ ਉਸੇ ਕਾਪੀ ਨੂੰ ਰੀਸਟਾਰਟ ਕੀਤਾ ਜਦੋਂ ਕਿ ਦੂਜੀ ਕਾਪੀ ਲੋਡ ਸੰਭਾਲ ਰਹੀ ਸੀ। ਇਹਨਾਂ ਮਸ਼ੀਨਾਂ 'ਤੇ, ਤੁਸੀਂ vLLM ਨੂੰ ਜਿੰਨੀ ਮੈਮੋਰੀ ਦਿੰਦੇ ਹੋ, ਉਹ ਬਾਕੀ ਸਾਰੇ ਕੰਮਾਂ ਵਾਲੀ ਮੈਮੋਰੀ ਵਿੱਚੋਂ ਹੀ ਆਉਂਦੀ ਹੈ।

ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਇਹਨਾਂ ਵਿੱਚੋਂ ਦੋ ਮਸ਼ੀਨਾਂ ਹਨ

• ਜੇ ਮਾਡਲ ਅਤੇ ਤੁਹਾਨੂੰ ਚਾਹੀਦਾ ਕੈਸ਼ ਇੱਕ ਮਸ਼ੀਨ 'ਤੇ ਫਿੱਟ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਹਰੇਕ 'ਤੇ ਇੱਕ ਕਾਪੀ ਚਲਾਓ ਅਤੇ ਉਹਨਾਂ ਨੂੰ least-connection proxy ਦੇ ਪਿੱਛੇ ਰੱਖੋ। ਮਾਡਲ ਨੂੰ ਸਿਰਫ਼ ਤਦ ਵੰਡੋ ਜਦੋਂ ਇੱਕ ਮਸ਼ੀਨ ਤੁਹਾਨੂੰ ਚਾਹੀਦਾ ਕੈਸ਼ ਸੰਭਾਲ ਨਾ ਸਕੇ।
• ਹਰੇਕ ਕਲਾਇੰਟ ਨੂੰ proxy ਵੱਲ ਨਿਰਦੇਸ਼ਿਤ ਕਰੋ, ਜਿਸ ਵਿੱਚ ਬੈਚ ਜੌਬਸ ਅਤੇ ਪੁਰਾਣੇ configs ਸ਼ਾਮਲ ਹਨ।
• ਹਰੇਕ ਕਾਪੀ ਤੋਂ ਸਿੱਧੇ metrics ਪੜ੍ਹੋ।
• ਹਰੇਕ ਮਸ਼ੀਨ ਨੂੰ ਉਸਦਾ ਆਪਣਾ ਮੈਮੋਰੀ ਹਿੱਸਾ ਦਿਓ, ਇਹ ਦੇਖਦੇ ਹੋਏ ਕਿ ਉਸ 'ਤੇ ਹੋਰ ਕੀ ਚੱਲ ਰਿਹਾ ਹੈ।
• ਤੁਹਾਡੇ ਆਪਣੇ ਟ੍ਰੈਫਿਕ ਦੇ ਅਧਾਰ 'ਤੇ ਤੈਅ ਕਰੋ ਕਿ ਇੱਕ ਕਾਪੀ ਇੱਕ ਸਮੇਂ ਕਿੰਨੇ requests ਸੰਭਾਲਦੀ ਹੈ: ਸਾਡੇ ਮਿਸ਼ਰਣ ਲਈ, 12 ਨੇ 8 ਨੂੰ ਹਰਾਇਆ।
• ਉਮੀਦ ਕਰੋ ਕਿ ਸਵਿੱਚ ਕਰਨ ਵਿੱਚ ਮਾਡਲ ਉੰਨੇ ਸਮੇਂ ਲਈ ਗਾਇਬ ਰਹੇਗਾ ਜਿੰਨਾ ਸਮਾਂ ਇੱਕ ਕਾਪੀ ਨੂੰ ਸ਼ੁਰੂ ਹੋਣ ਵਿੱਚ ਲੱਗਦਾ ਹੈ, ਅਤੇ ਇਸ ਲਈ ਯੋਜਨਾ ਬਣਾਓ।

Factory Floor ਇੱਕ ਜਾਂ ਦੋ ਮਸ਼ੀਨਾਂ ਲਈ proxy ਅਤੇ launch configs, ਹੈਲਥ ਚੈੱਕ ਅਤੇ ਮਾਡਲ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਚਲਾਈ ਜਾਣ ਵਾਲੀ tool-use ਟੈਸਟ, ਨਾਲ ਹੀ ਬਾਕੀ ਮਸ਼ੀਨ ਲਈ ਵਾਚਡੌਗ ਅਤੇ ਮੈਮੋਰੀ ਗਾਰਡ ਲੈ ਕੇ ਆਉਂਦਾ ਹੈ।