Ano ang prompt caching? Paano muling ginagamit ang paulit-ulit na prompt

Ang prompt caching ay nangangahulugang naaalala ng API ang simula ng iyong kahilingan at muling ginagamit ito sa susunod na ipadala mo ang parehong simula. Ipinapadala mo pa rin ang buong teksto sa bawat tawag, ngunit nalalaktawan ng provider ang pagbabasa muli ng paulit-ulit na bahagi, at ang ilang provider ay naniningil ng mas mababang rate para sa bahaging iyon. Gumagana lamang ito sa simula ng kahilingan, at kung ang simula ay magkapareho.

Ang support bot na paulit-ulit na binabasa ang parehong pahina#

Sabihin nating may support bot ka na may 2,000 ticket bawat araw. Bawat kahilingan ay nagsisimula sa parehong 3,000 token: tono ng boses, mga patakaran sa refund, patakaran sa pagpapadala. Pagkatapos nito ay ang isang linyang mensahe ng customer, tulad ng "Nasaan ang order ko?" (Kung malabo pa rin ang token, magsimula sa ano ang token.)

Kung walang caching, binabasa ng provider ang lahat ng 3,000 token ng mga patakaran muli para sa ticket number 1, ticket number 2, at ticket number 2,000. Parehong pahina, binasa ng 2,000 beses. Sa caching, ang unang kahilingan ay nagbabayad ng buong presyo ng pagbasa nito, at ang mga susunod na kahilingan na nagsisimula sa parehong teksto ay maaaring muling gamitin ang trabaho.

Ang API guide ng DeepSeek (sinuri noong 24 Oktubre 2026) ay naglalarawan nito mismo: ang context caching ay naka-on bilang default, hindi nangangailangan ng pagbabago sa code, at ang susunod na kahilingan na may magkakapatong na prefix ay itinuturing na "cache hit". Ang input lamang ang naka-cache. Ang sagot ay muling nililikha sa bawat pagkakataon.

Ano ang itinuturing na "pareho": ang tuntunin ng prefix#

Nagtutugma ang cache mula sa unang karakter pataas. Sa sandaling magkaiba ang iyong kahilingan sa naka-cache, ang lahat pagkatapos ng puntong iyon ay bago. Kaya mas mahalaga ang pagkakasunod-sunod ng iyong kahilingan kaysa sa haba nito.

Narito ang pagkakamaling tahimik na pumapatay sa caching. Gusto ng developer na malaman ng bot ang oras at inilalagay ito sa itaas:

Current time: 14:03:22
You are a support assistant for a shop...
(3,000 tokens of rules)

Nagbabago ang oras bawat segundo, kaya ang pinakaunang linya ay nagkakaiba sa bawat kahilingan, at wala nang makakatugma pagkatapos nito. Ang solusyon ay ilipat ang anumang nagbabago sa dulo:

You are a support assistant for a shop...
(3,000 tokens of rules)
Current time: 14:03:22
Customer: Where is my order?

Ngayon ang 3,000 token ng mga patakaran ay nauuna at nananatiling magkapareho. Ang parehong lohika ay sumasaklaw sa dalawang karaniwang kaso: ang mahabang chat ay muling nagpapadala ng buong kasaysayan nito sa bawat turn, kaya ang mga lumang mensahe ay handa nang paulit-ulit na simula (higit pa rito sa bakit mas mahal ang mahabang chat), at ang isang agent ay inuulit ang mga depinisyon ng tool at mga tagubilin nito sa bawat hakbang.

Ang caching ay best-effort din. Sinasabi ng DeepSeek na ang cache ay tumatagal ng ilang segundo upang mabuo, ang isang hit ay nangangailangan ng buong tugma ng isang umiiral na cache prefix unit, walang garantisadong hit rate, at ang mga hindi nagamit na cache ay nililinis, kadalasan sa loob ng ilang oras hanggang araw. Kaya ang pangalawang kahilingan na pinaputok kalahating segundo pagkatapos ng una ay maaaring hindi pa tumama, at ang hit ay maaaring mas mababa kaysa sa buong prefix mo.

