ਬਿੱਲ ਕਿਉਂ ਅਚਾਨਕ ਵਧ ਗਿਆ

ਜਦੋਂ ਟੀਮ ਨੇ ਪਹਿਲੀ ਵਾਰ generative AI ਜੋੜਿਆ, ਤਾਂ ਉਨ੍ਹਾਂ ਨੇ ਹਰ ਯੂਜ਼ਰ ਰਿਕਵੈਸਟ ਨੂੰ ਸਭ ਤੋਂ ਨਵੇਂ ਅਤੇ ਸਭ ਤੋਂ ਸਮਰੱਥ ਮਾਡਲ ਕੋਲ ਭੇਜ ਦਿੱਤਾ। ਜਿਵੇਂ-ਜਿਵੇਂ ਟ੍ਰੈਫਿਕ ਵਧਿਆ, ਪ੍ਰਤੀ-ਰਿਕਵੈਸਟ ਲਾਗਤ ਵੀ ਉਸੇ ਰਫਤਾਰ ਨਾਲ ਵਧਦੀ ਗਈ, ਅਤੇ CFO ਦੀ ਸਪ੍ਰੈਡਸ਼ੀਟ ਨੇ ਦਿਖਾਇਆ ਕਿ ਖਰਚਾ ਯੂਜ਼ਰਾਂ ਦੀ ਵਾਧੇ ਦੀ ਰਫਤਾਰ ਤੋਂ ਵੀ ਤੇਜ਼ੀ ਨਾਲ ਵਧ ਰਿਹਾ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ ਵਰਤਿਆ ਜਾਣ ਵਾਲਾ ਤੁਰੰਤ ਹੱਲ—"ਬੱਸ ਇੱਕ ਸਸਤਾ ਮਾਡਲ ਵਰਤੋ"—ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਅਸਫਲ ਰਹਿੰਦਾ ਹੈ ਕਿਉਂਕਿ ਵੱਖ-ਵੱਖ ਕੁਐਰੀਆਂ (queries) ਨੂੰ ਵੱਖ-ਵੱਖ ਤਰ੍ਹਾਂ ਦੀ ਤਰਕ ਸ਼ਕਤੀ (reasoning levels) ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਅਸਲ ਕੁੰਜੀ ਇਹ ਹੈ ਕਿ ਰਿਕਵੈਸਟ ਕਿਵੇਂ ਭੇਜੀ ਜਾਂਦੀ ਹੈ, ਨਾ ਕਿ ਹਮੇਸ਼ਾ ਕਿਹੜਾ ਮਾਡਲ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।

ਪੈਸੇ ਬਚਾਉਣ ਵਾਲਾ ਇੱਕ ਰੂਟਿੰਗ ਲੇਅਰ (routing layer) ਬਣਾਉਣਾ

ਇੰਜੀਨੀਅਰ ਨੇ inference service ਨੂੰ ਕਿਸੇ ਹੋਰ ਪ੍ਰੋਡਕਸ਼ਨ ਕੰਪੋਨੈਂਟ ਵਾਂਗ ਹੀ ਮੰਨਿਆ: ਟਾਇਅਰ (tiers) ਤੈਅ ਕੀਤੇ, SLAs ਸੈੱਟ ਕੀਤੇ, ਅਤੇ latency budgets ਨੂੰ ਲਾਗੂ ਕੀਤਾ। ਇਸ ਤੋਂ ਬਾਅਦ ਤਿਆਰ ਹੋਏ ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ ਚਾਰ ਹਿੱਸੇ ਹਨ ਜੋ ਮਿਲ ਕੇ 95% ਦੀ ਕਮੀ ਲਿਆਉਂਦੇ ਹਨ।

ਟਾਇਰਡ ਰੂਟਿੰਗ (Tiered routing)

