Jinsi ya kupima tokens per second kwenye LLM yako

Kwa nini tokens per second huamua kama GPU inalipa

Tokens per second ni kasi ambayo seva yako inazalisha matini ya matokeo, na ndiyo namba inayoamua kama kukodisha GPU ni nafuu kuliko kulipia API kwa kila token. Mashine ya GPU hulipiwa kwa saa bila kujali kama inafanya kazi au imetulia. API inayohudumiwa hulipiwa kwa token. Kwa hivyo, GPU inakuwa na faida tu ikiwa utadumisha kasi ya juu ya matokeo katika saa nyingi unazolipia.

Hii inamaanisha unahitaji kipimo halisi, si namba uliyosoma mahali fulani. Ukurasa huu unafafanua namba nne zinazostahili kurekodiwa, kisha unatoa amri zinazozizalisha na hesabu zinazozigeuza kuwa uamuzi.

Kwa nini takwimu ya tokens kwa sekunde iliyochapishwa si namba yako

DigitalOcean ilichapisha takwimu za throughput mnamo Julai 2026 kwa NVIDIA H200 moja inayoendesha llama3.3-70b-instruct katika FP8 (8-bit floating point) chini ya vLLM. Takwimu hizi ni muhimu lakini si zako.

[
  {
    "config": "H200, one stream",
    "tok_s": "47"
  },
  {
    "config": "H100, saturated",
    "tok_s": "236"
  },
  {
    "config": "H200, saturated",
    "tok_s": "2,036"
  },
  {
    "config": "H200, saturated, in+out",
    "tok_s": "4,071.6"
  }
]

Kila mstari hapo juu umenukuliwa kutoka ukurasa huo, na miwili kati yake ni kiwango cha chini cha masafa yanayotolewa, kwa hivyo soma hiyo miwili kama msingi. Hakuna chochote katika chati hii kilichopimwa na sisi.

Anza na mistari miwili ya mwisho. Kichwa cha habari ni 4,071.6 tok/s, wakati kiwango cha output pekee ni 2,036 tok/s. Kichwa cha habari huhesabu tokens za input na output pamoja. Jaribio hilo lilitumia tokens 1,024 za input dhidi ya tokens 1,024 za output, kwa hivyo karibu nusu kamili ya kichwa cha habari ni output. Mgawanyo huu ni muhimu kwa sababu output ndiyo nusu unayotozwa malipo, na ndiyo nusu ya polepole. Prefill (kusoma prompt) huchakata tokens zote za input kwa hatua moja. Decode (kuandika jibu) hutoa token moja kwa wakati mmoja. Kichwa cha habari cha total-throughput huchanganya namba ya bei nafuu na ile ya gharama kubwa.

Sasa mstari wa kwanza. H200 hiyohiyo inayohudumia ombi moja kwa wakati mmoja hutoa 47 tok/s, kwa hivyo takwimu ya saturation ni zaidi ya mara arobaini zaidi kwenye vifaa vinavyofanana. Pengo hilo lipo kwa sababu hatua moja ya decode huacha GPU ikisubiri kumbukumbu kwa muda mwingi, na maombi ya wakati mmoja hujaza muda huo wa kutofanya kazi. Mstari wa pili, 236 tok/s, ni H100 moja kwenye model hiyohiyo, ikizuiliwa na KV cache (cache ya key na value, kumbukumbu ya kila ombi ambayo mazungumzo yanayohudumiwa huweka kwenye kadi). Kadi ya 80 GB hushikilia maombi machache ya wakati mmoja kwa model ya 70B, kwa hivyo saturation yake huwa ya chini.

Badilisha model au badilisha uwiano wa input kwa output na kila namba hapo juu itabadilika. Takwimu zilizochapishwa huweka matarajio yako, si bajeti yako, ambayo ndiyo kanuni hiyohiyo inayotumika katika kufanya benchmarking ya VPS kwa uaminifu kwenye diski na mtandao.

Nambari nne za msingi

