Input dhidi ya Output Tokens: Tofauti ya Gharama Claude

Kwa nini output tokens hugharimu zaidi ya input tokens

Output tokens hugharimu mara tano ya input tokens kwenye kila Claude model iliyo kwenye catalogue ya sasa. Sababu ni muundo wa computation. Kusoma prompt ni kupitisha model mara moja. Kuandika jibu ni kupitisha model mara moja kwa kila token, na kila upitishaji lazima usubiri uliotangulia ukamilike.

Uwiano huo ni sawa kwenye kila mstari wa price list. Kwa hiyo, model unayochagua haibadili kiasi cha bill yako kinachotokana na output. Muundo wa workload yako ndio huamua hilo. Hatua ya agent inayosoma tokens 60,000 na kujibu kwa tokens 800 hutumia karibu gharama yoyote kwenye output. Kazi ya drafting inayosoma tokens 2,000 na kuandika tokens 12,000 hutumia karibu gharama yoyote kwenye input. Hali zote mbili zimehesabiwa hapa chini kwa kutumia rates zilizochapishwa na Anthropic za August 2026.

Prefill huendeshwa mara moja, decoding huendeshwa mara moja kwa kila token

Seva ya inference hushughulikia ombi katika awamu mbili zenye gharama tofauti sana. Prefill husoma prompt. Decoding huandika jibu.

Prefill huchakata prompt yote kwa wakati mmoja. Kila token ya prompt huingia kwenye network katika forward pass ileile, kwa hiyo kazi ya attention na feed-forward huwa idadi ndogo ya matrix multiplication kubwa zinazohusisha maelfu ya token kwa wakati mmoja. Usomaji mmoja wa model weights kutoka kwenye memory unatosha kuhudumia prompt nzima. Matrix units za accelerator hubaki zikiwa na kazi, jambo linalomaanisha kuwa prefill ni compute-bound: kikomo ni kasi ambayo chip inaweza kufanya multiplication.

Decoding haiwezi kufanya hivyo, kwa sababu token 2 inategemea token 1. Token ambayo model imetengeneza hivi karibuni huwa sehemu ya input ya hatua inayofuata, kwa hiyo hatua hizo haziwezi kuendeshwa kwa wakati mmoja. Kila output token hupata forward pass yake, na kila pass husoma seti nzima ya model weights kutoka kwenye high-bandwidth memory ili kutengeneza token moja. Hilo hufanya decoding iwe memory-bound: kikomo ni kasi ya kuhamisha weights, si kasi ya kuzizidisha. Traffic ileile ya weights iliyohudumia prompt nzima wakati wa prefill hukutengenezea token moja wakati wa decoding.

Mifumo ya serving hukabiliana na hali hii kwa kutumia batching. Maombi mengi hufanya decoding pamoja, kwa hiyo usomaji mmoja wa weights hutengeneza token moja kwa kila ombi lililo kwenye batch. Ndiyo maana decoding inaweza kumudu gharama hiyo. Kikomo bado ni memory. Kila ombi linaloendelea hushikilia KV cache (key/value cache, hali ya attention iliyohifadhiwa kwa kila token hadi wakati huo), cache hiyo hukua kwa kila token inayotengenezwa, na inapojaza accelerator batch haiwezi kuongezeka zaidi.

Hakuna kati ya hayo kinachokupa nambari kamili, na hupaswi kuchukulia 5x kuwa ratio iliyopimwa ya hardware. Hiyo ni bei iliyowekwa na Anthropic, ikizingatia tofauti hiyo ya gharama. Unachoweza kuthibitisha mwenyewe ni mwelekeo huo, na huchukua takribani dakika moja.

Jipimie pengo la kuingiza na kutoa mwenyewe

Sakinisha zana kwenye kompyuta yoyote ya Ubuntu:

sudo apt update && sudo apt install -y curl jq moreutils

Sasa tuma prompt fupi inayoomba jibu refu, kisha weka muhuri wa muda kwenye kila mstari kwa kutumia muda uliofika.

curl -sN https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"claude-sonnet-5","max_tokens":1000,"stream":true,
       "messages":[{"role":"user","content":"Count from 1 to 300, one number per line."}]}' \
  | ts -s '%.s'