ਇੱਕ ਹਲਕਾ ਫਰੰਟ-ਐਂਡ ਹਰੇਕ ਆਉਣ ਵਾਲੀ ਰਿਕਵੈਸਟ ਨੂੰ ਮੁਸ਼ਕਲ ਦੇ ਅਧਾਰ 'ਤੇ ਕਲਾਸੀਫਾਈ ਕਰਦਾ ਹੈ। ਲਗਭਗ 95% ਕੁਐਰੀਆਂ ਇੱਕ "ਸਸਤੇ" ਟਾਇਰ ਵਿੱਚ ਜਾਂਦੀਆਂ ਹਨ ਜੋ ਇੱਕ ਸਾਧਾਰਨ ਮਾਡਲ ਚਲਾਉਂਦਾ ਹੈ; ਸਿਰਫ਼ ਸਭ ਤੋਂ ਔਖੀਆਂ 5% ਕੁਐਰੀਆਂ ਨੂੰ ਹੀ ਪ੍ਰੀਮੀਅਮ ਮਾਡਲ ਕੋਲ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ। ਇਹ ਕਲਾਸੀਫਿਕੇਸ਼ਨ ਨਿਯਮ-ਅਧਾਰਤ (ਜਿਵੇਂ ਕਿ ਲੰਬਾਈ, ਡੋਮੇਨ-ਵਿਸ਼ੇਸ਼ ਕੀਵਰਡਾਂ ਦੀ ਮੌਜੂਦਗੀ) ਹੋ ਸਕਦੀ ਹੈ ਜਾਂ ਪੁਰਾਣੇ ਡੇਟਾ ਤੋਂ ਸਿੱਖੀ ਹੋਈ ਹੋ ਸਕਦੀ ਹੈ। ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ ਘੱਟ-ਲਾਗਤ ਵਾਲੇ ਟਾਇਰ ਦੀ ਵਰਤੋਂ ਕਰਨ ਨਾਲ, ਚੈਟਬੋਟ ਦਾ ਮਹੀਨਾਵਾਰ ਖਰਚਾ $420 ਤੋਂ ਘਟ ਕੇ $28 ਰਹਿ ਗਿਆ।

ਮਾਡਲ ਰਾਈਟ-ਸਾਈਜ਼ਿੰਗ (Model right-sizing)

ਕਾਰਜ ਦੀ ਗੁੰਝਲਤਾ ਦੇ ਅਨੁਸਾਰ ਮਾਡਲ ਦੀ ਸਮਰੱਥਾ ਦਾ ਮੇਲ ਕਰਨਾ ਸਭ ਤੋਂ ਵੱਧ ਬਚਤ ਕਰਦਾ ਹੈ:

  • ਸਧਾਰਨ ਚੈਟ (Simple chat) – ਫਲੈਗਸ਼ਿਪ ਮਾਡਲ ਦੀ ਬਜਾਏ ਇੱਕ ਹਲਕਾ (lightweight) ਮਾਡਲ ਵਰਤੋ (97.5% ਬਚਤ)।
  • ਕਲਾਸੀਫਿਕੇਸ਼ਨ (Classification) – ਮਿਡ-ਸਾਈਜ਼ ਮਾਡਲ ਦੀ ਜਗ੍ਹਾ ਇੱਕ ਸਸਟੇ ਵਿਕਲਪ ਦੀ ਵਰਤੋਂ ਕਰੋ (98.3% ਬਚਤ)।
  • ਸਮਰੀਜ਼ੇਸ਼ਨ (Summarization) – ਟਾਪ-ਟਾਇਰ ਮਾਡਲ ਦੀ ਜਗ੍ਹਾ ਮਿਡ-ਰੇਂਜ ਮਾਡਲ ਦੀ ਵਰਤੋਂ ਕਰੋ (97.2% ਬਚਤ)।

ਮਾਡਲਾਂ ਦੇ ਸਹੀ ਨਾਮ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਹਨ; ਸਿਧਾਂਤ ਇਹ ਹੈ ਕਿ ਸਭ ਤੋਂ ਸਮਰੱਥ ਮਾਡਲ ਨੂੰ ਸਿਰਫ਼ ਉਨ੍ਹਾਂ ਕੁਝ ਕੁਐਰੀਆਂ ਲਈ ਰਾਖਵਾਂ ਰੱਖਿਆ ਜਾਵੇ ਜਿਨ੍ਹਾਂ ਨੂੰ ਸੱਚਮੁੱਚ ਇਸਦੀ ਲੋੜ ਹੈ।

ਸਮਾਰਟ ਕੈਸ਼ਿੰਗ (Smart caching)

