ਸਾਡੇ ਹੈਲਥ ਚੈੱਕ ਨੇ ਇੱਕ ਦਿਨ ਵਿੱਚ ਇੱਕ ਸਿਹਤਮੰਦ ਮਾਡਲ ਸਰਵਰ ਨੂੰ ਅੱਠ ਵਾਰ ਰੀਸਟਾਰਟ ਕੀਤਾ
Ops
22 ਜੁਲਾਈ ਨੂੰ ਇੱਕ ਵਾਚਡੌਗ ਨੇ ਸਾਡੇ ਲੋਕਲ ਮਾਡਲ ਸਰਵਰ ਨੂੰ ਅੱਠ ਵਾਰ ਰੀਸਟਾਰਟ ਕੀਤਾ। ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਵੀ ਰੀਸਟਾਰਟ ਪਿੱਛੇ ਕੋਈ ਕ੍ਰੈਸ਼ ਨਹੀਂ ਸੀ। ਉਹ ਚੈੱਕ ਜੋ ਮਾਡਲ ਨੂੰ ਚਾਲੂ ਰੱਖਣ ਲਈ ਬਣਾਇਆ ਗਿਆ ਸੀ, ਉਹੀ ਉਸਨੂੰ ਬੰਦ ਕਰ ਰਿਹਾ ਸੀ।
ਕੀ ਹੋਇਆ
ਮਾਡਲ ਸਰਵਰ ਇੱਕ NVIDIA GB10 ਮਸ਼ੀਨ 'ਤੇ vLLM ਚਲਾਉਂਦਾ ਸੀ ਅਤੇ ਇੱਕ ਸਿੰਗਲ ਰਿਕਵੈਸਟ ਲਈ ਲਗਭਗ 8 ਟੋਕਨ ਪ੍ਰਤੀ ਸਕਿੰਟ ਪੈਦਾ ਕਰਦਾ ਸੀ। ਹਰ ਪੰਜ ਮਿੰਟਾਂ ਬਾਅਦ ਇੱਕ ਵਾਚਡੌਗ ਇਸਨੂੰ ਇੱਕ ਅਸਲੀ ਚੈਟ ਰਿਕਵੈਸਟ ਭੇਜਦਾ ਸੀ ਅਤੇ ਜਵਾਬ ਲਈ 45 ਸਕਿੰਟ ਤੱਕ ਦਾ ਇੰਤਜ਼ਾਰ ਕਰਦਾ ਸੀ। ਲਗਾਤਾਰ ਪੰਜ ਅਸਫਲ ਚੈੱਕ ਦਾ ਮਤਲਬ ਸੀ ਕਿ ਸਰਵਰ ਹੈਂਗ ਹੋ ਗਿਆ ਹੈ, ਅਤੇ ਵਾਚਡੌਗ ਇਸਨੂੰ ਰੀਸਟਾਰਟ ਕਰ ਦਿੰਦਾ ਸੀ। ਇੱਕ ਰੀਸਟਾਰਟ ਨਾਲ ਮਾਡਲ ਕਈ ਮਿੰਟਾਂ ਲਈ ਬੰਦ ਹੋ ਜਾਂਦਾ ਸੀ ਜਦੋਂ ਲਗਭਗ 19 GB ਦੇ ਵੇਟਸ ਦੁਬਾਰਾ ਲੋਡ ਹੁੰਦੇ ਸਨ।
ਉਸ ਦਿਨ ਇੱਕ ਬੈਚ ਜੌਬ ਸਰਵਰ 'ਤੇ ਇੱਕੋ ਸਮੇਂ ਦੋ ਤੋਂ ਚਾਰ ਰਿਕਵੈਸਟਾਂ ਨੂੰ ਮਿੰਟਾਂ ਤੱਕ ਬਿਜ਼ੀ ਰੱਖਦੀ ਸੀ। ਵਾਚਡੌਗ ਦਾ ਰਿਕਵੈਸਟ ਉਨ੍ਹਾਂ ਦੇ ਪਿੱਛੇ ਕਤਾਰ ਵਿੱਚ ਇੰਤਜ਼ਾਰ ਕਰਦਾ ਸੀ, ਸਮਾਂ ਖਤਮ ਹੋ ਜਾਂਦਾ ਸੀ, ਅਤੇ ਇੱਕ ਅਸਫਲਤਾ ਵਜੋਂ ਗਿਣਿਆ ਜਾਂਦਾ ਸੀ। ਅਜਿਹੇ ਪੰਜ ਚੈੱਕਾਂ ਤੋਂ ਬਾਅਦ, ਇੱਕ ਸਿਹਤਮੰਦ ਸਰਵਰ ਰੀਸਟਾਰਟ ਹੋ ਗਿਆ ਸੀ। ਸਾਡੇ ਕੋਲ ਇੱਕ "busy" ਫਲੈਗ ਫਾਈਲ ਸੀ ਜਿਸਦਾ ਵਾਚਡੌਗ ਪਾਲਣ ਕਰਦਾ ਸੀ, ਪਰ ਬੈਚ ਜੌਬ ਨੇ ਕਦੇ ਵੀ ਇਸਨੂੰ ਸੈੱਟ ਨਹੀਂ ਕੀਤਾ ਸੀ।
ਇੱਕ ਝੂਠਾ ਰੀਸਟਾਰਟ ਅਗਲੇ ਵੱਲ ਕਿਵੇਂ ਲੈ ਗਿਆ
ਹਰ ਰੀਸਟਾਰਟ ਨੇ ਚੱਲ ਰਹੇ ਰਿਕਵੈਸਟਾਂ ਨੂੰ 500 ਐਰਰ ("cannot schedule new futures after shutdown") ਨਾਲ ਫੇਲ੍ਹ ਕਰ ਦਿੱਤਾ। ਇੱਕ ਦੂਜੇ ਵਾਚਡੌਗ ਨੇ 500 ਐਰਰਾਂ ਦੀ ਗਿਣਤੀ ਕੀਤੀ ਅਤੇ ਜਦੋਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੋ ਗਏ ਤਾਂ ਸਰਵਰ ਨੂੰ ਰੀਸਟਾਰਟ ਕਰ ਦਿੱਤਾ, ਅਤੇ ਜਿੰਨੇ ਵੱਧ ਐਰਰ ਇਸਨੂੰ ਦਿਖਾਈ ਦਿੰਦੇ, ਇਹ ਓਨੀ ਜਲਦੀ ਕਾਰਵਾਈ ਕਰਦਾ। ਇਸ ਲਈ ਹਰ ਝੂਠਾ ਰੀਸਟਾਰਟ ਅਗਲੇ ਰੀਸਟਾਰਟ ਨੂੰ ਹੋਰ ਜਲਦੀ ਲਿਆਉਂਦਾ ਸੀ। ਕੁੱਲ ਮਿਲਾ ਕੇ, ਚਾਰ ਵੱਖ-ਵੱਖ ਵਾਚਡੌਗ ਉਸ ਸਰਵਰ ਨੂੰ 5, 10, 15 ਅਤੇ 30 ਮਿੰਟਾਂ ਦੇ ਟਾਈਮਰਾਂ 'ਤੇ ਰੀਸਟਾਰਟ ਕਰ ਸਕਦੇ ਸਨ।
ਉਸ ਤੋਂ ਸਾਡੇ ਦੁਆਰਾ ਅਪਣਾਇਆ ਗਿਆ ਨਿਯਮ
ਇੱਕ ਹੈਲਥ ਚੈੱਕ ਨੂੰ ਉਸ ਚੀਜ਼ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਨੀ ਚਾਹੀਦੀ ਜਿਸਦੀ ਉਹ ਰੱਖਿਆ ਕਰਦਾ ਹੈ। ਇੱਕ ਮਾਡਲ ਸਰਵਰ ਦਾ ਘੱਟ ਸਰੋਤ ਚੱਲ ਰਹੇ ਰਿਕਵੈਸਟਾਂ ਲਈ ਉਸਦੇ ਸਲਾਟ ਹਨ। ਇੱਕ ਚੈੱਕ ਜੋ ਉਨ੍ਹਾਂ ਸਲਾਟਾਂ ਵਿੱਚੋਂ ਇੱਕ ਲੈਂਦਾ ਹੈ, ਜਾਂ ਇੱਕ ਦਾ ਇੰਤਜ਼ਾਰ ਕਰਦਾ ਹੈ, ਉਹ ਭਾਰ ਦਾ ਹਿੱਸਾ ਬਣ ਜਾਂਦਾ ਹੈ ਜਿਸਦਾ ਉਹ ਫੈਸਲਾ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ। ਸਸਤਾ ਚੈੱਕ ਕਰੋ, ਅਤੇ ਸਿਰਫ਼ ਤਦ ਹੀ ਰੀਸਟਾਰਟ ਕਰੋ ਜਦੋਂ ਤੁਸੀਂ ਦਿਖਾ ਸਕੋ ਕਿ ਸਰਵਰ ਹੈਂਗ ਹੋ ਗਿਆ ਹੈ।
ਉਹ ਚੈੱਕ ਜਿਸਨੇ ਇਸਦੀ ਥਾਂ ਲਈ
vLLM /metrics 'ਤੇ ਆਪਣੇ ਕਾਊਂਟਰ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਨਵਾਂ ਚੈੱਕ ਪਹਿਲਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ:
- ਚੱਲ ਰਹੇ ਰਿਕਵੈਸਟ ਅਤੇ ਅੱਗੇ ਵਧ ਰਿਹਾ ਇੰਜਣ: ਸਿਹਤਮੰਦ ਅਤੇ ਬਿਜ਼ੀ। ਕੋਈ ਟੈਸਟ ਰਿਕਵੈਸਟ ਨਹੀਂ ਭੇਜਿਆ ਜਾਂਦਾ।
- ਦੋ ਪੜ੍ਹਾਈਆਂ ਦੇ ਵਿਚਕਾਰ ਚੱਲ ਰਹੇ ਰਿਕਵੈਸਟ ਅਤੇ ਕੋਈ ਪ੍ਰਗਤੀ ਨਹੀਂ: ਹੈਂਗ। ਇਹ ਉਹ ਕੇਸ ਹੈ ਜੋ ਅਜੇ ਵੀ ਰੀਸਟਾਰਟ ਕਰਦਾ ਹੈ।
- ਕੁਝ ਵੀ ਚੱਲ ਨਹੀਂ ਰਿਹਾ: ਆਈਡਲ। ਸਿਰਫ਼ ਤਦ ਹੀ ਚੈੱਕ ਇੱਕ ਛੋਟਾ ਜਵਾਬ ਮੰਗਦਾ ਹੈ, ਜੋ ਇੱਕ ਆਈਡਲ ਇੰਜਣ ਤੁਰੰਤ ਦੇ ਦਿੰਦਾ ਹੈ।
ਪਹਿਲੇ ਵਰਜਨ ਨੇ ਪੈਦਾ ਕੀਤੇ ਗਏ ਟੋਕਨਾਂ ਨੂੰ ਪ੍ਰਗਤੀ ਵਜੋਂ ਗਿਣਿਆ। ਇਹ ਅੱਠ ਟੈਸਟ ਪਾਸ ਕਰ ਗਿਆ, ਅਤੇ ਆਪਣੇ ਪਹਿਲੇ ਲਾਈਵ ਰਨ ਵਿੱਚ ਇਸਨੇ ਸਰਵਰ ਨੂੰ ਬਿਜ਼ੀ ਅਤੇ ਸਿਹਤਮੰਦ ਪਾਇਆ: 2 ਰਿਕਵੈਸਟ ਚੱਲ ਰਹੇ ਸਨ, ਦੋ ਪੜ੍ਹਾਈਆਂ ਦੇ ਵਿਚਕਾਰ 107 ਨਵੇਂ ਟੋਕਨ ਸਨ।
ਉਸ ਤੋਂ ਬਾਅਦ ਅਸੀਂ ਕੀ ਬਦਲਿਆ
- ਇੰਜਣ ਦੇ ਸਟੈਪ, ਆਊਟਪੁੱਟ ਟੋਕਨ ਨਹੀਂ। ਜਦੋਂ vLLM ਇੱਕ ਲੰਬੇ ਪ੍ਰੌਂਪਟ ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ, ਤਾਂ ਉਹ ਕੁਝ ਸਮੇਂ ਲਈ ਕੋਈ ਆਊਟਪੁੱਟ ਟੋਕਨ ਪੈਦਾ ਨਹੀਂ ਕਰਦਾ ਪਰ ਫਿਰ ਵੀ ਸਟੈਪ ਲੈਂਦਾ ਰਹਿੰਦਾ ਹੈ। ਸਟੈਪਾਂ ਦੀ ਗਿਣਤੀ ਕਰਨ ਨਾਲ (vllm:iteration_tokens_total ਦੀ ਗਿਣਤੀ) ਇਹ ਯਕੀਨੀ ਬਣਦਾ ਹੈ ਕਿ ਲੰਬਾ ਪ੍ਰੌਂਪਟ ਫਸੇ ਹੋਏ ਸਰਵਰ ਵਾਂਗ ਨਾ ਦਿਖਾਈ ਦੇਵੇ।
- "ਫਸੇ ਹੋਏ" ਮੰਨਣ ਤੋਂ ਪਹਿਲਾਂ ਦੋ ਵਾਰੀ ਇੰਤਜ਼ਾਰ, ਤਾਂ ਜੋ ਛੋਟਾ ਵਿਰਾਮ ਅਸਫਲਤਾ ਵਜੋਂ ਨਾ ਗਿਣਿਆ ਜਾਵੇ।
- ਦੋ ਪੜ੍ਹਾਈਆਂ ਦੇ ਵਿਚਕਾਰ ਹੋਣ ਵਾਲੀ ਰੀਸਟਾਰਟ ਨੂੰ ਉਸੇ ਮੈਟ੍ਰਿਕਸ ਵਿੱਚ ਪ੍ਰੋਸੈਸ ਸ਼ੁਰੂਆਤ ਦੇ ਸਮੇਂ ਦੁਆਰਾ ਫੜਿਆ ਜਾਂਦਾ ਹੈ; ਚੈੱਕ ਫਿਰ ਦੋ ਵੱਖ-ਵੱਖ ਪ੍ਰੋਸੈਸਾਂ ਦੇ ਕਾਊਂਟਰਾਂ ਦੀ ਤੁਲਨਾ ਕਰਨ ਦੀ ਬਜਾਏ ਜਵਾਬ ਮੰਗਦਾ ਹੈ।
- ਇੱਕ ਪ੍ਰੌਕਸੀ ਨੂੰ ਸਿਰਫ਼ /models ਰਾਹੀਂ ਚੈੱਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਲੀਸਟ-ਕਨੈਕਸ਼ਨ ਪ੍ਰੌਕਸੀ ਦੇ ਪਿੱਛੇ, /metrics ਦੀ ਹਰ ਪੜ੍ਹਾਈ ਵੱਖ-ਵੱਖ ਬੈਕਐਂਡ ਤੋਂ ਆ ਸਕਦੀ ਹੈ, ਜਿਵੇਂ ਅਸੀਂ ਦੇਖਿਆ ਸੀ ਜਦੋਂ ਅਸੀਂ ਦੋ ਮਸ਼ੀਨਾਂ 'ਤੇ ਮਾਡਲ ਦੀ ਇੱਕ ਕਾਪੀ ਚਲਾਈ ਸੀ। ਬੈਕਐਂਡਾਂ ਨੂੰ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਚੈੱਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਫਰਕ ਸੌਖੀ ਤਰ੍ਹਾਂ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਜਦੋਂ ਅਸੀਂ ਇਹ ਨੋਟ ਲਿਖ ਰਹੇ ਸੀ, ਤਾਂ ਸਾਡੇ ਦੋਵੇਂ ਮਾਡਲ ਸਰਵਰ ਹਰੇਕ 12 ਰਿਕਵੈਸਟ ਚਲਾ ਰਹੇ ਸਨ, ਜੋ ਉਨ੍ਹਾਂ ਦੀ ਸੀਮਾ ਹੈ। ਇੱਕ ਟੈਸਟ ਰਿਕਵੈਸਟ ਕਤਾਰ ਵਿੱਚ ਇੰਤਜ਼ਾਰ ਕਰਦਾ। ਨਵੇਂ ਚੈੱਕ ਨੇ ਦੋਵਾਂ ਨੂੰ ਬਿਜ਼ੀ ਅਤੇ ਸਿਹਤਮੰਦ ਰਿਪੋਰਟ ਕੀਤਾ, 126 ਅਤੇ 101 ਟੋਕਨ ਪ੍ਰਤੀ ਸਕਿੰਟ 'ਤੇ, ਬਿਨਾਂ ਇੱਕ ਵੀ ਭੇਜੇ।
Factory Floor 1.0.2 ਇਸ ਚੈੱਕ ਨੂੰ models/llm-health.py ਵਜੋਂ ਸ਼ਿਪ ਕਰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਆਈਡਲ, ਬਿਜ਼ੀ, ਫਸੇ ਹੋਏ ਅਤੇ ਰੀਸਟਾਰਟ ਹੋਏ ਸਰਵਰਾਂ, ਬਿਨਾਂ ਮੈਟ੍ਰਿਕਸ ਵਾਲੇ ਸਰਵਰ, ਇੱਕ ਪ੍ਰੌਕਸੀ ਅਤੇ ਇੱਕ ਮਰੇ ਹੋਏ ਬੈਕਐਂਡ ਲਈ ਟੈਸਟ ਸ਼ਾਮਲ ਹਨ।