• Muda wa token ya kwanza, TTFT. Huu ni muda wa kusubiri kati ya kutuma ombi na kupokea token ya kwanza. Unajumuisha muda wa prefill na muda wa kusubiri kwenye foleni. Mtumiaji huhisi muda huu moja kwa moja.
• Token za matokeo kwa sekunde, kwa kila mtiririko. Kasi ya uandishi wa jibu moja baada ya kuanza. Zaidi ya takriban 20 tok/s, kasi hii inazidi uwezo wa kusoma wa watu wengi, hivyo kasi ya ziada hapa haina faida kubwa.
• Jumla ya uwezo wa matokeo uliokithiri. Jumla ya mitiririko yote inayofanyika kwa wakati mmoja wakati seva imelemewa kikamilifu. Hii ndiyo nambari ya uwezo, na ndiyo inayohalalisha gharama za GPU.
• p50 na p99 TTFT chini ya concurrency. p50 ni ombi la katikati. p99 ni thamani ambayo maombi 99 kati ya 100 hayazidi. Uundaji wa foleni huonekana kwanza kwenye p99.

Nambari mbili za kwanza huboreka wakati seva haina shughuli nyingi. Ya tatu huboreka wakati seva ina shughuli nyingi. Nambari hizi hupingana, ndiyo maana hakuna nambari moja inayoweza kuelezea uwezo wa seva ya kuhudumia.

Rekebisha urefu wa ingizo na pato kabla ya kupima

Kiwango cha utendaji (throughput) hutegemea umbo la trafiki. Prompt ya token 4,000 yenye jibu la token 50 ni kazi inayotegemea sana prefill. Prompt ya token 200 yenye jibu la token 2,000 ni kazi inayotegemea sana decode. Seva moja itatoa idadi tofauti sana ya token kwa sekunde kwa kazi hizo mbili, kwa hivyo chagua uwiano mmoja, uandike kando ya kila namba unayorekodi, na usiwahi kulinganisha uwiano tofauti. Uwiano wa 1,024 kwa ingizo na 1,024 kwa pato ni chaguo-msingi linalofaa kwa sababu wachuuzi kadhaa huchapisha matokeo kwa uwiano huo. Ikiwa unajua trafiki yako halisi, tumia trafiki hiyo halisi.

Lazimisha pia urefu wa pato. Model inayofikia stop token baada ya token 60 hutoa muda mfupi wa utekelezaji unaoonekana kuwa wa haraka, kwa sababu TTFT inakuwa sehemu kubwa zaidi ya muda huo. Flag ya --ignore-eos katika mteja wa benchmark wa vLLM hufanya kila ombi kuzalisha idadi kamili ya token zilizoelekezwa, ili majaribio mawili yaweze kulinganishwa. Chaguo la model hubadilisha namba hizi zaidi kuliko flag yoyote: kutosheleza model ya Qwen 3 kwenye GPU moja ya VPS inashughulikia upande wa kumbukumbu wa chaguo hilo.

Pima mtiririko mmoja kwanza

Anza na hali rahisi zaidi. Hii ni hatua ya kuhakiki mfumo na kuweka kiwango cha juu cha utendaji. Ollama huchapisha muda wake wa uchakataji.

ollama run llama3.1:8b --verbose "Write 200 words about disk scheduling."

Mstari wa kusoma ni eval rate, ambao ni idadi ya token zinazozalishwa kwa sekunde. prompt eval rate ni kasi ya prefill, na load duration ni muda uliotumika kupakia model kwenye VRAM. Katika ombi la kwanza baada ya kuanzisha seva (cold start), load duration huwa kubwa, kwa hivyo total duration inaweza kupotosha. Endesha amri hiyo mara mbili na usome matokeo ya pili. Ollama huondoa model isiyotumika kwenye kumbukumbu baada ya dakika tano kwa chaguo-msingi, kwa hivyo kusubiri muda mrefu kati ya majaribio kutakurudisha kwenye hali ya kuanza upya.

Sehemu hizo hizo zinapatikana kupitia API, ambayo ni rahisi zaidi kuandikia script.

curl -s http://127.0.0.1:11434/api/generate -d '{
  "model": "llama3.1:8b",
  "prompt": "Write 200 words about disk scheduling.",
  "stream": false
}' | jq '{eval_count, eval_duration,
         tok_s: (.eval_count / (.eval_duration / 1000000000))}'