ts -s huweka mwanzoni mwa kila mstari idadi ya sekunde zilizopita tangu command ianze. Kuna mambo mawili muhimu ya kusoma kutoka kwenye matokeo hayo. Mstari wa kwanza wa content_block_delta unaonyesha muda hadi tokeni ya kwanza, na prefill yote ilifanyika ndani yake. Kila mstari unaofuata ni hatua moja ndogo ya decoding, na mihuri ya muda huendelea kuongezeka hadi message_stop ifike.

Sasa geuza muundo huo. Weka hati ndefu kwenye prompt na uweke kikomo cha jibu kuwa tokeni chache.

curl -sN https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d "$(jq -n --rawfile doc ./long-document.txt \
       '{model:"claude-sonnet-5", max_tokens:16, stream:true,
         messages:[{role:"user", content:("Answer in one word. Is this document about networking?\n\n" + $doc)}]}')" \
  | ts -s '%.s'

Delta ya kwanza inachukua muda mrefu kuliko ilivyokuwa kwa prompt fupi, kwa sababu prefill ina maandishi mengi zaidi ya kusoma. Baada ya kufika, jibu linaisha karibu mara moja, kwa sababu tokeni chache tu ndizo zinazosubiri kufanyiwa decoding. Makumi ya maelfu ya tokeni yaliingia, lakini saa karibu haikusogea. Mamia machache yalitoka, na saa iliendelea kuhesabu muda wote.

Kila jibu lisilotiririshwa huishia na nambari unazotozwa.

{
  "usage": {
    "input_tokens": 41283,
    "output_tokens": 6,
    "cache_creation_input_tokens": 0,
    "cache_read_input_tokens": 0
  }
}

Andika sehemu zote nne kwa kila request kwenye log. output_tokens inajumuisha extended thinking, kwa hiyo model inayofikiri kabla ya kujibu hutoza thinking hiyo kwa kiwango cha output. Ili kukadiria gharama ya prompt kabla ya kuituma, POST /v1/messages/count_tokens hukubali request body hiyo hiyo, hurudisha {"input_tokens": N} bila kuendesha model, na ni bure. Si sehemu pekee ya API isiyotozwa, na sehemu za Claude API ambazo hutozwi kamwe zinafaa kuchunguzwa kabla ya kupanga bajeti ya mradi wa kwanza.

Claude hutoza kiasi gani kwa kila token milioni kufikia Agosti 2026

[
  {
    "label": "Haiku 4.5",
    "input_usd": 1,
    "output_usd": 5,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5 (to 31 Aug)",
    "input_usd": 2,
    "output_usd": 10,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5 (from 1 Sep)",
    "input_usd": 3,
    "output_usd": 15,
    "output_multiple": 5
  },
  {
    "label": "Opus 5",
    "input_usd": 5,
    "output_usd": 25,
    "output_multiple": 5
  },
  {
    "label": "Fable 5",
    "input_usd": 10,
    "output_usd": 50,
    "output_multiple": 5
  }
]

Safu ya mwisho ni output iliyogawanywa kwa input, na inaonyesha 5 katika kila mstari. Haiku 4.5 hutoza $1 kwa input na $5 kwa output. Opus 5 hutoza $5 kwa input na $25 kwa output. Fable 5, ambayo ndiyo ghali zaidi, hutoza $10 kwa input na $50 kwa output, na kile ambacho viwango hivyo vya Fable 5 vinakununulia kinafaa kusomwa kabla hujaondoa safu hiyo ya juu. Kupanda katika kiwango hicho huzidisha pande zote mbili kwa kigezo kilekile, kwa hiyo hubadilisha jumla yako lakini huacha mgawanyo wa input na output kama ulivyokuwa.

Sonnet 5 inaonekana mara mbili kwa sababu kiwango chake cha utangulizi kinaisha. Hadi 31 Agosti 2026 hutoza $2 kwa input na $10 kwa output. Kuanzia 1 Septemba 2026, kiwango cha kawaida cha $3 kwa input na $15 kwa output kitatumika, ambacho ni 50% zaidi kwa pande zote mbili. Kila mfano uliohesabiwa hapa chini hutumia kiwango cha Agosti.

