ਡਿਵੈਲਪਰਾਂ ਨੇ ਪਾਇਆ ਹੈ ਕਿ Claude ਦੀ prompt-caching ਚੁੱਪਚਾਪ ਫੇਲ ਹੋ ਸਕਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਜ਼ੀਰੋ cached tokens ਮਿਲਣ ਦੇ ਬਾਵਜੂਦ ਪ੍ਰੀਮੀਅਮ ਦਰਾਂ ਲਈ ਚਾਰਜ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇੱਕ WhatsApp ਹੈਂਡਲਰ 'ਤੇ ਇੱਕ ਹਫ਼ਤੇ ਦੇ ਲੌਗ ਰਨ ਨੇ ਕੋਈ ਵੀ cache reads ਨਹੀਂ ਦਿਖਾਏ, ਫਿਰ ਵੀ API ਨੇ caching ਫੀਚਰ ਲਈ ਬਿਲਿੰਗ ਕੀਤੀ—ਜਿਸ ਨਾਲ ਮਹੀਨਾਵਾਰ ਲਾਗਤ $1,890 ਤੋਂ ਘਟ ਕੇ $406 ਰਹਿ ਗਈ।

ਇਹ ਸਮੱਸਿਆ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ

Prompt caching ਦਾ ਮਕਸਦ prompt ਦੇ ਇੱਕ ਸਥਿਰ ਹਿੱਸੇ (ਜਿਸ ਨੂੰ “prefix” ਕਿਹਾ ਜਾਂਦਾ ਹੈ) ਨੂੰ ਦੁਬਾਰਾ ਵਰਤ ਕੇ ਲਾਗਤਾਂ ਨੂੰ ਘਟਾਉਣਾ ਅਤੇ ਜਵਾਬਾਂ ਦੀ ਰਫ਼ਤਾਰ ਵਧਾਉਣਾ ਹੈ। ਜਦੋਂ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ, ਤਾਂ ਉੱਚ-ਟ੍ਰੈਫਿਕ ਵਾਲੀਆਂ ਐਪਸ ਆਪਣੇ ਮਹੀਨਾਵਾਰ ਬਿੱਲਾਂ ਵਿੱਚ ਸੈਂਕੜੇ ਡਾਲਰਾਂ ਦੀ ਬਚਤ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਜਦੋਂ ਇਹ ਕੰਮ ਨਹੀਂ ਕਰਦਾ, ਤਾਂ ਡਿਵੈਲਪਰ ਉਸ ਫੀਚਰ ਲਈ ਪੈਸੇ ਦਿੰਦੇ ਹਨ ਜਿਸਦੀ ਉਹ ਅਸਲ ਵਿੱਚ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੇ, ਅਤੇ ਇਹ ਚੁੱਪਚਾਪ ਹੋਣ ਵਾਲੀ ਅਸਫਲਤਾ ਸਮੱਸਿਆ ਦਾ ਇਸ਼ਾਰਾ ਦੇਣ ਲਈ ਕੋਈ ਗਲਤੀ (error) ਜਾਂ ਚੇਤਾਵਨੀ ਨਹੀਂ ਦਿੰਦੀ।

ਬੱਗ (bug) ਕਿਵੇਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ

API ਇੱਕ cache-control flag ਅਤੇ ਇੱਕ prefix ਸਵੀਕਾਰ ਕਰਦੀ ਹੈ, ਫਿਰ ਦੱਸਦੀ ਹੈ ਕਿ cache ਤੋਂ ਕਿੰਨੇ tokens ਪੜ੍ਹੇ ਗਏ ਸਨ। ਦੇਖੇ ਗਏ ਮਾਮਲੇ ਵਿੱਚ, ਹਰ ਰਿਕਵੈਸਟ ਨੇ cache-read count ਜ਼ੀਰੋ ਦਿਖਾਇਆ। ਕਾਲ ਸਫਲ ਰਹੀ, ਕੋਈ exception ਨਹੀਂ ਆਇਆ, ਅਤੇ ਬਿਲਿੰਗ ਵਿੱਚ ਪ੍ਰੀਮੀਅਮ cache ਦੀ ਲਾਗਤ ਸ਼ਾਮਲ ਸੀ। ਇਹ ਅਸਫਲਤਾ ਉਦੋਂ ਤੱਕ ਦਿਖਾਈ ਨਹੀਂ ਦਿੰਦੀ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ read count ਨੂੰ log ਨਹੀਂ ਕਰਦੇ।

