Vật lý của token/giây

Tốc độ sinh token không bí ẩn: trong lúc decode, mỗi token đơn lẻ đòi hỏi đọc gần như toàn bộ trọng số đang kích hoạt từ bộ nhớ một lần. Điều đó khiến decode bị chặn bởi băng thông bộ nhớ, và nghĩa là bạn dự đoán được tok/s bằng phép chia. Mọi thứ người ta tranh luận — lượng hóa, MoE, offload, xử lý theo lô — đều là công thức này đội mũ khác.

Công thức duy nhất

token/giây ≈ băng thông bộ nhớ hiệu dụng ÷ byte trọng số đọc mỗi token

RTX 4090, 8B Q4_K_M:
  1008 GB/s ÷ 4.9 GB ≈ 205 tok/s trần lý thuyết
  quan sát được: ~120–150 tok/s (phụ phí, attention, đọc KV)

Bảng kiểm tra tỉnh táo cho một trường hợp phổ biến (8B ở Q4_K_M, một luồng — số cấp-độ-lớn, không phải thông số; tự đo lấy):

Vì sao khoảng cách giữa trần và thực tế? Phụ phí khởi động kernel, khối lượng attention tăng theo ngữ cảnh, và đọc KV cache chồng lên trọng số. Công thức cho bạn cái trần; bạn thực hiện điển hình 60–75% của nó ở một luồng.

Một card, bốn mô hình

Công thức cũng dự đoán kích thước mô hình đổi lấy tốc độ thế nào trên phần cứng cố định. Trần trên card ~1,000 GB/s, rồi 60–75% thực hiện (minh họa):

Hai bài học rơi ra. Nhân đôi tham số xấp xỉ giảm một nửa tốc độ trên cùng card. Và một 32B trên card 24 GB vẫn đủ nhanh cho chat — bị-chặn-bộ-nhớ không phải tuyệt vọng. Cặp đôi đó là lý do card 24 GB và mức lượng hóa 32B Q4 cứ xuất hiện cùng nhau (xem hạng GPU).

Lượng hóa là tính năng tốc độ, không chỉ là nén

Cùng công thức, ít byte hơn: mô hình 8B ở fp16 đọc ~16 GB mỗi token; ở Q4_K_M nó đọc ~4.9 GB. Trên cùng card, Q4 chạy khoảng 3 lần tốc độ fp16 và vừa nơi fp16 không vừa. Đó là lý do các mức lượng hóa hạng Q4 là khuyến nghị mặc định cho dùng cục bộ (xem lượng hóa) — mất mát chất lượng nhỏ, và lợi tốc độ là cấu trúc, không phải ngẫu nhiên.

Ngữ cảnh làm bạn chậm đi

Khi hội thoại dài ra, mỗi token mới còn phải đọc KV cache của mọi token trước đó — những lượt đọc đó tỉ lệ theo độ dài ngữ cảnh. Gần ngữ cảnh trống, một 8B Q4 có thể đạt 140 tok/s trên card hạng 4090; sâu trong phiên 64k-token, cùng thiết lập có thể chùng xuống một nửa hoặc một phần ba. Kernel attention cũng hết vừa các hình dạng thân thiện cache. Khối lượng công việc ngữ-cảnh-dài là nơi flash attention và lượng hóa KV tự trả tiền (xem KV cache và núm chỉnh engine).

Một nhầm lẫn phổ biến: "mô hình chậm dần khi cuộc chat kéo dài" thường là KV lớn lên, không phải server xuống cấp (xem KV cache).

MoE: nhanh-đổi-lấy-năng-lực

Mô hình mixture-of-experts chỉ kích hoạt vài khối expert mỗi token, nên byte đọc mỗi token bám theo tham số kích hoạt, không phải tổng. Mô hình tổng-30B/kích-hoạt-3B ở Q4 chỉ đọc cặp gigabyte mỗi token — nó decode như mô hình nhỏ trong khi mang kiến thức mô hình lớn. Đó là toàn bộ sức hút của các họ MoE cho dùng cục bộ (xem các họ mô hình): bạn trả bộ nhớ để lưu trữ expert, nhưng băng thông chỉ cho những cái bạn dùng.

