Đo tokens mỗi giây của LLM chạy local

Vì sao tokens mỗi giây quyết định GPU có đáng tiền hay không

Tokens mỗi giây là tốc độ server tạo ra văn bản đầu ra. Đây là con số quyết định việc thuê GPU có rẻ hơn trả phí API theo từng token hay không. GPU box được tính phí theo giờ, dù đang bận hay rảnh. Hosted API được tính phí theo token. Vì vậy, GPU chỉ có lợi nếu bạn duy trì tốc độ đầu ra đủ cao trong phần lớn số giờ đã trả tiền.

Bạn cần số liệu đo thực tế, không phải một con số đọc ở đâu đó. Phần này định nghĩa 4 con số cần ghi lại, sau đó đưa ra các command để tạo ra chúng và cách tính để đưa ra quyết định.

Vì sao con số token mỗi giây được công bố không phải là con số của bạn

DigitalOcean công bố các số liệu throughput vào tháng 7 năm 2026 cho một NVIDIA H200 chạy llama3.3-70b-instruct ở FP8 (floating point 8-bit) dưới vLLM. Các số liệu này hữu ích, nhưng không phải số liệu của bạn.

[
  {
    "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"
  }
]

Mọi dòng ở trên đều được trích từ trang đó, và 2 dòng trong số đó là mức thấp của một khoảng giá trị được nêu trong trang, nên hãy xem 2 dòng đó là mức sàn. Không có số liệu nào trong biểu đồ này do chúng tôi đo.

Hãy bắt đầu với 2 dòng cuối. Con số headline là 4,071.6 tok/s, trong khi tốc độ chỉ tính output là 2,036 tok/s. Headline tính gộp cả input token và output token. Bài test đó dùng 1,024 input token và 1,024 output token, nên output gần như chiếm đúng một nửa headline. Việc tách 2 phần này rất quan trọng vì output là phần chậm hơn. Prefill (đọc prompt) xử lý toàn bộ input token trong một lượt. Decode (ghi câu trả lời) tạo từng token một. Headline về total throughput lấy trung bình giữa một phần ít tốn tài nguyên và một phần tốn tài nguyên hơn.

Bây giờ hãy xem dòng đầu tiên. Cùng một H200, khi chỉ phục vụ một request mỗi lần, đạt 47 tok/s, nên con số khi GPU bão hòa cao hơn 40 lần trên cùng phần cứng. Khoảng cách này tồn tại vì trong phần lớn thời gian, một decode step khiến GPU phải chờ memory, còn các request chạy đồng thời tận dụng khoảng thời gian rảnh đó. Dòng thứ 2, 236 tok/s, là kết quả của một H100 chạy cùng model, bị giới hạn bởi KV cache (key và value cache, tức vùng memory theo từng request mà một conversation đang được phục vụ giữ trên card). Card 80 GB chứa được ít request đồng thời hơn khi chạy model 70B, nên đạt mức bão hòa thấp hơn.

Khi đổi model hoặc thay đổi tỷ lệ input trên output, mọi con số ở trên đều thay đổi. Số liệu được công bố giúp bạn đặt kỳ vọng, không phải lập ngân sách. Đây cũng là nguyên tắc áp dụng khi benchmark VPS một cách trung thực về disk và network.

Bốn con số quan trọng

• Thời gian đến token đầu tiên, TTFT. Khoảng trễ từ lúc gửi request đến lúc token đầu tiên trong output được trả về. Giá trị này gồm thời gian prefill và thời gian chờ trong queue. Người dùng cảm nhận trực tiếp độ trễ này.
• Số token output mỗi giây trên mỗi stream. Tốc độ ghi một câu trả lời sau khi bắt đầu. Trên khoảng 20 tok/s, tốc độ này đã nhanh hơn tốc độ đọc của hầu hết mọi người, nên tăng thêm thường không mang lại nhiều lợi ích.
• Throughput output tổng khi bão hòa. Tổng throughput của tất cả stream chạy đồng thời khi server được tải đầy đủ. Đây là con số thể hiện capacity và cũng là con số quyết định chi phí GPU.
• p50 và p99 TTFT khi có concurrency. p50 là request ở vị trí giữa. p99 là giá trị mà 99 trên 100 request hoàn thành trong khoảng thời gian thấp hơn giá trị đó. Queueing luôn xuất hiện ở p99 trước.