ਉਹ ਆਮ ਤਰੀਕੇ ਜਿਨ੍ਹਾਂ ਨਾਲ cache ਟੁੱਟ ਜਾਂਦਾ ਹੈ

  • Prefix ਬਹੁਤ ਛੋਟਾ ਹੈ – ਹਰ Claude ਮਾਡਲ cacheable prefix ਲਈ ਇੱਕ ਘੱਟੋ-ਘੱਟ token ਲੰਬਾਈ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ। Haiku 4.5 ਨੂੰ ਘੱਟੋ-ਘੱਟ 4,096 tokens ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ; Sonnet 4.6 ਨੂੰ ਸਿਰਫ਼ 1,024 ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਛੋਟਾ prefix ਭੇਜਣ ਨਾਲ ਰਿਕਵੈਸਟ ਫਾਰਮੈਟ ਤਾਂ ਪੂਰਾ ਹੋ ਜਾਂਦਾ ਹੈ ਪਰ ਸਰਵਿਸ cache ਨਿਰਦੇਸ਼ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਦਿੰਦੀ ਹੈ।
  • ਇੱਕ ਬਦਲਣਯੋਗ byte ਬਦਲ ਜਾਂਦਾ ਹੈ – Caching ਲਈ ਬਿਲਕੁਲ byte-for-byte ਮੈਚ ਹੋਣਾ ਜ਼ਰੂਰੀ ਹੈ। ਸਿਸਟਮ prompt ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ timestamp, new Date(), ਜਾਂ ਯੂਜ਼ਰ ਈਮੇਲ ਵਰਗਾ ਕੋਈ ਡਾਇਨਾਮਿਕ ਤੱਤ ਜੋੜਨ ਨਾਲ byte sequence ਬਦਲ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਹਰ ਰਿਕਵੈਸਟ ਨੂੰ ਇੱਕ ਨਵੀਂ, uncached ਲਿਖਤ ਵਜੋਂ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ।
  • Tool list ਦਾ ਕ੍ਰਮ ਬਦਲ ਜਾਂਦਾ ਹੈ – Tools ਨੂੰ prompt ਦੇ ਅੱਗੇ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ। ਜੇਕਰ tool array ਨੂੰ object keys ਤੋਂ ਬਣਾਇਆ ਗਿਆ ਹੈ, ਤਾਂ ਕਾਲਾਂ ਦੇ ਵਿਚਕਾਰ iteration order ਵੱਖਰਾ ਹੋ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ byte layout ਬਦਲ ਜਾਂਦਾ ਹੈ ਅਤੇ cache ਟੁੱਟ ਜਾਂਦਾ ਹੈ।

ਹੱਲ ਜੋ ਤੁਸੀਂ ਅੱਜ ਹੀ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹੋ

  • Prefix ਲੰਬਾਈ ਦੀ ਜਾਂਚ ਕਰੋ – ਰਿਕਵੈਸਟ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ, ਮਾਡਲ ਦੀ ਘੱਟੋ-ਘੱਟ ਲੰਬਾਈ ਦੇ ਮੁਕਾਬਲੇ prefix ਦੇ token count ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਓ। ਜੇਕਰ ਇਹ ਘੱਟ ਹੈ ਤਾਂ prefix ਨੂੰ ਰੱਦ ਕਰ ਦਿਓ ਜਾਂ ਉਸ ਵਿੱਚ ਕੁਝ ਜੋੜ ਕੇ ਲੰਬਾ ਕਰ ਦਿਓ।
  • ਹਰ ਕਾਲ 'ਤੇ cache reads ਨੂੰ log ਕਰੋ – “cache read tokens” ਫੀਲਡ ਨੂੰ ਰਿਕਾਰਡ ਕਰੋ। ਲਗਾਤਾਰ ਜ਼ੀਰੋ ਆਉਣਾ ਇਸ ਗੱਲ ਦਾ ਸਪੱਸ਼ਟ ਸੰਕੇਤ ਹੈ ਕਿ cache ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਹੋ ਰਹੀ।
  • Prompt ਦੇ ਸ਼ੁਰੂਆਤੀ bytes ਨੂੰ ਫ੍ਰੀਜ਼ ਕਰੋ – ਡਾਇਨਾਮਿਕ ਡੇਟਾ ਨੂੰ cached segment ਤੋਂ ਬਾਹਰ ਰੱਖੋ। ਜੇਕਰ ਤੁਹਾਨੂੰ ਯੂਜ਼ਰ-ਵਿਸ਼ੇਸ਼ ਜਾਣਕਾਰੀ ਸ਼ਾਮਲ ਕਰਨੀ ਹੀ ਪੈਂਦੀ ਹੈ, ਤਾਂ ਇਸਨੂੰ cached prefix ਤੋਂ ਬਾਅਦ ਰੱਖੋ।
  • Model identifiers ਨੂੰ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ ਕਰੋ – ਯਕੀਨੀ ਬਣਾਓ ਕਿ routing ਵਿੱਚ ਵਰਤਿਆ ਗਿਆ model ID ਤੁਹਾਡੇ cache table ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ID ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ; ਮਿਲੇ-ਜੁਲੇ (mismatched) IDs cache lookup ਨੂੰ ਰੋਕਦੇ ਹਨ।

