Magkano ang isang RAG na tanong: ilang chunk ang ipapadala

Gumagana ang iyong document chatbot, dumarating ang unang invoice, at mas malaki ito kaysa sa dapat bayaran ng mga tanong. Sa halos lahat ng RAG setup, isang lugar lang ang napupunta ang pera: ang mga retrieved chunk na ipinapasok mo sa harap ng bawat tanong. Ang isang RAG na tanong ay gumagastos ng tokens ng tanong, ng iyong mga instruksyon at N chunks sa input side, at ng maikling sagot sa output side. Ang mga chunk ang bahaging kontrolado mo, at bawat isa ay nagdadagdag ng parehong bilang ng tokens sa bawat request.

Binibilang ng gabay na ito ang isang request, pinopresyuhan ang 1,000 at 100,000 nito sa live na presyo, at ipinapakita kung ano ang nagbabago kapag inilipat mo ang top-k mula 3 patungong 10. Ang retrieval mismo (ang iyong vector store, ang iyong chunking) ay nananatili sa iyong panig; ang huling generation call lang ang napupunta sa model API. Kung bago sa iyo ang input at output billing, magsimula sa input vs output tokens.

Ano ang nasa isang RAG request#

Sabihin nating may support bot ka sa mga dokumento ng kumpanya. May customer na nagtanong, "How do I reset two-factor login?", nagbalik ang retriever mo ng limang pinakamagandang passage, at ipinadala mo ito sa model:

• isang system prompt: "Answer only from the context. If it is not there, say so." — mga 300 tokens kapag naidagdag na ang formatting rules;
• ang tanong kasama ang kaunting chat context — mga 200 tokens;
• 5 chunks na mga 500 tokens bawat isa — 5 × 500 = 2,500 tokens;
• ang sagot: dalawa o tatlong maiikling talata — mga 300 tokens out.

Ang input side ay 2,500 + 300 + 200 = 3,000 tokens, ang output side mga 300. Ito ang mga assumption ng may-akda para sa isang tipikal na support bot; palitan ng sarili mong numero. Lahat ng nasa ibaba ay gumagamit ng isang request na ito bilang unit.

Ang mabilis na paraan para makita ang hugis: ang mga chunk ay halos limang-ikaanim ng buong input, at ang input ay sampung beses ng sagot. Subukan mo mismo ang estimate:

Magkano ang 1,000 tanong#

Masyadong maliit ang isang request para maramdaman, kaya i-scale ito. Sa 3,000 tokens in at 300 out, ang 1,000 tanong ay nagpapadala ng 3,000,000 input tokens at gumagawa ng 300,000 output tokens. I-drag ang mga slider sa ibaba para tumugma sa sarili mong bot; muling kinakalkula ng site sa live na presyo para sa bawat model.

Ipinapakita ng table ang parehong workload para sa lahat ng tatlong model, kasama ang OpenRouter reference sa tabi nito. Kung bibilangin sa kabuuan, kasama ang input at output, mas mura ang bawat isa sa kanila kaysa sa OpenRouter dito.

At sa 100,000 tanong? Iyon ay 300,000,000 tokens in at 30,000,000 out. Sa DeepSeek-V4-Flash iyon ay $7.50, sa GLM-5.3-Flash $7.20, sa MiniMax-M2.7 $19.50. Ang mga presyo ay fixed per model, walang peak hours, kaya ang night batch at daytime chat ay pareho ang gastos per token. Tingnan ang buong listahan ng presyo sa the pricing page.

Top-k: bawat chunk ay nagdadagdag ng parehong halaga#

Narito ang pangalawang senaryo: isang internal wiki assistant. May nagmungkahi, "Magpadala tayo ng 10 chunks sa halip na 3, para sure." Ang input ay lumalaki sa tuwid na linya: bawat chunk ay dagdag na 500 tokens sa bawat request.

2,000 laban sa 5,500 tokens: pareho ang haba ng sagot, kaya ang buong pagkakaiba sa bill ng wiki assistant ay input. Kung nakakakuha ka ba ng mas magandang sagot ay tanong ng kalidad: lampas sa punto kung saan nasa context na ang tamang passage, ang dagdag na chunk ay kadalasang nagdadagdag ng ingay at gastos. Praktikal na paraan para pumili ng k: kumuha ng set ng totoong tanong, tingnan kung sa anong k lumalabas ang tamang passage, at huminto nang kaunti sa itaas nito.

