Mở đầu — vì sao bài này quan trọng
Hãy hình dung bạn vừa ra mắt một trợ lý AI tư vấn sản phẩm cho một sàn thương mại điện tử Việt Nam. Tính năng hoạt động chính xác, câu trả lời chất lượng, đội ngũ rất tự hào. Nhưng rồi báo cáo phân tích cho thấy: 40% người dùng đóng cửa sổ chat trước khi câu trả lời đầu tiên hiện ra. Mô hình không sai. Câu trả lời không tệ. Vấn đề chỉ là một thứ: nó quá chậm.
Đây là một sự thật phũ phàng mà rất nhiều AI Product Manager học được theo cách đau đớn: với sản phẩm AI, độ trễ (latency) là một phần của chất lượng sản phẩm, không phải là chỉ số kỹ thuật bên lề. Một câu trả lời tuyệt vời đến sau 12 giây thường thua một câu trả lời khá ổn bắt đầu hiện ra sau 0.8 giây. Người dùng cảm nhận tốc độ trước khi họ kịp đánh giá nội dung.
Khác với API truyền thống nơi bạn trả về kết quả một lần, LLM sinh văn bản theo từng token một cách tuần tự. Điều này tạo ra một cấu trúc độ trễ rất đặc thù mà nếu không hiểu, bạn sẽ tối ưu sai chỗ — đổ tiền vào GPU đắt hơn trong khi vấn đề thật nằm ở prompt quá dài, hoặc cắt giảm chất lượng output trong khi đáng lẽ chỉ cần bật streaming.
Bài này sẽ giúp bạn — với tư cách PM — hiểu độ trễ của LLM được cấu thành từ đâu, đo nó bằng chỉ số nào, và có những đòn bẩy nào để tối ưu mà không phải tự tay viết một dòng CUDA nào. Mục tiêu là bạn ra được quyết định đánh đổi (trade-off) đúng đắn giữa tốc độ, chi phí và chất lượng.
Khái niệm cốt lõi
Hai thành phần độ trễ quan trọng nhất
Mọi cuộc trò chuyện về tối ưu latency LLM đều quy về hai con số. Bạn cần thuộc lòng chúng:
1. Time To First Token (TTFT) — Thời gian đến token đầu tiên. Đây là khoảng thời gian từ lúc người dùng nhấn gửi đến lúc ký tự đầu tiên của câu trả lời xuất hiện. TTFT phản ánh giai đoạn mô hình "đọc và hiểu" toàn bộ input — giai đoạn này gọi là prefill (xử lý prompt). TTFT càng nhỏ, người dùng càng cảm thấy hệ thống "phản hồi ngay".
2. Time Per Output Token (TPOT / TPT) — Thời gian sinh mỗi token tiếp theo. Sau token đầu tiên, mô hình sinh tiếp từng token một trong giai đoạn gọi là decode. TPOT đo tốc độ "gõ" của AI. Người ta hay quy đổi sang tokens/giây cho dễ hình dung (ví dụ 50 tokens/giây nghĩa là TPOT khoảng 20ms).
Công thức tổng độ trễ của một câu trả lời:
> Tổng thời gian ≈ TTFT + (TPOT × số token sinh ra)
Đây là công thức quan trọng nhất của cả bài. Nó cho bạn biết: với câu trả lời ngắn, TTFT chi phối trải nghiệm; với câu trả lời dài (tóm tắt tài liệu, viết email), TPOT × độ dài mới là phần lớn.
Vì sao tách hai chỉ số lại quan trọng đến vậy
Vì cách tối ưu cho mỗi cái hoàn toàn khác nhau.
- TTFT phụ thuộc chủ yếu vào độ dài input (prompt dài thì prefill lâu), vào việc prompt có được cache hay không, và vào hàng đợi chờ GPU rảnh. Muốn giảm TTFT, bạn rút gọn prompt, dùng prompt caching, hoặc chọn hạ tầng ít tải.
- TPOT phụ thuộc vào kích thước mô hình và phần cứng. Mô hình càng lớn thì mỗi token sinh ra càng chậm. Muốn giảm TPOT, bạn đổi sang mô hình nhỏ hơn, dùng kỹ thuật tăng tốc decode, hoặc nâng cấp phần cứng.
Các đòn bẩy tối ưu chính (theo ngôn ngữ PM)
Bạn không cần code, nhưng cần biết "menu" các lựa chọn để đối thoại với engineer:
- Streaming — trả token ngay khi sinh ra thay vì chờ đủ cả câu. Đòn bẩy số một, gần như miễn phí, cải thiện cảm nhận tốc độ ngay lập tức.
- Rút gọn prompt / context — input ngắn hơn thì prefill nhanh hơn, TTFT giảm.
- Prompt caching — phần đầu prompt lặp lại (system prompt, tài liệu cố định) được cache lại, lần sau không phải prefill lại từ đầu.
- Chọn đúng kích cỡ mô hình — không phải tác vụ nào cũng cần mô hình lớn nhất. Mô hình nhỏ sinh token nhanh hơn nhiều lần.
- Giới hạn độ dài output (max tokens) — vì tổng thời gian tỉ lệ thuận với số token sinh ra.
- Speculative decoding — một mô hình nhỏ "đoán trước" nhiều token, mô hình lớn chỉ xác minh; tăng tốc decode đáng kể (engineer triển khai, bạn chỉ cần biết để hỏi).
- Đặt hạ tầng gần người dùng (region) — độ trễ mạng từ Việt Nam đến server ở Mỹ có thể cộng thêm 200–300ms khứ hồi.
Tình huống thực tế
Ví dụ 1: Chatbot CSKH của một fintech tại TP.HCM — "Trả lời đúng nhưng ai cũng bỏ đi"
Một công ty ví điện tử (giả định tên VíNhanh) tích hợp chatbot AI trả lời câu hỏi về giao dịch, phí, hạn mức. Họ dùng một mô hình lớn qua API, không streaming. Đo lường ban đầu: tổng thời gian phản hồi trung bình 9 giây, nhưng tỉ lệ người dùng rời đi trước khi thấy câu trả lời lên tới 35%.
PM yêu cầu team tách chỉ số. Kết quả: TTFT là 7.5 giây (!), TPOT chỉ chiếm phần nhỏ. Nguyên nhân: mỗi request, hệ thống nhồi vào prompt toàn bộ 4.000 token tài liệu chính sách công ty + lịch sử 20 lượt chat trước. Prefill khổng lồ này khiến TTFT phình to.
Hành động: (1) Bật streaming ngay — người dùng thấy chữ chạy sau ~2 giây thay vì màn hình trống 9 giây. (2) Thay vì nhồi cả 4.000 token chính sách, chỉ đưa vào đoạn liên quan đến câu hỏi (đây là lý do RAG tồn tại — bài 19). (3) Bật prompt caching cho phần system prompt cố định. Kết quả sau hai tuần: TTFT giảm còn 1.3 giây, tỉ lệ bỏ đi giảm còn 9%.
Bài học: Đừng tin con số trung bình. Tách TTFT/TPOT chỉ ra đúng thủ phạm là prompt quá dài, chứ không phải mô hình chậm. Streaming là cách rẻ nhất để mua lại niềm tin của người dùng.
Ví dụ 2: Công cụ tóm tắt hợp đồng cho công ty luật — khi câu trả lời dài, TPOT mới là vua
Một startup legaltech làm tính năng tóm tắt hợp đồng 20 trang thành bản tóm tắt 800 từ. Output dài (khoảng 1.100 token). Họ dùng mô hình hàng đầu chạy ở khoảng 25 tokens/giây. Tính ra: phần decode mất 1.100 ÷ 25 ≈ 44 giây. TTFT có nhanh đến mấy cũng không cứu nổi — vì đây là bài toán output dài, TPOT × số token thống trị.
PM đứng trước trade-off kinh điển. Các phương án thảo luận với team: (a) Đổi sang mô hình nhỏ hơn chạy 80 tokens/giây — decode chỉ còn ~14 giây, nhưng phải kiểm chứng chất lượng tóm tắt có tụt không qua đánh giá (bài 26). (b) Áp dụng speculative decoding để tăng tốc decode mà giữ nguyên mô hình lớn. (c) Thiết kế lại UX: thay vì chờ cả bản tóm tắt, hiển thị tóm tắt theo từng mục (các bên, giá trị, điều khoản phạt...) cuốn chiếu, để người dùng đọc mục đầu trong khi mục sau đang sinh.
Họ chọn kết hợp (a) và (c): mô hình tầm trung + streaming theo từng phần. Người dùng bắt đầu đọc sau 2 giây và không còn cảm giác "treo".
Bài học: Với tác vụ output dài, đừng phí công tối ưu TTFT. Đòn bẩy nằm ở giảm số token output, tăng tốc độ decode, và thiết kế UX cho phép người dùng tiêu thụ kết quả từng phần.
Ví dụ 3: Trợ lý gợi ý sản phẩm thời gian thực — độ trễ mạng vùng địa lý
Một sàn TMĐT Đông Nam Á phục vụ người dùng Việt Nam, Indonesia, Philippines. Họ gọi API LLM đặt ở vùng us-east (Mỹ). Kỹ thuật báo TTFT đo tại server Mỹ rất tốt — 400ms. Nhưng người dùng ở Hà Nội phàn nàn vẫn chậm. Đo từ thiết bị thật ở Việt Nam: độ trễ vòng mạng (round-trip) đến Mỹ cộng thêm gần 280ms mỗi chiều, và vì streaming mở kết nối liên tục, độ trễ này khuếch đại cảm giác giật cục.
Hành động: chuyển sang endpoint đặt ở vùng Singapore (gần Việt Nam hơn nhiều), bật nén truyền, và đưa các tác vụ đơn giản (gợi ý nhanh) sang một mô hình nhỏ chạy gần biên (edge — bài 53). TTFT cảm nhận tại Hà Nội giảm từ ~1.1 giây xuống ~550ms.
Bài học: Latency không chỉ nằm trong mô hình. Khoảng cách địa lý giữa người dùng và server là một thành phần thật, đặc biệt với người dùng Việt Nam. Luôn đo độ trễ từ thiết bị của người dùng thật, không phải từ server.
Hướng dẫn từng bước
Đây là quy trình một AI PM nên đi để tối ưu độ trễ một tính năng AISẵn:
Bước 1 — Thiết lập đo lường tách bạch. Yêu cầu team log ba thứ cho mỗi request: TTFT, TPOT (hoặc tokens/giây), và tổng thời gian. Báo cáo theo p50, p95, p99. Không có đo lường thì mọi tối ưu chỉ là cảm tính.
Bước 2 — Xác định tính năng của bạn là "TTFT-bound" hay "TPOT-bound". Hỏi: output thường dài bao nhiêu? Nếu output ngắn (chat hỏi đáp, phân loại) → ưu tiên TTFT. Nếu output dài (tóm tắt, soạn thảo) → ưu tiên TPOT và số token output.
Bước 3 — Bật streaming nếu chưa có. Đây gần như luôn là việc đầu tiên nên làm. Nó không giảm latency thật nhưng cải thiện latency cảm nhận (perceived) đáng kể, với chi phí kỹ thuật thấp.
Bước 4 — Tấn công độ dài input. Rà soát prompt: có nhồi tài liệu thừa không? Lịch sử hội thoại có cần giữ hết 20 lượt không? Áp dụng prompt caching cho phần cố định. Mỗi token input cắt được đều rút ngắn prefill.
Bước 5 — Tấn công độ dài output. Đặt max tokens hợp lý. Hướng dẫn mô hình trả lời súc tích trong prompt ("trả lời ngắn gọn dưới 3 câu"). Đôi khi giảm độ dài output là cách nhanh nhất giảm tổng thời gian.
Bước 6 — Cân nhắc đổi/định tuyến mô hình. Không phải request nào cũng cần mô hình mạnh nhất. Các câu đơn giản định tuyến sang mô hình nhỏ, nhanh (chủ đề của bài 41). Đây là đòn bẩy giảm TPOT mạnh nhất.
Bước 7 — Kiểm tra hạ tầng và vùng địa lý. Đặt endpoint gần người dùng. Đo từ thiết bị thật ở thị trường mục tiêu.
Bước 8 — Đo lại và xác nhận không hy sinh chất lượng. Mọi tối ưu tốc độ đều có nguy cơ giảm chất lượng. Sau khi đổi, chạy lại bộ đánh giá chất lượng và làm A/B test (bài 31) để chắc rằng nhanh hơn nhưng vẫn đủ tốt.
Lỗi thường gặp & mẹo
Lỗi 1: Chỉ nhìn con số trung bình. Trung bình giấu đi đuôi dài. Người dùng gặp p99 = 15 giây sẽ rời đi và kể xấu sản phẩm. Luôn theo dõi p95, p99.
Lỗi 2: Nhầm latency cảm nhận với latency thật. Streaming không làm câu trả lời hoàn thành nhanh hơn, nhưng làm người dùng cảm thấy nhanh hơn rất nhiều. Đừng bỏ qua đòn bẩy "cảm nhận" chỉ vì nó không thay đổi tổng thời gian.
Lỗi 3: Tối ưu sai thành phần. Đổ tiền nâng GPU (giảm TPOT) trong khi vấn đề thật là prompt 5.000 token (TTFT). Tách chỉ số trước khi hành động.
Lỗi 4: Tối ưu tốc độ mà quên đo chất lượng. Đổi sang mô hình nhỏ làm TPOT đẹp nhưng câu trả lời sai nhiều hơn — đánh đổi tệ. Luôn ghép tối ưu latency với đánh giá chất lượng.
Lỗi 5: Quên độ trễ mạng và cold start. Server ở xa người dùng, hoặc mô hình tự host bị "khởi động nguội" sau thời gian không dùng, đều cộng thêm vài giây mà bảng đo nội bộ không thấy.
Mẹo: Đặt "ngân sách độ trễ" (latency budget) ngay từ đầu dự án — ví dụ "TTFT p95 < 1 giây, hoàn thành p95 < 6 giây". Có ngân sách thì mọi quyết định trade-off đều có thước đo rõ ràng.
Mẹo: Dùng các tín hiệu UX khi chờ — hiệu ứng "đang gõ", skeleton, hoặc câu mở đầu chung — để lấp khoảng TTFT, làm người dùng kiên nhẫn hơn.
Bài tập thực hành
- Phân loại tính năng. Lấy một tính năng AI bạn biết (chatbot, tóm tắt, viết caption...). Xác định nó là TTFT-bound hay TPOT-bound, và giải thích vì sao dựa trên độ dài output điển hình.
- Tính toán nhanh. Một tính năng có TTFT = 800ms, tốc độ sinh 40 tokens/giây, output trung bình 600 token. Tính tổng thời gian phản hồi. Sau đó, nếu đổi sang mô hình 100 tokens/giây nhưng TTFT tăng lên 1.000ms, tổng thời gian mới là bao nhiêu? Đáng đổi không?
- Đề xuất ngân sách độ trễ. Viết một latency budget (TTFT p95 và tổng thời gian p95) cho một trợ lý CSKH thời gian thực phục vụ người dùng Việt Nam, kèm lý do.
- Lập kế hoạch tối ưu. Cho tình huống: tính năng tóm tắt email mất trung bình 14 giây, output dài, TTFT chỉ 600ms. Liệt kê theo thứ tự ưu tiên 4 hành động bạn sẽ làm và rủi ro chất lượng của mỗi hành động.
Tóm tắt
Độ trễ là một thuộc tính chất lượng của sản phẩm AI, không phải chi tiết kỹ thuật bên lề. Toàn bộ bài này quy về một công thức bạn cần nhớ: Tổng thời gian ≈ TTFT + (TPOT × số token output).
- TTFT (Time To First Token) phụ thuộc độ dài input, prompt caching và hạ tầng — quan trọng nhất với tác vụ output ngắn.
- TPOT (Time Per Output Token) phụ thuộc kích cỡ mô hình và phần cứng — quan trọng nhất với tác vụ output dài.
- Tách hai chỉ số (kèm p95, p99) là điều kiện tiên quyết để tối ưu đúng chỗ.
- Các đòn bẩy chính: streaming (cải thiện cảm nhận, rẻ), rút gọn input, prompt caching, giới hạn output, chọn/định tuyến mô hình phù hợp, đặt hạ tầng gần người dùng.
- Mọi tối ưu tốc độ đều phải đi kèm kiểm tra chất lượng và A/B test — nhanh hơn nhưng sai hơn là một đánh đổi tồi.