Viwango hubadilika, na ukurasa huu si mahali pa kuvithibitisha. claude.com/pricing ndio chanzo rasmi cha taarifa. Kinachobaki baada ya mabadiliko ya bei ni mbinu.

Kuna jambo moja ambalo orodha ya bei haionyeshi. Documentation ya Anthropic inasema kuwa Claude 4.7 na modeli za baadaye hutumia tokenizer mpya ambayo huzalisha takribani 30% zaidi ya token kwa maandishi yaleyale kuliko tokenizer ya Sonnet 4.6 na modeli za awali. Kulinganisha modeli mbili kwa bei ya token milioni pekee kutafanya mpya ionekane bora kuliko ilivyo, kwa sababu waraka uleule huwa na token nyingi zaidi kwenye modeli hiyo. Linganisha kwa gharama ya kukamilisha task halisi, na hesabu prompt zako halisi ukitumia modeli unayopanga kutumia. Mtego huohuo upo kati ya providers, ambao tokenizer zao hutofautiana kwa zaidi ya kiwango hicho, kwa hiyo kuhesabu gharama ya kazi halisi kwenye Claude na ChatGPT kunakupa taarifa zaidi kuliko kuweka rate card hizo mbili kando kwa kando. thamani ya token milioni moja za Claude katika maandishi halisi inaeleza jinsi kiasi hicho kinavyoonekana katika matumizi ya kawaida.

Ni wakati gani output huanza kutawala gharama yako?

Output ikiwa na bei ya mara 5 ya input, kiwango cha kusawazisha gharama ni rahisi kukikumbuka. Taja idadi ya input tokens kuwa I na output tokens kuwa O. Gharama ya input ni I. Gharama ya output ni mara 5 ya O. Output inazidi nusu ya matumizi yako wakati 5 mara O ni kubwa kuliko I, yaani uwiano wa tokens wa input 5 kwa output 1.

Kwa hiyo, ikiwa prompt yako ni ndefu zaidi ya mara tano kuliko jibu lako, input ndiyo kipengele kikubwa cha gharama. Chini ya hapo, output ndiyo kubwa.

[
  {
    "label": "100:1",
    "input_share_pct": 95.2,
    "output_share_pct": 4.8
  },
  {
    "label": "75:1",
    "input_share_pct": 93.75,
    "output_share_pct": 6.25
  },
  {
    "label": "20:1",
    "input_share_pct": 80,
    "output_share_pct": 20
  },
  {
    "label": "10:1",
    "input_share_pct": 66.7,
    "output_share_pct": 33.3
  },
  {
    "label": "5:1",
    "input_share_pct": 50,
    "output_share_pct": 50
  },
  {
    "label": "1:1",
    "input_share_pct": 16.7,
    "output_share_pct": 83.3
  },
  {
    "label": "1:6",
    "input_share_pct": 3.2,
    "output_share_pct": 96.8
  }
]

Kwa uwiano wa 100 kwa 1, output ni 4.8% ya gharama, na kufupisha prompt ndilo jambo pekee linalostahili kufanywa. Kwa uwiano wa 5 kwa 1, pande hizo mbili zina gharama sawa. Kwa uwiano wa 1 kwa 6, output ni 96.8% na prompt ina mchango mdogo sana katika jumla. Watu wengi hukadiria vibaya uwiano wao wenyewe, kwa hiyo toa takwimu hiyo kwenye logs zako kabla ya kuboresha chochote.

Mzigo wa kazi wa agent: muktadha mrefu unaingia, jibu fupi linatoka

Chukua hatua moja ya agent ya retrieval: tokeni 60,000 za nyaraka zilizorejeshwa na historia ya mazungumzo kama ingizo, kisha jibu la tokeni 800. Hiyo ni uwiano wa 75 kwa 1, ambao ni wa kawaida kwa kitu kinachosoma kabla ya kuandika.

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.06,
    "output_cost": 0.004,
    "total_cost": 0.064
  },
  {
    "label": "Sonnet 5 (Aug)",
    "input_cost": 0.12,
    "output_cost": 0.008,
    "total_cost": 0.128
  },
  {
    "label": "Opus 5",
    "input_cost": 0.3,
    "output_cost": 0.02,
    "total_cost": 0.32
  },
  {
    "label": "Fable 5",
    "input_cost": 0.6,
    "output_cost": 0.04,
    "total_cost": 0.64
  }
]