Ang context window ang isa pang limitasyon. Lahat ng tatlong model dito ay may sapat na espasyo para sa ordinaryong top-k: 180K tokens para sa MiniMax-M2.7, 380K para sa DeepSeek-V4-Flash at 390K para sa GLM-5.3-Flash. Magkaiba ang output limits: hanggang 8,192 tokens bawat sagot para sa GLM-5.3-Flash at MiniMax-M2.7, hanggang 32,768 para sa DeepSeek-V4-Flash, na mahalaga kung ang mga sagot mo ay mahahabang report kaysa maiikling tugon.

Ang buong dokumento sa prompt, o apat na chunk#

Pangatlong senaryo: contract Q&A. Ang tamad na bersyon ay nagpapasok ng buong 30,000-token na PDF sa bawat tanong. Ang retrieval na bersyon ay nagpapadala ng tanong, mga instruksyon at apat na relevant chunk na mga 650 tokens bawat isa, mga 3,000 tokens sa kabuuan. Parehong 1,000 tanong, parehong 300-token na sagot:

Ang buong dokumento ay nagpapadala ng sampung beses ng input, 30,000 ÷ 3,000 = 10, para sa parehong tanong. Makatuwiran pa rin ito para sa isang beses na tanong tungkol sa dokumentong kasya sa context. Para sa bot na sumasagot buong araw, ito ang mamahaling default. Kung marami sa input na iyon ay parehong teksto sa bawat pagkakataon, basahin ang tungkol sa prompt caching.

Ipadala ang request#

Nasa ibaba ang generation step. Ang retrieval part ay sa iyo: ang chunks ay kung ano man ang ibinalik ng vector store mo. Gumagana ang parehong code sa OpenAI SDK o plain curl.

from openai import OpenAI

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

chunks = ["Chunk 1 text...", "Chunk 2 text...", "Chunk 3 text..."]
context = "\n\n---\n\n".join(chunks)

resp = client.chat.completions.create(
    model="deepseek-ai/DeepSeek-V4-Flash-0731",
    max_tokens=400,
    messages=[
        {"role": "system", "content": "Answer only from the context. If the answer is not there, say so."},
        {"role": "user", "content": f"Context:\n{context}\n\nQuestion: How do I reset two-factor login?"},
    ],
)
print(resp.choices[0].message.content)
print(resp.usage.prompt_tokens, resp.usage.completion_tokens)

curl https://api.cheaptokens.dev/v1/chat/completions \
  -H "Authorization: Bearer YOUR_CHEAPTOKENS_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-ai/DeepSeek-V4-Flash-0731",
    "max_tokens": 400,
    "messages": [
      {"role": "system", "content": "Answer only from the context. If the answer is not there, say so."},
      {"role": "user", "content": "Context:\nChunk 1...\n\nQuestion: How do I reset two-factor login?"}
    ]
  }'

Ang huling linya ng Python example ang kapaki-pakinabang. Ang usage.prompt_tokens ay ang totoong input mo per tanong; ihambing ito sa 3,000 estimate at palitan ang mga assumption ko ng sarili mong numero. Gamitin ang buong model id, tulad ng sa example: deepseek-ai/DeepSeek-V4-Flash-0731. Nakalista ang mga id sa docs. Ang buong setup ay nasa the docs, at kung gusto mong makita kung paano nagdadagdag ang tokens ng bot sa isang dialogue, ang why a long chat costs more ay sumasaklaw sa history part.

Apat na paraan para paliitin ang input#

Magsimula sa max_tokens, na naglilimita sa sagot at nagpoprotekta sa iyo mula sa runaway reply. Pagkatapos, bawasan ang k sa pinakamaliit na value na nakakahanap pa rin ng tamang passage. Gawing mas tight ang mga chunk, para ang 500 tokens ay may dalang 500 tokens ng kahulugan at hindi headers at boilerplate. Alisin ang duplicate chunk bago ipadala: ang dalawang halos magkaparehong passage ay doble ang gastos at isang beses lang nagsasabi. At sukatin gamit ang usage sa totoong traffic, dahil ang hula tungkol sa 500-token chunk ay hula lang. Para sa mas malawak na pagtingin kung saan napupunta ang tokens sa isang API call, tingnan ang how many tokens a request uses.

Ilagay ang sarili mong tokens per request sa calculator sa itaas para mapresyuhan ang bot mo sa lahat ng tatlong model; kung mahahaba ang mga sagot mo, ang DeepSeek-V4-Flash ang unang tingnan.