ਜਿਸ ਟੀਮ ਨੇ ਇੱਕ production-grade inference service ਬਣਾਈ ਸੀ, ਉਸਨੇ 48 ਘੰਟਿਆਂ ਲਈ DigitalOcean Inference 'ਤੇ ਛੇ ਭਾਸ਼ਾ ਮਾਡਲਾਂ (language models) ਨੂੰ ਚਲਾਇਆ। $0.20-ਪ੍ਰਤੀ-ਮਹੀਨਾ ਵਾਲੇ “tiny” ਮਾਡਲ ਨੇ ਮਹਿੰਗੇ ਵਿਕਲਪਾਂ ਨੂੰ ਪਛਾੜ ਦਿੱਤਾ। ਇਹ ਉਹਨਾਂ ਦੇ droplets ਦੀ 8 GB ਮੈਮੋਰੀ ਸੀਮਾ ਦੇ ਅੰਦਰ ਰਿਹਾ ਅਤੇ ਉਹਨਾਂ ਕ੍ਰੈਸ਼ਾਂ ਤੋਂ ਬਚਿਆ ਜਿਨ੍ਹਾਂ ਨੇ 70 B ਵੇਰੀਐਂਟ ਨੂੰ ਡਿਗੋਆ ਸੀ, ਜਿਸ ਨਾਲ ਬਹੁਤ ਘੱਟ ਲਾਗਤ 'ਤੇ ਵਰਤੋਂਯੋਗ latency ਅਤੇ accuracy ਪ੍ਰਦਾਨ ਕੀਤੀ।
ਇਹ ਟੈਸਟ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ
ਉਹ ਉੱਦਮ (Enterprises) ਜੋ large language models (LLMs) ਨੂੰ APIs ਵਜੋਂ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ, ਅਕਸਰ ਇਹ ਮੰਨ ਲੈਂਦੇ ਹਨ ਕਿ ਵੱਡੇ ਅਤੇ ਮਹਿੰਗੇ ਮਾਡਲ ਸਭ ਤੋਂ ਵਧੀਆ ਅਨੁਭਵ ਦੀ ਗਾਰੰਟੀ ਦਿੰਦੇ ਹਨ। ਅਸਲ ਵਿੱਚ, production ਵਾਤਾਵਰਣਾਂ ਨੂੰ ਮੈਮੋਰੀ, concurrency, ਅਤੇ uptime ਦੀਆਂ ਗਾਰੰਟੀਆਂ ਨੂੰ ਸੰਭਾਲਣਾ ਪੈਂਦਾ ਹੈ। ਇੱਕ ਮਾਡਲ ਜੋ ਕਾਗਜ਼ 'ਤੇ ਵਧੀਆ ਲੱਗਦਾ ਹੈ, ਉਹ ਉਦੋਂ ਇੱਕ ਦੇਣਦਾਰੀ (liability) ਬਣ ਸਕਦਾ ਹੈ ਜਦੋਂ ਇਹ out-of-memory (OOM) ਕ੍ਰੈਸ਼ ਕਰਦਾ ਹੈ ਜਾਂ cold starts ਦੌਰਾਨ ਸਰਵਿਸ ਨੂੰ ਰੋਕ ਦਿੰਦਾ ਹੈ। ਇਹ ਪ੍ਰੈਕਟੀਕਲ ਪ੍ਰਯੋਗ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਇੱਕ ਸਸਤਾ ਮਾਡਲ ਸੀਮਤ ਹਾਰਡਵੇਅਰ 'ਤੇ ਇਕਲੌਤਾ ਵਿਹਾਰਕ ਵਿਕਲਪ ਹੋ ਸਕਦਾ ਹੈ।
ਛੇ ਮੁਕਾਬਲੇਬਾਜ਼
| ਮਾਡਲ | ਮਹੀਨਾਵਾਰ ਲਾਗਤ | ਔਸਤ Latency | Accuracy* | RAM ਦੀ ਵਰਤੋਂ / ਕ੍ਰੈਸ਼ |
|---|---|---|---|---|
| mistral-tiny | $0.20 | 120 ms | 88 % | 1.2 GB |
| mistral-small | $0.80 | 180 ms | 91 % | 2.4 GB |
| mistral-medium | $2.50 | 250 ms | 93 % | 4.1 GB |
| mistral-large | $5.00 | 300 ms | 94 % | 6.8 GB |
| llama-70b | $8.00 | 450 ms | 95 % | CRASH |
| mixtral-8x7b | $10.00 | 500 ms | 96 % | CRASH |
*Accuracy ਟੀਮ ਦੇ ਅੰਦਰੂਨੀ benchmark suite 'ਤੇ ਮਾਡਲਾਂ ਦੇ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ।
“tiny” ਮਾਡਲ ਦੀ ਲਾਗਤ ਮਹੀਨਾਵਾਰ ਇੱਕ ਚੌਥੇ ਡਾਲਰ ਤੋਂ ਵੀ ਘੱਟ ਸੀ ਅਤੇ ਇਹ 8 GB ਮੈਮੋਰੀ ਦੀ ਸੀਮਾ ਦੇ ਅੰਦਰ ਰਿਹਾ। ਦੋ ਸਭ ਤੋਂ ਵੱਡੇ ਮਾਡਲ—llama-70b ਅਤੇ mixtral-8x7b—ਉਸ ਸੀਮਾ ਤੋਂ ਬਾਹਰ ਨਿਕਲ ਗਏ ਅਤੇ ਵਾਰ-ਵਾਰ ਹੋਸਟ ਨੂੰ ਕ੍ਰੈਸ਼ ਕਰ ਦਿੱਤਾ, ਜਿਸ ਕਾਰਨ ਉੱਚ accuracy ਸਕੋਰ ਦੇ ਬਾਵਜੂਦ ਉਹ ਵਰਤੋਂ ਯੋਗ ਨਹੀਂ ਰਹੇ।
ਉਹ ਮੁਸ਼ਕਲਾਂ ਜਿਨ੍ਹਾਂ ਨੇ ਵੱਡੇ ਮਾਡਲਾਂ ਨੂੰ ਡੁਬੋ ਦਿੱਤਾ
- Hard-coded endpoints – ਅਸਲ ਆਰਕੀਟੈਕਚਰ ਹਰ ਰਿਕਵੈਸਟ ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਮਾਡਲ ਨੂੰ ਭੇਜਦਾ ਸੀ। ਜਦੋਂ ਉਹ ਮਾਡਲ ਫੇਲ ਹੋ ਗਿਆ, ਤਾਂ ਪੂਰੀ API ਬੰਦ ਹੋ ਗਈ।
- No memory caps – ਵੱਡੇ ਮਾਡਲਾਂ ਨੇ ਸਾਰੀ ਉਪਲਬਧ RAM ਖਾ ਲਈ, ਜਿਸ ਨਾਲ ਬਿਨਾਂ ਕਿਸੇ ਚੇਤਾਵਨੀ ਦੇ OOM ਕ੍ਰੈਸ਼ ਹੋ ਗਏ।
- Cold-start latency – ਇੱਕ ਨਵੇਂ ਮਾਡਲ ਲਈ ਪਹਿਲੀ ਵਾਰ ਦੀਆਂ ਰਿਕਵੈਸਟਾਂ ਵਿੱਚ ਕਈ ਸਕਿੰਟ ਲੱਗ ਗਏ, ਜਿਸ ਨਾਲ ਪ੍ਰਤੀਕਿਰਿਆ ਦੀ ਗਤੀ (responsiveness) ਪ੍ਰਭਾਵਿਤ ਹੋਈ।
- Unbounded concurrency – ਇੱਕੋ ਸਮੇਂ ਆਈਆਂ ਰਿਕਵੈਸਟਾਂ ਦੀ ਭੀੜ ਨੇ ਮੈਮੋਰੀ ਅਤੇ CPU ਨੂੰ ਸੰਤੁਲਿਤ ਕਰ ਦਿੱਤਾ, ਜਿਸ ਨਾਲ ਸਿਸਟਮਿਕ ਫੇਲ੍ਹ ਹੋਣ ਦੀਆਂ ਸਥਿਤੀਆਂ ਬਣ ਗਈਆਂ।
ਜੇਕਰ ਸਰਵਿਸ ਅਸਲ ਲੋਡ ਦੇ ਹੇਠਾਂ ਆਨਲਾਈਨ ਨਹੀਂ ਰਹਿ ਸਕਦੀ, ਤਾਂ ਕੱਚੇ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਅੰਕੜਿਆਂ ਦਾ ਕੋਈ ਮਤਲਬ ਨਹੀਂ ਹੈ।
ਡਾਇਨਾਮਿਕ ਰੂਟਿੰਗ ਦਾ ਹੱਲ
ਇੰਜੀਨੀਅਰਾਂ ਨੇ ਤਿੰਨ ਸਿਧਾਂਤਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਰਿਕਵੈਸਟ ਪਾਥ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਿਆ:
- Runtime model selection – ਰੂਟਰ ਇੱਕ ਸਟੈਟਿਕ endpoint ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਬਜਾਏ ਹਰ ਰਿਕਵੈਸਟ ਲਈ ਇੱਕ ਮਾਡਲ ਚੁਣਦਾ ਹੈ।
- Hardware awareness – ਹਰ ਰਿਕਵੈਸਟ ਨੂੰ ਮੈਮੋਰੀ ਬਜਟ ਮਿਲਦਾ ਹੈ; ਰੂਟਰ ਸਿਰਫ਼ ਉਹਨਾਂ ਮਾਡਲਾਂ ਨੂੰ ਭੇਜਦਾ ਹੈ ਜੋ ਬਾਕੀ ਬਚੀ RAM ਵਿੱਚ ਫਿੱਟ ਹੋ ਸਕਦੇ ਹਨ।
- Fallback chains – ਜੇਕਰ ਚੁਣਿਆ ਗਿਆ ਮਾਡਲ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ ਜਾਂ ਟਾਈਮ-ਆਊਟ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਰੂਟਰ ਆਪਣੇ ਆਪ ਅਗਲੇ ਸਭ ਤੋਂ ਵਧੀਆ ਮਾਡਲ ਨਾਲ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ।
ਸੋਧੀ ਹੋਈ ਆਰਕੀਟੈਕਚਰ ਚਾਰ ਪੱਕੇ ਸੁਰੱਖਿਆ ਉਪਾਅ ਜੋੜਦੀ ਹੈ:
- Bounded concurrency – ਇੱਕ semaphore ਸਮਾਨਾਂਤਰ (parallel) inferences ਨੂੰ ਸੀਮਤ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਮੈਮੋਰੀ ਖਤਮ ਹੋਣ ਤੋਂ ਰੋਕਿਆ ਜਾ ਸਕਦਾ ਹੈ।
- Fail-fast timeouts – ਸਖ਼ਤ ਪ੍ਰਤੀ-ਰਿਕਵੈਸਟ ਟਾਈਮਰ ਹੌਲੀ ਮਾਡਲਾਂ ਨੂੰ ਪੂਰੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਰੋਕਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਰੋਕ ਦਿੰਦੇ ਹਨ।
- Memory buffers – ਸਿਸਟਮ droplet ਦੀ RAM 'ਤੇ 20% ਵਾਧੂ ਜਗ੍ਹਾ (headroom) ਰਾਖਵੀਂ ਰੱਖਦਾ ਹੈ, ਜੋ OS overhead ਅਤੇ ਅਚਾਨਕ ਵਾਧੇ (spikes) ਲਈ ਜਗ੍ਹਾ ਦੀ ਗਾਰੰਟੀ ਦਿੰਦਾ ਹੈ।
- Pre-warming – ਸ਼ੁਰੂਆਤ ਵੇਲੇ ਹਰੇਕ ਮਾਡਲ ਨੂੰ ਡਮੀ ਰਿਕਵੈਸਟਾਂ ਭੇਜੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਜਿਸ ਨਾਲ ਸ਼ੁਰੂਆਤੀ cold-start ਦੀ ਸਮੱਸਿਆ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ।
ਇਹਨਾਂ ਉਪਾਵਾਂ ਨੇ ਇੱਕ ਕਮਜ਼ੋਰ ਪਾਈਪਲਾਈਨ ਨੂੰ ਇੱਕ ਲਚਕਦਾਰ (resilient) ਸਰਵਿਸ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ ਜੋ ਬਹੁਤੀ accuracy ਨੂੰ ਗੁਆਏ ਬਿਨਾਂ 8 GB ਦੇ ਸਾਧਾਰਨ droplets 'ਤੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਸੰਭਾਲ ਸਕਦੀ ਹੈ।
ਅੱਗੇ ਕੀ ਦੇਖਣਾ ਹੈ
- Hardware scaling – ਜਿਵੇਂ-ਜਿਵੇਂ ਕਲਾਉਡ ਪ੍ਰੋਵਾਈਡਰ ਘੱਟ ਕੀਮਤਾਂ 'ਤੇ ਵੱਧ ਮੈਮੋਰੀ ਵਾਲੇ droplets ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦੇ ਹਨ, ਵੱਡੇ ਮਾਡਲਾਂ ਲਈ ਬ੍ਰੇਕ-ਈਵਨ (breakeven) ਬਿੰਦੂ ਬਦਲ ਸਕਦਾ ਹੈ।
- Model compression – Quantization ਜਾਂ knowledge distillation ਉੱਚ-accuracy ਵਾਲੇ ਮਾਡਲਾਂ ਦੇ RAM footprint ਨੂੰ ਘਟਾ ਸਕਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਉਹਨਾਂ ਨੂੰ ਛੋਟੀਆਂ ਮਸ਼ੀਨਾਂ 'ਤੇ ਚਲਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।
- Adaptive routing – ਭਵਿੱਖ ਦੇ ਰੂਟਰ ਅਸਲ ਸਮੇਂ (real time) ਵਿੱਚ ਸਿੱਖ ਸਕਦੇ ਹਨ ਕਿ ਕਿਸ ਮਾਡਲ ਨਾਲ ਦਿੱਤੀ ਗਈ ਕੁਐਰੀ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਸਮਝੌਤਾ (trade-off) ਮਿਲਦਾ ਹੈ, ਜਿਸ ਨਾਲ accuracy-cost ਸੰਤੁਲਨ ਹੋਰ ਵੀ ਆਟੋਮੇਟ ਹੋ ਜਾਵੇਗਾ।
ਸਿੱਖਿਆ ਸਧਾਰਨ ਹੈ: production ਵਿੱਚ, ਉਹ ਮਾਡਲ ਜੋ ਦਬਾਅ ਹੇਠ ਕੰਮ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ, ਉਸ ਮਾਡਲ ਨਾਲੋਂ ਵੱਧ ਮੁੱਲ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਜੋ ਕਾਗਜ਼ 'ਤੇ ਸਭ ਤੋਂ ਵਧੀਆ ਲੱਗਦਾ ਹੈ। ਸਿਰਫ਼ headline accuracy ਦੇ ਆਧਾਰ 'ਤੇ ਨਹੀਂ, ਸਗੋਂ ਆਪਣੀਆਂ ਤੈਨਾਤੀ (deployment) ਦੀਆਂ ਸੀਮਾਵਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਮਾਡਲ ਦੀ ਚੋਣ ਕਰੋ।