Độ trễ (latency) là thời gian người dùng phải chờ, thường đo bằng thời gian đến token đầu tiên (TTFT) và tổng thời gian hoàn thành câu trả lời. Thông lượng (throughput) là lượng việc hệ thống xử lý được trong một đơn vị thời gian, ví dụ tổng số token mỗi giây hoặc số yêu cầu mỗi phút cho tất cả người dùng cộng lại. Một người dùng quan tâm độ trễ; người vận hành phục vụ cả công ty quan tâm thông lượng. Hai chỉ số thường đánh đổi nhau: tăng số người dùng đồng thời giúp thông lượng tăng nhưng mỗi người có thể chờ lâu hơn.
Độ trễ và thông lượng AI là gì
Độ trễ và thông lượng AI là hai cách nhìn khác nhau về tốc độ của cùng một hệ thống. Hãy hình dung một quán phở: độ trễ là thời gian một khách chờ từ lúc gọi món đến lúc có tô phở; thông lượng là số tô quán phục vụ được mỗi giờ. Quán có thể bán rất nhiều tô mỗi giờ nhưng giờ cao điểm từng khách vẫn chờ lâu.
Với AI tạo sinh, câu trả lời được sinh dần từng token, nên độ trễ có nhiều lớp:
- Thời gian đến token đầu tiên (TTFT): khoảng chờ trước khi chữ đầu tiên hiện ra. Mô hình cần đọc hết prompt trước khi viết, nên prompt càng dài TTFT càng lớn.
- Tốc độ sinh (token/giây cho mỗi người): chữ hiện ra nhanh hay chậm sau khi đã bắt đầu.
- Tổng thời gian: TTFT cộng thời gian sinh toàn bộ câu trả lời.
Thông lượng thì đo ở cấp hệ thống: tổng token mỗi giây cho tất cả người dùng, hoặc số yêu cầu hoàn thành mỗi phút. Một máy chủ có thể phục vụ 20 người cùng lúc với thông lượng cao, trong khi mỗi người thấy chữ chạy chậm hơn so với lúc chỉ có một mình.
Các chỉ số tốc độ thường gặp và ý nghĩa
Khi đọc trang tài liệu API, bài đánh giá GPU hay báo cáo của công cụ chạy mô hình, bạn sẽ gặp các thuật ngữ sau. Cách gọi có thể khác nhau giữa nguồn, nên luôn xem họ đo trong điều kiện nào.
| Chỉ số | Đo cái gì | Ai quan tâm | Ảnh hưởng lớn nhất |
|---|---|---|---|
| TTFT | Thời gian chờ chữ đầu tiên | Người dùng chat, voice bot | Độ dài prompt, tải máy chủ |
| Token/giây mỗi luồng | Tốc độ chữ chạy cho một người | Người dùng cuối | Băng thông bộ nhớ GPU, kích thước mô hình |
| Tổng token/giây | Năng lực toàn hệ thống | Người vận hành, IT | Số yêu cầu đồng thời, phần mềm phục vụ |
| Yêu cầu/phút | Số tác vụ xong mỗi phút | Quy trình xử lý hàng loạt | Độ dài trung bình đầu vào, đầu ra |
| Độ trễ p95 | Thời gian mà 95% yêu cầu nhanh hơn | Người thiết kế dịch vụ | Giờ cao điểm, yêu cầu dài bất thường |
Điều gì quyết định độ trễ và thông lượng
Nhiều yếu tố cộng lại, nhưng có thể gom thành bốn nhóm chính.
Kích thước mô hình và lượng tử hóa
Mô hình càng nhiều tham số, mỗi token càng tốn tính toán và đọc bộ nhớ. Lượng tử hóa xuống 4-bit hoặc 8-bit giúp giảm dung lượng, thường tăng tốc độ trên cùng phần cứng nhưng có thể giảm nhẹ chất lượng.
Phần cứng
Ở giai đoạn sinh token, tốc độ thường bị giới hạn bởi băng thông bộ nhớ GPU hơn là sức tính toán thuần. Đó là lý do GPU có VRAM nhanh cho tốc độ token/giây cao hơn rõ rệt so với chạy bằng CPU và RAM thường.
Độ dài ngữ cảnh
Prompt dài, nhiều tài liệu đính kèm làm TTFT tăng và chiếm thêm bộ nhớ cho KV cache, từ đó giảm số người phục vụ được cùng lúc.
Phần mềm phục vụ
Các công cụ như vLLM dùng kỹ thuật gom lô liên tục (continuous batching) để tăng thông lượng khi nhiều người dùng, còn Ollama ưu tiên dễ cài cho một người hoặc nhóm nhỏ. Cùng mô hình, cùng GPU, phần mềm khác nhau có thể cho thông lượng chênh nhau đáng kể.
Đọc thông số quảng cáo sao cho không bị nhầm
Con số ‘X token/giây’ xuất hiện khắp nơi, nhưng thiếu ngữ cảnh thì gần như vô nghĩa. Trước khi so sánh, hãy hỏi đủ các câu sau:
- Đo cho một người hay tổng nhiều người? 1.000 token/giây tổng cho 50 luồng khác hẳn 1.000 token/giây cho một luồng.
- Mô hình nào, lượng tử hóa mức nào? Bản 4-bit nhanh hơn bản 16-bit của cùng mô hình.
- Độ dài prompt và đầu ra bao nhiêu? Thử với prompt 100 token cho kết quả đẹp hơn nhiều so với prompt 8.000 token.
- Đo TTFT hay chỉ đo tốc độ sinh? Nhiều bảng chỉ khoe tốc độ sinh, bỏ qua thời gian chờ ban đầu.
- Phiên bản phần mềm, driver nào? Hiệu năng thay đổi theo bản cập nhật.
Với API thương mại, tốc độ còn dao động theo giờ trong ngày và tải chung của nhà cung cấp. Nếu cần cam kết, hãy xem các gói có mức dịch vụ rõ ràng và tự đo trong khung giờ làm việc thật của công ty.
Nguyên tắc chung: chỉ tin con số bạn tự đo với dữ liệu của mình, còn số liệu công bố dùng để khoanh vùng lựa chọn.
Bao nhiêu là đủ nhanh cho từng ứng dụng
Không phải ứng dụng nào cũng cần nhanh như nhau. Đặt yêu cầu đúng giúp tránh đầu tư thừa.
- Chatbot trên website, Zalo: người dùng chủ yếu cảm nhận TTFT. Chữ bắt đầu hiện trong khoảng 1–2 giây thường tạo cảm giác phản hồi tốt; tốc độ chữ chạy chỉ cần nhanh hơn tốc độ đọc.
- Voice bot tổng đài: nhạy cảm nhất với độ trễ vì có thêm bước nhận dạng giọng nói và đọc lại. Khoảng lặng dài khiến khách nghĩ cuộc gọi bị rớt.
- Trợ lý nội bộ cho 20–50 nhân viên: cần cân bằng; ước lượng số người dùng đồng thời giờ cao điểm, thường thấp hơn nhiều so với tổng nhân sự.
- Xử lý hàng loạt ban đêm: phân loại hàng nghìn email, tóm tắt hồ sơ. Độ trễ từng yêu cầu gần như không quan trọng, thông lượng và chi phí mới là chính.
Ví dụ ước lượng
Công ty 40 người, giờ cao điểm khoảng 6–8 người hỏi cùng lúc, mỗi câu trả lời khoảng 300–500 token. Bạn cần hệ thống giữ tốc độ dễ chịu cho khoảng 8 luồng song song, không cần phục vụ 40 luồng. Ước lượng này giúp chọn đúng cỡ GPU thay vì mua quá lớn.
Cách tự đo độ trễ và thông lượng
Bạn có thể tự đo mà không cần công cụ phức tạp.
Chuẩn bị
- Bộ 20–50 prompt mẫu lấy từ công việc thật, đủ cả ngắn và dài.
- Ghi lại mô hình, mức lượng tử hóa, phần mềm và phiên bản.
Các bước
- Bật chế độ streaming, ghi thời điểm gửi yêu cầu và thời điểm nhận token đầu tiên để có TTFT.
- Đếm số token đầu ra chia cho thời gian sinh để có token/giây mỗi luồng. Nhiều công cụ như Ollama hiển thị sẵn thông số này ở chế độ chi tiết.
- Chạy lại với 1, 4, 8, 16 yêu cầu đồng thời, ghi tổng token/giây và TTFT trung bình.
- Tính độ trễ p95 thay vì chỉ nhìn trung bình.
Kiểm tra kết quả
Vẽ bảng đơn giản: số luồng đồng thời ở cột trái, TTFT và token/giây mỗi luồng ở các cột sau. Điểm mà TTFT bắt đầu tăng vọt chính là giới hạn thực tế của hệ thống. Hãy vận hành ở mức thấp hơn điểm đó để dự phòng giờ cao điểm.
Cách cải thiện tốc độ và lỗi thường gặp
Khi hệ thống chậm, đừng vội nâng cấp phần cứng. Thử các cách sau trước:
- Rút gọn prompt: bỏ hướng dẫn lặp, chỉ đưa đoạn tài liệu liên quan thay vì cả file.
- Giới hạn độ dài đầu ra: yêu cầu trả lời ngắn gọn, đặt số token tối đa hợp lý.
- Dùng prompt caching: phần mở đầu cố định được lưu đệm giúp giảm TTFT trên các nền tảng hỗ trợ.
- Chọn mô hình vừa đủ: phân loại email không cần mô hình lớn nhất.
- Đổi phần mềm phục vụ: khi nhiều người dùng, công cụ hỗ trợ batching tốt cho thông lượng cao hơn.
- Đẩy việc không gấp sang xử lý hàng loạt: giải phóng tài nguyên cho người dùng trực tiếp.
Lỗi thường gặp
- Đo khi máy rảnh rồi kết luận cho giờ cao điểm.
- So sánh tốc độ giữa hai mô hình khác mức lượng tử hóa.
- Mô hình tràn VRAM, phải chia sang RAM hệ thống khiến tốc độ giảm mạnh mà không ai để ý.
- Bỏ qua độ trễ mạng khi máy chủ AI đặt ở chi nhánh khác hoặc đường truyền yếu.
Trước khi mua GPU hay chọn gói API, hãy viết ra hai con số: số người dùng đồng thời giờ cao điểm và thời gian chờ tối đa chấp nhận được. Hai con số này định hướng cấu hình tốt hơn mọi bảng benchmark.
Muốn đưa AI vào công việc của doanh nghiệp? PCTech tư vấn, đánh giá mức sẵn sàng AI và triển khai chatbot, AI agent, tự động hóa cho doanh nghiệp.
10 câu hỏi, 2 phút, nhận mức độ và việc nên làm tiếp theo. Dùng thử ngay
Câu hỏi thường gặp
Token mỗi giây bao nhiêu là nhanh?
Phụ thuộc mục đích. Với chat, tốc độ nhanh hơn tốc độ đọc của người dùng đã đủ thoải mái; với xử lý hàng loạt, nên nhìn tổng thông lượng của hệ thống.
Vì sao AI trả lời chậm khi tôi dán tài liệu dài?
Mô hình phải đọc toàn bộ phần đầu vào trước khi viết chữ đầu tiên, nên prompt dài làm thời gian chờ ban đầu tăng. Hãy chỉ đưa đoạn liên quan hoặc dùng RAG.
Độ trễ và thông lượng cái nào quan trọng hơn?
Với ứng dụng tương tác trực tiếp như chatbot, voice bot thì độ trễ quan trọng hơn. Với xử lý hàng loạt như phân loại hồ sơ, thông lượng và chi phí quan trọng hơn.
Chạy AI bằng CPU có quá chậm không?
Mô hình nhỏ đã lượng tử hóa vẫn chạy được trên CPU cho một người dùng, nhưng tốc độ thấp hơn đáng kể so với GPU. Phục vụ nhiều người cùng lúc thì nên có GPU.
TTFT là gì?
TTFT là Time To First Token, thời gian từ lúc gửi câu hỏi đến khi nhận token đầu tiên. Đây là chỉ số quyết định cảm giác 'AI phản hồi nhanh hay chậm'.
Mạng internet có ảnh hưởng tốc độ AI không?
Có, đặc biệt với API đặt ở nước ngoài hoặc máy chủ nội bộ truy cập từ xa. Độ trễ mạng cộng thêm vào TTFT, nên hãy đo cả từ máy người dùng thật.
Bài viết liên quan
- vLLM là gì? Chạy mô hình AI tốc độ cao trên server
- Ollama vs vLLM: chọn công cụ chạy mô hình AI nội bộ
- Cần bao nhiêu VRAM để chạy LLM 7B, 14B, 32B, 70B?
- Quantization (lượng tử hóa) mô hình AI là gì? Giảm bộ nhớ mà vẫn giữ chất lượng
- Prompt caching là gì? Cách giảm chi phí và độ trễ API AI
- Batch API là gì? Xử lý hàng loạt bằng AI với chi phí thấp
- GPU đám mây vs server tại chỗ cho AI doanh nghiệp: chọn hướng nào
- Context window (cửa sổ ngữ cảnh) là gì? Ảnh hưởng gì khi dùng AI