Hai chỉ số đầu tốt hơn khi server ít tải. Chỉ số thứ ba tốt hơn khi server bận. Chúng tác động ngược chiều nhau. Vì vậy, không có một con số duy nhất nào mô tả đầy đủ một serving box.

Cố định độ dài input và output trước khi đo

Throughput phụ thuộc vào dạng traffic. Một prompt 4,000 token với câu trả lời 50 token là workload thiên về prefill. Một prompt 200 token với câu trả lời 2,000 token là workload thiên về decode. Cùng một server sẽ báo tokens per second rất khác nhau cho hai trường hợp này. Vì vậy, hãy chọn một tỷ lệ, ghi tỷ lệ đó cạnh mọi số liệu bạn thu thập và không bao giờ so sánh giữa các tỷ lệ khác nhau. Tỷ lệ 1,024 token input và 1,024 token output là lựa chọn mặc định hợp lý vì một số vendor công bố số liệu ở tỷ lệ này. Nếu biết traffic thực tế của mình, hãy dùng chính traffic đó.

Đồng thời, hãy cố định cả độ dài output. Một model dừng ở stop token sau 60 token sẽ tạo ra một lần chạy ngắn hơn và không thể so sánh với một lần chạy đầy đủ. TTFT chiếm tỷ trọng lớn hơn trong lần chạy đó, làm giảm throughput output theo cách benchmark tính toán, dù mỗi request hoàn tất sớm hơn. Flag --ignore-eos trong benchmark client của vLLM khiến mọi request generate đúng số token được yêu cầu, nhờ đó hai lần chạy vẫn có thể so sánh. Lựa chọn model làm thay đổi các số liệu này nhiều hơn bất kỳ flag nào: đưa một model Qwen 3 lên một GPU VPS duy nhất trình bày phần memory liên quan đến lựa chọn đó.

Đo một stream trước

Bắt đầu với trường hợp đơn giản nhất. Đây là phép kiểm tra tính hợp lý và cũng là giới hạn trên. Ollama tự in các số liệu thời gian.

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

Dòng cần đọc là eval rate, tức số output token mỗi giây. prompt eval rate là tốc độ prefill, còn load duration là thời gian nạp model vào VRAM. Trong lần gọi đầu tiên sau khi khởi động lạnh, load duration lớn nên total duration gây hiểu nhầm. Chạy lệnh 2 lần và đọc kết quả thứ 2. Theo mặc định, Ollama unload model khi không hoạt động trong 5 phút, nên nếu chờ lâu giữa 2 lần chạy, bạn sẽ quay lại trường hợp khởi động lạnh.

Các trường này cũng có trong API, thuận tiện hơn khi viết 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 có đơn vị là nanosecond, nên chia cho 1,000,000,000 để đổi sang giây. Đây chính xác là phép chia mà tài liệu API của Ollama hướng dẫn để tính số token mỗi giây. Nếu server chưa chạy, tự host LLM bằng Ollama trên VPS có hướng dẫn cài đặt và tạo systemd unit.

TTFT cần một request streaming, và curl có thể đo thời gian này.

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 là thời điểm byte đầu tiên của response body đến nơi. Với một streaming chat completion, byte đó thuộc về server-sent event đầu tiên. Event này có thể chứa token nội dung đầu tiên hoặc delta chỉ có role được gửi ngay trước đó. Vì vậy, hãy xem giá trị này là TTFT với sai số khoảng 1 event. Giá trị này đủ chính xác để so sánh 2 lần chạy trên cùng một server.

Các số liệu của 1 stream làm cho máy có vẻ mạnh hơn theo 2 cách. TTFT là tốt nhất có thể vì không có request nào xếp hàng trước bạn. Tốc độ trên mỗi stream cũng là tốt nhất có thể vì toàn bộ card chỉ phục vụ 1 request. Cả 2 số này đều không cho biết máy có thể xử lý bao nhiêu tải.

Chạy một lần quét concurrency như thế nào?

Một lần quét chạy cùng một workload cố định với concurrency tăng dần và ghi lại kết quả ở từng bước. vLLM cung cấp sẵn client cho việc này. Client dùng OpenAI API nên cũng hoạt động với Ollama và mọi dịch vụ tương thích với OpenAI API khác.

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 giới hạn số request đang được xử lý đồng thời. Đây là biến bạn sẽ quét. --num-prompts là tổng số request được gửi, nên đặt gần gấp 10 lần concurrency để có giá trị trung bình ổn định. Bản tóm tắt in ra Output token throughput (tok/s): và Total token throughput (tok/s):, sau đó là Mean TTFT (ms):, Median TTFT (ms): và P99 TTFT (ms): dưới heading Time to First Token.

