Dashboard của bạn hiển thị độ trễ P95 4.2 giây. Trang benchmark nói model của bạn đạt 800 tokens mỗi giây — “nhanh” — vậy mà người dùng của bạn vẫn đóng tab trước khi token đầu tiên kịp xuất hiện.
Khoảng cách đó chính là toàn bộ câu chuyện về độ trễ của LLM: con số mà mọi người đem ra benchmark và con số mà người dùng thực sự cảm nhận là hai con số khác nhau, và hầu hết đội ngũ đang tối ưu nhầm một trong hai.
Độ trễ là khía cạnh giàu dữ liệu nhưng nghèo chỉ dẫn nhất trong stack LLM: các trang benchmark công bố hàng trăm bảng TTFT và tokens-per-second — trang provider của Artificial Analysis và bảng xếp hạng tốc độ trực tiếp của AI API Cost là những điểm tham chiếu tiêu biểu — nhưng gần như không trang nào cho bạn biết phải làm gì với con số của mình. Tài liệu của nhà cung cấp giải thích stack của họ, không phải stack của bạn. Và chỉ số mà ngành ưa chuộng nhất — tokens mỗi giây — thường xuyên bị nhầm lẫn với thứ người dùng thực sự cảm nhận.
Bài viết này chính là lớp chỉ dẫn: độ trễ thực sự nghĩa là gì (bốn con số khác nhau, chỉ một trong số đó là TPS), vì sao giờ đây nó là một chỉ số sản phẩm, cách đo lường nó với một ngân sách mà bạn có thể bảo vệ, cách sửa từng lớp — streaming, caching, model tiering, regional routing — và những sai lầm biến việc tối ưu thành mê tín.
”Latency” thực sự nghĩa là gì với LLM API
Điểm chính: có bốn con số độ trễ, và tối ưu nhầm con số chính là cách các đội ngũ tung ra những model “nhanh” mà người dùng cảm thấy chậm.
- TTFT — time to first token. Điều người dùng cảm nhận đầu tiên: khoảng cách giữa lúc “gửi” và token đầu tiên được stream về. Con số quan trọng bậc nhất cho các sản phẩm tương tác.
- Inter-token latency — nghịch đảo của TPS. Tốc độ stream phần còn lại của response. Quan trọng với output dài và agent loops; không liên quan với một câu trả lời một dòng.
- Total request time. Tổng thời gian, trừ đi cảm nhận từ streaming. Thứ mà batch và các tác vụ nền quan tâm; không phải thứ người dùng cảm nhận.
- Perceived latency. Kết quả mà streaming tạo ra: TTFT cộng với nhịp độ của luồng stream. Một hệ thống có TTFT tốt và nhịp độ đều đặn sẽ cho cảm giác nhanh ngay cả khi tổng thời gian dài.
Sự ám ảnh của ngành với TPS chính là cái bẫy: một model 800 tokens/sec với TTFT 1.5 giây mất ấn tượng đầu tiên trước một model 300 tokens/sec với TTFT 300ms. Hãy đo cả bốn con số; tối ưu theo từng use case.
Vì sao độ trễ là một chỉ số sản phẩm
Điểm chính: agents nhân độ trễ lên nhiều lần, và người dùng cảm nhận chính sản phẩm — những con số đã dịch chuyển từ bảng benchmark sang biểu đồ churn.
Hai lý do mang tính cấu trúc khiến độ trễ giờ là một quyết định sản phẩm:
-
Agent loops nhân mọi khoảng chờ lên nhiều lần. Một cuộc hội thoại duy nhất tạo ra N lần gọi model tuần tự; lợi thế 500ms mỗi lần gọi trở thành lợi thế 5 giây trên một loop 10 lần gọi. Logic lãi kép tương tự đã tạo ra quy tắc 800ms cho hệ thống tương tác cũng áp dụng ở đây: các lần gọi tuần tự được nhân lên, nên độ trễ mỗi lần gọi là một quyết định sản phẩm, không phải một chi tiết hiệu năng thứ yếu.
-
Tốc độ cảm nhận chính là sự giữ chân. Các nghiên cứu về streaming UI liên tục cho thấy thời gian đến token đầu tiên quyết định chất lượng cảm nhận; model benchmark nhanh nhất vẫn thua nếu TTFT của nó chậm. Câu hỏi sản phẩm không phải “model nhanh cỡ nào” — mà là “token đầu tiên của người dùng đến nhanh cỡ nào”.
Cách đo lường: ngân sách độ trễ
Điểm chính: đo lường là một ngân sách, không phải một benchmark — hãy phân tách, đo ở cả P50 và P95, tại vùng của bạn, với kích thước prompt thật của bạn.
Cách phân tách ngân sách:
| Giai đoạn | Bao gồm những gì | Khoảng điển hình |
|---|---|---|
| Network | DNS, TLS, kết nối, khoảng cách vùng | 20-200ms |
| Queueing | phía nhà cung cấp, tiến gần đến rate-limit | 0-500ms+ |
| TTFT | model prefill + token đầu tiên | 200-1500ms |
| Inter-token | nhịp độ generation | 1-5ms/token |
| Client | parsing, rendering, hạ tầng streaming | 10-100ms |
Các quy tắc giúp ngân sách trung thực:
- Đo tại các vùng production. Kết quả đo tại US-east cho một sản phẩm phục vụ Singapore là một con số hoàn toàn khác — độ trễ vùng có thể còn lớn hơn độ trễ model.
- P50 giấu câu chuyện; P95 mới kể câu chuyện đó. Trung vị che giấu các timeout; phần đuôi phân phối (tail) mới là thứ người dùng ghi nhớ.
- Cùng kích thước prompt, cùng mức concurrency. Những benchmark dùng prompt tí hon làm đẹp TTFT và không phạt gì cả. Hoặc bạn dùng đúng tập prompt của mình, hoặc kết quả đo chỉ là chiêu trò marketing.
Script đo lường, tối giản nhưng trung thực:
import time
from openai import OpenAI
client = OpenAI() # your production endpoint and region
PROMPT = "..." # a representative production prompt
N, STREAM = 50, True # 50 runs, streaming on
ttfts, ipss = [], []
for _ in range(N):
t0 = time.perf_counter()
first = True
stream = client.chat.completions.create(model="gpt-4o-mini",
messages=[{"role": "user", "content": PROMPT}],
stream=STREAM)
for chunk in stream:
if first:
ttfts.append((time.perf_counter() - t0) * 1000) # TTFT in ms
first = False
t_last = time.perf_counter()
else:
ipss.append((time.perf_counter() - t_last) * 1000) # inter-token ms
t_last = time.perf_counter()
def pct(xs, p):
xs = sorted(xs); return xs[int(len(xs) * p)]
print(f"TTFT P50={pct(ttfts, .5):.0f}ms P95={pct(ttfts, .95):.0f}ms")
print(f"Inter-token P50={pct(ipss, .5):.1f}ms P95={pct(ipss, .95):.1f}ms")Hãy chạy nó từ những vùng mà người dùng của bạn thực sự ở đó, với kích thước prompt thật, và ghi lại kết quả làm baseline để CI suite của bạn so sánh.
Thói quen đo lường phải nằm trong CI: một latency regression suite fail khi TTFT lệch chuẩn là thứ duy nhất giữ cho câu nói “model đã tốt hơn” trung thực — cùng kỷ luật mà thực hành observability tốt xây dựng cho phần còn lại của stack.
Cách tối ưu: streaming, caching, routing
Điểm chính: ba đòn bẩy, theo thứ tự triển khai — stream mọi thứ, cache những gì lặp lại, route theo tier — và cả ba đều là config, không phải dự án.
Lớp 1 — Streaming. Đòn bẩy đầu tiên và rẻ nhất: stream response và render token ngay khi chúng đến. Quyết định tương tác nằm ở SSE so với WebSocket — SSE cho luồng request-response (đơn giản hơn, gốc HTTP, hoạt động xuyên qua hầu hết proxy), WebSocket cho luồng hai chiều (agents, realtime audio). Những chi tiết production có thể phá hỏng streaming chưa tối ưu: proxy buffering (các trung gian giữ response cho đến khi hoàn tất sẽ phá hỏng toàn bộ mục đích), xử lý ngắt kết nối (client bỏ đi; stream phải hủy bỏ), và backpressure. Streaming không làm model nhanh hơn — nó khiến khoảng chờ của người dùng tan biến vào nhịp độ của stream.
Lớp 2 — Caching. Hai lợi ích khác biệt: prompt caching (các prefix lặp lại bỏ qua prefill, cắt TTFT ở lần gọi thứ hai giống hệt) và response caching (các request giống hệt được phục vụ mà không cần chạm tới model). Hướng dẫn về prompt caching trình bày về kinh tế học của nó; góc độ độ trễ cũng cùng một đòn bẩy: prefix ổn định giúp lần gọi thứ hai nhanh hơn và rẻ hơn. Hãy theo dõi miss rate — một cache trượt 90% số lần chỉ thêm chi phí mà chẳng mang lại lợi ích gì.
Lớp 3 — Model tiering và routing. Luồng tương tác không cần frontier model cho mọi lượt: route các lần gọi quan trọng với UX sang fast tier (bao gồm các nhà cung cấp chip chuyên dụng được đề cập trong bài so sánh fast-inference của chúng tôi) và các tác vụ nền sang cost tier. Custom routing biến quyết định theo từng request thành một thao tác cơ học, và fallbacks giúp sự cố gián đoạn thỉnh thoảng của fast tier không trở thành câu chuyện độ trễ của bạn.
Cách khắc phục độ trễ toàn cầu: regional routing
Điểm chính: với người dùng toàn cầu, chọn vùng quan trọng hơn chọn model — cùng một model, đúng vùng, là khoảng cách giữa 300ms và 900ms.
Các con số không biết nói dối: một model phục vụ từ Mỹ cho người dùng châu Âu mang thêm 100-200ms độ trễ mạng cho mỗi chặng so với một regional endpoint, và sự khác biệt này nhân lên qua các agent loops. Giải pháp mang tính kiến trúc:
- Nearest-region routing. Phục vụ mỗi người dùng từ vùng gần nhất có sẵn model — lớp load-balancing làm việc này ở cấp endpoint.
- Auto-failover giữa các vùng. Khi một provider hoặc vùng suy giảm, hãy failover sang vùng kế tiếp trước khi ngân sách TTFT của người dùng bị tiêu hết — tài liệu auto-failover trình bày chi tiết cơ chế.
- Edge calls, một cách ngắn gọn. Với những đường dẫn cực kỳ nhạy cảm với độ trễ, edge functions có thể đứng trước lời gọi LLM — giảm chặng mạng và xử lý việc tái sử dụng kết nối. Lưu ý trung thực: edge tự mang thêm chi phí cold-start, và với hầu hết workload, regional endpoint vẫn thắng; hãy kiểm thử trước khi áp dụng (đây là ngoại lệ biên duy nhất mà chúng tôi nêu rõ thay vì hứa hẹn quá mức).
Quy tắc đo lường ở phần trước áp dụng ở đây với sức nặng gấp bội: quyết định regional routing cần dữ liệu đo tại vùng — một benchmark tại Mỹ cho một thay đổi routing toàn cầu không phải là một phép đo.
Những sai lầm phổ biến
Điểm chính: bốn kiểu thất bại — mỗi kiểu biến một sáng kiến tối ưu độ trễ thành trò hề.
- Chỉ tối ưu một chỉ số. Ám ảnh TPS mà bỏ qua TTFT; ám ảnh TTFT mà bỏ qua streaming. Mô hình bốn con số trong bài viết này chính là thuốc giải.
- Bỏ qua lớp mạng. Toàn bộ tối ưu phía model, không một chút regional routing — với sản phẩm toàn cầu, đó là tối ưu nhầm một nửa ngân sách.
- Cache mà không có kỷ luật hit-rate. Cache “vì nó nhanh” với miss rate 90% — kinh tế học caching chỉ vận hành khi prefix ổn định và hit rate được đo lường.
- Không có baseline trước khi tối ưu. Thay đổi stack, tung bản cập nhật, và chưa bao giờ đo trạng thái trước khi thay đổi. Không có CI latency suite, “tối ưu” chỉ là một niềm hy vọng kèm dashboard.
Câu hỏi thường gặp
Nên tối ưu chỉ số độ trễ nào trước?
TTFT cho các sản phẩm tương tác — đó là thứ người dùng cảm nhận đầu tiên. TPS cho agent loops và output dài. Hãy tối ưu chỉ số mà use case của bạn cảm nhận, sau đó đo các chỉ số còn lại để chúng không âm thầm suy thoái.
Streaming có thực sự nhanh hơn, hay chỉ cảm giác nhanh hơn?
Cả hai, theo những nghĩa khác nhau: tổng thời gian thường không đổi, nhưng perceived latency giảm mạnh vì token đầu tiên đến sớm và stream dàn đều phần còn lại. Với sản phẩm tương tác, perceived latency chính là chỉ số sản phẩm — hãy stream mọi thứ.
Chọn vùng ảnh hưởng đến độ trễ nhiều cỡ nào?
Thường nhiều hơn cả việc chọn model: các chặng mạng xuyên lục địa thêm hàng trăm mili-giây cho mỗi lần gọi, nhân lên qua các agent loops. Nearest-region routing là thay đổi độ trễ có đòn bẩy lớn nhất mà hầu hết sản phẩm toàn cầu không bao giờ thực hiện.
Nên dùng SSE hay WebSocket cho streaming?
SSE cho luồng request-response — đơn giản hơn, gốc HTTP, thân thiện với proxy. WebSocket cho luồng hai chiều như realtime agents. Chọn theo hình dạng luồng dữ liệu, không theo trào lưu, chính là toàn bộ câu trả lời.
Caching có thực sự giảm độ trễ không?
Prompt caching cắt TTFT trên các prefix lặp lại (prefill là phần đắt đỏ), còn response caching loại bỏ hoàn toàn độ trễ model cho các request giống hệt — nhưng chỉ khi hit rate là thật. Hãy đo hit rate; miss rate chính là khoản thuế phải trả.
Vì sao P95 của tôi lại tệ hơn P50 nhiều như vậy?
Độ trễ đuôi (tail latency) trong LLM API đến từ hàng đợi của provider khi tải cao, tiến gần đến rate-limit, và biến động mạng giữa các vùng. Nếu phần đuôi quan trọng (và nó đúng là quan trọng), giải pháp là sự kết hợp giữa headroom, fallbacks và regional routing — không phải một model nhanh hơn.
Tóm tắt
Tối ưu độ trễ LLM API là bài toán của bốn con số: đo TTFT, inter-token, total và perceived latency ở cả P50 và P95 tại các vùng production của bạn; sau đó sửa từng lớp — streaming cho cảm nhận, caching cho những lần lặp lại, tiering cho sự cân bằng chi phí-tốc độ, và regional routing cho nửa ngân sách thuộc về mạng. Các bảng benchmark cho bạn biết điều gì là khả thi; ngân sách của bạn cho bạn biết điều gì thuộc về mình. Đo trước, tối ưu sau, và model nhanh nhất thế giới sẽ trở thành model mà người dùng của bạn thực sự cảm nhận được.
Bạn không thể sửa một ngân sách độ trễ mà mình chưa từng đo. Nhận TokSpan API key — $5 tín dụng miễn phí để đo lường — và chạy cùng một tập prompt từ vài vùng khác nhau.