Output ni 6.25% ya gharama ya hiyo call kwa kila model, kwa sababu uwiano huo haubadiliki katika price list nzima. Call hiyo inagharimu $0.32 kwenye Opus 5, $0.128 kwenye Sonnet 5 kwa kiwango cha August, na $0.064 kwenye Haiku 4.5. Hatua mia mbili kama hizo kwa siku kwenye Opus 5 zinagharimu $64 kwa siku.

Lever inaonekana wazi ukishaona mgawanyo huo. Kupunguza jibu kutoka tokeni 800 hadi 400 huokoa takriban 3% ya gharama ya call. Kuondoa tokeni 20,000 za muktadha uliopitwa na wakati kwenye prompt huokoa takriban theluthi moja ya gharama hiyo. Kupunguza urefu wa output kwenye agent inayosoma zaidi kuliko inavyoandika ni karibu juhudi iliyopotea. tokeni za coding agent huenda wapi hasa inaeleza kinachojaza prompt hiyo mwanzoni.

Mzigo wa uundaji: prompt fupi, rasimu ndefu

Sasa badilisha muundo. Muhtasari wa token 2,000 na rasimu ya token 12,000, kwa uwiano wa 1 hadi 6.

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.002,
    "output_cost": 0.06,
    "total_cost": 0.062,
    "batch_total_cost": 0.031
  },
  {
    "label": "Sonnet 5 (Aug)",
    "input_cost": 0.004,
    "output_cost": 0.12,
    "total_cost": 0.124,
    "batch_total_cost": 0.062
  },
  {
    "label": "Opus 5",
    "input_cost": 0.01,
    "output_cost": 0.3,
    "total_cost": 0.31,
    "batch_total_cost": 0.155
  },
  {
    "label": "Fable 5",
    "input_cost": 0.02,
    "output_cost": 0.6,
    "total_cost": 0.62,
    "batch_total_cost": 0.31
  }
]

Output ni 96.8% ya bili hii. Opus 5 hugharimu $0.31 kwa kila rasimu, ikilinganishwa na $0.062 kwenye Haiku 4.5. Tofauti hiyo ya mara tano inatokana karibu kabisa na upande wa output, ambao ndipo model ya bei nafuu huokoa gharama zaidi.

Safu ya mwisho inaonyesha kazi hiyo hiyo kupitia Batch API, ambayo hupunguza gharama ya input na output kwa 50%. Opus 5 hushuka hadi $0.155 kwa kila rasimu. Batch hurudisha matokeo ndani ya saa 24 badala ya mara moja, kwa hiyo inafaa kwa uundaji wa ripoti za usiku na uainishaji wa kiasi kikubwa. Haifai kwa kazi ambayo mtu anakaa akisubiri matokeo.

Model routing huwa na faida hapa kwa njia ambayo haina kwenye hatua ya agent. Ikiwa sehemu ndefu ya kazi ni ya kimfumo, kama kupanga upya maandishi au kupanua outline ambayo tayari umeidhinisha, model ya bei nafuu huzalisha token hizo kwa theluthi moja ya tano ya gharama. kuchagua kati ya Opus, Sonnet na Haiku inaeleza mahali ambapo kiwango halisi cha ubora kinapatikana.

Caching hupunguza gharama ya input, na input pekee

Prompt caching huhifadhi prefix ya prompt yako kwenye server na hutoza sehemu ya kiwango cha input ili kuisoma tena. Kufikia August 2026, multipliers ni 1.25x ya kiwango cha msingi cha input kuandika cache ya dakika 5, 2x kuandika cache ya saa 1, na 0.1x kusoma cache hit.

Output haimo kwenye mpango huo. Hakuna output iliyohifadhiwa kwenye cache. Kila token ambayo model huandika hutozwa kwa kiwango kamili cha output kila mara, bila kujali ni kiasi gani cha prompt kilichorejeshwa kama cache hit.

Tumia agent step hiyo hiyo kwenye Opus 5, ambapo tokeni 55,000 kati ya tokeni 60,000 za input zinatolewa kutoka kwenye warm cache.