Output đó không có tốc độ trên từng stream, nhưng có thể tính được bằng một phép chia. Mean TPOT (ms): là thời gian trung bình cho mỗi output token sau token đầu tiên. Vì vậy, 25 ms cho mỗi token tương đương 40 token mỗi giây trên mỗi stream. Lấy throughput của output chia cho concurrency cũng cho cùng kết quả.

Sau đó lặp lại quy trình và lưu kết quả của từng lần chạy.

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

Một concurrency sweep thực sự cho thấy điều gì?

[
  {
    "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
  }
]

6 hàng đó chỉ minh họa dạng kết quả mà một sweep tạo ra trên một GPU box nhỏ có thể thuê, với các bậc độ lớn hợp lý. Đây không phải số đo trên server của bạn và cũng không phải số liệu do vendor cung cấp. Hãy chạy vòng lặp ở trên rồi thay bằng số liệu của bạn.

Hãy đọc dạng của đường cong, vì chính dạng đó mới có tính khái quát. Với một stream, toàn bộ box đạt 92 token mỗi giây, với p99 TTFT là 61 ms. Ở 128 streams, tổng throughput đạt 2304 token mỗi giây, cao hơn 25 lần, trong khi tốc độ của từng stream giảm còn 18 token mỗi giây và p99 TTFT tăng lên 3820 ms. Tổng throughput tăng vì batching biến thời gian chờ memory nhàn rỗi thành công việc hữu ích. Tốc độ trên từng stream giảm vì cùng một năng lực compute giờ phải được chia sẻ.

Lần tăng gấp đôi cuối cùng là dấu hiệu rõ nhất. Tăng từ 64 lên 128 stream chỉ bổ sung chưa đến 6 phần trăm vào tổng throughput, trong khi p99 TTFT tăng khoảng 3 lần. Điều đó có nghĩa là các request đang xếp hàng thay vì được xử lý, có thể vì KV cache đã đầy hoặc server đã chạm giới hạn scheduling như max_num_seqs của vLLM. Điểm vận hành hữu ích nằm sớm hơn: ở 32 stream, box vẫn trả về 1728 token mỗi giây, bằng 75 phần trăm mức đỉnh, với 54 token mỗi giây trên mỗi stream và p99 TTFT là 498 ms. Hãy báo cáo điểm đó làm capacity của bạn. Không thể dùng mức đỉnh của đường cong để phục vụ người dùng.

Ollama và vLLM không đo cùng một thứ

Chạy phép đo đó trên Ollama với cấu hình mặc định thì tổng throughput gần như không thay đổi. OLLAMA_NUM_PARALLEL mặc định là 1, nên mỗi lần chỉ có một request chạy, còn các request khác phải chờ. Hàng đợi làm p99 TTFT tăng, trong khi tổng output vẫn giữ nguyên. Hãy tăng giá trị này trước khi đo bất kỳ thứ gì.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=8"

Khởi động lại với sudo systemctl restart ollama, sau đó xác nhận model vẫn vừa với bộ nhớ. Mỗi parallel slot được cấp phần riêng trong context window, vì vậy tài liệu Ollama lưu ý rằng context 2K với 4 parallel request sẽ phân bổ 8K. Tăng số slot quá cao sẽ khiến model tràn khỏi VRAM. Kiểm tra ollama ps: nếu cột PROCESSOR hiển thị giá trị như 48%/52% CPU/GPU, một phần model đang chạy trên CPU. Khi đó throughput sẽ giảm khi tăng concurrency thay vì tăng. Sau số parallel slot, các request sẽ được xếp hàng tối đa đến OLLAMA_MAX_QUEUE, mặc định là 512. Sau giới hạn này, server trả về 503.