eval_duration ni nanoseconds, kwa hivyo kugawanya kwa 1,000,000,000 kunatoa sekunde. Mgawanyo huo ndio hasa unaoelekezwa na nyaraka za API ya Ollama kwa ajili ya token kwa sekunde. Ikiwa seva bado haijawashwa, kujihudumia LLM kwa kutumia Ollama kwenye VPS inaelezea usakinishaji na unit ya systemd.

TTFT inahitaji ombi la streaming, na curl inaweza kukupimia muda huo.

curl -s -o /dev/null -N \
  -w 'ttfb=%{time_starttransfer}s  total=%{time_total}s\n' \
  http://127.0.0.1:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"Qwen/Qwen3-8B",
       "messages":[{"role":"user","content":"Write 200 words about disk scheduling."}],
       "stream":true,"max_tokens":256}'

time_starttransfer ni wakati ambapo byte ya kwanza ya mwili wa jibu inafika. Katika streaming chat completion, byte hiyo ni ya tukio la kwanza lililotumwa na seva, ambalo linaweza kuwa token ya kwanza ya maudhui au delta ya role pekee iliyotumwa kabla yake. Kwa hivyo, chukulia thamani hiyo kama TTFT kwa makadirio ya tukio moja. Inatosha kulinganisha majaribio mawili kwenye seva hiyo hiyo.

Namba za mtiririko mmoja hupendelea seva kupita kiasi. TTFT ndiyo bora zaidi itakavyokuwa, kwa sababu hakuna kitu kilichopangwa kwenye foleni mbele yako. Kasi ya kila mtiririko ndiyo bora zaidi itakavyokuwa, kwa sababu kadi nzima inahudumia ombi moja. Hakuna kati ya hizi inayoeleza uwezo halisi wa seva hiyo.

Jinsi ya kufanya concurrency sweep?

Sweep huendesha workload moja maalum kwa concurrency inayoongezeka na kurekodi kinachotokea katika kila hatua. vLLM husafirisha client kwa ajili ya kazi hii, na inatumia OpenAI API, kwa hivyo inafanya kazi pia dhidi ya Ollama na kitu chochote kinachooana na OpenAI.

vllm bench serve \
  --backend openai-chat \
  --base-url http://127.0.0.1:8000 \
  --endpoint /v1/chat/completions \
  --model Qwen/Qwen3-8B \
  --dataset-name random \
  --random-input-len 1024 \
  --random-output-len 1024 \
  --ignore-eos \
  --num-prompts 160 \
  --max-concurrency 16 \
  --percentile-metrics ttft,tpot,itl,e2el \
  --metric-percentiles 50,99

--max-concurrency huweka kikomo cha maombi yanayoshughulikiwa kwa wakati mmoja, na ndiyo variable unayofanyia sweep. --num-prompts ni jumla ya maombi yaliyotumwa, kwa hivyo iweke karibu mara kumi ya concurrency ili kupata wastani thabiti. Muhtasari huchapisha Output token throughput (tok/s): na Total token throughput (tok/s):, kisha Mean TTFT (ms):, Median TTFT (ms): na P99 TTFT (ms): chini ya kichwa cha habari cha Time to First Token.

Hakuna rate ya kila stream katika matokeo hayo, lakini inaweza kupatikana kwa mgawanyo rahisi. Mean TPOT (ms): ni muda wa wastani kwa kila output token baada ya ya kwanza, kwa hivyo 25 ms kwa kila token ni 40 tokens kwa sekunde kwa kila stream. Kugawanya output throughput kwa concurrency kunatoa jibu lilelile.

Kisha iweke kwenye loop, huku ukihifadhi kila run.

for C in 1 4 16 32 64 128; do
  vllm bench serve \
    --backend openai-chat \
    --base-url http://127.0.0.1:8000 \
    --endpoint /v1/chat/completions \
    --model Qwen/Qwen3-8B \
    --dataset-name random \
    --random-input-len 1024 \
    --random-output-len 1024 \
    --ignore-eos \
    --num-prompts $(( C * 10 )) \
    --max-concurrency "$C" \
    --percentile-metrics ttft,tpot,itl,e2el \
    --metric-percentiles 50,99 \
    --save-result --result-filename "sweep-c$C.json"