Paano ito makikita: ang mga cache field sa usage#

Hindi mo kailangang hulaan kung gumana ito. Iniulat ito ng bawat provider sa usage bahagi ng tugon, sa ilalim ng sarili nitong mga pangalan ng field.

Gumagamit ang DeepSeek ng dalawang field:

• prompt_cache_hit_tokens — mga input token na natagpuan sa cache
• prompt_cache_miss_tokens — mga input token na hindi

Sabihin nating ang unang support ticket mo ay bumalik na may prompt_cache_hit_tokens: 0 at prompt_cache_miss_tokens: 3200, at ang isang ticket makalipas ang isang minuto ay nagpapakita ng prompt_cache_hit_tokens: 3000 at prompt_cache_miss_tokens: 200. Ang 3,000 token ng mga patakaran ay muling ginamit; ang bagong mensahe ng customer at ilang token lamang ang binasa mula sa simula. Kung ang hit number ay nananatiling zero sa bawat tawag, tingnan ang simula ng iyong kahilingan: may nagbabago doon.

Iba ang gumagana ang Anthropic, dahil minamarkahan mo kung ano ang i-cache. Nagdaragdag ka ng cache_control na may type na ephemeral sa kahilingan o sa isang content block:

{
  "model": "your-model-id",
  "max_tokens": 300,
  "system": [
    {
      "type": "text",
      "text": "You are a support assistant... (long rules)",
      "cache_control": {"type": "ephemeral"}
    }
  ],
  "messages": [{"role": "user", "content": "Where is my order?"}]
}

Ayon sa dokumentasyon ng prompt caching ng Anthropic (sinuri noong 24 Oktubre 2026), ang sagot ay nag-uulat ng tatlong numero: cache_creation_input_tokens (isinulat sa cache ngayon), cache_read_input_tokens (binasa mula rito), at input_tokens (ang dumating pagkatapos ng huling cache breakpoint). Sabihin nating ang unang tawag ay nagpapakita ng cache_creation_input_tokens: 10000, cache_read_input_tokens: 0; ang pangalawa ay nagpapakita ng 0 at 10000. Iyon ay isang cache write na sinusundan ng cache read.

May isang bitag sa screen. Ang mga prompt na mas maikli kaysa sa minimum ng modelo (512, 1,024 o 4,096 token, depende sa modelo) ay pinoproseso nang walang caching at walang error. Makikita mo ang mga zero sa parehong cache field at walang babala. Ang default na tagal ay 5 minuto, libreng nire-refresh sa bawat paggamit; ang opsyonal na ttl ng 1h ay nagpapanatili nito nang mas matagal.

Ano ang ginagawa nito sa iyong bill#

Binabago ng caching ang presyo ng paulit-ulit na bahagi, kaya sulit na bilangin minsan. Naglilista ang Anthropic ng mga multiplier sa base input price: ang cache write na may 5-minutong tagal ay nagkakahalaga ng 1.25×, ang read ay 0.1× (0.05× para sa Opus 5.5 at Sonnet 5.5). Kunin ang 10,000-token prefix na muling ginamit sa 20 kahilingan sa loob ng 5-minutong window, gamit ang standard na 0.1× read:

10,000 × 20 = 200,000 token sa base price na walang caching

10,000 × 1.25 = 12,500 para sa unang kahilingan na nagsusulat ng cache

19 × 10,000 × 0.1 = 19,000 para sa 19 na kahilingan na nagbabasa nito

12,500 + 19,000 = 31,500 token-equivalents na may caching

