StreamLake ਨੇ ਹੁਣੇ ਆਪਣੀਆਂ LLM ਕੀਮਤਾਂ ਬਦਲ ਦਿੱਤੀਆਂ ਹਨ। ਇੱਥੇ ਉਹ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਅਸਲ ਵਿੱਚ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।
ਜੇਕਰ ਤੁਸੀਂ StreamLake 'ਤੇ ਫੀਚਰ ਲਾਂਚ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ LLM ਮਾਡਲ ਕੀਮਤਾਂ ਵਿੱਚ ਹਾਲੀਆ ਬਦਲਾਅ ਕੋਈ ਅਜਿਹੀ ਨੋਟ (footnote) ਨਹੀਂ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਅਣਦੇਖਾ ਕਰ ਸਕਦੇ ਹੋ। ਇਹ ਇੱਕ ਸੰਚਾਲਨ ਸੰਕੇਤ (operational signal) ਹੈ। ਜਦੋਂ ਪਲੇਟਫਾਰਮ ਇਨਫਰੈਂਸ (inference) ਲਈ ਆਪਣੀਆਂ ਫੀਸਾਂ ਨੂੰ ਅਪਡੇਟ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੀ ਯੂਨਿਟ ਇਕਨਾਮਿਕਸ (unit economics) ਬਦਲ ਜਾਂਦੀ ਹੈ, ਚਾਹੇ ਤੁਸੀਂ ਇਸ ਵੱਲ ਧਿਆਨ ਦਿਓ ਜਾਂ ਨਾ। ਉਹ ਟੀਮਾਂ ਜੋ ਮੁਨਾਫੇ ਵਿੱਚ ਰਹਿੰਦੀਆਂ ਹਨ, ਉਹ ਹਨ ਜੋ ਇਹਨਾਂ ਅਪਡੇਟਾਂ ਨੂੰ ਸਿਰਫ਼ ਸਵੀਕਾਰ ਕਰਨ ਦੀ ਬਜਾਏ ਆਡਿਟ ਕਰਨ ਦੇ ਕਾਰਨ ਵਜੋਂ ਦੇਖਦੀਆਂ ਹਨ।
StreamLake ਨੇ ਮਾਡਲ ਦੀਆਂ ਕੀਮਤਾਂ ਬਦਲ ਦਿੱਤੀਆਂ ਹਨ। ਇਹ ਮੁੱਖ ਤੱਥ ਹੈ। ਹਰੇਕ ਐਂਡਪੁਆਇੰਟ (endpoint) ਅਤੇ ਟੋਕਨ ਟਾਇਰ (token tier) ਲਈ ਸਹੀ ਦਰਾਂ ਦੇ ਬਦਲਾਅ ਹੇਠਾਂ ਦਿੱਤੇ ਲਿੰਕ ਵਾਲੇ ਡਿਵੈਲਪਰ ਐਨਾਂਸਮੈਂਟ ਵਿੱਚ ਦੱਸੇ ਗਏ ਹਨ। ਤੁਹਾਡਾ ਕੰਮ ਸਿਰਫ਼ ਨਵੇਂ ਅੰਕਾਂ ਨੂੰ ਪੜ੍ਹਨਾ ਅਤੇ ਅੱਗੇ ਵਧਣਾ ਨਹੀਂ ਹੈ। ਇਹ ਸਮਝਣਾ ਹੈ ਕਿ ਉਹ ਅੰਕ ਪਿਛਲੇ ਛੇ ਮਹੀਨਿਆਂ ਵਿੱਚ ਤੁਹਾਡੇ ਦੁਆਰਾ ਲਏ ਗਏ ਹਰ ਉਤਪਾਦ ਫੈਸਲੇ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ।
ਕੀਮਤਾਂ ਵਿੱਚ ਬਦਲਾਅ ਤੁਹਾਡੀ ਉਮੀਦ ਨਾਲੋਂ ਵੱਧ ਦੁਖਦਾਈ ਕਿਉਂ ਹੁੰਦਾ ਹੈ
ਜ਼ਿਆਦਾਤਰ ਸਾਫਟਵੇਅਰ ਕਾਰੋਬਾਰ ਨਿਸ਼ਚਿਤ ਲਾਗਤਾਂ (fixed costs) ਦੇ ਆਲੇ-ਦੁਆਲੇ ਬਣੇ ਹੁੰਦੇ ਹਨ। ਤੁਸੀਂ ਸਰਵਰ, ਡਾਟਾਬੇਸ ਅਤੇ ਬੈਂਡਵਿਡਥ ਲਈ ਭੁਗਤਾਨ ਕਰਦੇ ਹੋ। ਉਹ ਬਿੱਲ ਅਨੁਮਾਨਿਤ ਹੁੰਦੇ ਹਨ। Large language models ਇਸ ਮਾਡਲ ਨੂੰ ਤੋੜ ਦਿੰਦੇ ਹਨ। ਇਨਫਰੈਂਸ (inference) ਇੱਕ ਵੈਰੀਏਬਲ ਲਾਗਤ (variable cost) ਹੈ ਜੋ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਉਪਭੋਗਤਾ ਦੇ ਵਿਵਹਾਰ ਨਾਲ ਜੁੜੀ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਗਾਹਕ ਜੋ ਤੁਹਾਡੀ ਐਪ ਵਿੱਚ ਪੰਜਾਹ ਪੰਨਿਆਂ ਦਾ ਦਸਤਾਵੇਜ਼ ਕਾਪੀ-ਪੇਸਟ ਕਰਦਾ ਹੈ, ਉਹ ਇੱਕ ਅਜਿਹੇ ਗਾਹਕ ਨਾਲੋਂ ਬਿੱਲ ਵਿੱਚ ਬਹੁਤ ਵੱਖਰਾ ਹੁੰਦਾ ਹੈ ਜੋ ਸਿਰਫ਼ ਤਿੰਨ ਸ਼ਬਦਾਂ ਦਾ ਸਵਾਲ ਪੁੱਛਦਾ ਹੈ। ਜਦੋਂ StreamLake ਆਪਣੀਆਂ ਦਰਾਂ ਬਦਲਦਾ ਹੈ, ਤਾਂ ਉਹ ਵੈਰੀਏਬਿਲਟੀ (variability) ਹੋਰ ਵੀ ਵਧ ਜਾਂਦੀ ਹੈ।
ਮਾਡਲ ਦੀਆਂ ਉੱਚ ਲਾਗਤਾਂ ਮਾਰਜਿਨਾਂ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਘਟਾਉਂਦੀਆਂ ਹਨ ਜੋ ਤੁਰੰਤ ਦਿਖਾਈ ਨਹੀਂ ਦਿੰਦੀਆਂ। ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਲਾਂਚ ਵੇਲੇ ਅੰਕਾਂ ਦੀ ਜਾਂਚ ਕਰੋ ਅਤੇ ਪਾਓ ਕਿ ਤੁਹਾਡਾ AI ਫੀਚਰ ਵਧੀਆ ਮੁਨਾਫੇ ਵਾਲਾ ਹੈ। ਛੇ ਮਹੀਨਿਆਂ ਬਾਅਦ, ਕੀਮਤਾਂ ਦੇ ਅਪਡੇਟ ਅਤੇ ਵਰਤੋਂ ਵਿੱਚ ਵਾਧੇ ਤੋਂ ਬਾਅਦ, ਉਹੀ ਫੀਚਰ ਹਰ ਕਾਲ 'ਤੇ ਪੈਸੇ ਗੁਆ ਰਿਹਾ ਹੁੰਦਾ ਹੈ। ਖ਼ਤਰਾ ਉਹਨਾਂ ਟੀਮਾਂ ਲਈ ਸਭ ਤੋਂ ਵੱਧ ਹੈ ਜੋ ਫਲੈਟ-ਰੇਟ (flat-rate) ਕੀਮਤਾਂ ਰੱਖਦੀਆਂ ਹਨ। ਜੇਕਰ ਤੁਸੀਂ ਉਪਭੋਗਤਾਵਾਂ ਤੋਂ ਪ੍ਰਤੀ ਮਹੀਨਾ $29 ਲੈਂਦੇ ਹੋ ਅਤੇ ਤੁਹਾਡਾ ਬੈਕਐਂਡ ਇੱਕ ਸਿੰਗਲ ਭਾਰੀ ਇਨਫਰੈਂਸ ਕਾਲ 'ਤੇ $8 ਖਰਚ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਕੋਈ ਬਿਜ਼ਨਸ ਮਾਡਲ ਨਹੀਂ ਹੈ। ਤੁਹਾਡੇ ਕੋਲ ਸਿਰਫ਼ ਇੱਕ ਸਬਸਿਡੀ ਹੈ।
ਦਰਦ ਇਸ ਗੱਲ 'ਤੇ ਵੀ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਵਾਧਾ ਇਨਪੁਟ ਟੋਕਨਾਂ (input tokens), ਆਉਟਪੁੱਟ ਟੋਕਨਾਂ (output tokens), ਜਾਂ ਵਿਸ਼ੇਸ਼ ਮਾਡਲ ਫੈਮਿਲੀਜ਼ 'ਤੇ ਅਸਰ ਪਾ ਰਿਹਾ ਹੈ। ਕੁਝ ਐਪਲੀਕੇਸ਼ਨਾਂ ਇਨਪੁਟ-ਭਾਰੀ (input-heavy) ਹੁੰਦੀਆਂ ਹਨ। ਕੋਡ ਰਿਵਿਊ ਟੂਲਜ਼ ਬਾਰੇ ਸੋਚੋ ਜੋ ਪੂਰੀਆਂ ਰਿਪੋਜ਼ਟਰੀਆਂ ਨੂੰ ਕੰਟੈਕਸਟ (context) ਵਜੋਂ ਭੇਜਦੇ ਹਨ। ਦੂਜੇ ਆਉਟਪੁੱਟ-ਭਾਰੀ (output-heavy) ਹੁੰਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ ਲੰਬੇ ਰੂਪ ਵਿੱਚ ਲਿਖਣ ਵਾਲੇ ਸਹਾਇਕ (writing assistants) ਜੋ ਉਪਭੋਗਤਾ ਨੂੰ ਹਜ਼ਾਰਾਂ ਟੋਕਨ ਸਟ੍ਰੀਮ ਕਰਦੇ ਹਨ। ਕੀਮਤ ਵਿੱਚ ਬਦਲਾਅ ਜੋ ਸਿਰਫ਼ ਆਉਟਪੁੱਟ ਟੋਕਨਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ, ਉਹ ਕੋਡ ਰਿਵਿਊਅਰ ਨਾਲੋਂ ਲੇਖਕ ਨੂੰ ਜ਼ਿਆਦਾ ਪ੍ਰਭਾਵਿਤ ਕਰੇਗਾ, ਅਤੇ ਇਸਦਾ ਉਲਟ ਵੀ। ਨੁਕਸਾਨ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਤੁਹਾਨੂੰ ਆਪਣੀ ਟੋਕਨ ਪ੍ਰੋਫਾਈਲ (token profile) ਬਾਰੇ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਇੱਕ ਕੀਮਤ-ਜਾਗਰੂਕ ਵਰਕਫਲੋ (Workflow) ਬਣਾਓ
ਆਪਣੇ ਮਹੀਨਾਵਾਰ ਬਿੱਲ ਦੇ ਤੁਹਾਨੂੰ ਹੈਰਾਨ ਕਰਨ ਦੀ ਉਡੀਕ ਕਰਨਾ ਇੱਕ ਮਾੜੀ ਰਣਨੀਤੀ ਹੈ। ਉਹ ਟੀਮਾਂ ਜੋ ਕੀਮਤਾਂ ਦੇ ਉਤਾਰ-ਚੜ੍ਹਾਅ ਵਿੱਚ ਬਚਦੀਆਂ ਹਨ, ਉਹ ਆਪਣੀਆਂ ਰੋਜ਼ਾਨਾ ਆਦਤਾਂ ਵਿੱਚ ਮਾਨੀਟਰਿੰਗ (monitoring) ਨੂੰ ਸ਼ਾਮਲ ਕਰਦੀਆਂ ਹਨ। ਇੱਥੇ ਦੱਸਿਆ ਗਿਆ ਹੈ ਕਿ ਸਪ੍ਰੈਡਸ਼ੀਟਾਂ ਵਿੱਚ ਡੁੱਬੇ ਬਿਨਾਂ ਇਹ ਕਿਵੇਂ ਕਰਨਾ ਹੈ।
ਪਹਿਲਾਂ, ਹਰੇਕ API ਕਾਲ ਨੂੰ ਫੀਚਰ ਅਤੇ ਮਾਡਲ ਦੇ ਅਨੁਸਾਰ ਟੈਗ ਕਰੋ। ਜੇਕਰ ਤੁਹਾਡੀ ਐਪ ਵਿੱਚ ਇੱਕ ਸਮਰਾਈਜ਼ਰ (summarizer), ਇੱਕ ਚੈਟਬੋਟ, ਅਤੇ ਇੱਕ ਟ੍ਰਾਂਸਲੇਸ਼ਨ ਲੇਅਰ ਹੈ, ਤਾਂ ਆਪਣੇ ਲੌਗਿੰਗ ਪਾਈਪਲਾਈਨ (logging pipeline) ਵਿੱਚ ਲਾਗਤਾਂ ਨੂੰ ਵੱਖ ਕਰੋ। ਜਦੋਂ StreamLake ਆਪਣੀਆਂ ਦਰਾਂ ਨੂੰ ਅਪਡੇਟ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਅਜਿਹੀ ਰਿਪੋਰਟ ਚਲਾਉਣ ਦੇ ਯੋਗ ਹੋਣੇ ਚਾਹੀਦੇ ਹੋ ਜੋ ਕਹੇ, "ਸਮਰਾਈਜ਼ਰ ਸਾਡੇ ਇਨਫਰੈਂਸ ਖਰਚੇ ਦਾ 70 ਪ੍ਰਤੀਸ਼ਤ ਹੈ।" ਉਹ ਸਟੀਕਤਾ ਤੁਹਾਨੂੰ ਦੱਸਦੀ ਹੈ ਕਿ ਪਹਿਲਾਂ ਕਿੱਥੇ ਆਪਟੀਮਾਈਜ਼ (optimize) ਕਰਨਾ ਹੈ।
ਦੂਜਾ, ਬਜਟ ਅਲਰਟ (budget alerts) ਸੈੱਟ ਕਰੋ। StreamLake ਸਮੇਤ ਜ਼ਿਆਦਾਤਰ ਪਲੇਟਫਾਰਮ ਤੁਹਾਨੂੰ ਖਰਚ ਦੀਆਂ ਸੀਮਾਵਾਂ (spending thresholds) ਨਿਰਧਾਰਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ। ਉਹਨਾਂ ਨੂੰ ਸਖ਼ਤੀ ਨਾਲ ਸੈੱਟ ਕਰੋ। ਜੇਕਰ ਤੁਹਾਡਾ ਰੋਜ਼ਾਨਾ ਇਨਫਰੈਂਸ ਬਿੱਲ ਬੇਸਲਾਈਨ ਤੋਂ 30 ਪ੍ਰਤੀਸ਼ਤ ਵੱਧ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਘੰਟਿਆਂ ਦੇ ਅੰਦਰ ਇੱਕ Slack ਮੈਸੇਜ ਜਾਂ ਈਮੇਲ ਚਾਹੁੰਦੇ ਹੋ, ਨਾ ਕਿ ਤੀਹ ਦਿਨਾਂ ਬਾਅਦ ਇੱਕ ਅਚਾਨਕ ਇਨਵੌਇਸ
ਹਰ ਕੀਮਤ ਵਾਧੇ ਦਾ ਸਾਹਮਣਾ ਸਿਰਫ਼ ਲਾਗਤ ਘਟਾਉਣ ਨਾਲ ਹੀ ਨਹੀਂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ। ਕਈ ਵਾਰ ਸਹੀ ਜਵਾਬ ਆਪਣੇ ਉਤਪਾਦ ਨੂੰ ਬਦਲਣਾ ਹੁੰਦਾ ਹੈ। ਜੇਕਰ ਕੋਈ ਮੁੱਖ ਫੀਚਰ ਅਜਿਹੇ endpoint 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਜਿਸਦੀ ਕੀਮਤ ਦੁੱਗਣੀ ਹੋ ਗਈ ਹੈ, ਤਾਂ ਹੋਰ ਸਖ਼ਤ ਸਵਾਲ ਪੁੱਛੋ। ਕੀ ਤੁਸੀਂ overhead ਘਟਾਉਣ ਲਈ requests ਨੂੰ batch ਵਿੱਚ ਕਰ ਸਕਦੇ ਹੋ? ਕੀ ਤੁਸੀਂ ਸਭ ਤੋਂ ਆਮ ਪੰਜਾਹ ਯੂਜ਼ਰ ਕੁਐਰੀਆਂ (user queries) ਨੂੰ cache ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਮਾਡਲ ਦੀ ਬਜਾਏ ਡਾਟਾਬੇਸ ਤੋਂ ਉਹਨਾਂ ਨੂੰ ਸਰਵ ਕਰ ਸਕਦੇ ਹੋ? ਕੀ ਤੁਸੀਂ ਭਾਰੀ pre-processing ਨੂੰ client-side embeddings 'ਤੇ ਮੂਵ ਕਰ ਸਕਦੇ ਹੋ ਤਾਂ ਜੋ ਤੁਸੀਂ API ਨੂੰ ਘੱਟ ਟੈਕਸਟ ਭੇਜ ਸਕੋ?
ਇੱਥੇ ਹਾਈਬ੍ਰਿਡ ਆਰਕੀਟੈਕਚਰ (Hybrid architectures) ਤੁਹਾਡੇ ਦੋਸਤ ਹਨ। ਕਈ ਟੀਮਾਂ ਇਹ ਫੈਸਲਾ ਕਰਨ ਲਈ ਕਿ ਕੀ ਕਿਸੇ ਯੂਜ਼ਰ ਕੁਐਰੀ ਨੂੰ ਮਹਿੰਗੇ reasoning engine ਦੀ ਲੋੜ ਹੈ ਜਾਂ ਨਹੀਂ, upstream 'ਤੇ ਇੱਕ ਸਸਤਾ classifier model ਚਲਾਉਂਦੀਆਂ ਹਨ। ਜੇਕਰ ਸਵਾਲ ਮਾਮੂਲੀ ਹੈ, ਤਾਂ ਇਸਦਾ ਜਵਾਬ ਕਿਸੇ lightweight model ਜਾਂ rules-based system ਨਾਲ ਦਿਓ। ਮਹਿੰਗੇ ਕਾਲ (call) ਨੂੰ ਸਿਰਫ਼ ਔਖੇ ਸਵਾਲਾਂ ਲਈ ਰਾਖਵਾਂ ਰੱਖੋ। ਇਹ ਤੁਹਾਡੇ ਉਤਪਾਦ ਦੀ ਗੁਣਵੱਤਾ ਨੂੰ ਘਟਾਏ ਬਿਨਾਂ ਤੁਹਾਡੇ ਖਰਚੇ ਦੇ ਕਰਵ (spend curve) ਨੂੰ ਘਟਾ ਦਿੰਦਾ ਹੈ।
ਤੁਹਾਡੇ ਪਾਸੇ ਕੀਮਤ ਰਣਨੀਤੀ (pricing strategy) ਦਾ ਵੀ ਸਵਾਲ ਹੈ। ਜੇਕਰ inference costs ਵਧ ਰਹੀਆਂ ਹਨ, ਤਾਂ usage-based tiers ਰਾਹੀਂ ਇਸਦਾ ਕੁਝ ਹਿੱਸਾ ਯੂਜ਼ਰਾਂ 'ਤੇ ਪਾਉਣਾ ਯੂਜ਼ਰ-ਵਿਰੋਧੀ ਨਹੀਂ ਹੈ। ਇਹ ਇਮਾਨਦਾਰੀ ਹੈ। ਉਹ ਗਾਹਕ ਜੋ ਬਹੁਤ ਜ਼ਿਆਦਾ token loads ਪੈਦਾ ਕਰਦੇ ਹਨ, ਉਹ ਉਸ ਇਨਫਰਾਸਟ੍ਰਕਚਰ ਲਈ ਭੁਗਤਾਨ ਕਰਦੇ ਹਨ ਜਿਸਦੀ ਉਹ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। ਜਿਨ੍ਹਾਂ ਦੀਆਂ ਲੋੜਾਂ ਘੱਟ ਹਨ, ਉਹ ਕਿਫਾਇਤੀ ਪਲਾਨਾਂ 'ਤੇ ਰਹਿੰਦੇ ਹਨ। ਇਸਦਾ ਵਿਕਲਪ ਇੱਕ ਅਜਿਹੇ moat ਦੇ ਪਿੱਛੇ ਭੱਜਣਾ ਹੈ ਜੋ ਮੌਜੂਦ ਹੀ ਨਹੀਂ ਹੈ, ਜਦੋਂ ਕਿ ਤੁਹਾਡਾ ਮਾਰਜਿਨ ਘਟ ਕੇ ਕੁਝ ਵੀ ਨਹੀਂ ਰਹਿ ਜਾਂਦਾ ਹੈ।
ਵੇਰਵੇ ਕਿੱਥੋਂ ਪ੍ਰਾਪਤ ਕੀਤੇ ਜਾਣ
ਸਹੀ ਨਵੀਆਂ ਦਰਾਂ, ਲਾਗੂ ਹੋਣ ਦੀਆਂ ਮਿਤੀਆਂ, ਅਤੇ ਪ੍ਰਭਾਵਿਤ ਮਾਡਲ ਤੀਰ (model tiers) ਅਧਿਕਾਰਤ Stream ਵਿੱਚ ਦਸਤਾਵੇਜ਼ੀਕ੍ਰਿਤ ਹਨ।