vLLM dùng continuous batching, nên đưa request mới vào batch đang chạy khi các slot được giải phóng. Đường cong throughput tiếp tục tăng cho đến khi một tài nguyên cạn kiệt: thường là KV cache, dù giới hạn được cấu hình như max_num_seqs hoặc overhead lập lịch CPU có thể làm đường cong phẳng sớm hơn. Ollama tối ưu cho một model, một máy và chi phí thiết lập thấp. Vì vậy, hai engine sẽ cho kết quả khác nhau khi chạy cùng một phép đo. Đây mới là chủ đề chính của So sánh Ollama và vLLM dưới góc độ engine serving. Hãy ghi lại engine và version đã tạo ra từng số đo.

Năm cách đo sai thứ cần đo

• Client ở xa. Benchmark từ laptop qua Internet cộng thêm round trip của bạn vào mọi TTFT, nên kết quả đo thực chất phản ánh kết nối tại nhà. Chạy client trong cùng region với server.
• Model đang ở trạng thái cold. Request đầu tiên phải tải weight và trên vLLM còn có thể phải thực hiện graph capture. Gửi một batch warmup rồi bỏ kết quả.
• Prefix caching đã trả lời thay bạn. vLLM mặc định bật automatic prefix caching, nên gửi đi gửi lại cùng một prompt sẽ đo cache thay vì prefill, khiến TTFT giảm xuống chỉ còn một phần nhỏ so với giá trị thực. --dataset-name random tránh được vấn đề này vì mỗi prompt đều khác nhau. Để chắc chắn, hãy khởi động server với --no-enable-prefix-caching.
• Output quá ngắn. Với câu trả lời dài 32 token, TTFT chiếm phần lớn thời gian của mỗi request và tokens per second thực chất đang mô tả prefill. Dùng --ignore-eos với độ dài output thực tế.
• Chỉ báo cáo concurrency 1. Mức này cho TTFT đẹp nhất trên bảng đo và chỉ là đầu vào chi phí phù hợp nếu các request thực tế của bạn không bao giờ chồng lấp. Nếu chúng có chồng lấp, chi phí phụ thuộc vào throughput duy trì được ở mức concurrency mà traffic thực tế tạo ra, vì vậy cũng phải đo ở mức đó.

Biến số đo được thành quyết định

Lấy throughput của output mà lần quét đo được tại mức concurrency tương ứng với lưu lượng thực tế của bạn, rồi so sánh với giá trên mỗi token. Đây chỉ là giá trị ở trạng thái bão hòa nếu có đủ request chồng lấp để giữ batch luôn đầy. Workload gửi từng request một phải dùng tốc độ của một stream đơn. Điểm hòa vốn chỉ cần một phép chia, sau khi tính giá input token đi kèm với mỗi output token:

cost_per_million_output = price_out + price_in * (input_tokens / output_tokens)
break_even_tok_s = (price_per_hour / cost_per_million_output) * 1000000 / 3600

Hãy tính với bảng giá tháng 07 năm 2026 của DigitalOcean. Dedicated inference endpoint H200 của họ có giá $4.47 mỗi giờ. Serverless Llama 3.3 70B có giá $0.65 cho mỗi triệu input token và $0.65 cho mỗi triệu output token. Với tỷ lệ 1:1 ở trên, mỗi triệu output token đi kèm một triệu input token. Vì vậy, giá thực tế là $1.30 cho mỗi triệu output token. Lấy 4.47 chia cho 1.30 được khoảng 3.44 triệu output token mỗi giờ. Chia tiếp cho 3,600 giây được khoảng 955 output token mỗi giây, hoặc khoảng 1,910 token mỗi giây nếu tính cả input và output. Đây là giá do họ công bố. Phép chia là cách chúng ta tính. Khi kiểm tra vào ngày 25 tháng 10 năm 2026, endpoint H200 vẫn có giá $4.47 mỗi giờ. Tuy nhiên, DigitalOcean đã deprecated serverless Llama 3.3 70B vào ngày 18 tháng 08 năm 2026 và hướng người dùng sang Llama 4 Maverick, có giá niêm yết $0.25 cho mỗi triệu input token và $0.87 cho mỗi triệu output token. Đây là model khác, nên phải quét riêng trước khi kết quả so sánh có ý nghĩa.

