ਪ੍ਰੋਂਪਟ ਕੈਸ਼ਿੰਗ (prompt caching) ਨੂੰ ਚਾਲੂ ਕਰਨ ਨਾਲ ਮੇਰਾ ਕੋਈ ਫਾਇਦਾ ਨਹੀਂ ਹੋਇਆ—ਬਲਕਿ, ਮੇਰਾ OpenAI-API ਇਨਵੌਇਸ ਲਗਭਗ ਇੱਕ ਚੌਥਾਈ ਵਧ ਗਿਆ। ਇਸਦਾ ਕਾਰਨ ਇੱਕ ਸਿੰਗਲ ਲਾਈਨ ਸੀ ਜੋ ਹਰ ਰਿਕੁਐਸਟ ਨਾਲ ਬਦਲ ਰਹੀ ਸੀ: ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ ਵਿੱਚ ਦਰਜ ਇੱਕ ਟਾਈਮਸਟੈਂਪ (timestamp)।
LLM ਪ੍ਰੋਵਾਈਡਰ ਟੋਕਨ-ਪ੍ਰੋਸੈਸਿੰਗ ਲਾਗਤਾਂ ਨੂੰ ਘਟਾਉਣ ਲਈ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਪ੍ਰੋਂਪਟ ਦੇ ਟੁਕੜਿਆਂ ਨੂੰ ਕੈਸ਼ (cache) ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ। ਇੱਕ ਕੈਸ਼ ਰੀਡ (ਇੱਕ “hit”) ਦੀ ਲਾਗਤ ਆਮ ਦਰ ਦੇ ਇੱਕ-ਦਸਵੇਂ ਹਿੱਸੇ ਜਿੰਨੀ ਘੱਟ ਹੁੰਦੀ ਹੈ, ਜਦੋਂ ਕਿ ਇੱਕ ਕੈਸ਼ ਰਾਈਟ (ਇੱਕ “miss”) ਦੀ ਲਾਗਤ ਲਗਭਗ ਆਮ ਕੀਮਤ ਦਾ 1.25 × ਹੁੰਦੀ ਹੈ। ਜੇਕਰ ਰਾਈਟ ਹੁੰਦੀ ਹੈ ਪਰ ਕੈਸ਼ ਕੀਤਾ ਗਿਆ ਟੁਕੜਾ ਕਦੇ ਪੜ੍ਹਿਆ ਨਹੀਂ ਜਾਂਦਾ, ਤਾਂ ਵਾਧੂ 25% ਚਾਰਜ ਬੇਕਾਰ ਜਾਂਦਾ ਹੈ। ਬਿਲਕੁਲ ਇਹੀ ਉਦੋਂ ਹੋਇਆ ਜਦੋਂ ਟਾਈਮਸਟੈਂਪ ਕਾਰਨ ਪ੍ਰੋਂਪਟ ਕਿਸੇ ਵੀ ਮੌਜੂਦਾ ਕੈਸ਼ ਐਂਟਰੀ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾ ਸਕਿਆ।
ਕੈਸ਼ਿੰਗ ਕਿਉਂ ਉਲਟਾ ਪੈ ਸਕਦੀ ਹੈ
ਪ੍ਰੋਂਪਟ ਕੈਸ਼ਿੰਗ ਕੈਸ਼ ਕੀਤੇ ਹਿੱਸੇ ਦੇ ਸਹੀ (exact) ਬਾਈਟ ਸੀਕੁਐਂਸ (byte sequence) ਨੂੰ ਮਿਲਾ ਕੇ ਕੰਮ ਕਰਦੀ ਹੈ। ਪ੍ਰੋਵਾਈਡਰ ਇਨਪੁਟ ਨੂੰ ਹੈਸ਼ (hash) ਕਰਦਾ ਹੈ; ਜੇਕਰ ਹੈਸ਼ ਕਿਸੇ ਸਟੋਰ ਕੀਤੇ ਐਂਟਰੀ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ, ਤਾਂ ਸਿਸਟਮ ਪਿਛਲੀ ਗਣਨਾ (computation) ਦੀ ਮੁੜ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਅਤੇ ਸਸਤੀ ਰੀਡ ਦਰ ਲਾਗੂ ਕਰਦਾ ਹੈ। ਕੋਈ ਵੀ ਤਬਦੀਲੀ—ਇੱਥੋਂ ਤੱਕ ਕਿ ਇੱਕ ਸਿੰਗਲ ਅੱਖਰ ਵੀ—ਮੇਲ ਨੂੰ ਤੋੜ ਦਿੰਦੀ ਹੈ ਅਤੇ ਇੱਕ ਨਵੀਂ ਗਣਨਾ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਦੀ ਹੈ, ਜਿਸਦਾ ਬਿੱਲ ਉੱਚੀ ਰਾਈਟ ਦਰ 'ਤੇ ਲਗਾਇਆ ਜਾਂਦਾ ਹੈ।
ਮੇਰੇ ਮਾਮਲੇ ਵਿੱਚ ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ ਇੱਥੋਂ ਸ਼ੁਰੂ ਹੋ ਰਿਹਾ ਸੀ:
Current session started: 2026-07-14T09:41:07Z
ਕਿਉਂਕਿ ਹਰ API ਕਾਲ ਲਈ ਟਾਈਮਸਟੈਂਪ ਅਪਡੇਟ ਹੋ ਰਿਹਾ ਸੀ, ਰਿਕੁਐਸਟ ਦੇ ਪਹਿਲੇ ਕੁਝ ਬਾਈਟ ਕਦੇ ਵੀ ਇੱਕੋ ਜਿਹੇ ਨਹੀਂ ਸਨ। ਪ੍ਰੋਵਾਈਡਰ ਨੇ ਹਰ ਕਾਲ ਨੂੰ ਇੱਕ ਨਵੀਂ ਕੈਸ਼ ਐਂਟਰੀ ਵਜੋਂ ਮੰਨਿਆ, ਰਾਈਟ ਪ੍ਰੀਮੀਅਮ ਲਗਾਇਆ, ਅਤੇ ਕਦੇ ਵੀ ਰੀਡ ਰਿਕਾਰਡ ਨਹੀਂ ਕੀਤਾ। ਨਤੀਜੇ ਵਜੋਂ cache_creation_input_tokens ਵਿੱਚ ਲਗਾਤਾਰ ਵਾਧਾ ਹੋਇਆ ਜਦੋਂ ਕਿ cache_read_input_tokens ਜ਼ੀਰੋ 'ਤੇ ਰਿਹਾ, ਜੋ ਕਿ ਇਸ ਗੱਲ ਦਾ ਸਪੱਸ਼ਟ ਸੰਕੇਤ ਸੀ ਕਿ ਕੈਸ਼ ਕਦੇ ਵੀ ਹਿੱਟ (hit) ਨਹੀਂ ਹੋ ਰਿਹਾ ਸੀ।
ਟੁੱਟੇ ਹੋਏ ਕੈਸ਼ ਦੀ ਪਛਾਣ ਕਿਵੇਂ ਕਰੀਏ
API ਦੁਆਰਾ ਦਿੱਤੇ ਗਏ ਵਰਤੋਂ ਲੌਗਸ (usage logs) ਦੋ ਮੁੱਖ ਕਾਊਂਟਰ ਦਿੰਦੇ ਹਨ:
- cache_creation_input_tokens – ਉਹ ਟੋਕਨ ਜਿਨ੍ਹਾਂ ਨੇ ਰਾਈਟ (write) ਨੂੰ ਟ੍ਰਿਗਰ ਕੀਤਾ।
- cache_read_input_tokens – ਉਹ ਟੋਕਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਰੀਡ (read) ਤੋਂ ਫਾਇਦਾ ਹੋਇਆ।
ਜਦੋਂ ਪਹਿਲਾ ਵਧਦਾ ਹੈ ਅਤੇ ਦੂਜਾ ਸਥਿਰ ਰਹਿੰਦਾ ਹੈ, ਤਾਂ ਕੈਸ਼ ਦੀ ਮੁੜ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੀ ਜਾ ਰਹੀ ਹੁੰਦੀ। ਇੱਕ ਤੇਜ਼ ਸੈਨਿਟੀ ਚੈੱਕ (sanity check) ਇਹ ਹੈ ਕਿ ਬਿਲਕੁਲ ਉਹੀ ਰਿਕੁਐਸਟ ਦੋ ਵਾਰ ਦੁਹਰਾਓ; ਜੇਕਰ ਕੈਸ਼ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ, ਤਾਂ ਦੂਜੀ ਕਾਲ ਵਿੱਚ ਰੀਡ ਟੋਕਨਾਂ ਵਿੱਚ ਵਾਧਾ ਦਿਖਾਈ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ।
ਸਮੱਸਿਆ ਦਾ ਹੱਲ
ਹੱਲ ਸਧਾਰਨ ਹੈ: ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਕੈਸ਼ ਕੀਤਾ ਗਿਆ ਖੇਤਰ ਕਾਲਾਂ ਦੌਰਾਨ ਸਟੈਟਿਕ (static) ਰਹੇ। ਇਹਨਾਂ ਦੋ ਨਿਯਮਾਂ ਦੀ ਪਾਲਣਾ ਕਰੋ:
- ਨਾ-ਬਦਲਣਯੋਗ (immutable) ਸਮੱਗਰੀ ਨੂੰ ਪਹਿਲਾਂ ਰੱਖੋ। ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ, ਟੂਲ ਡੈਫੀਨੇਸ਼ਨ, ਜਾਂ ਕੋਈ ਵੀ ਹਦਾਇਤ ਜੋ ਕਦੇ ਨਹੀਂ ਬਦਲਦੀ, ਰਿਕੁਐਸਟ ਦੇ ਸ਼ੁਰੂਆਤੀ ਬਾਈਟਾਂ ਵਿੱਚ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
- ਬਦਲਣਯੋਗ (mutable) ਸਮੱਗਰੀ ਨੂੰ ਅਖੀਰ ਵਿੱਚ ਲਗਾਓ। ਟਾਈਮਸਟੈਂਪ, ਯੂਜ਼ਰ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਟੈਕਸਟ, ਰਿਕੁਐਸਟ ID, ਜਾਂ ਕੋਈ ਵੀ ਡੇਟਾ ਜੋ ਹਰ ਕਾਲ ਦੇ ਨਾਲ ਬਦਲਦਾ ਹੈ, ਕੈਸ਼ ਕੀਤੇ ਸੈਗਮੈਂਟ ਤੋਂ ਬਾਅਦ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ।
ਜੇਕਰ ਇੱਕ ਅੱਖਰ ਵੀ ਬਦਲਦਾ ਹੈ, ਤਾਂ ਹੈਸ਼ ਬਦਲ ਜਾਂਦਾ ਹੈ ਅਤੇ ਕੈਸ਼ ਮਿਸ (cache miss) ਬਣਿਆ ਰਹਿੰਦਾ ਹੈ। ਪ੍ਰੋਂਪਟ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਮੁੜ ਵਿਵਸਥਿਤ ਕਰਨਾ ਕਿ ਟਾਈਮਸਟੈਂਪ ਅਖੀਰ ਵਿੱਚ ਹੋਵੇ, ਕੈਸ਼ ਹਿੱਟ ਰੇਟ ਨੂੰ ਬਹਾਲ ਕਰਦਾ ਹੈ ਅਤੇ ਬਿੱਲ ਨੂੰ ਉਮੀਦ ਕੀਤੇ ਘੱਟ-ਲਾਗਤ ਪੱਧਰ 'ਤੇ ਵਾਪਸ ਲਿਆਉਂਦਾ ਹੈ।
ਕੈਸ਼ਿੰਗ ਅਸਲ ਵਿੱਚ ਕਦੋਂ ਮਦਦ ਕਰਦੀ ਹੈ
ਪ੍ਰੋਂਪਟ ਕੈਸ਼ਿੰਗ ਉਹਨਾਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਸ਼ਾਨਦਾਰ ਕੰਮ ਕਰਦੀ ਹੈ ਜਿੱਥੇ ਇੱਕੋ ਜਿਹੇ ਹਦਾਇਤਾਂ ਦੇ ਸੈੱਟ ਦੀ ਕਈ ਵਾਰ ਮੁੜ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ:
- ਏਜੰਟ ਲੂਪਸ (Agent loops) ਜਿੱਥੇ ਇੱਕ AI ਵਾਰ-ਵਾਰ ਟੂਲਜ਼ ਦੇ ਇੱਕ ਨਿਸ਼ਚਿਤ ਸੈੱਟ ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ।
- ਚੈਟ ਸੈਸ਼ਨ ਜੋ ਇੱਕ ਲੰਬੇ, ਸਟੈਟਿਕ ਦਸਤਾਵੇਜ਼ ਦਾ ਹਵਾਲਾ ਦਿੰਦੇ ਹਨ ਜਦੋਂ ਕਿ ਸਿਰਫ ਯੂਜ਼ਰ ਦੀ ਤਾਜ਼ਾ ਕੁਐਰੀ (query) ਬਦਲਦੀ ਹੈ।
- ਬਲਕ ਡੇਟਾ ਐਕਸਟਰੈਕਸ਼ਨ (Bulk data extraction) ਜਿੱਥੇ ਇੱਕੋ ਜਿਹੇ ਪਾਰਸਿੰਗ ਪ੍ਰੋਂਪਟ ਨੂੰ ਕਈ ਰਿਕਾਰਡਾਂ 'ਤੇ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਸਿੰਗਲ-ਸ਼ੌਟ ਕਾਲਾਂ ਲਈ ਜਿਸ ਵਿੱਚ ਹਰ ਵਾਰ ਇੱਕ ਨਵਾਂ ਸੰਦਰਭ (context) ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ—ਜਿਵੇਂ ਕਿ ਇੱਕ ਵਿਲੱਖਣ
ਕੁਝ ਡਿਵੈਲਪਰਾਂ ਦਾ ਤਰਕ ਹੈ ਕਿ ਸਟੈਟਿਕ (static) ਬਨਾਮ ਡਾਇਨਾਮਿਕ (dynamic) ਪ੍ਰੋਂਪਟ ਹਿੱਸਿਆਂ ਨੂੰ ਪ੍ਰਬੰਧਿਤ ਕਰਨ ਦੀ ਜਟਿਲਤਾ ਬਚਤ ਨਾਲੋਂ ਵੱਧ ਹੈ। ਇਹ ਵਿਚਾਰ ਇਸ ਤੱਥ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦਾ ਹੈ ਕਿ ਬਹੁਤ ਸਾਰੀਆਂ ਪ੍ਰੋਡਕਸ਼ਨ ਪਾਈਪਲਾਈਨਾਂ ਪਹਿਲਾਂ ਹੀ ਕੌਂਫਿਗਰੇਸ਼ਨ (ਸਟੈਟਿਕ) ਨੂੰ ਯੂਜ਼ਰ ਡੇਟਾ (ਡਾਇਨਾਮਿਕ) ਤੋਂ ਵੱਖ ਕਰਦੀਆਂ ਹਨ। ਪ੍ਰੋਂਪਟਾਂ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਨਾਲ ਢਾਂਚਾ ਦੇ ਕੇ, ਉਹੀ ਕੈਸ਼ਿੰਗ ਮਕੈਨਿਜ਼ਮ ਜੋ API ਦੇ ਮੂਲ ਡਿਵੈਲਪਰਾਂ ਦੀ ਬਚਤ ਕਰ ਸਕਦਾ ਸੀ, ਬਿਨਾਂ ਕਿਸੇ ਵਾਧੂ ਕੋਸ਼ਿਸ਼ ਦੇ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਇਸ ਦਾ ਸਮਝੌਤਾ ਪ੍ਰੋਂਪਟ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਇੱਕ ਮਾਮੂਲੀ ਅਨੁਸ਼ਾਸਨ ਹੈ, ਨਾ ਕਿ ਤਕਨਾਲੋਜੀ ਵਿੱਚ ਕੋਈ ਮੂਲ ਖਾਮੀ।
ਅੱਗੇ ਕੀ ਦੇਖਣਾ ਹੈ
- ਦੋਵੇਂ ਕੈਸ਼ ਕਾਊਂਟਰਾਂ ਦੀ ਨਿਗਰਾਨੀ ਆਪਣੇ ਵਰਤੋਂ ਡੈਸ਼ਬੋਰਡ ਵਿੱਚ ਹਫ਼ਤਾਵਾਰੀ ਤੌਰ 'ਤੇ ਕਰੋ।
- ਪ੍ਰੋਂਪਟ ਉਸਾਰੀ ਦੀ ਜਾਂਚ (Audit) ਕਰੋ ਤਾਂ ਜੋ ਇਹ ਯਕੀਨੀ ਬਣਾਇਆ ਜਾ ਸਕੇ ਕਿ ਕੋਈ ਵੀ ਵੇਰੀਏਬਲ ਤੱਤ ਕੈਸ਼ ਕੀਤੇ ਬਲਾਕ ਤੋਂ ਬਾਅਦ ਆਉਂਦਾ ਹੈ।
- ਅਸਲ ਬਚਤ ਨੂੰ ਮਾਪਣ ਲਈ ਇੱਕ ਪ੍ਰਤੀਨਿਧ ਵਰਕਲੋਡ 'ਤੇ ਕੈਸ਼ਿੰਗ ਦੇ ਨਾਲ ਅਤੇ ਇਸ ਤੋਂ ਬਿਨਾਂ A/B ਟੈਸਟ ਚਲਾਓ।
- ਕਿਸੇ ਵੀ ਪ੍ਰੌਕਸੀ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਰੋਅ (raw) ਰਿਕਵੈਸਟ ਪੇਲੋਡਾਂ ਦੀ ਤੁਲਨਾ ਕਰਕੇ ਗੇਟਵੇ ਦੀ ਪੁਸ਼ਟੀ (Validate) ਕਰੋ।
ਮੁੱਖ ਗੱਲ (Takeaway)
ਪ੍ਰੋਂਪਟ ਕੈਸ਼ਿੰਗ LLM API ਦੀਆਂ ਲਾਗਤਾਂ ਨੂੰ ਕਾਫ਼ੀ ਘਟਾ ਸਕਦੀ ਹੈ, ਪਰ ਇਹ ਉਦੋਂ ਹੀ ਸੰਭਵ ਹੈ ਜੇਕਰ ਕੈਸ਼ ਕੀਤਾ ਗਿਆ ਹਿੱਸਾ ਸਾਰੀਆਂ ਕਾਲਾਂ ਵਿੱਚ ਬਿਲਕੁਲ ਇੱਕੋ ਜਿਹਾ ਹੋਵੇ। ਪ੍ਰੋਂਪਟ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਕੋਈ ਗਲਤ ਟਾਈਮਸਟੈਂਪ ਜਾਂ ਕੋਈ ਹੋਰ ਡਾਇਨਾਮਿਕ ਟੋਕਨ ਹਰ ਵਾਰ ਇੱਕ ਮਹਿੰਗੀ 'ਰਾਈਟ' (write) ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਮਜ਼ਬੂਰ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਬਿੱਲ ਵਧ ਜਾਂਦਾ ਹੈ। ਸਟੈਟਿਕ ਹਦਾਇਤਾਂ ਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਰੱਖ ਕੇ ਅਤੇ ਬਦਲਦੇ ਡੇਟਾ ਨੂੰ ਅੰਤ ਵਿੱਚ ਰੱਖ ਕੇ, ਤੁਸੀਂ ਕੈਸ਼ ਨੂੰ ਆਪਣਾ ਕੰਮ ਕਰਨ ਦੇ ਲਗਦੇ ਹੋ ਅਤੇ ਆਪਣੇ ਖਰਚਿਆਂ ਨੂੰ ਕੰਟਰੋਲ ਵਿੱਚ ਰੱਖਦੇ ਹੋ।