done

for f in sweep-c*.json; do
  jq -r --arg f "$f" \
    '[$f, .output_throughput, .total_token_throughput,
      .median_ttft_ms, .p99_ttft_ms] | @tsv' "$f"
done

Uchanganuzi wa concurrency sweep unaonyesha nini hasa?

[
  {
    "label": "1 stream",
    "per_stream_tok_s": 92,
    "total_tok_s": 92,
    "ttft_p50_ms": 48,
    "ttft_p99_ms": 61
  },
  {
    "label": "4 streams",
    "per_stream_tok_s": 88,
    "total_tok_s": 352,
    "ttft_p50_ms": 71,
    "ttft_p99_ms": 96
  },
  {
    "label": "16 streams",
    "per_stream_tok_s": 71,
    "total_tok_s": 1136,
    "ttft_p50_ms": 152,
    "ttft_p99_ms": 244
  },
  {
    "label": "32 streams",
    "per_stream_tok_s": 54,
    "total_tok_s": 1728,
    "ttft_p50_ms": 287,
    "ttft_p99_ms": 498
  },
  {
    "label": "64 streams",
    "per_stream_tok_s": 34,
    "total_tok_s": 2176,
    "ttft_p50_ms": 611,
    "ttft_p99_ms": 1240
  },
  {
    "label": "128 streams",
    "per_stream_tok_s": 18,
    "total_tok_s": 2304,
    "ttft_p50_ms": 1490,
    "ttft_p99_ms": 3820
  }
]

Safu hizo 6 ni kielelezo cha umbo linalotokana na sweep kwenye seva ndogo ya GPU inayokodishwa, kwa viwango vinavyokubalika. Hizi si vipimo vya seva yako, na si takwimu za muuzaji. Endesha loop iliyo hapo juu na ubadilishe takwimu hizo na zako.

Soma umbo hilo, kwa sababu umbo ndilo linaloweza kutumika kwa ujumla. Katika stream moja, seva nzima inazalisha 92 tokens kwa sekunde ikiwa na p99 TTFT ya 61 ms. Katika 128 streams, jumla inafikia 2304 tokens kwa sekunde, mara ishirini na tano zaidi, wakati kila stream binafsi inashuka hadi 18 tokens kwa sekunde na p99 TTFT inafikia 3820 ms. Jumla ya throughput inapanda kwa sababu batching inageuza muda wa kusubiri wa kumbukumbu kuwa kazi yenye tija. Kasi ya kila stream inashuka kwa sababu nguvu ileile ya kompyuta sasa inagawanywa.

Kuongezeka mara mbili kwa mwisho ndiko kunakoashiria kikomo. Kutoka stream 64 hadi 128 kunaongeza chini ya asilimia sita kwenye jumla, wakati p99 TTFT inakaribia mara tatu, jambo linalomaanisha kuwa KV cache imejaa na maombi yanapanga foleni badala ya kuchakatwa. Sehemu bora ya kufanyia kazi iko mapema zaidi: katika stream 32, seva bado inatoa 1728 tokens kwa sekunde, asilimia 75 ya uwezo wake wa juu, kwa 54 tokens kwa sekunde kwa kila stream na p99 TTFT ya 498 ms. Ripoti sehemu hiyo kama uwezo wako. Kilele cha curve hiyo ni namba ambayo huwezi kuitumia kuhudumia watumiaji.

Ollama na vLLM hazipimi kitu kimoja

Endesha jaribio hilo dhidi ya seva ya kawaida ya Ollama na jumla haitabadilika sana. OLLAMA_NUM_PARALLEL imewekwa kuwa 1 kwa chaguo-msingi, kwa hivyo ombi moja hufanya kazi huku mengine yakisubiri, na foleni ndiyo inayofanya p99 TTFT kupanda huku jumla ya matokeo ikibaki vilevile. Iongeze kabla ya kupima chochote.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=8"