ਹਰ ਕੈਸ਼ ਹਿੱਟ (cache hit) ਇੱਕ ਨੈੱਟਵਰਕ ਕਾਲ ਅਤੇ ਇੱਕ API ਚਾਰਜ ਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦਾ ਹੈ। ਇੱਕ ਡਿਸਟ੍ਰੀਬਿਊਟਡ Redis ਕੈਸ਼ ਸਫਲ ਜਵਾਬਾਂ ਦੇ ਨਾਲ-ਨਾਲ "ਨੈਗੇਟਿਵ" ਜਵਾਬ ("ਮੈਨੂੰ ਨਹੀਂ ਪਤਾ") ਨੂੰ ਵੀ ਸਟੋਰ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਉਹੀ ਅਣਉੱਤਰਿਤ ਸਵਾਲ ਦੁਬਾਰਾ ਆਉਂਦਾ ਹੈ, ਤਾਂ ਸਿਸਟਮ ਮਾਡਲ ਨੂੰ ਦੂਜੀ ਵਾਰ ਬੁਲਾਉਣ ਦੀ ਬਜਾਏ ਕੈਸ਼ ਕੀਤੇ ਹੋਏ "ਮੈਨੂੰ ਨਹੀਂ ਪਤਾ" ਜਵਾਬ ਨੂੰ ਵਾਪਸ ਕਰ ਦਿੰਦਾ ਹੈ। ਹਜ਼ਾਰਾਂ ਰਿਕਵੈਸਟਾਂ ਦੇ ਉੱਪਰ, ਇਹ ਇਕੱਲਾ ਹੀ ਬਿੱਲ ਵਿੱਚੋਂ ਇੱਕ ਵੱਡਾ ਹਿੱਸਾ ਘਟਾ ਦਿੰਦਾ ਹੈ।

ਪ੍ਰੋਂਪਟ ਕੰਪਰੈਸ਼ਨ (Prompt compression)

ਲੰਬੇ ਪ੍ਰੋਂਪਟ ਟੋਕਨ ਦੀ ਵਰਤੋਂ ਵਧਾਉਂਦੇ ਹਨ, ਜਿਸਦਾ ਸਿੱਧਾ ਅਸਰ ਲਾਗਤ 'ਤੇ ਪੈਂਦਾ ਹੈ। ਟੀਮ ਕਲਾਇੰਟ ਸਾਈਡ 'ਤੇ ਜਾਂ ਪ੍ਰੀ-ਪ੍ਰੋਸੈਸਿੰਗ ਸਟੈਪ ਵਿੱਚ ਇੱਕ ਸਸਤਾ ਸਮਰੀਜ਼ਰ ਚਲਾਉਂਦੀ ਹੈ, ਜੋ ਮਹਿੰਗੇ ਮਾਡਲ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ 2,000-ਟੋਕਨ ਦੇ ਕੰਟੈਕਸਟ ਨੂੰ ਘਟਾ ਕੇ ਲਗਭਗ 400 ਟੋਕਨ ਕਰ ਦਿੰਦੀ ਹੈ। ਟੋਕਨਾਂ ਦੀ ਇਹ ਕਮੀ ਸਾਰੀਆਂ ਰਿਕਵੈਸਟਾਂ ਵਿੱਚ ਗੁਣਾ ਹੋ ਜਾਂਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਅੰਤਮ-ਯੂਜ਼ਰ ਦੇ ਅਨੁਭਵ ਨੂੰ ਬਦਲੇ ਬਿਨਾਂ ਭਾਰੀ ਬਚਤ ਹੁੰਦੀ ਹੈ।

ਰਣਨੀਤਕ ਬੈਚਿੰਗ (Strategic batching)

ਬੈਚਿੰਗ ਕਈ ਸੁਤੰਤਰ ਰਿਕਵੈਸਟਾਂ ਨੂੰ ਇੱਕ ਸਿੰਗਲ API ਕਾਲ ਵਿੱਚ ਇਕੱਠਾ ਕਰਦੀ ਹੈ। ਇਸ ਦਾ ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ ਹੈ: ਜੇਕਰ ਕੋਈ ਯੂਜ਼ਰ ਜਵਾਬ ਦੀ ਉਡੀਕ ਕਰ ਰਿਹਾ ਹੈ, ਤਾਂ ਬੈਚਿੰਗ ਨਾ ਕਰੋ; ਜੇਕਰ ਰਿਕਵੈਸਟ ਬੈਕਗ੍ਰਾਊਂਡ ਵਿੱਚ ਚੱਲ ਰਹੀ ਹੈ (ਰਾਤ ਦੀਆਂ ਰਿਪੋਰਟਾਂ, ਸ਼ਡਿਊਲ ਕੀਤੇ ਕੰਮ), ਤਾਂ ਸਭ ਕੁਝ ਬੈਚ ਕਰ ਦਿਓ। ਸਿਰਫ਼ ਰਾਤ ਦੇ ਸਮੇਂ ਵਾਲੇ ਬੈਚ ਜੌਬਸ ਹੀ ਖਰਚੇ ਵਿੱਚ ਹੋਰ 10-20% ਦੀ ਕਮੀ ਲਿਆਉਂਦੇ ਹਨ।

ਆਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਲੂਪ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨਾ

