# Độ trễ model AI: đo đến lúc hoàn tất, nên con số dài hơn bạn tưởng

> Độ trễ ở đây tính đến lúc hoàn tất cả yêu cầu: p50 chạy 7.998 đến 26.226 ms, đuôi p99 dài 5,89 đến 16,80 lần p50, và một lượt timeout vẫn bị tính tiền.

- URL: https://wisa.vn/blog/do-tre-model-ai
- Markdown: https://wisa.vn/blog/do-tre-model-ai.md
- Ngôn ngữ: vi
- Loại: post
- Xuất bản: 2026-10-30T15:46:00.000Z
- Cập nhật: 2026-10-31T06:51:29Z
- Tác giả: Đội ngũ WinSell (Product)
- Thời gian đọc: ~5 phút
- Từ khoá: độ trễ model ai, thời gian hoàn tất yêu cầu, phân vị p99, chi phí mỗi kết quả dùng được
- cluster: chon-va-so-sanh-model
- targetQuery: độ trễ model ai
- citations: OpenAI — tối ưu độ trễ (https://developers.openai.com/api/docs/guides/latency-optimization); Google — danh mục model Gemini (https://ai.google.dev/gemini-api/docs/models); EleutherAI — lm-evaluation-harness (https://github.com/EleutherAI/lm-evaluation-harness); Wisa — chuyên mục Chọn và so sánh model (https://wisa.vn/blog/chu-de/chon-va-so-sanh-model)

---

Độ trễ model AI ở đây là thời gian hoàn tất toàn bộ yêu cầu, không phải mốc byte đầu tiên, nên nó là khoảng thời gian bạn ngồi chờ. Một cửa sổ 7 ngày kết thúc 27/10/2026, số liệu đo tại gateway của Wisa, cho thấy p50 chạy từ 7.998 ms đến 26.226 ms trên sáu model.

## Độ trễ ở đây là thời gian hoàn tất, không phải mốc byte đầu tiên

Định nghĩa dùng xuyên suốt bài: `latency_ms` là thời gian hoàn tất toàn bộ yêu cầu, tính từ lúc gateway nhận yêu cầu tới lúc token cuối cùng được ghi xong. Bộ dữ liệu không có mốc byte đầu tiên, nên không có cách nào tách phần chờ trước khi chữ đầu hiện ra khỏi phần chờ còn lại. Vì vậy mọi con số dưới đây dài hơn cảm giác của bạn khi nhận một câu trả lời ngắn.

Công thức thông lượng đi kèm cũng neo vào cùng một mốc: output_tokens ÷ (latency_ms ÷ 1.000). Nếu bạn đang dùng một chỉ số khác để đặt ngưỡng timeout, hãy đổi sang mốc hoàn tất trước khi so với bảng này, vì hai mốc không thay thế được cho nhau.

## p50 trải từ 7.998 ms đến 26.226 ms trên sáu model

p50 là 7.998 ms ở DeepSeek V4.1 Flash 1017 và 26.226 ms ở GPT 6.1 SOL, tức 3,28 lần. Khoảng cách này nhỏ hơn nhiều so với khoảng cách ở phần đuôi, và đó là lý do một bảng chỉ có p50 thường khiến người chọn model yên tâm quá sớm.

Sáu hàng trong bảng sau là toàn bộ model có đủ mẫu trong cửa sổ đo. Cột n cho biết mỗi hàng dựa trên bao nhiêu yêu cầu. Hàng Claude Sonnet 5.5 chỉ có 48 mẫu, nên đọc nó như một ước lượng chứ không phải một hằng số.

## Đuôi p99 dài 5,89 đến 16,80 lần p50

| Model | n | p50 | p95 | p99 | p99 ÷ p50 |
| --- | --- | --- | --- | --- | --- |
| DeepSeek V4.1 Flash 1017 | 4.660 | 7.998 ms | 27.807 ms | 63.460 ms | 7,93 |
| Claude Sonnet 5.5 | 48 | 10.029 ms | 45.156 ms | 142.126 ms | 14,17 |
| Gemini 3.8 Flash | 6.051 | 10.181 ms | 27.344 ms | 59.922 ms | 5,89 |
| DeepSeek V4.1 Flash | 213 | 11.581 ms | 74.224 ms | 194.521 ms | 16,80 |
| Claude Opus 5.5 | 271 | 15.168 ms | 103.013 ms | 170.422 ms | 11,24 |
| GPT 6.1 SOL | 214 | 26.226 ms | 125.749 ms | 244.824 ms | 9,34 |

Đuôi ngắn nhất thuộc về Gemini 3.8 Flash: p99 là 59.922 ms, chia cho p50 là 10.181 ms ra 5,89. Đuôi dài nhất thuộc về DeepSeek V4.1 Flash: p99 là 194.521 ms, chia cho p50 là 11.581 ms ra 16,80. Cùng một cửa sổ, cùng một định nghĩa, mà mức phân tán khác nhau rõ rệt.

Hàng GPT 6.1 SOL cho thấy đuôi tính bằng giây: p99 là 244.824 ms, tức khoảng 244,8 giây cho một lần gọi. Đó là con số bạn phải đặt vào ngưỡng timeout nếu muốn phục vụ 99 trong 100 lượt.

## Vì sao một lượt timeout vẫn bị tính token đã sinh?

Khi bạn cắt một lượt ở ngưỡng timeout, phần token model đã sinh vẫn nằm trong hoá đơn, còn kết quả thì không về tới người dùng. Tỉ lệ lỗi trong bảng chính là phần này: Claude Opus 5.5 có 2,21% lượt lỗi, DeepSeek V4.1 Flash có 0%.

Vì thế chi phí của một kết quả dùng được không phải chi phí một lượt, mà là chi phí một lượt chia cho (1 − tỉ lệ lỗi). Với Claude Opus 5.5, một lượt chuẩn 2.000 token vào và 700 token ra tốn 26,40 đồng ở mức 4.800đ vào và 24.000đ ra; chia cho 0,9779 ra 27,00 đồng. Với DeepSeek V4.1 Flash, cùng cấu trúc lượt, mức 720đ vào và 2.880đ ra cho 3,456 đồng; chia cho 1 vẫn là 3,456 đồng.

Hai con số 27,00 đồng và 3,456 đồng chênh nhau 7,81 lần, và phần chênh đó không đến từ độ trễ. Độ trễ quyết định bạn chờ bao lâu; tỉ lệ lỗi quyết định bạn phải trả bao nhiêu cho một kết quả dùng được. Nếu tỉ lệ lỗi của model bạn đang dùng thấp hơn 1%, phần chia thêm này gần như bằng không và bạn có thể bỏ qua nó khi ước lượng chi phí tháng.

## Đọc bảng độ trễ theo thứ tự nào

Bước một là lọc theo loại việc. Một lượt hỏi đáp ngắn và một lượt sinh báo cáo dài không cùng phân bố, nên đừng so p50 của hai loại việc với nhau. Bước hai là đọc cột n. Bước ba là chọn phân vị khớp với ngưỡng chịu đựng của bạn: nếu có người ngồi chờ câu trả lời, hãy đặt ngưỡng theo p50 và p95; nếu bạn chạy nền không giám sát, p99 mới là cột quyết định ngưỡng timeout.

Cách đọc số mẫu và ý nghĩa từng phân vị được trình bày kỹ hơn ở [benchmark model AI](/blog/benchmark-model-ai) và [benchmark trong AI là gì](/blog/benchmark-trong-ai-la-gi). Nếu câu hỏi của bạn là model nào phát chữ nhanh hơn chứ không phải model nào xong việc sớm hơn, hãy đọc [tốc độ đọc của AI](/blog/toc-do-doc-cua-ai), vì đó là một phép đo khác. Khái niệm nền nằm ở [inference là gì](/tu-dien/inference), còn danh sách model đầy đủ nằm trong [chuyên mục chọn và so sánh model](/blog/chu-de/chon-va-so-sanh-model).

## Giới hạn của bài này

Bài này không nói model nào nhanh nhất. Nó chỉ nói độ trễ của một cửa sổ 7 ngày, đo trên lưu lượng thật của một gateway, với sáu model đủ mẫu. Nếu việc của bạn là prompt rất dài hoặc đầu ra rất ngắn, phân bố sẽ khác và p50 của bạn sẽ khác.

Con số cũng có hạn sử dụng. p99 phản ứng với thay đổi lưu lượng nhanh hơn p50, nên sau vài tuần hãy đo lại thay vì trích lại bảng trên. Và nếu model bạn cần không nằm trong sáu hàng này, bạn chưa có gì để so: 40 trong 46 model của danh mục chưa đủ mẫu để công bố một phân vị nào.

## Câu hỏi thường gặp
### Độ trễ model AI được đo từ lúc nào đến lúc nào?

Từ lúc gateway nhận yêu cầu tới lúc token cuối cùng của câu trả lời được ghi xong. Bộ dữ liệu không ghi mốc byte đầu tiên, nên con số bạn thấy là toàn bộ thời gian chờ chứ không phải phần chờ trước khi chữ đầu hiện ra.

### p50 của sáu model đã đo là bao nhiêu?

p50 thấp nhất là 7.998 ms ở DeepSeek V4.1 Flash 1017 và cao nhất là 26.226 ms ở GPT 6.1 SOL, tức 3,28 lần. Bốn hàng còn lại nằm giữa hai đầu đó, và mỗi hàng đều kèm số mẫu riêng để bạn cân nhắc độ tin.

### Vì sao p99 dài hơn p50 nhiều lần?

Vì p99 là mẫu xấu nhất trong 100 lượt, còn p50 là lượt điển hình. Trong cửa sổ 7 ngày, đuôi p99 dài từ 5,89 lần p50 ở Gemini 3.8 Flash đến 16,80 lần ở DeepSeek V4.1 Flash.

### Một lượt timeout có bị tính tiền không?

Có, phần token đã sinh trước khi bạn cắt lượt vẫn được tính. Vì thế chi phí mỗi kết quả dùng được phải chia thêm cho (1 − tỉ lệ lỗi), và với Claude Opus 5.5 phép chia đó đẩy 26,40 đồng lên 27,00 đồng.

### Độ trễ khác tốc độ đọc ở chỗ nào?

Độ trễ đo toàn bộ thời gian một yêu cầu chiếm dụng, còn tốc độ đọc chỉ đo số token phát ra mỗi giây trong lúc model đang sinh chữ. Một model có thể phát chữ nhanh mà vẫn xong việc muộn vì nó viết dài hơn.

---

## Đường dẫn cho agent
- Bản HTML: https://wisa.vn/blog/do-tre-model-ai
- Mục lục Blog: https://wisa.vn/blog (markdown: https://wisa.vn/blog.md)
- Bản đồ site cho LLM: https://wisa.vn/llms.txt
- Toàn văn nội dung: https://wisa.vn/llms-full.txt
- Dữ liệu sản phẩm và bảng giá: https://wisa.vn/facts.json
- Sitemap: https://wisa.vn/sitemap.xml
- Quy tắc crawl: https://wisa.vn/robots.txt