ਜੇਕਰ ਤੁਸੀਂ large language models 'ਤੇ production workloads ਚਲਾਉਂਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਜਾਣਦੇ ਹੋ ਕਿ ਮਾਡਲ ਦੀ ਪ੍ਰਦਰਸ਼ਨ (performance) ਸਿਰਫ਼ ਅੱਧੀ ਜੰਗ ਹੈ। ਦੂਜਾ ਅੱਧਾ ਮਹੀਨੇ ਦੇ ਅੰਤ ਵਿੱਚ ਆਉਣ ਵਾਲਾ ਬਿੱਲ ਹੈ। ਤਿੰਨ ਪ੍ਰਦਾਤਾਵਾਂ—Mancer 2, Novita, ਅਤੇ StreamLake—ਨੇ ਹਾਲ ਹੀ ਵਿੱਚ ਆਪਣੀਆਂ ਮਾਡਲ ਕੀਮਤਾਂ ਵਿੱਚ ਬਦਲਾਅ ਕੀਤੇ ਹਨ। ਜੇਕਰ ਤੁਸੀਂ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਵੀ API 'ਤੇ ਨਿਰਭਰ ਹੋ, ਤਾਂ ਤੁਹਾਡਾ ਅਗਲਾ ਇਨਵੌਇਸ (invoice) ਪਿਛਲੇ ਵਾਲੇ ਨਾਲੋਂ ਵੱਖਰਾ ਹੋ ਸਕਦਾ ਹੈ।
ਇਹ ਹੁਣ ਕੋਈ ਅਸਧਾਰਨ ਗੱਲ ਨਹੀਂ ਰਹੀ। LLM ਮਾਰਕੀਟ ਅਜੇ ਵੀ ਇਸ ਗੱਲ ਦਾ ਪ੍ਰਯੋਗ ਕਰ ਰਹੀ ਹੈ ਕਿ inference ਲਈ ਕਿਵੇਂ ਚਾਰਜ ਕੀਤਾ ਜਾਵੇ। ਕੁਝ ਪ੍ਰਦਾਤਾ ਹਜ਼ਾਰ ਟੋਕਨਾਂ (tokens) ਅਨੁਸਾਰ ਬਿੱਲ ਕਰਦੇ ਹਨ। ਹੋਰ ਬੇਨਤੀਆਂ (requests) ਨੂੰ tiers ਵਿੱਚ ਬੰਨ੍ਹਦੇ ਹਨ ਜਾਂ ਲਗਾਤਾਰ ਵਰਤੋਂ ਲਈ ਛੋਟ (discounts) ਦਿੰਦੇ ਹਨ। ਜਦੋਂ ਕੋਈ ਪਲੇਟਫਾਰਮ ਆਪਣੀ ਯੂਨਿਟ ਕੀਮਤ ਬਦਲਦਾ ਹੈ ਜਾਂ ਆਪਣੇ tiers ਨੂੰ ਮੁੜ ਸੰਗਠਿਤ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਬਜਟ 'ਤੇ ਇਸਦਾ ਪ੍ਰਭਾਵ ਮਾਮੂਲੀ ਪਰੇਸ਼ਾਨੀ ਤੋਂ ਲੈ ਕੇ ਲਾਗਤ ਵਿੱਚ ਵੱਡੀ ਵਾਧੇ ਤੱਕ ਹੋ ਸਕਦਾ ਹੈ। ਇਹਨਾਂ ਅਪਡੇਟਾਂ 'ਤੇ ਨਜ਼ਰ ਰੱਖਣਾ ਕੋਈ ਵਿਕਲਪ ਨਹੀਂ ਹੈ। ਇਹ ਕੰਮ ਦਾ ਹੀ ਇੱਕ ਹਿੱਸਾ ਹੈ।
API Pricing 'ਤੇ ਤੁਹਾਡਾ ਧਿਆਨ ਕਿਉਂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ
ਡਿਵੈਲਪਰ ਅਕਸਰ API pricing ਨੂੰ ਇੱਕ ਅਜਿਹੀ ਚੀਜ਼ ਵਾਂਗ ਮੰਨਦੇ ਹਨ ਜਿਸ ਨੂੰ ਇੱਕ ਵਾਰ ਸੈੱਟ ਕਰਕੇ ਭੁੱਲ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਤੁਸੀਂ ਇੱਕ ਮਾਡਲ ਦਾ benchmark ਕਰਦੇ ਹੋ, ਇੱਕ ਪ੍ਰਦਾਤਾ ਚੁਣਦੇ ਹੋ, ਅਤੇ ਫਿਰ ਫੀਚਰ ਬਣਾਉਣ ਵੱਲ ਵਧ ਜਾਂਦੇ ਹੋ। ਇਹ ਉਦੋਂ ਤੱਕ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਆਉਂਦੀ। ਮੌਜੂਦਾ ਹਾਲਾਤਾਂ ਵਿੱਚ, ਕੀਮਤਾਂ ਵਿੱਚ ਬਦਲਾਅ ਬਿਨਾਂ ਕਿਸੇ ਵੱਡੇ ਸ਼ੋਰ-ਸ਼ਰਾਬੇ ਦੇ ਹੋ ਸਕਦੇ ਹਨ। ਇੱਕ ਪ੍ਰਦਾਤਾ ਕਿਸੇ ਪੁਰਾਣੇ (legacy) ਮਾਡਲ ਦੀ ਲਾਗਤ ਘਟਾ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਉਸਦੇ ਨਵੇਂ endpoint ਦੀ ਕੀਮਤ ਵਧਾ ਸਕਦਾ ਹੈ। ਕੋਈ ਹੋਰ output-token surcharges ਲਾਗੂ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਪਿਛਲੀ ਤਿਮਾਹੀ ਵਿੱਚ ਨਹੀਂ ਸਨ। ਜੇਕਰ ਤੁਸੀਂ ਨਜ਼ਰ ਨਹੀਂ ਰੱਖ ਰਹੇ, ਤਾਂ ਤੁਹਾਨੂੰ ਇਸਦਾ ਪਤਾ ਉਦੋਂ ਹੀ ਲੱਗਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਡਾ cloud ਬਿੱਲ ਆਉਂਦਾ ਹੈ।
LLM ਬਿਲਿੰਗ ਦੀ ਬਾਰੀਕੀ (granularity) ਇਸ ਨੂੰ ਖਾਸ ਤੌਰ 'ਤੇ ਔਖਾ ਬਣਾਉਂਦੀ ਹੈ। ਤੁਸੀਂ ਸ਼ਾਇਦ ਹੀ ਕਦੇ ਕੋਈ ਫਿਕਸ ਮਾਸਿਕ ਰੇਟ ਅਦਾ ਕਰਦੇ ਹੋ। ਤੁਸੀਂ ਹਰ prompt token ਅਤੇ ਹਰ completion token ਲਈ ਭੁਗਤਾਨ ਕਰਦੇ ਹੋ। Output ਪਾਸੇ ਕੀਮਤ ਵਿੱਚ ਵਾਧਾ, input ਪਾਸੇ ਵਾਧੇ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਦੁਖਦਾਈ ਹੋ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ completions ਅਕਸਰ prompts ਨਾਲੋਂ ਲੰਬੇ ਹੁੰਦੇ ਹਨ। ਜੇਕਰ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਲੰਬੇ ਟੈਕਸਟ, ਕੋਡ, ਜਾਂ multi-step reasoning chains ਤਿਆਰ ਕਰਦੀ ਹੈ, ਤਾਂ ਪ੍ਰਤੀ-ਟੋਕਨ (per-token) ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਵਾਧਾ ਵੀ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਵਧ ਜਾਂਦਾ ਹੈ।
ਇੱਥੇ 'drift' ਦੀ ਸਮੱਸਿਆ ਵੀ ਹੈ। ਸਮੇਂ ਦੇ ਨਾਲ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਦਾ token profile ਬਦਲਦਾ ਰਹਿੰਦਾ ਹੈ। ਤੁਸੀਂ ਇੱਕ ਨਵਾਂ system prompt ਜੋੜ ਸਕਦੇ ਹੋ ਜੋ ਵਧੇਰੇ input tokens ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ chain-of-thought prompting 'ਤੇ ਜਾ ਸਕਦੇ ਹੋ ਜੋ ਲੰਬੇ outputs ਪੈਦਾ ਕਰਦੀ ਹੈ। ਭਾਵੇਂ ਪ੍ਰਦਾਤਾ ਦੀਆਂ ਕੀਮਤਾਂ ਸਥਿਰ ਰਹਿਣ, ਫਿਰ ਵੀ ਤੁਹਾਡੀਆਂ ਲਾਗਤਾਂ ਬਦਲ ਜਾਣਗੀਆਂ। ਜਦੋਂ ਪ੍ਰਦਾਤਾਵਾਂ ਦੀਆਂ ਕੀਮਤਾਂ ਇੱਕੋ ਸਮੇਂ ਬਦਲਦੀਆਂ ਹਨ, ਤਾਂ ਇਸਦਾ ਸਾਂਝਾ ਪ੍ਰਭਾਵ ਉਸ ਟੀਮ ਨੂੰ ਹੈਰਾਨ ਕਰ ਸਕਦਾ ਹੈ ਜਿਸ ਕੋਲ ਇਸਦੀ ਜਾਣਕਾਰੀ ਨਹੀਂ ਹੈ।
ਕੀ ਬਦਲਿਆ ਹੈ
Mancer 2, Novita, ਅਤੇ StreamLake ਨੇ ਕੀਮਤਾਂ ਵਿੱਚ ਬਦਲਾਅ ਕੀਤੇ ਹਨ। ਵੇਰਵੇ ਪਲੇਟਫਾਰਮ ਅਨੁਸਾਰ ਵੱਖ-ਵੱਖ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਦਿਸ਼ਾ ਇੱਕੋ ਹੈ: ਜੋ ਲਾਗਤ ਢਾਂਚਾ (cost structure) ਤੁਸੀਂ ਪਿਛਲੇ ਮਹੀਨੇ ਵਰਤਿਆ ਸੀ, ਉਹ ਸ਼ਾਇਦ ਹੁਣ ਲਾਗੂ ਨਾ ਹੋਵੇ।
Mancer 2 ਨੇ ਆਪਣੀਆਂ ਮਾਡਲ ਕੀਮਤਾਂ ਨੂੰ ਅਪਡੇਟ ਕੀਤਾ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਸਦੇ endpoints ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੇ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਆਪਣੀ per-request ਲਾਗਤ ਦਾ ਮੁੜ ਮੁਲਾਂਕਣ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਆਪਣੇ ਅੰਦਰੂਨੀ ਦਸਤਾਵੇਜ਼ਾਂ (internal documentation) ਵਿੱਚ ਪੁਰਾਣੀਆਂ ਕੀਮਤਾਂ ਸੇਵ ਕੀਤੀਆਂ ਹਨ, ਤਾਂ ਉਹ ਅੰਕੜੇ ਹੁਣ ਗਲਤ ਹਨ।
Novita ਨੇ ਵੀ ਆਪਣੀਆਂ ਸੇਵਾਵਾਂ ਵਿੱਚ ਕੀਮਤਾਂ ਵਿੱਚ ਬਦਲਾਅ ਕੀਤੇ ਹਨ। ਉਹਨਾਂ ਟੀਮਾਂ ਲਈ ਜਿਨ੍ਹਾਂ ਨੇ Novita ਨੂੰ ਇੱਕ ਖਾਸ ਬਜਟ ਦੇ ਅਨੁਸਾਰ ਚੁਣਿਆ ਸੀ, ਨਵੇਂ ਰੇਟ ਉਹਨਾਂ ਦੇ ਚੱਲ ਰਹੇ ਪ੍ਰੋਜੈਕਟਾਂ ਦੀ ਕੁੱਲ ਲਾਗਤ (total cost of ownership) ਨੂੰ ਬਦਲ ਸਕਦੇ ਹਨ।
StreamLake ਨੇ ਵੀ ਆਪਣੀ ਕੀਮਤਾਂ ਬਦਲ ਦਿੱਤੀਆਂ ਹਨ। ਅਗਲੇ ਬਿਲਿੰਗ ਚੱਕਰ (billing cycle) ਤੋਂ ਪਹਿਲਾਂ StreamLake ਦੇ ਪੁਰਾਣੇ ਰੇਟ ਕਾਰਡ 'ਤੇ ਅਧਾਰਤ ਕਿਸੇ ਵੀ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਦੀ ਸਮੀਖਿਆ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ।
ਕਿਉਂਕਿ ਇਹ ਤਿੰਨ ਵੱਖ-ਵੱਖ ਪਲੇਟਫਾਰਮ ਹਨ ਅਤੇ ਉਹਨਾਂ ਦੇ ਕੀਮਤ ਮਾਡਲ ਵੀ ਵੱਖ-ਵੱਖ ਹਨ, ਇਸ ਲਈ ਕੋਈ ਸਰਵਵਿਆਪਕ ਨਿਯਮ ਨਹੀਂ ਹੈ ਕਿ ਤੁਸੀਂ ਜ਼ਿਆਦਾ ਭੁਗਤਾਨ ਕਰੋਗੇ ਜਾਂ ਘੱਟ। ਇੱਕ ਪ੍ਰਦਾਤਾ ਸ਼ਾਇਦ starter-tier ਰੇਟ ਘਟਾ ਸਕਦਾ ਹੈ ਅਤੇ premium throughput ਕੀਮਤਾਂ ਵਧਾ ਸਕਦਾ ਹੈ। ਕੋਈ ਹੋਰ context-window premiums ਨੂੰ ਐਡਜਸਟ ਕਰ ਸਕਦਾ ਹੈ। ਸਿਰਫ਼ ਇੱਕ ਹੀ ਸੁਰੱਖਿਅਤ ਅੰਦਾਜ਼ਾ ਹੈ ਕਿ ਤੁਹਾਡੀ ਪੁਰਾਣੀ spreadsheet ਗਲਤ ਹੈ।
ਰੇਟਾਂ ਵਿੱਚ ਬਦਲਾਅ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨ ਦੀਆਂ ਲੁਕੀਆਂ ਹੋਈਆਂ ਲਾਗਤਾਂ
ਆਓ ਦੇਖੀਏ ਕਿ ਅਸਲ ਵਿੱਚ ਇਸਦਾ ਕੀ ਮਤਲਬ ਹੈ। ਮੰਨ ਲਓ ਤੁਸੀਂ ਇੱਕ customer-support assistant ਚਲਾਉਂਦੇ ਹੋ ਜੋ ਦਿਨ ਵਿੱਚ ਦਸ ਹਜ਼ਾਰ ਗੱਲਬਾਤਾਂ ਸੰਭਾਲਦਾ ਹੈ। ਹਰ ਗੱਲਬਾਤ ਵਿੱਚ ਔਸਤਨ ਦੋ ਹਜ਼ਾਰ input tokens ਅਤੇ ਚਾਰ ਸੌ output tokens ਹੁੰਦੇ ਹਨ। ਪ੍ਰਤੀ ਮਿਲੀਅਨ ਟੋਕਨਾਂ ਵਿੱਚ ਕੁਝ ਸੈਂਟਾਂ ਦਾ ਬਦਲਾਅ ਵੀ ਮਹੀਨੇ ਦੇ ਸੈਂਕੜੇ ਡਾਲਰਾਂ ਤੱਕ ਹੋ ਸਕਦਾ ਹੈ। ਜੇਕਰ ਕੀ
ਲਾਗਤ-ਟਰੈਕਿੰਗ (Cost-Tracking) ਦੀ ਆਦਤ ਕਿਵੇਂ ਬਣਾਈ ਜਾਵੇ
ਇਸ ਨੂੰ ਕੰਟਰੋਲ ਵਿੱਚ ਰੱਖਣ ਲਈ ਤੁਹਾਨੂੰ ਕਿਸੇ ਵੱਡੀ ਫਾਈਨੈਂਸ ਟੀਮ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਰੁਟੀਨ ਅਤੇ ਬਦਲਾਅ ਦਰਜ ਕਰਨ ਲਈ ਇੱਕ ਜਗ੍ਹਾ ਦੀ ਲੋੜ ਹੈ।
ਆਪਣੇ ਰੇਟ ਕਾਰਡਾਂ (rate cards) ਨੂੰ ਕੇਂਦਰਿਤ ਕਰਨ ਨਾਲ ਸ਼ੁਰੂਆਤ ਕਰੋ। ਇੱਕ ਸਧਾਰਨ ਦਸਤਾਵੇਜ਼ ਰੱਖੋ—ਚਾਹੇ ਉਹ ਇੱਕ ਸਾਂਝਾ wiki ਪੇਜ ਹੋਵੇ, ਇੱਕ Notion table ਹੋਵੇ, ਜਾਂ ਤੁਹਾਡੇ dev channel ਵਿੱਚ ਇੱਕ pinned message ਹੋਵੇ—ਜਿਸ ਵਿੱਚ ਤੁਹਾਡੇ ਦੁਆਰਾ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਹਰ ਮਾਡਲ ਲਈ ਮੌਜੂਦਾ per-token ਜਾਂ per-request ਕੀਮਤ ਦੀ ਸੂਚੀ ਹੋਵੇ। ਜਦੋਂ ਕੋਈ ਪ੍ਰੋਵਾਈਡਰ ਬਦਲਾਅ ਦਾ ਐਲਾਨ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਰੰਤ ਦਸਤਾਵੇਜ਼ ਨੂੰ ਅਪਡੇਟ ਕਰੋ। Sprint review ਦੀ ਉਡੀਕ ਨਾ ਕਰੋ।
ਅਗਲਾ ਕਦਮ, ਆਪਣੀ ਵਰਤੋਂ (usage) ਨੂੰ ਪ੍ਰੋਵਾਈਡਰ ਅਤੇ ਮਾਡਲ ਦੇ ਅਨੁਸਾਰ ਟੈਗ ਕਰੋ। ਜ਼ਿਆਦਾਤਰ observability tools ਤੁਹਾਨੂੰ API calls ਨਾਲ custom metadata ਜੋੜਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ। ਹਫ਼ਤਾਵਾਰੀ ਲਾਗਤ ਦੇ ਸਾਰ (cost summaries) ਤਿਆਰ ਕਰਨ ਲਈ ਉਹਨਾਂ ਟੈਗਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਜੇਕਰ ਤੁਹਾਨੂੰ ਕੋਈ ਅਚਾਨਕ ਵਾਧਾ (spike) ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਕੁਝ ਹੀ ਸਕਿੰਟਾਂ ਵਿੱਚ ਇਹ ਪਤਾ ਲਗਾ ਸਕਦੇ ਹੋ ਕਿ ਇਹ ਵਰਤੋਂ ਵਿੱਚ ਵਾਧੇ ਕਾਰਨ ਹੋਇਆ ਹੈ ਜਾਂ ਰੇਟ ਵਿੱਚ ਬਦਲਾਅ ਕਾਰਨ, ਦਿਨਾਂ ਦੀ ਉਡੀਕ ਕੀਤੇ ਬਿਨਾਂ।
ਇੱਕ burn-rate alert ਬਣਾਓ। ਇਸ ਦਾ ਸ਼ਾਨਦਾਰ ਹੋਣਾ ਜ਼ਰੂਰੀ ਨਹੀਂ ਹੈ। ਇੱਕ scheduled script ਜੋ ਤੁਹਾਡੇ usage dashboard ਤੋਂ ਜਾਣਕਾਰੀ ਲੈਂਦੀ ਹੈ ਅਤੇ ਹਰ ਸਵੇਰ Slack 'ਤੇ ਇੱਕ ਅੰਕ ਪੋਸਟ ਕਰਦੀ ਹੈ, ਉਹ ਕਾਫ਼ੀ ਹੈ। ਜਦੋਂ ਅੰਕ ਵਧਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਉਸੇ ਦਿਨ ਪਤਾ ਲੱਗ ਜਾਵੇਗਾ, ਨਾ ਕਿ ਤੀਹ ਦਿਨਾਂ ਬਾਅਦ ਜਦੋਂ ਫਾਈਨੈਂਸ ਟੀਮ ਕੋਈ ਗੁੱਸੇ ਵਾਲਾ ਈਮੇਲ ਭੇਜਦੀ ਹੈ।
ਹਰ ਤਿਮਾਹੀ ਵਿੱਚ ਆਪਣੇ ਮਾਡਲ ਦੀ ਚੋਣ ਦੀ ਸਮੀਖਿਆ ਕਰੋ। ਜਨਵਰੀ ਵਿੱਚ ਤੁਹਾਡੇ ਕੰਮ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਮਾਡਲ ਜੂਨ ਵਿੱਚ ਸ਼ਾਇਦ ਸਭ ਤੋਂ ਵਧੀਆ ਨਾ ਹੋਵੇ, ਇਸ ਲਈ ਨਹੀਂ ਕਿ ਮਾਡਲ ਖਰਾਬ ਹੋ ਗਿਆ ਹੈ, ਸਗੋਂ ਇਸ ਲਈ ਕਿਉਂਕਿ ਕੀਮਤਾਂ ਦਾ ਦ੍ਰਿਸ਼ (pricing landscape) ਬਦਲ ਗਿਆ ਹੈ। ਕੋਈ ਪ੍ਰੋਵਾਈਡਰ ਜੋ ਪਹਿਲਾਂ ਬਹੁਤ ਮਹਿੰਗਾ ਸੀ, ਸ਼ਾਇਦ ਉਸਨੇ ਰੇਟ ਘਟਾ ਦਿੱਤੇ ਹੋਣ। ਕੋਈ ਸਸਤਾ ਮਨਪਸੰਦ ਮਾਡਲ ਸ਼ਾਇਦ ਰੇਟ ਵਧਾ ਦਿੱਤੇ ਹੋਣ। ਆਪਣੇ benchmarks ਨੂੰ ਪੁਰਾਣੀਆਂ ਕੀਮਤਾਂ ਦੀ ਬਜਾਏ ਲਾਈਵ ਕੀਮਤਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਦੁਬਾਰਾ ਚਲਾਓ।
ਅੰਤ ਵਿੱਚ, ਆਪਣੇ architecture ਦੇ ਫੈਸਲਿਆਂ ਵਿੱਚ ਕੀਮਤਾਂ ਦਾ ਧਿਆਨ ਰੱਖੋ। ਜੇਕਰ ਤੁਹਾਨੂੰ ਪਤਾ ਹੈ ਕਿ ਕੋਈ ਪ੍ਰੋਵਾਈਡਰ ਅਕਸਰ ਰੇਟ ਬਦਲਦਾ ਹੈ, ਤਾਂ ਆਪਣੇ ਸਿਸਟਮ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕਰੋ ਕਿ ਤੁਸੀਂ ਅੱਧਾ codebase ਦੁਬਾਰਾ ਲਿਖੇ ਬਿਨਾਂ endpoints ਬਦਲ ਸਕੋ। Client ਨੂੰ ਇੱਕ internal interface ਦੇ ਪਿੱਛੇ ਰੱਖੋ (abstract ਕਰੋ)। ਮਾਡਲ ਦਾ ਨਾਮ ਇੱਕ configuration file ਵਿੱਚ ਰੱਖੋ, ਨਾ ਕਿ ਆਪਣੇ prompt layer ਵਿੱਚ hard-code ਕਰੋ।
ਭਰੋਸੇਯੋਗ ਅਪਡੇਟਸ ਕਿੱਥੋਂ ਪ੍ਰਾਪਤ ਕੀਤੇ ਜਾਣ
ਪ੍ਰੋਵਾਈਡਰ ਬਲੌਗ ਅਤੇ documentation ਅਧਿਕਾਰਤ ਸਰੋਤ ਹਨ, ਪਰ ਰੁੱਝੇ ਹੋਏ ਹਫ਼ਤੇ ਵਿੱਚ ਉਹਨਾਂ ਵੱਲ ਧਿਆਨ ਨਾ ਜਾਣ ਦੀ ਸੰਭਾਵਨਾ ਰਹਿੰਦੀ ਹੈ। ਇੱਕ ਵਿਕਲਪ ਇਹ ਹੈ ਕਿ ਉਹ curated roundups ਫੋਲੋ ਕੀਤੇ ਜਾਣ ਜੋ ਪੂਰੇ ecosystem ਵਿੱਚ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਬਦਲਾਅਾਂ ਨੂੰ ਟ੍ਰੈਕ ਕਰਦੇ ਹਨ। ਹਾਲ ਹੀ ਦੇ Mancer 2, Novita, ਅਤੇ StreamLake ਦੇ ਬਦਲਾਅਾਂ ਦੀ ਪੂਰੀ ਜਾਣਕਾਰੀ ਲਈ, ਇੱਥੇ ਵਿਸਤ੍ਰਿਤ ਸਾਰ ਦੇਖੋ:
LLM Pricing ਵਿੱਚ ਬਦਲਾਅ: Mancer 2, Novita, ਅਤੇ StreamLake
ਜੇਕਰ ਤੁਸੀਂ ਜਾਣਕਾਰੀ ਨਾਲ ਜੁੜੇ ਰਹਿਣਾ ਚਾਹੁੰਦੇ ਹੋ ਅਤੇ ਉਹਨਾਂ ਹੋਰ ਬਿਲਡਰਾਂ ਨਾਲ ਵਿਚਾਰ ਸਾਂਝੇ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ ਜੋ ਆਪਣੇ AI infrastructure ਦੇ ਬਿੱਲਾਂ ਨੂੰ ਕੰਟਰੋਲ ਵਿੱਚ ਰੱਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਨ, ਤਾਂ ਇੱਕ ਕਮਿਊਨਿਟੀ ਵੀ ਹੈ ਜਿਸ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣਾ ਫਾਇਦੇਮੰਦ ਹੋ ਸਕਦਾ ਹੈ:
ਅਚਾਨਕ ਆਉਣ ਵਾਲੇ ਬਿੱਲਾਂ ਦੇ ਵਿਰੁੱਧ ਸਭ ਤੋਂ ਵਧੀਆ ਬਚਾਅ ਉਹ ਲੋਕਾਂ ਦਾ ਨੈੱਟਵਰਕ ਹੈ ਜੋ ਬਦਲਾਅ ਹੁੰਦੇ ਹੀ ਉਸ ਬਾਰੇ ਸੂਚਿਤ ਕਰਦੇ ਹਨ।
ਅਸਲ ਸਿੱਖਿਆ
ਕੀਮਤਾਂ ਵਿੱਚ ਉਤਾਰ-ਚੜ੍ਹਾਅ (Pricing volatility) ਮੌਜੂਦਾ LLM ਮਾਰਕੀਟ ਦੀ ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ, ਕੋਈ ਖਰਾਬੀ (bug) ਨਹੀਂ। ਮਾਡਲਾਂ ਨੂੰ ਚਲਾਉਣਾ ਸਸਤਾ ਹੁੰਦਾ ਜਾ ਰਿਹਾ ਹੈ, ਪ੍ਰੋਵਾਈਡਰ ਰੇਟ ਦੇ ਢਾਂਚੇ ਨਾਲ ਪ੍ਰਯੋਗ ਕਰ ਰਹੇ ਹਨ, ਅਤੇ ਮੁਕਾਬਲਾ ਕੀਮਤਾਂ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ। ਲੰਬੇ ਸਮੇਂ ਵਿੱਚ ਇਹ ਚੰਗੀ ਖ਼ਬਰ ਹੈ, ਪਰ ਸਿਰਫ਼ ਉਦੋਂ ਹੀ ਜੇਕਰ ਤੁਸੀਂ ਧਿਆਨ ਦੇ ਰਹੇ ਹੋ। ਆਪਣੀਆਂ API ਲਾਗਤਾਂ ਨਾਲ ਉਹੀ ਵਿਵਹਾਰ ਕਰੋ ਜੋ ਤੁਸੀਂ ਆਪਣੇ uptime metrics ਨਾਲ ਕਰਦੇ ਹੋ: ਉਹਨਾਂ ਨੂੰ ਮਾਪੋ, ਉਹਨਾਂ 'ਤੇ ਅਲਰਟ ਸੈੱਟ ਕਰੋ, ਅਤੇ ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਉਹਨਾਂ ਬਾਰੇ ਸਵਾਲ ਕਰੋ। Mancer 2, Novita, ਅਤੇ StreamLake ਦੇ ਹਾਲੀਆ ਬਦਲਾਅ ਸਿਰਫ਼ ਇੱਕ ਤਾਜ਼ਾ ਯਾਦ ਦਿਵਾਉਣ ਦਾ ਤਰੀਕਾ ਹਨ ਕਿ ਤੁਹਾਡੇ AI stack ਦੀ ਕੀਮਤ ਕਦੇ ਵੀ ਪੱਕੀ ਨਹੀਂ ਹੁੰਦੀ।