Hình dáng cụ thể tại thời điểm viết: hạng Qwen3-30B-A3B chỉ đọc ~3B tham số kích hoạt mỗi token — kiến thức mô-hình-lớn ở tốc độ mô-hình-nhỏ, với ~18 GB VRAM ở Q4.

Decode suy đoán (speculative decoding)

Ghép một mô hình nháp nhỏ với mục tiêu lớn: bản nháp đề xuất k token giá rẻ, mục tiêu xác minh cả k trong một lượt forward, token được chấp nhận ra ở chất lượng của mục tiêu. Trên khối lượng công việc kiểu-greedy — hoàn thành code, JSON, trích xuất ở nhiệt độ thấp — kỳ vọng tăng tốc decode 2–3 lần. Ở nhiệt độ cao bản nháp đoán sai nhiều hơn và lợi ích teo lại. llama.cpp lộ điều này qua --model-draft và các flag độ dài nháp; tên flag chính xác trôi giữa các phiên bản, kiểm tra --help.

Chi phí: bản nháp phải dùng chung tokenizer với mục tiêu, và cả hai mô hình ngồi trong bộ nhớ.

Song song hóa: thực tế

Hai GPU không cho bạn 2 lần một luồng. Song song tensor (vLLM -tp 2) tách mỗi tầng across các card cho thông lượng, đổi bằng lưu lượng liên kết; phép chia mặc định của llama.cpp là pipeline (theo tầng), giúp dung lượng nhiều hơn là độ trễ một-luồng. Kỳ vọng thực tế cho một phép chia hai-card tốt: 1.2–1.6 lần một-luồng, không phải 2 lần. Nếu ai hứa co giãn tuyến tính mỗi GPU, họ đang bán thứ gì đó.

Thêm card thì dung lượng co giãn đẹp đẽ — đó là câu chuyện server ở đồng thời.

Vách đá offload CPU

Khi tầng ở lại CPU, lượt forward của mỗi token nhảy qua PCIe (~10–25 GB/s) vào RAM hệ thống rồi về. Vòng lặp chạy theo tốc độ của bộ phận cư trú chậm nhất: mô hình với 80% tầng trên GPU chạy gần tốc độ CPU hơn nhiều so với "80% tốc độ GPU". Nếu mô hình gần vừa, hạ một nấc lượng hóa thay vì offload nửa vời — xem núm chỉnh engine. Dấu hiệu của offload một phần vô tình là 3–10 tok/s trên phần cứng hạng GPU.

Prefill bị chặn bởi tính toán: TTFT là phép đo khác

Xử lý prompt của bạn song song across token và bị giới hạn bởi sức tính, không phải băng thông — card hạng 4090 prefill được 8B Q4 vài nghìn tok/s. Nên bản dán 12k-token tốn ~3–5 s trước token đầu ra đầu tiên, dù decode sau đó chạy 140 tok/s. Thời gian đến token đầu và tok/s ổn định là hai con số đo hai nút thắt khác nhau; khi đọc benchmark, kiểm tra nó đang trình cái nào.

Tự đo lấy

Số trên trang (kể cả trang này) là trần và dải. Thiết lập của bạn đo trong hai phút:

1. Sinh ~200 token từ một prompt ngắn; bỏ qua lần chạy đầu tiên (nạp nguội).
2. Lấy decode ổn định: token sinh ra ÷ giây sau token đầu tiên.
3. Ghi riêng thời gian đến token đầu trên một bản dán dài — đó là nút thắt khác.

llama-server in prompt-eval và eval tok/s mỗi request; LM Studio hiển thị decode tok/s trực tiếp; nvidia-smi xác nhận GPU thực sự bận trong lúc bạn đo.

Nhanh cảm giác thế nào

Các ngưỡng thấp bất ngờ vì tốc độ đọc của con người chỉ ~5–10 tok/s — nhưng chờ một bản hoàn thành ở 5 tok/s là khổ cực. Tự cảm nhận: mô phỏng dựng cùng một câu trả lời ở các tốc độ token khác nhau, và một phút ở đó dạy nhiều hơn mọi bảng.

Dưới ~2–3 tok/s một UI streaming cảm giác hỏng thay vì chậm — người ta đóng tab, nên coi đó là sàn cứng cho dùng tương tác.

Liên quan: Tổng quan phần cứng · toán VRAM · hạng GPU · núm chỉnh engine