[
  {
    "label": "No cache",
    "input_cost": 0.3,
    "output_cost": 0.02,
    "total_cost": 0.32
  },
  {
    "label": "55k prefix cache read",
    "input_cost": 0.0525,
    "output_cost": 0.02,
    "total_cost": 0.0725
  }
]

Gharama ya call inashuka kutoka $0.32 hadi $0.0725. Mstari wa output haubadiliki: $0.02 kabla, na $0.02 baada. Caching hupunguza bill na kubadilisha muundo wake. Output ilikuwa 6.25% ya call hiyo. Sasa ni zaidi ya robo yake, jambo linalobadilisha lever inayofaa kuvutwa baadaye.

Call ya kwanza hulipia uandishi. Kuandika cache ya dakika 5 hugharimu 1.25x ya input ya msingi, kwa hiyo hujilipia baada ya hit moja. Kuandika cache ya saa 1 hugharimu 2x, kwa hiyo kunahitaji hit mbili. multipliers za uandishi na usomaji, na mahali caching inapoacha kujilipa inaeleza hesabu hiyo.

Mikakati minne unayoweza kudhibiti

1. Weka max_tokens kwenye urefu wa majibu wa p95, si kwenye kiwango cha juu cha modeli.
2. Peleka hatua zenye maelezo mengi kwenye modeli ya gharama nafuu.
3. Fanya kwa kundi kazi yoyote ambayo hakuna anayesubiri matokeo yake.
4. Futa maelekezo yanayoongeza urefu wa majibu.

max_tokens ni kikomo cha juu kisichoweza kuvukwa. Kukipanga kuwa juu hakugharimu chochote peke yake, kwa sababu unatozwa kwa tokeni zinazozalishwa, si kwa kiwango hicho cha juu. Kikomo kikubwa huondoa tu kizuizi kwenye jibu linalokwenda vibaya. Toa usambazaji wa output_tokens kutoka kwenye logs zako, weka kikomo hicho juu kidogo ya asilimia 95, kisha shughulikia stop_reason: "max_tokens" kwenye code kwa kuendeleza jibu au kujaribu tena. Ukataji unaogundua hugharimu chini ya maelezo marefu ya tokeni 4,000 ambayo unalipia kisha kuyatupa. Extended thinking pia huhesabiwa kwenye output_tokens, kwa hiyo weka bajeti hiyo kwa kutumia ushahidi huo huo.

Routing hufanya kazi wakati sehemu ya gharama kubwa ya hatua inatokana na wingi wa kazi, si uamuzi. Acha modeli imara ifanye uamuzi, kisha kabidhi uandishi kwa modeli ya bei nafuu. Pima toleo lililopitia routing kwenye evaluation set yako kwanza, kwa sababu modeli ya bei nafuu inayohitaji majaribio mawili hugharimu zaidi ya jaribio moja la modeli ghali.

Batching ndiyo mkakati pekee unaopunguza bei ya output. Punguzo la 50% kwa pande zote mbili, matokeo ndani ya saa 24, na kazi yoyote iliyoratibiwa inastahili.

