Claude Opus 5 ਦੀ ਨਵੀਂ prompt-caching API ਚੈਟ-ਸਟਾਈਲ ਐਪਸ ਲਈ ਟੋਕਨ ਬਿੱਲਾਂ ਨੂੰ ਕਾਫ਼ੀ ਘਟਾ ਦਿੰਦੀ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਮਾਡਲ ਨੂੰ ਬਦਲੇ ਹੋਏ ਟੈਕਸਟ ਨੂੰ ਦੁਬਾਰਾ ਪੜ੍ਹਨ ਤੋਂ ਬਚਾਉਂਦੀ ਹੈ। ਪਹਿਲੀ ਬੇਨਤੀ (request) ਲਈ ਥੋੜ੍ਹਾ ਜਿਹਾ ਵਾਧੂ ਖਰਚਾ ਲੱਗਦਾ ਹੈ; ਹਰ ਅਗਲੀ ਬੇਨਤੀ ਦੀ ਕੀਮਤ ਮੂਲ ਦਰ ਦਾ ਲਗਭਗ ਦਸਵਾਂ ਹਿੱਸਾ ਹੁੰਦੀ ਹੈ, ਜੋ ਕਿ ਵਾਰ-ਵਾਰ ਹੋਣ ਵਾਲੇ ਖਰਚੇ ਨੂੰ ਇੱਕ ਵਾਰ ਦੇ ਖਰਚੇ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ।
ਡਿਵੈਲਪਰ ਇੱਕੋ ਸ਼ਬਦਾਂ ਲਈ ਦੋ ਵਾਰ ਕਿਉਂ ਭੁਗਤਾਨ ਕਰਦੇ ਹਨ
ਜ਼ਿਆਦਾਤਰ ਗੱਲਬਾਤ ਵਾਲੇ ਇੰਟਰਫੇਸ (conversational interfaces) ਹਰ ਵਾਰ ਪੂਰਾ ਪ੍ਰੋਂਪਟ (prompt) ਦੁਬਾਰਾ ਬਣਾਉਂਦੇ ਹਨ: ਜਦੋਂ ਵੀ ਕੋਈ ਯੂਜ਼ਰ ਅਗਲਾ ਸਵਾਲ ਪੁੱਛਦਾ ਹੈ, ਤਾਂ 8,000-ਟੋਕਨ ਵਾਲਾ ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ, ਨਾਲ ਲੱਗੀਆਂ PDF ਫਾਈਲਾਂ ਅਤੇ ਪੂਰੀ ਗੱਲਬਾਤ ਦਾ ਇਤਿਹਾਸ ਇਕੱਠੇ ਮਾਡਲ ਕੋਲ ਜਾਂਦਾ ਹੈ। ਮਾਡਲ ਹਰ ਟੋਕਨ ਨੂੰ ਦੁਬਾਰਾ ਪ੍ਰੋਸੈਸ ਕਰਦਾ ਹੈ ਭਾਵੇਂ ਉਸ ਟੈਕਸਟ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਕਦੇ ਬਦਲਦਾ ਹੀ ਨਹੀਂ। ਮੌਜੂਦਾ ਕੀਮਤਾਂ ਅਨੁਸਾਰ, ਇਹ ਵਾਧੂ ਕੰਮ ਇੱਕ ਰੁਝੇਵੇਂ ਵਾਲੇ ਬੋਟ ਦੀ ਲਾਗਤ ਨੂੰ ਬਹੁਤ ਵਧਾ ਸਕਦਾ ਹੈ।
ਕੈਸ਼ (cache) ਕਿਵੇਂ ਗਣਿਤ ਨੂੰ ਬਦਲਦਾ ਹੈ
API ਇੱਕ ਨਿਰਧਾਰਤ ਬ੍ਰੇਕਪੁਆਇੰਟ (breakpoint) ਤੱਕ ਟੋਕਨਾਂ ਦੇ ਹਰ "ਬਲਾਕ" (block) ਲਈ ਇੱਕ ਕੈਸ਼ ਐਂਟਰੀ ਬਣਾਉਂਦੀ ਹੈ। ਜਦੋਂ ਅਗਲੀ ਬੇਨਤੀ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਉਹੀ ਬਲਾਕ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਸੇਵਾ ਇਸਨੂੰ ਦੁਬਾਰਾ ਟੋਕਨਾਈਜ਼ ਕਰਨ ਦੀ ਬਜਾਏ ਕੈਸ਼ ਤੋਂ ਪੜ੍ਹਦੀ ਹੈ। ਕੀਮਤਾਂ ਦਾ ਵੰਡਾਅ ਬਚੇ ਹੋਏ ਕੰਮ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ:
- Cache write – 5-minute TTL: 1.25 × base price
- Cache write – 1-hour TTL: 2 × base price
- Cache read (hit): 0.1 × base price
ਅਸਲ ਵਿੱਚ, ਇੱਕ ਨਵੇਂ ਬਲਾਕ ਲਈ ਪਹਿਲੀ ਕਾਲ ਦੀ ਕੀਮਤ ਇੱਕ ਆਮ ਬੇਨਤੀ ਨਾਲੋਂ ਥੋੜ੍ਹੀ ਜ਼ਿਆਦਾ ਹੁੰਦੀ ਹੈ। ਕੈਸ਼ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੀ ਹਰ ਅਗਲੀ ਕਾਲ 90% ਸਸਤੀ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਜਿਵੇਂ-ਜਿਵੇਂ ਗੱਲਬਾਤ ਲੰਬੀ ਹੁੰਦੀ ਜਾਂਦੀ ਹੈ, ਕੁੱਲ ਖਰਚਾ ਤੇਜ਼ੀ ਨਾਲ ਘਟਦਾ ਜਾਂਦਾ ਹੈ।
ਪ੍ਰੋਂਪਟਾਂ ਨੂੰ ਸਟ੍ਰਕਚਰ ਕਰਨ ਲਈ "ਸੁਨਹਿਰੀ ਨਿਯਮ"
ਕੈਸ਼ ਦੀ ਪ੍ਰਭਾਵਸ਼ੀਲਤਾ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਸਟੈਟਿਕ (static) ਅਤੇ ਡਾਇਨਾਮਿਕ (dynamic) ਸਮੱਗਰੀ ਨੂੰ ਕਿੱਥੇ ਰੱਖਦੇ ਹੋ। ਜੋ ਚੀਜ਼ਾਂ ਸਥਿਰ ਰਹਿੰਦੀਆਂ ਹਨ ਉਨ੍ਹਾਂ ਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਰੱਖੋ, ਅਤੇ ਜੋ ਹਮੇਸ਼ਾ ਬਦਲਦੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ ਉਨ੍ਹਾਂ ਨੂੰ ਅੰਤ ਵਿੱਚ ਰੱਖੋ। ਇੱਕ ਭਰੋਸੇਯੋਗ ਕ੍ਰਮ ਇਸ ਤਰ੍ਹਾਂ ਹੈ:
- Tools – ਕਿਸੇ ਵੀ ਬਾਹਰੀ ਫੰਕਸ਼ਨਾਂ ਦੀਆਂ ਪਰਿਭਾਸ਼ਾਵਾਂ ਜਿਨ੍ਹਾਂ ਨੂੰ ਮਾਡਲ ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ।
- System instructions – ਉੱਚ-ਪੱਧਰੀ ਵਿਵਹਾਰ ਜਿਸ ਦੀ ਤੁਸੀਂ ਮਾਡਲ ਤੋਂ ਉਮੀਦ ਕਰਦੇ ਹੋ।
- Documents – ਲੰਬਾ ਸੰਦਰਭ (context) ਜਿਵੇਂ ਕਿ PDF, ਗਿਆਨ ਅਧਾਰ (knowledge bases), ਜਾਂ ਨੀਤੀਆਂ ਦੇ ਅੰਸ਼।
- User questions – ਲਾਈਵ ਸਵਾਲ ਜੋ ਹਰ ਵਾਰ ਬਦਲਦਾ ਰਹਿੰਦਾ ਹੈ।
ਜੇਕਰ ਤੁਸੀਂ ਬ੍ਰੇਕਪੁਆਇੰਟ ਤੋਂ ਪਹਿਲਾਂ ਕਿਸੇ ਵੀ ਟੋਕਨ ਨੂੰ ਬਦਲਦੇ ਹੋ, ਤਾਂ ਕੈਸ਼ ਐਂਟਰੀ ਅਯੋਗ ਹੋ ਜਾਂਦੀ ਹੈ ਅਤੇ ਮਾਡਲ ਨੂੰ ਉਸ ਤੋਂ ਬਾਅਦ ਦੀ ਹਰ ਚੀਜ਼ ਨੂੰ ਦੁਬਾਰਾ ਪ੍ਰੋਸੈਸ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।
ਲੁਕੀਆਂ ਹੋਈਆਂ ਸੀਮਾਵਾਂ ਜਿਨ੍ਹਾਂ ਦਾ ਤੁਹਾਨੂੰ ਧਿਆਨ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ
- Minimum block size – Opus 5 ਸਿਰਫ਼ ਉਹਨਾਂ ਬਲਾਕਾਂ ਨੂੰ ਕੈਸ਼ ਕਰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ 512 ਟੋਕਨ ਹੁੰਦੇ ਹਨ। ਇਸ ਤੋਂ ਛੋਟੀਆਂ ਚੀਜ਼ਾਂ ਕੈਸ਼ ਵਿੱਚ ਨਹੀਂ ਆਉਂਦੀਆਂ।
- Timestamp bug – ਕੈਸ਼ ਕੀਤੇ ਬਲਾਕ ਦੇ ਅੰਦਰ ਬਦਲਦਾ ਹੋਇਆ ਟਾਈਮਸਟੈਂਪ (timestamp) ਪਾਉਣ ਨਾਲ ਕੈਸ਼ ਮਿਸ ਹੋਣਾ ਯਕੀਨੀ ਹੈ, ਕਿਉਂਕਿ ਬਲਾਕ ਦਾ ਟੈਕਸਟ ਕਦੇ ਵੀ ਬਿਲਕੁਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ।
- 20-block look-back – ਸੇਵਾ ਮੇਲ ਲੱਭਣ ਲਈ ਸਿਰਫ਼ ਪਿਛਲੇ 20 ਬਲਾਕਾਂ ਦੀ ਜਾਂਚ ਕਰਦੀ ਹੈ। ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਚੱਲਣ ਵਾਲੇ ਸੈਸ਼ਨ ਜੋ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਦੇ ਹਨ, ਉਹ ਕੈਸ਼ ਵਿੰਡੋ ਤੋਂ ਬਾਹਰ ਜਾ ਸਕਦੇ ਹਨ।
- Parallel requests – ਇੱਕੋ ਸਮੇਂ ਕਈ ਇੱਕੋ ਜਿਹੇ ਰਿਕਵੈਸਟ ਭੇਜਣ ਨਾਲ ਸਾਰੀਆਂ ਫੇਲ ਹੋ ਜਾਣਗੀਆਂ, ਕਿਉਂਕਿ ਕੈਸ਼ ਪਹਿਲੀ ਰਿਕਵੈਸਟ ਖਤਮ ਹੋਣ ਤੋਂ ਬਾਅਦ ਹੀ ਭਰਿਆ ਜਾਂਦਾ ਹੈ। ਪਹਿਲਾਂ ਇੱਕ ਸਿੰਗਲ ਕਾਲ ਨਾਲ ਕੈਸ਼ ਨੂੰ ਵਾਰਮ (warm) ਕਰੋ, ਫਿਰ ਬਾਕੀ ਰਿਕਵੈਸਟਾਂ ਭੇਜੋ।
ਆਪਣੇ API ਰਿਸਪਾਂਸ ਵਿੱਚ ਬਚਤ ਦੇਖਣਾ
ਹਰ ਰਿਸਪਾਂਸ ਤਿੰਨ ਟੋਕਨ ਕਾਊਂਟਰ ਦੱਸਦਾ ਹੈ:
cache_read_input_tokens– ਉਹ ਟੋਕਨ ਜੋ ਕੈਸ਼ ਤੋਂ ਆਏ ਹਨ।cache_creation_input_tokens– ਇਸ ਰਿਕਵੈਸਟ ਵਿੱਚ ਕੈਸ਼ ਵਿੱਚ ਲਿਖੇ ਗਏ ਟੋਕਨ।input_tokens– ਨਵੇਂ ਟੋਕਨ ਜੋ ਕੈਸ਼ ਨਹੀਂ ਕੀਤੇ ਗਏ ਸਨ।
ਉਸ ਵਾਰ ਲਈ ਮਾਡਲ ਦੁਆਰਾ ਵਰਤੇ ਗਏ ਕੁੱਲ ਟੋਕਨਾਂ ਨੂੰ ਜਾਣਨ ਲਈ ਤਿੰਨਾਂ ਨੰਬਰਾਂ ਨੂੰ ਜੋੜੋ। ਜੇਕਰ ਦੋਵੇਂ ਕੈਸ਼ ਫੀਲਡ ਜ਼ੀਰੋ ਹਨ, ਤਾਂ ਰਿਕਵੈਸਟ ਕੈਸ਼ ਵਿੱਚ ਨਹੀਂ ਮਿਲੀ; ਆਪਣੇ ਬਲਾਕ ਦੇ ਆਕਾਰ ਅਤੇ ਬ੍ਰੇਕਪੁਆਇੰਟ ਦੀ ਸਥਿਤੀ ਦੀ ਜਾਂਚ ਕਰੋ।
ਸਿੱਖਿਆ (Takeaway): ਅਟੱਲ (immutable) ਸੰਦਰਭ ਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਰੱਖ ਕੇ ਅਤੇ Claude Opus 5 ਦੀ prompt-caching API ਨੂੰ ਮੁੱਖ ਕੰਮ ਕਰਨ ਦੇ ਕੇ, ਤੁਸੀਂ ਵਾਰ-ਵਾਰ ਹੋਣ ਵਾਲੇ ਟੋਕਨ ਖਰਚੇ ਨੂੰ ਇੱਕ ਵਾਰ ਦੇ ਖਰਚੇ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹੋ। ਇਸ ਦਾ ਨਤੀਜਾ ਕਿਸੇ ਵੀ ਚੈਟਬੋਟ ਲਈ ਲਾਗਤ ਵਿੱਚ ਭਾਰੀ ਕਮੀ ਹੈ ਜੋ ਵਾਰ-ਵਾਰ ਇੱਕੋ ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ ਜਾਂ ਦਸਤਾਵੇਜ਼ਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ—ਬਸ਼ਰਤੇ ਕਿ ਤੁਸੀਂ ਟੋਕਨ ਦੀ ਘੱਟੋ-ਘੱਟ ਸੀਮਾ ਦਾ ਸਤਿਕਾਰ ਕਰੋ, ਕੈਸ਼ ਕੀਤੇ ਬਲਾਕਾਂ ਦੇ ਅੰਦਰ ਬਦਲਣਯੋਗ ਮਾਰਕਰਾਂ ਤੋਂ ਬਚੋ, ਅਤੇ ਆਪਣੀ ਕੈਸ਼-ਯੋਗ ਸਮੱਗਰੀ ਨੂੰ 20-ਬਲਾਕ ਦੀ ਸੀਮਾ ਦੇ ਅੰਦਰ ਰੱਖੋ।