Từ quyết định ở đây là sustained. Đạt 955 output token mỗi giây ở trạng thái bão hòa trong 2 giờ mỗi ngày không có nghĩa là duy trì được 955 output token mỗi giây, vì bạn vẫn phải trả tiền cho 22 giờ còn lại. Thuê card dưới dạng GPU Droplet cũng không hạ ngưỡng này. Vào ngày 25 tháng 10 năm 2026, bảng giá Droplet của DigitalOcean vẫn niêm yết H200 ở mức $4.47 mỗi giờ theo hình thức on-demand, bằng với endpoint. Các NVIDIA Droplet rẻ nhất của họ, gồm RTX 4000 ở mức $0.76 mỗi giờ và L40S hoặc RTX 6000 ở mức $1.57 mỗi giờ, quá nhỏ để chạy model 70B ở FP8. Vì vậy, theo các số liệu trên, H200 đạt mức bão hòa 2,036 output token mỗi giây phải đạt trung bình khoảng 47 phần trăm mức đỉnh đó trong mọi giờ bạn trả tiền thì mới chỉ ngang với mức $0.65 cho mỗi triệu token đầu vào và đầu ra. Thấp hơn mức đó thì giá theo token có lợi hơn. GPU idle, không phải token chạy chậm, thường là nguyên nhân khiến self-hosting không hiệu quả.

Vì vậy, quyết định của bạn có 2 đầu vào. Lần quét cho biết mức trần. Mẫu lưu lượng cho biết bạn thực sự đạt được bao nhiêu phần của mức trần đó. Nhân 2 giá trị này, sau đó đưa kết quả vào phép tính hòa vốn giữa GPU VPS và API tính phí theo token để xem đáp án tương ứng với lưu lượng của bạn.

FAQ

Tốc độ token mỗi giây bao nhiêu là tốt đối với LLM tự host?

Có 2 cách trả lời, vì chỉ số này phục vụ 2 mục đích. Với một người đọc output, tốc độ trên khoảng 20 output token mỗi giây cho mỗi stream đã nhanh hơn tốc độ đọc, nên cao hơn cũng không giúp ích thêm. Về chi phí, con số cần quan tâm là tổng throughput output bạn có thể duy trì với tải thực tế, và “tốt” nghĩa là đủ để đạt điểm hòa vốn. Với mức $0.65 cho mỗi triệu token, áp dụng như nhau cho input và output, trên máy có chi phí $4.47 mỗi giờ, ngưỡng này gần 955 output token mỗi giây nếu duy trì tỷ lệ 1:1 và dùng mức giá tháng 2026. Một stream trên model lớn không bao giờ đạt được mức đó. Đây là lý do batching tồn tại.

Vì sao throughput của Ollama không tăng khi tôi thêm các request đồng thời?

OLLAMA_NUM_PARALLEL mặc định là 1, nên server xử lý mỗi lần 1 request cho mỗi model và xếp các request còn lại vào queue, tối đa đến OLLAMA_MAX_QUEUE (mặc định là 512), trước khi trả về 503. Tổng output vẫn giữ nguyên trong khi p99 TTFT tăng. Đây là dấu hiệu của queue, không phải GPU đang bận. Đặt biến này trong systemd drop-in rồi restart. Sau đó kiểm tra ollama ps, vì mỗi parallel slot sẽ nhân context được cấp phát và có thể đẩy một phần model sang CPU.

Tôi nên đo time to first token hay token mỗi giây?

Cả 2, vì chúng thay đổi theo hướng ngược nhau khi tải tăng. TTFT là độ trễ mà người dùng cảm nhận, còn output throughput khi hệ thống bão hòa là yếu tố ảnh hưởng đến hóa đơn. Ghi lại p50 và p99 TTFT ở mỗi mức concurrency. Sau đó chọn mức concurrency cao nhất mà p99 TTFT vẫn chấp nhận được đối với bạn. Báo cáo throughput tại mức đó làm capacity, không dùng mức tối đa ở đỉnh của đường cong.

Tốc độ token mỗi giây cao hơn có luôn đồng nghĩa với chi phí mỗi token thấp hơn không?

Không. Chi phí mỗi token bằng giá theo giờ chia cho số token mà máy thực sự tạo ra trong một giờ. Vì vậy, một server nhanh nhưng phần lớn thời gian idle vẫn có chi phí mỗi token cao. Yếu tố quyết định là utilisation, không phải tốc độ tối đa. Cũng cần chú ý đến đơn vị: tổng token throughput được báo cáo có thể tính cả input token. Vì vậy, với tỷ lệ input trên output là 1:1, con số đó gần gấp đôi output rate. Nếu API đang so sánh cũng tính phí input token và output token, hãy tính giá của cả 2 phần trước khi so sánh.