ਲਾਗਤ ਦਾ ਪਹਿਲੂ

ਇੱਕ ਅਜਿਹੀ ਐਪ ਲਈ ਜੋ ਰੋਜ਼ਾਨਾ ਹਜ਼ਾਰਾਂ ਕਾਲਾਂ ਕਰਦੀ ਹੈ, uncached ਤੋਂ cached 'ਤੇ ਜਾਣਾ ਮਹੀਨਾਵਾਰ ਖਰਚਿਆਂ ਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਘਟਾ ਸਕਦਾ ਹੈ—ਦਿਖਾਏ ਗਏ ਮਾਮਲੇ ਵਿੱਚ ਲਗਭਗ $1,890 ਤੋਂ $406 ਤੱਕ। ਮਾਮੂਲੀ ਟ੍ਰੈਫਿਕ ਵਿੱਚ ਵੀ ਮਹੱਤਵਪੂਰਨ ਬਚਤ ਦੇਖਣ ਨੂੰ ਮਿਲਦੀ ਹੈ, ਅਤੇ ਇੱਕ ਵੱਡੇ ਸਥਿਰ prompt ਨੂੰ ਦੁਬਾਰਾ ਵਰਤਣ ਨਾਲ ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਸੁਧਾਰ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ latency ਘਟ ਸਕਦੀ ਹੈ।

ਵਿਰੋਧੀ ਪੱਖ

ਹਾਲਾਂਕਿ, ਅਸਫਲਤਾ ਦੀ ਚੁੱਪਚਾਪ ਕੁਦਰਤ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਦਾ ਇੱਕੋ ਇੱਕ ਤਰੀਕਾ ਕਿ ਤੁਸੀਂ ਜ਼ਿਆਦਾ ਪੈਸੇ ਨਹੀਂ ਦੇ ਰਹੇ, read count ਦੀ ਜਾਂਚ ਕਰਨਾ ਹੈ—ਕੁਝ ਅਜਿਹਾ ਜਿਸ ਨੂੰ ਬਹੁਤ ਸਾਰੇ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਦਿੰਦੇ ਹਨ।

ਅੱਗੇ ਕੀ ਦੇਖਣਾ ਹੈ

  • Metric dashboards – ਰਿਕਵੈਸਟ ਵੌਲਯੂਮ ਦੇ ਨਾਲ cache-read tokens ਲਈ ਇੱਕ ਗੇਜ (gauge) ਜੋੜੋ।
  • Tool-ordering stability – ਜੇਕਰ ਤੁਸੀਂ ਡਾਇਨਾਮਿਕ ਤੌਰ 'ਤੇ ਤਿਆਰ ਕੀਤੀਆਂ ਗਈਆਂ tool lists 'ਤੇ ਨਿਰਭਰ ਹੋ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ prompt ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਨਿਸ਼ਚਿਤ ਕ੍ਰਮ (deterministically) ਵਿੱਚ ਸੌਰਟ ਕਰਨ ਬਾਰੇ ਵਿਚਾਰ ਕਰੋ।

ਸਾਰ (Bottom line): Claude ਦੀ prompt caching ਉਦੋਂ ਕੋਈ error ਨਹੀਂ ਦਿੰਦੀ ਜਦੋਂ ਇਹ ਤੁਹਾਡੀ ਰਿਕਵੈਸਟ ਨੂੰ ਚੁੱਪਚਾਪ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਦਿੰਦੀ ਹੈ। Read tokens ਨੂੰ log ਕਰਕੇ cache ਦੀ ਪ੍ਰਭਾਵਸ਼ੀਲਤਾ ਦੀ ਜਾਂਚ ਕਰੋ, ਸਹੀ prefix ਲੰਬਾਈ ਲਾਗੂ ਕਰੋ, ਅਤੇ prompt ਦੇ ਸ਼ੁਰੂਆਤੀ bytes ਨੂੰ ਅਟੱਲ (immutable) ਰੱਖੋ। ਉਦੋਂ ਹੀ ਤੁਸੀਂ ਵਾਅਦਾ ਕੀਤੇ ਲਾਗਤ ਅਤੇ ਰਫ਼ਤਾਰ ਦੇ ਲਾਭ ਪ੍ਰਾਪਤ ਕਰ ਸਕੋਗੇ।