Mkakati wa mwisho ndiyo ambao watu wengi huruka. Kauli kama "kuwa kamili" na "eleza mantiki yako" huweka urefu wa output kwenye kila call utakayowahi kufanya. Badala yake, taja muundo unaotaka: "Jibu kwa sentensi zisizozidi tatu", au "Rudisha JSON object pekee, bila preamble". System prompt inayoongeza tokeni 300 kwenye kila jibu hugharimu mara tano ya gharama ya tokeni hizo hizo 300 zinapokuwa kwenye prompt. kudhibiti gharama za agent anayeendelea kufanya kazi inashughulikia upande wa monitoring, na kuamua kama API au usajili wa bei tambarare ni nafuu kwa matumizi yako ni jambo la kuamua kabla hujatumia wiki moja kurekebisha matumizi ya kila tokeni ambayo subscription ingekuwa imeyagharamia. Kwa developer mmoja, hilo hutegemea zaidi kama Claude Pro ya $20 kwa mwezi na vikomo vya matumizi vinavyoambatana nayo vinatosha kazi ambayo ungekuwa ukiipimia kwa matumizi. Ikiwa tayari unafikia vikomo hivyo katikati ya session, kuamua ni window ipi unayoisubiri ndilo jambo la kwanza, kwa sababu suluhisho linalofuata linaweza kuwa modeli ndogo, context nyepesi, credits za ziada za matumizi, au kuhamishia kazi hiyo kwenye API yenye billing kulingana na matumizi. Ikiwa API hiyo yenye billing kulingana na matumizi itakuwa njia nafuu zaidi ya kufanya kazi hiyo, kushuka kwenye plan ndogo au kuighairi hakuathiri mwezi ambao tayari umelipia, kwa hiyo kubadili hakutakugharimu chochote unapoondoka. Ikiwa plan unayoilinganisha na Pro ni ya ChatGPT badala ya API yenye billing kulingana na matumizi, ngazi mbili za subscription zikiwa na bei sambamba inaonyesha ipi ni nafuu zaidi kwa kazi ya coding. Ikiwa swali hilo linaulizwa kwa ajili ya team badala ya developer mmoja, kumbuka kuwa Claude Enterprise inaunganisha ada ya kila seat na tokeni zinazopimwa kwa viwango hivi hivi vya API, kwa hiyo kila mkakati kwenye ukurasa huu bado unatumika kwa sehemu ya bili inayopimwa kwa matumizi.

FAQ

Kwa nini tokeni za matokeo hugharimu zaidi kuliko tokeni za ingizo?

Kuzizalisha hutumia muda mwingi zaidi wa accelerator kwa kila tokeni. Prompt huchakatwa kwa forward pass moja inayopitia prompt yote, hivyo usomaji mmoja wa uzito wa model unatosha kwa maelfu ya tokeni, na hardware huzuiwa na throughput ya kuzidisha. Jibu huzalishwa tokeni moja kwa wakati, na kila tokeni huhitaji forward pass yake inayosoma tena uzito wote wa model, hivyo hardware huzuiwa na memory bandwidth. Anthropic hutoza matokeo mara tano ya ingizo katika catalogue yote ya sasa, kuanzia Haiku 4.5 hadi Fable 5.

Je, prompt caching hufanya tokeni za matokeo ziwe nafuu?

Hapana. Prompt caching hutumika kwa ingizo pekee. Kufikia August 2026, kusoma kutoka kwenye cache hugharimu 0.1x ya kiwango cha msingi cha ingizo, na kuandika kwenye cache hugharimu 1.25x kwa muda wa 5 minute au 2x kwa muda wa 1 hour. Matokeo hutozwa kwa kiwango kamili katika kila call, bila kujali cache imefanya nini. Ndiyo maana caching hubadilisha muundo wa bili yako pamoja na ukubwa wake: upande wa ingizo unapopungua sana, matokeo huwa sehemu yenye thamani zaidi ya kupunguza.

Je, max_tokens ya juu itanigharimu pesa ikiwa jibu litarudi fupi?

Hapana. Unatozwa kwa tokeni ambazo model inazalisha kwa kweli, hivyo max_tokens ni kikomo cha juu, si mgao uliowekwa mapema. Bado ni muhimu, kwa sababu ndicho kikomo pekee thabiti cha jibu linaloweza kuendelea bila kudhibitiwa. Kiweke juu kidogo ya percentile ya 95 ya output_tokens uliyoona, kisha shughulikia stop_reason: "max_tokens" kwenye code badala ya kutuma jibu lililokatwa bila taarifa.

Ninawezaje kupata uwiano wangu mwenyewe wa tokeni za ingizo dhidi ya matokeo?

Andika input_tokens, output_tokens, cache_read_input_tokens na cache_creation_input_tokens kutoka kwenye object ya usage ya kila response, kisha gawanya jumla hizo kwa kipindi cha wiki moja. Ukiwa juu ya ingizo 5 kwa matokeo 1, gharama yako iko kwenye prompt, kwa hiyo weka sehemu thabiti kwenye cache na punguza iliyobaki. Ukiwa chini ya hapo, gharama yako iko kwenye jibu, kwa hiyo punguza urefu wake na hamishia hatua zinazozalisha sehemu kubwa zaidi yake kwenye model ya bei nafuu au kwenye Batch API.