ਤੁਸੀਂ ਉਸ ਚੀਜ਼ ਨੂੰ ਸੁਧਾਰ ਨਹੀਂ ਸਕਦੇ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਮਾਪਦੇ ਨਹੀਂ ਹੋ। ਇੰਜੀਨੀਅਰ ਨੇ ਚਾਰ ਹਫ਼ਤਾਵਾਰੀ ਮੈਟ੍ਰਿਕਸ ਸੈੱਟ ਕੀਤੇ:

  1. ਟਾਇਰ ਅਨੁਸਾਰ ਪ੍ਰਤੀ ਰਿਕਵੈਸਟ ਖਰਚਾ।
  2. ਹਰੇਕ ਰੂਟਿੰਗ ਪਾਥ ਲਈ ਕੈਸ਼-ਹਿੱਟ ਰੇਟ।
  3. ਸਸਤੇ ਤੋਂ ਪ੍ਰੀਮੀਅਮ ਟਾਇਰਾਂ ਵਿੱਚ ਐਸਕਲੇਸ਼ਨ ਰੇਟ।
  4. ਪ੍ਰਤੀ ਗਾਹਕ ਸੈਗਮੈਂਟ ਖਰਚਾ।

ਇਹ ਅੰਕੜੇ ਬਦਲਾਅ (drift) ਨੂੰ ਸਾਹਮਣੇ ਲਿਆਉਂਦੇ ਹਨ—ਉਦਾਹਰਨ ਲਈ, ਵਧ ਰਿਹਾ ਐਸਕਲੇਸ਼ਨ ਰੇਟ ਇਹ ਸੰਕੇਤ ਦੇ ਸਕਦਾ ਹੈ ਕਿ ਕਲਾਸੀਫਿਕੇਸ਼ਨ ਲੌਜਿਕ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਖ਼ਤ ਹੈ ਜਾਂ ਸਸਤੇ ਮਾਡਲ ਦੀ ਗੁਣਵੱਤਾ ਘਟ ਗਈ ਹੈ। ਟੀਮ ਹਰ ਹਫ਼ਤੇ ਥ੍ਰੈਸ਼ਹੋਲਡ (thresholds), ਮਾਡਲ ਅਸਾਈਨਮੈਂਟ ਅਤੇ ਕੈਸ਼ ਪਾਲਿਸੀਆਂ 'ਤੇ ਕੰਮ ਕਰਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਖਰਚੇ ਦੇ ਕੰਟਰੋਲ ਨੂੰ ਸੰਕਟ ਦੀ ਪ੍ਰਤੀਕਿਰਿਆ ਦੀ ਬਜਾਏ ਇੱਕ ਆਦਤ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।

ਮੁੱਖ ਸਿੱਖਿਆ (Takeaway)

ਇੱਕ ਅਨੁਸ਼ਾਸਿਤ ਰੂਟਿੰਗ ਲੇਅਰ ਜੋ ਰਿਕਵੈਸਟਾਂ ਨੂੰ ਕਲਾਸੀਫਾਈ ਕਰਦੀ ਹੈ, ਮਾਡਲਾਂ ਨੂੰ ਸਹੀ ਸਾਈਜ਼ ਵਿੱਚ ਰੱਖਦੀ ਹੈ, ਤੇਜ਼ੀ ਨਾਲ ਕੈਸ਼ਿੰਗ ਕਰਦੀ ਹੈ, ਪ੍ਰੋਂਪਟ ਨੂੰ ਕੰਪਰੈਸ ਕਰਦੀ ਹੈ, ਅਤੇ ਬੈਕਗ੍ਰਾਊਂਡ ਕੰਮਾਂ ਨੂੰ ਬੈਚ ਕਰਦੀ ਹੈ, ਉਹ ਭਰੋਸੇਯੋਗਤਾ ਨੂੰ ਉੱਚਾ ਰੱਖਦੇ ਹੋਏ AI-API ਖਰਚੇ ਨੂੰ 95% ਤੱਕ ਘਟਾ ਸਕਦੀ ਹੈ। Inference stack ਨੂੰ ਇੱਕ ਪ੍ਰੋਡਕਸ਼ਨ ਸਰਵਿਸ ਵਾਂਗ ਮੰਨੋ: ਟਾਇਅਰ ਤੈਅ ਕਰੋ, ਨਤੀਜਿਆਂ ਨੂੰ ਮਾਪੋ, ਅਤੇ ਹਰ ਹਫ਼ਤੇ ਸੁਧਾਰ ਕਰੋ।