Anzisha upya ukitumia sudo systemctl restart ollama, kisha thibitisha kuwa modeli bado inatoshea. Kila nafasi ya sambamba (parallel slot) hupata sehemu yake ya context window, kwa hivyo nyaraka za Ollama zinaeleza kuwa context ya 2K yenye maombi 4 ya sambamba hutenga 8K. Ikiwa utaongeza idadi ya nafasi hizo sana, modeli itafurika nje ya VRAM. Angalia ollama ps: safu ya PROCESSOR inayosoma kitu kama 48%/52% CPU/GPU inamaanisha kuwa sehemu ya modeli iko kwenye CPU, na throughput sasa itashuka unapoongeza concurrency badala ya kupanda. Baada ya nafasi za sambamba kujaa, maombi hupangwa kwenye foleni hadi OLLAMA_MAX_QUEUE, 512 kwa chaguo-msingi, ambapo baada ya hapo seva hujibu 503.

vLLM hutumia continuous batching, kwa hivyo hukubali maombi mapya kwenye batch inayoendelea kadiri nafasi zinavyopatikana, na mkondo wake huendelea kupanda hadi KV cache inapoisha. Ollama huboresha utendaji kwa ajili ya modeli moja, mashine moja, na gharama ndogo ya usanidi. Injini hizi mbili kwa hivyo hutoa majibu tofauti kwa jaribio lilelile, ambalo ndilo mada halisi ya Ollama na vLLM zikilinganishwa kama injini za kuhudumia. Rekodi ni injini ipi na toleo lipi lililozalisha kila namba.

Njia tano za kupima kitu kisicho sahihi

• Mteja yuko mbali. Kufanya benchmarking kutoka kwenye laptop yako kupitia Internet kunaongeza muda wa round trip kwenye kila TTFT, kwa hivyo unapima muunganisho wako wa nyumbani. Endesha mteja katika region moja na seva.
• Model ilikuwa baridi. Ombi la kwanza linagharamia upakiaji wa uzito (weight loading), na kwenye vLLM linaweza pia kugharamia graph capture. Tuma batch ya warmup na utupe matokeo yake.
• Prefix caching imekujibu. vLLM huwezesha prefix caching ya kiotomatiki kwa chaguo-msingi, kwa hivyo kutuma prompt ileile mara kwa mara kunapima cache badala ya prefill, na TTFT inashuka hadi sehemu ndogo ya thamani halisi. --dataset-name random inazuia hili kwa sababu kila prompt ni tofauti. Ili kuwa na uhakika, anzisha seva kwa --no-enable-prefix-caching.
• Matokeo yalikuwa mafupi. Kwa majibu ya 32-token, TTFT hutawala kila ombi na tokens per second yako inafafanua prefill pekee. Tumia --ignore-eos yenye urefu wa matokeo wa kweli.
• Umeripoti concurrency 1. Hii ndiyo namba rafiki zaidi kwenye karatasi na haina uhusiano wowote na gharama.

Badilisha namba uliyopima kuwa uamuzi

Chukua throughput ya juu kabisa ya output kutoka kwenye sweep yako, siyo kasi ya stream moja, na uilinganishe na bei ya kila token. Break-even hupatikana kwa mgawanyo mmoja:

break_even_tok_s = (price_per_hour / price_per_million_output_tokens) * 1000000 / 3600

Fanya hesabu hii kwa kutumia bei za DigitalOcean za Julai 2026. Endpoint yao ya H200 dedicated inference ilikuwa $4.47 kwa saa, na ile ya serverless ilikuwa $0.65 kwa kila milioni moja ya tokens. Kwa hiyo, 4.47 ukigawanya kwa 0.65 unapata milioni 6.88 za tokens kwa saa, na ukigawanya kwa sekunde 3,600 unapata takriban 1,910 output tokens kwa sekunde. Bei ni zao. Mgawanyo ni wetu.