Kaya ang paulit-ulit na bahagi ay nagkakahalaga ng mas mababa sa ikalimang bahagi ng uncached na halaga. Ang catch: kung lumipas ang 5 minuto sa pagitan ng mga kahilingan, ang susunod ay muling nagsusulat ng cache sa 1.25×, at ang bihirang gamiting prefix ay maaaring maging mas mahal kaysa sa walang caching.

Ngayon ang bot mula sa simula, bilang plain full-price baseline. 2,000 kahilingan bawat araw, 3,000 input token at mga 300 output token bawat isa:

2,000 × 3,000 = 6,000,000 input token bawat araw

2,000 × 300 = 600,000 output token bawat araw

Ang talahanayan ay nagpepresyo sa workload ng araw na iyon sa bawat available na modelo ng CheapTokens katabi ng OpenRouter:

Ang DeepSeek-V4-Flash ay mas mura kaysa sa OpenRouter sa kabuuan, kasama ang input at output, at ang workload ay kasya nang madali: 380K context at hanggang 32,768 output token bawat sagot. Ito ang full-price na gastos ng workload: input token × presyo bawat token. Ang mahabang stable prefix ang pinakamalaking bahagi ng input.

Subukan ito sa loob ng limang minuto#

Ang plano: ipadala ang parehong mahabang system prompt nang dalawang beses na may magkaibang tanong at tingnan ang usage. Ilagay ang sarili mong teksto ng mga patakaran sa support_rules.txt (isang pahina o dalawa ay sapat). Ang endpoint ay ang OpenAI-compatible na CheapTokens API, at maaari mong kunin ang key mula sa iyong account.

from openai import OpenAI

client = OpenAI(base_url='https://api.cheaptokens.dev/v1', api_key='YOUR_API_KEY')

SYSTEM = open('support_rules.txt').read()  # long, never changes

for question in ['Where is my order?', 'Can I change the address?']:
    r = client.chat.completions.create(
        model='deepseek-ai/DeepSeek-V4-Flash-0731',
        messages=[
            {'role': 'system', 'content': SYSTEM},
            {'role': 'user', 'content': question},
        ],
        max_tokens=300,
    )
    print(r.usage)

Ano ang titingnan sa printout: sinasabi ng prompt_tokens kung gaano kalaki ang iyong kahilingan. Parehong may dalang SYSTEM teksto ang dalawang kahilingan, kaya karamihan ng numerong iyon ay nauulit mula sa isang kahilingan patungo sa susunod — halos kasinglaki ng file ng iyong mga patakaran. Ang paulit-ulit na simula na iyon ang bahaging maaaring muling gamitin ng provider na may caching, tulad ng DeepSeek API o Anthropic sa itaas. Ngayon isang ehersisyo sa pagkakasunod-sunod: magdagdag ng linya na may kasalukuyang oras (datetime.now()) sa itaas ng SYSTEM at patakbuhin muli. Hindi na magbabahagi ng simula ang dalawang kahilingan, dahil nagkakaiba sila mula sa pinakaunang linya. Ilagay ang parehong linya sa dulo ng prompt at bumalik ang shared start.

Isang maikling checklist para sa sarili mong mga prompt:

1. Stable na teksto muna: mga tagubilin, patakaran, depinisyon ng tool, halimbawa.
2. Nagbabagong teksto sa huli: petsa, pangalan ng user, pinakabagong mensahe.
3. Panatilihing byte-for-byte na magkapareho ang prefix — kahit isang dagdag na espasyo ay binibilang.
4. Tingnan ang minimum na laki ng provider bago magtaka kung bakit walang naka-cache.
5. Tingnan ang mga usage field pagkatapos ng pagbabago, hindi bago.

Upang maipresyo ang sarili mong workload, buksan ang pricing page at ilagay ang iyong input at output sizes, o magsimula sa DeepSeek page. Kapag gumana na ang unang kahilingan, ang parehong estimate ay tumatagal ng isang minuto para sa anumang prompt na isusulat mo. Para sa kung magkano ang dalawang panig ng isang kahilingan, tingnan ang input vs output tokens.