Microsoft ਨੇ Azure API Management (APIM) ਵਿੱਚ ਇੱਕ ਸਮਰਪਿਤ AI Gateway tier ਜੋੜਿਆ ਹੈ। ਇਹ ਕਦਮ ਸੰਕੇਤ ਦਿੰਦਾ ਹੈ ਕਿ LLM ਕਾਲਾਂ ਨੂੰ ਹੁਣ ਇੱਕ ਵੱਖਰੇ ਵਰਕਲੋਡ (workload) ਵਜੋਂ ਮੰਨਿਆ ਜਾ ਰਿਹਾ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਇੱਕ ਹੋਰ API endpoint ਵਜੋਂ।
ਕਿਉਂ LLM ਟ੍ਰੈਫਿਕ ਕਲਾਸਿਕ ਗੇਟਵੇਅਜ਼ ਨੂੰ ਖਰਾਬ ਕਰਦਾ ਹੈ
ਇੱਕ ਸਿੰਗਲ ਪ੍ਰੋਂਪਟ (prompt) ਦੀ ਕੀਮਤ ਦੂਜੇ ਨਾਲੋਂ ਸੌ ਗੁਣਾ ਜ਼ਿਆਦਾ ਹੋ ਸਕਦੀ ਹੈ, ਫਿਰ ਵੀ ਇੱਕ ਸਟੈਂਡਰਡ API gateway ਦੋਵਾਂ ਨੂੰ ਇੱਕੋ ਰੀਕੁਐਸਟ ਵਜੋਂ ਦੇਖਦਾ ਹੈ। ਗੇਟਵੇਅ ਕਾਲਾਂ ਦੀ ਗਿਣਤੀ ਕਰਦਾ ਹੈ, ਨਾ ਕਿ ਉਹਨਾਂ ਟੋਕਨਾਂ (tokens) ਦੀ ਗਿਣਤੀ ਜੋ ਮਾਡਲ ਪ੍ਰੋਸੈਸ ਕਰਦਾ ਹੈ। ਇੱਕ ਰੀਕੁਐਸਟ ਜੋ ਕੁਝ ਸੌ ਟੋਕਨ ਭੇਜਦੀ ਹੈ ਅਤੇ ਇੱਕ ਜੋ ਹਜ਼ਾਰਾਂ ਟੋਕਨ ਭੇਜਦੀ ਹੈ, ਦੋਵੇਂ ਇੱਕੋ ਜਿਹੇ request-count ਮੈਟ੍ਰਿਕਸ ਪੈਦਾ ਕਰਦੇ ਹਨ, ਭਾਵੇਂ ਕਿ ਦੂਜੀ ਰੀਕੁਐਸਟ ਦੀ ਲਾਗਤ ਕਈ ਗੁਣਾ ਜ਼ਿਆਦਾ ਹੋ ਸਕਦੀ ਹੈ।
ਚਾਰ ਤੱਥ ਰੀਕੁਐਸਟ-ਅਧਾਰਤ ਸੀਮਾਵਾਂ ਨੂੰ AI ਲਈ ਬੇਕਾਰ ਬਣਾਉਂਦੇ ਹਨ:
- ਲਾਗਤ ≠ ਰੀਕੁਐਸਟ ਦੀ ਗਿਣਤੀ। ਬਿਲਿੰਗ ਟੋਕਨਾਂ ਨਾਲ ਜੁੜੀ ਹੁੰਦੀ ਹੈ, ਨਾ ਕਿ ਇਸ ਨਾਲ ਕਿ ਤੁਸੀਂ ਕਿੰਨੀਆਂ HTTP ਕਾਲਾਂ ਕਰਦੇ ਹੋ।
- ਟੋਕਨ ਦੀ ਮਾਤਰਾ ਵਿੱਚ ਬਹੁਤ ਵਾਧਾ-ਘਾਟਾ ਹੋ ਸਕਦਾ ਹੈ। ਇੱਕ ਕੁਐਰੀ (query) ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਸਵਾਲ ਹੋ ਸਕਦੀ ਹੈ; ਦੂਜੀ ਵਿੱਚ ਇੱਕ ਲੰਬਾ ਦਸਤਾਵੇਜ਼ ਸ਼ਾਮਲ ਹੋ ਸਕਦਾ ਹੈ।
- ਮਾਡਲ ਦੀ ਚੋਣ ਕੀਮਤ ਬਦਲ ਦਿੰਦੀ ਹੈ। ਵੱਖ-ਵੱਖ LLMs ਪ੍ਰਤੀ ਟੋਕਨ ਵੱਖ-ਵੱਖ ਦਰਾਂ ਲੈਂਦੇ ਹਨ।
- ਸਟ੍ਰੀਮਿੰਗ ਅੰਤਿਮ ਬਿੱਲ ਨੂੰ ਲੁਕਾ ਲੈਂਦੀ ਹੈ। ਜਦੋਂ ਜਵਾਬ ਸਟ੍ਰੀਮ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਸਟ੍ਰੀਮ ਖਤਮ ਹੋਣ ਤੱਕ ਕੁੱਲ ਟੋਕਨ ਗਿਣਤੀ ਦਾ ਪਤਾ ਨਹੀਂ ਲੱਗਦਾ।
ਜੇਕਰ ਤੁਸੀਂ ਸਿਰਫ਼ ਰੀਕੁਐਸਟਾਂ ਨੂੰ ਮਾਪਦੇ ਰਹਿੰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਅਜਿਹਾ ਮਾਨੀਟਰਿੰਗ ਡੇਟਾ ਹੋਵੇਗਾ ਜੋ ਤੁਹਾਨੂੰ ਅਸਲ ਖਰਚੇ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸੇਗਾ।
AI Gateway tier ਕੀ ਬਦਲਦਾ ਹੈ
ਟੋਕਨ ਦੀ ਵਰਤੋਂ ਨੂੰ ਕੰਟਰੋਲ ਕਰਨ ਲਈ ਲੋੜੀਂਦੀਆਂ ਜ਼ਿਆਦਾਤਰ ਪਾਲਿਸੀਆਂ ਪਹਿਲਾਂ ਹੀ ਸਟੈਂਡਰਡ APIM tiers ਵਿੱਚ ਮੌਜੂਦ ਹਨ—ਜੋ XML ਨਿਯਮਾਂ ਵਜੋਂ ਲਿਖੀਆਂ ਗਈਆਂ ਹਨ ਅਤੇ ਕਸਟਮ ਡੈਸ਼ਬੋਰਡਾਂ 'ਤੇ ਦਿਖਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ। AI tier ਉਹਨਾਂ ਹੀ ਸਮਰੱਥਾਵਾਂ ਨੂੰ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਬਣਾਏ ਗਏ ਅਨੁਭਵ ਵਿੱਚ ਇਕੱਠਾ ਕਰਦਾ ਹੈ:
- AI ਟ੍ਰੈਫਿਕ ਲਈ ਸਕੇਲਿੰਗ ਦਾ ਅਲਗਾਈਕਰਨ (Isolation of scaling)।
- ਸਰਲ ਕੌਂਫਿਗਰੇਸ਼ਨ ਜੋ ਹੱਥ ਨਾਲ ਤਿਆਰ ਕੀਤੀਆਂ XML ਪਾਲਿਸੀਆਂ ਦੀ ਲੋੜ ਨੂੰ ਖਤਮ ਕਰਦੀ ਹੈ।
ਮੁੱਖ ਬਦਲਾਅ ਕਾਰਜਸ਼ੀਲ (operational) ਹੈ: ਤੁਹਾਨੂੰ ਟੋਕਨ ਬਜਟ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਹੁਣ ਕੋਈ ਗੁੰਝਲਦਾਰ ਕੋਡ ਲਿਖਣ ਜਾਂ ਵੱਖਰੇ ਡੈਸ਼ਬੋਰਡਾਂ ਨੂੰ ਬਣਾਈ ਰੱਖਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਇਹ tier ਉਹਨਾਂ ਕੰਟਰੋਲਾਂ ਲਈ ਇੱਕ ਤਿਆਰ ਇੰਟਰਫੇਸ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।
ਕਦੋਂ ਬਦਲਣਾ ਹੈ – ਟ੍ਰੈਫਿਕ-ਅਧਾਰਤ ਗਾਈਡ
- AI ਤੁਹਾਡੇ ਟ੍ਰੈਫਿਕ ਦਾ ਇੱਕ ਛੋਟਾ ਹਿੱਸਾ ਹੈ। ਆਪਣੇ ਮੌਜੂਦਾ APIM tier ਦੀ ਵਰਤੋਂ ਜਾਰੀ ਰੱਖੋ ਅਤੇ ਜੇਕਰ ਤੁਹਾਨੂੰ ਬਾਰੀਕ ਕੰਟਰੋਲ ਦੀ ਲੋੜ ਹੈ ਤਾਂ ਟੋਕਨ ਪਾਲਿਸੀਆਂ ਜੋੜੋ।
- AI ਤੁਹਾਡੀਆਂ ਕਾਲਾਂ 'ਤੇ ਹਾਵੀ ਹੈ। ਸਕੇਲਿੰਗ ਨੂੰ ਅਲਗ ਰੱਖਣ ਅਤੇ ਲਾਗਤ ਪ੍ਰਬੰਧਨ (cost governance) ਨੂੰ ਸਾਫ਼ ਰੱਖਣ ਲਈ AI tier 'ਤੇ ਜਾਓ।
- ਤੁਸੀਂ ਇੰਜੀਨੀਅਰਿੰਗ ਦੇ ਵਾਧੂ ਕੰਮ ਤੋਂ ਬਚਣਾ ਚਾਹੁੰਦੇ ਹੋ। ਇਸ tier ਦੇ ਇਨ-ਬਿਲਟ ਟੂਲ ਕਸਟਮ ਪਾਲਿਸੀਆਂ ਬਣਾਉਣ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਬਣਾਈ ਰੱਖਣ ਵਿੱਚ ਲੱਗੇ ਸਮੇਂ ਨੂੰ ਖਤਮ ਕਰਦੇ ਹਨ।
ਸਭ ਤੋਂ ਵੱਡਾ ਖਰਚਾ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਦੀ ਕੀਮਤ ਨਹੀਂ ਹੈ; ਇਹ ਇੱਕ ਜਨਰਲ ਗੇਟਵੇਅ ਵਿੱਚ ਟੋਕਨ ਇਕਨਾਮਿਕਸ (token economics) ਨੂੰ ਸਮਝਣ ਲਈ ਕਮੀਆਂ ਨੂੰ ਸੁਧਾਰਨ ਵਿੱਚ ਬਿਤਾਏ ਗਏ ਇੰਜੀਨੀਅਰਿੰਗ ਘੰਟੇ ਹਨ।
ਪ੍ਰੀਵਿਊ-ਫੇਜ਼ (Preview-phase) ਪਲੇਅਬੁੱਕ
Microsoft ਅਜੇ ਵੀ AI tier ਪ੍ਰੀਵਿਊ ਵਿੱਚ ਪੇਸ਼ ਕਰ ਰਿਹਾ ਹੈ। ਇਸਨੂੰ ਇੱਕ ਟੈਸਟਬੈੱਡ ਵਜੋਂ ਲਓ, ਨਾ ਕਿ ਪ੍ਰੋਡਕਸ਼ਨ ਲਾਂਚ ਵਜੋਂ।
- ਇੱਕ ਉੱਚ-ਵਾਲੀਅਮ ਵਾਲਾ ਅੰਦਰੂਨੀ AI ਵਰਕਲੋਡ ਚੁਣੋ। ਉਹ ਸੇਵਾ ਚੁਣੋ ਜੋ ਸਭ ਤੋਂ ਵੱਧ ਟੋਕਨ ਟ੍ਰੈਫਿਕ ਪੈਦਾ ਕਰਦੀ ਹੈ।
- ਉਸ ਵਰਕਲੋਡ ਨੂੰ AI tier ਰਾਹੀਂ ਰੂਟ ਕਰੋ। ਪ੍ਰਤੀ ਖਪਤਕਾਰ (consumer) ਟੋਕਨ ਦੀ ਵਰਤੋਂ ਨੂੰ ਕੈਪਚਰ ਕਰਨ ਲਈ ਨਵੀਂ ਕੌਂਫਿਗਰੇਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰੋ।
- ਕੁਝ ਹਫ਼ਤਿਆਂ ਲਈ ਟੋਕਨ-ਖਰਚੇ ਦਾ ਡੇਟਾ ਇਕੱਠਾ ਕਰੋ। ਆਪਣੇ ਮੌਜੂਦਾ ਮਾਨੀਟਰਿੰਗ ਦੇ ਮੁਕਾਬਲੇ ਟੋਕਨ ਦੀ ਗਿਣਤੀ ਅਤੇ ਜੁੜੀਆਂ ਲਾਗਤਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ।
- ਬਜਟ ਬਣਾਉਣ ਲਈ ਬੇਸਲਾਈਨ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੀ ਇਸ tier ਦੇ ਲਾਗਤ-ਕੰਟਰੋਲ ਦੇ ਫਾਇਦੇ ਇਸਦੀ ਪ੍ਰੀਵਿਊ-ਫੇਜ਼ ਦੀਆਂ ਸੀਮਾਵਾਂ ਨਾਲੋਂ ਵੱਧ ਹਨ।
ਜਦੋਂ ਤੱਕ ਇਹ ਜਨਰਲ ਅਵੇਲੇਬਿਲਟੀ (general availability) ਤੱਕ ਨਹੀਂ ਪਹੁੰਚ ਜਾਂਦਾ, ਉਦੋਂ ਤੱਕ ਮਿਸ਼ਨ-ਕ੍ਰਿਟੀਕਲ ਪ੍ਰੋਡਕਸ਼ਨ ਵਰਕਲੋਡ ਨੂੰ ਪ੍ਰੀਵਿਊ ਸੇਵਾ ਵਿੱਚ ਨਾ ਲੈ ਜਾਓ।
ਵਿਰੋਧੀ ਨੁਕਤਾ: ਹਰ ਕਿਸੇ ਨੂੰ ਵੱਖਰੇ tier ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ
ਜੇਕਰ ਤੁਹਾਡਾ ਸੰਗਠਨ ਸਿਰਫ਼ ਕਦੇ-ਕਦੇ LLM ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ, ਤਾਂ AI tier ਦੀ ਵਾਧੂ ਲਾਗਤ ਜਾਇਜ਼ ਨਹੀਂ ਹੋ ਸਕਦੀ। ਤੁਸੀਂ ਮੌਜੂਦਾ ਪਾਲਿਸੀ ਫਰੇਮਵਰਕ ਨਾਲ ਟੋਕਨ-ਪੱਧਰ ਦਾ ਪ੍ਰਬੰਧਨ ਪ੍ਰਾ