Neno linaloamua hili ni sustained (endelevu). Kufikia 1,910 tokens kwa sekunde wakati wa saturation kwa saa mbili kwa siku siyo 1,910 tokens kwa sekunde kwa njia endelevu, kwa sababu unalipia pia saa nyingine ishirini na mbili. Crossover ya DigitalOcean yenyewe kwa ajili ya GPU Droplet ya bei nafuu ya $3.44 kwa saa inafikia asilimia 72.2 ya matumizi endelevu ya wastani, na chini ya hapo, bei ya kila token inakuwa nafuu zaidi. Saa za GPU ambazo hazitumiki, siyo tokens za polepole, ndizo zinazofanya self-hosting ishindwe mara nyingi.

Kwa hivyo, uamuzi wako una inputs mbili. Sweep inakupa uwezo wa juu kabisa (ceiling). Mfumo wako wa traffic unakupa sehemu ya uwezo huo ambayo unaitumia kihalisi. Zidisha namba hizo, kisha chukua matokeo hayo uende kwenye GPU VPS dhidi ya break-even ya API ya kila token na usome jibu kwa ajili ya kiasi chako cha matumizi.

FAQ

Je, ni kiasi gani kizuri cha tokens kwa sekunde kwa LLM inayojiendesha yenyewe?

Kuna majibu mawili, kwa sababu kipimo hiki kinafanya kazi mbili. Kwa mtu mmoja anayesoma matokeo, chochote kilicho juu ya takriban 20 output tokens kwa sekunde kwa kila mtiririko (stream) ni kasi zaidi kuliko kasi ya kusoma, kwa hivyo kasi zaidi haisaidii. Kwa gharama, namba inayojali ni jumla ya output throughput iliyojaa, na "nzuri" inamaanisha chochote kinachofikia kiwango chako cha faida. Kwa gharama ya $0.65 kwa kila milioni ya tokens kwenye seva inayogharimu $4.47 kwa saa, kiwango hicho cha chini kipo karibu na 1,910 output tokens kwa sekunde zilizodumishwa kwa bei za Julai 2026. Mtiririko mmoja kwenye modeli kubwa haufikii kiwango hicho, ndiyo sababu batching ipo.

Kwa nini throughput ya Ollama inabaki palepale ninapoongeza maombi ya wakati mmoja?

OLLAMA_NUM_PARALLEL imewekwa kuwa 1 kwa chaguo-msingi, kwa hivyo seva huendesha ombi moja kwa wakati mmoja kwa kila modeli na kupanga foleni zingine, hadi OLLAMA_MAX_QUEUE (512 kwa chaguo-msingi) kabla ya kurudisha 503. Jumla ya output inabaki palepale wakati p99 TTFT inapanda, ambayo ni ishara ya foleni badala ya GPU yenye shughuli nyingi. Weka variable hiyo kwenye systemd drop-in na uanzishe upya, kisha angalia ollama ps, kwa sababu kila nafasi ya sambamba (parallel slot) huzidisha context iliyotengwa na inaweza kusukuma sehemu ya modeli kwenye CPU.

Je, nipime muda wa token ya kwanza (TTFT) au tokens kwa sekunde?

Pima yote mawili, kwa sababu husogea katika mwelekeo tofauti kadiri mzigo unavyoongezeka. TTFT ndiyo anayohisi mtumiaji, na saturated output throughput ndiyo inayoonekana kwenye ankara yako. Rekodi p50 na p99 TTFT katika kila hatua ya concurrency, kisha chagua concurrency ya juu zaidi ambapo p99 TTFT bado inakubalika kwako. Ripoti throughput katika hatua hiyo kama uwezo wako, siyo kiwango cha juu zaidi kutoka kilele cha grafu.

Je, namba ya juu ya tokens kwa sekunde inamaanisha gharama ya chini kwa kila token?

Hapana. Gharama kwa kila token ni bei ya saa iliyogawanywa na tokens ambazo seva imezalisha kwa saa hiyo, kwa hivyo seva ya haraka inayokaa bila kazi siku nzima bado ina gharama kubwa kwa kila token. Matumizi (utilisation) ndiyo huamua, siyo kasi ya kilele. Angalia pia vipimo: jumla ya token throughput iliyotajwa huhesabu input tokens, kwa hivyo kwa uwiano wa 1:1 wa input kwa output, ni karibu mara mbili ya kiwango cha output unachotozwa.