Trong ngày 2026-11-03/04, bộ kiểm thử APB Full được chạy trên DeepSeek V4.1 Flash 1017 qua AIHubMix với năm nhà cung cấp. Mọi nhà cung cấp đều nhận cùng câu hỏi, tham số và tập lệnh gửi yêu cầu; thông tin của năm nhà cung cấp có trên trang mô hình. APB Profile này chỉ bao quát kênh chính thức của DeepSeek. Kênh này được truy cập qua tuyến nhà cung cấp chính thức DeepSeek của AIHubMix, không phải kết nối trực tiếp tới API của DeepSeek.
Bài viết này chỉ báo cáo điểm số, không xếp hạng hay đề xuất nhà cung cấp nào: Q 42.45, F 94.00, P 86.14, K 98.38 và R 100. Q, F, P và R là điểm của bốn mục; K là điểm phụ của P. Điểm tổng thể 73.76 là chỉ số tổng hợp, không phải chứng nhận và không có khoảng tin cậy. Tiêu chuẩn chấm điểm là AIHubMix Provider Benchmark Standard v2.0.
Điểm số của năm nhà cung cấp
Chữ đậm đánh dấu nhà cung cấp trong bài viết này. Thứ tự nhà cung cấp được cố định, không phải thứ hạng. K là điểm phụ của P, chiếm 20%, và được liệt kê riêng để tham khảo. Điểm tổng thể là chỉ số tổng hợp, không có khoảng tin cậy. Kênh chính thức DeepSeek và Alibaba Cloud chênh nhau 0.37 điểm tổng thể, không thể phân biệt rõ.
Tóm tắt nhanh
- Chất lượng câu trả lời: Q 42.45. BFCL 86.13%, HLE 15.06%, AA-LCR 53.20%. Bảy đầu ra HLE bị cắt ở giới hạn max_tokens và được tính là sai. Kênh này là mức cơ sở Q để so sánh với bốn kênh còn lại.
- Hỗ trợ chức năng: F 94.00. Đạt 137 trong số 147 lượt kiểm tra được tính điểm. Có thêm 27 lượt kiểm tra phụ thuộc vào số lượng token chính xác bị tuyên bố không hợp lệ và loại khỏi mẫu số.
- Tốc độ phản hồi: P 86.14. Trong cửa sổ đầu tiên với một yêu cầu đồng thời, có 15 yêu cầu không hợp lệ trên tổng số 30 (12 × 503, 2 × hết thời hạn, 1 × hết thời gian chờ đọc), được tính là vô hạn; trung vị thời gian đến token đầu tiên là 1.87 s (chỉ tính yêu cầu hợp lệ: 1.72 s); 10 yêu cầu đồng thời: 1.72 s; TPOT 2.84 ms.
- Bộ nhớ đệm: K 98.38. Cả 18 yêu cầu nóng ở mức 8k và 32k đều trúng bộ nhớ đệm; các yêu cầu đối chứng lạnh không đọc dữ liệu từ bộ nhớ đệm.
- Độ ổn định dịch vụ: R 100. Cả 300 yêu cầu riêng đều thành công ngay lần thử đầu tiên.
Thiết lập kiểm thử
Các yêu cầu được gửi qua AIHubMix bằng cách chọn tuyến nhà cung cấp chính thức DeepSeek; hướng dẫn bắt đầu nhanh trình bày cách cấu hình quyền truy cập.
| Mục | Chi tiết |
|---|---|
| Mô hình | DeepSeek V4.1 Flash 1017 |
| ID mô hình được yêu cầu | deepseek-flash |
| Tên mô hình trả về | deepseek-flash |
| Tuyến truy cập | Tuyến nhà cung cấp chính thức DeepSeek của AIHubMix; không phải kết nối trực tiếp tới API của DeepSeek |
| Tham số | Chế độ không suy nghĩ, temperature 1.0, max_tokens 16,384, thời gian chờ 300 s, không tự động thử lại |
| Tắt suy nghĩ | Tất cả yêu cầu đều dùng reasoning_effort=none |
| Thời gian | 2026-11-03 18:07 – 11-04 16:33 UTC+8; năm nhà cung cấp dùng chung một Mac mini, mạng và tài khoản |
| Số mẫu | Chất lượng câu trả lời: 4,250 lượt thử (BFCL 500 × 3, HLE 250 × 10, AA-LCR 25 × 10); các trường hợp chức năng: 60 × 3 cửa sổ; tốc độ: 90 với một yêu cầu đồng thời và 90 với 10 yêu cầu đồng thời; độ ổn định: 300; bộ nhớ đệm: 30 (ba nhóm cho mỗi tiền tố 8k và 32k) |
Q — chất lượng câu trả lời: 42.45
Bộ kiểm thử tổng hợp kết quả của BFCL 500 câu hỏi × 3 lượt chạy, HLE 250 × 10 và AA-LCR 25 × 10. BFCL được chấm bằng các quy tắc tự động; HLE và AA-LCR được chấm bởi mô hình giám khảo deepseek-flash. Cả năm nhà cung cấp đều trả lời cùng câu hỏi. Mười câu trả lời không thể chấm được đã bị loại, còn lại 4,240 lượt thử được chấm điểm.
| Benchmark | Câu hỏi | Đúng | Độ chính xác | Lỗi |
|---|---|---|---|---|
| Lượt gọi công cụ BFCL | 500 × 3 | 1,292/1,500 | 86.13% | 0 |
| Hỏi đáp khó HLE | 250 × 10 | 375/2,490 | 15.06% | 7 |
| Lập luận tài liệu dài AA-LCR | 25 × 10 | 133/250 | 53.20% | 0 |
| Tổng · khoảng tin cậy 95% 40.08%–44.73% | 4,240 lượt được chấm điểm | 1,800/4,240 | 42.45% | 7 |
Lỗi dịch vụ — yêu cầu thất bại hoặc đầu ra bị cắt — vẫn nằm trong mẫu số và được tính là sai. Trong trường hợp này, có bảy đầu ra HLE chạm giới hạn max_tokens. BFCL được chấm tự động; HLE và AA-LCR do mô hình giám khảo chấm.
Mẫu số BFCL là tổng số lượt của ba lần chạy.
| Hạng mục BFCL | Đạt | Tỷ lệ đạt |
|---|---|---|
| simple_python — một hàm, gọi đúng với các đối số chính xác | 334/360 | 92.78% |
| multiple — chọn đúng hàm trong số nhiều hàm | 268/300 | 89.33% |
| parallel — gọi cùng một hàm nhiều lần song song | 271/300 | 90.33% |
| parallel_multiple — gọi nhiều hàm khác nhau song song | 207/240 | 86.25% |
| irrelevance — không có hàm nào phù hợp, không nên gọi hàm nào | 113/150 | 75.33% |
| ahm_multi_turn — chuỗi công cụ ba giai đoạn | 99/150 | 66.00% |
So sánh với bốn nhà cung cấp còn lại
Mỗi mức chênh lệch được tính theo điểm phần trăm so với mức cơ sở này; các thanh sai số thể hiện khoảng 95%. Nếu khoảng này cắt qua 0 thì không thể phân biệt rõ. Mô hình giám khảo thuộc cùng họ DeepSeek với mô hình đang kiểm thử và chưa được hiệu chỉnh, vì vậy việc chấm HLE và AA-LCR có thể dễ dãi.
F — hỗ trợ chức năng: 94.00
Các trường hợp chức năng kiểm tra hành vi giao thức, không đánh giá chất lượng câu trả lời. Sáu mươi trường hợp thuộc sáu nhóm được chạy trong mỗi một trong ba cửa sổ — tổng cộng 180 lượt kiểm tra — và được đánh giá theo định dạng quy định trong tài liệu của từng nhà cung cấp. Các lượt kiểm tra không áp dụng, không hợp lệ và không được quan sát sẽ không tính vào mẫu số. Kênh này đạt 137 trong số 147 lượt kiểm tra được tính điểm, đạt điểm có trọng số 94.00; điểm có trọng số không đơn giản là 137/147.
| Nhóm | Trọng số | Đạt | Bị loại | Điểm nhóm |
|---|---|---|---|---|
| Truyền phát và giao thức tin nhắn | 20% | 27/27 | 3 | 100.00 |
| Giao diện công cụ | 20% | 30/30 | — | 100.00 |
| Ràng buộc đầu ra và tham số | 20% | 30/30 | — | 100.00 |
| Ngữ cảnh và trạng thái | 15% | 14/15 | 15 | 93.33 |
| Lỗi và khôi phục | 15% | 24/30 | — | 80.00 |
| Giao thức tính phí và bộ nhớ đệm | 10% | 12/15 | 15 | 80.00 |
| Tổng · có trọng số | — | 137/147 | 33 | 94.00 |
Điểm có trọng số tuân theo trọng số của từng nhóm; không phải số lượt kiểm tra đạt chia cho 147.
| Trường hợp thất bại | Các cửa sổ thất bại | Lý do |
|---|---|---|
| Tin nhắn sai định dạng (Lỗi và khôi phục) | 3/3 | Trả về 400, nhưng phần thân phản hồi trống, không có mô tả lỗi có cấu trúc |
| stream_options sai định dạng (Lỗi và khôi phục) | 3/3 | Trả về 400, nhưng phần thân phản hồi trống, không có mô tả lỗi có cấu trúc |
| Tính phí token suy nghĩ (Giao thức tính phí và bộ nhớ đệm) | 3/3 | Không trả về số lượng token suy nghĩ |
| Cô lập yêu cầu (Ngữ cảnh và trạng thái) | 1/3 | Bước đầu tiên không trả lời chỉ bằng STORED như yêu cầu, nên không thể tiếp tục kiểm tra tính cô lập |
Các lượt kiểm tra bị loại không được tính là đạt hay trượt.
| Trạng thái | Trường hợp | Số lượng | Lý do |
|---|---|---|---|
| Không được quan sát | Chuỗi dừng truyền phát | 3 | Yêu cầu của bước này không được gửi sau bước trước đó nên không thể đánh giá |
| Không hợp lệ | Đầu vào dài 10k; nằm trong giới hạn ngữ cảnh; đầu vào dài 32k; đầu vào dài 100k; vượt quá ngữ cảnh; số lượng đầu vào gốc; định nghĩa công cụ được tính vào đầu vào; số lượng đầu vào nhất quán trước và sau bộ nhớ đệm; số lượng đầu vào nhất quán giữa chế độ truyền phát và không truyền phát | 27 | Mẫu đếm gốc được cố định ở phía kiểm thử không khớp với mức sử dụng mà kênh này báo cáo, nên các lượt kiểm tra phụ thuộc vào số lượng chính xác được tuyên bố không hợp lệ và loại khỏi mẫu số |
| Không áp dụng | cache_control tường minh | 3 | Được ghi nhận trước là không được giao diện này hỗ trợ |
27 lượt kiểm tra không hợp lệ là các trường hợp đầu vào dài, giới hạn ngữ cảnh, số lượng gốc và tính nhất quán của bộ nhớ đệm trong danh sách. Vì mẫu cố định không khớp với mức sử dụng mà kênh này báo cáo, mọi lượt kiểm tra phụ thuộc vào số lượng chính xác đều bị loại thay vì chấm điểm.
Hai trường hợp thất bại trên cả năm nhà cung cấp: messages sai định dạng và stream_options sai định dạng. Cả hai đều trả về 400 với phần thân phản hồi trống, nên máy khách không nhận được mô tả lỗi có cấu trúc. Mẫu chung này cho thấy nhiều khả năng vấn đề nằm ở lớp cổng AIHubMix và cần được điều tra riêng. Việc tính phí token suy nghĩ cũng thất bại trên cả năm nhà cung cấp, nhưng vì các lý do khác nhau: ByteDance và Fireworks vẫn báo cáo token suy nghĩ sau khi đã tắt chế độ suy nghĩ, trong khi ba nhà cung cấp còn lại không trả về số lượng token suy nghĩ.
So sánh với bốn nhà cung cấp còn lại
P — tốc độ phản hồi: 86.14
Mỗi yêu cầu mang theo khoảng 10,000 token đầu vào và yêu cầu khoảng 1,100 token đầu ra. Ba cửa sổ lần lượt gửi 30 yêu cầu với một yêu cầu đồng thời và 30 yêu cầu với 10 yêu cầu đồng thời, tổng cộng 180 yêu cầu.
| Chỉ số | Giá trị |
|---|---|
| TTFA token đầu tiên | Một yêu cầu đồng thời: trung vị 1.87 s (trung vị của yêu cầu hợp lệ 1.72 s). 10 yêu cầu đồng thời: trung vị 1.72 s |
| TPOT | Một yêu cầu đồng thời: 2.84 ms/token. 10 yêu cầu đồng thời: 2.67 ms/token |
| Thông lượng hợp lệ (goodput) | 10 yêu cầu đồng thời: 1,546.0 token/s |
| Yêu cầu hợp lệ | Một yêu cầu đồng thời 75/90 (cửa sổ 1: 15/30); 10 yêu cầu đồng thời 90/90. Không hợp lệ: 12 × 503 service_unavailable_error, 2 × hết thời hạn, 1 × hết thời gian chờ đọc |
| Điểm thành phần | TTFA 51.65, TPOT 100.00, thông lượng 100.00; TTFA và TPOT lấy mức thấp hơn trong hai bậc, với trọng số lần lượt 35% / 35% / 30%; điểm phản hồi 83.08 |
| Cấu thành P | Điểm phản hồi 83.08 với trọng số 80%, bộ nhớ đệm K 98.38 với trọng số 20%; P 86.14 |
Cả 15 yêu cầu không hợp lệ đều nằm trong cửa sổ đầu tiên với một yêu cầu đồng thời: 12 yêu cầu trả về 503, 2 yêu cầu hết thời hạn và 1 yêu cầu hết thời gian chờ đọc. Yêu cầu không hợp lệ được tính là vô hạn, nên trung vị được báo cáo là 1.87 s. Chỉ tính các yêu cầu hợp lệ thì trung vị là 1.72 s. Với 10 yêu cầu đồng thời, trung vị cũng là 1.72 s. TPOT là 2.84 ms/token khi có một yêu cầu đồng thời và 2.67 ms/token khi có 10 yêu cầu đồng thời.
So sánh với bốn nhà cung cấp còn lại
Năm nhà cung cấp dùng chung một Mac mini, mạng và tài khoản. Ba cửa sổ được lên lịch lần lượt theo từng nhà cung cấp, nên các khoảng thời gian thu thập dữ liệu không hoàn toàn trùng nhau; không nên diễn giải quá mức những chênh lệch nhỏ.
K — bộ nhớ đệm: 98.38
Mỗi nhóm gửi năm yêu cầu. Yêu cầu đầu tiên khởi tạo một tiền tố cố định 8k hoặc 32k. Các yêu cầu từ thứ hai đến thứ tư giữ nguyên tiền tố và chỉ thay đổi câu hỏi cuối, ở các mốc 5, 30 và 120 giây. Yêu cầu thứ năm dùng tiền tố mới làm đối chứng lạnh. Ba cửa sổ × hai độ dài tạo thành 30 yêu cầu. K được tính bằng cách lấy số token đọc từ bộ nhớ đệm trong các yêu cầu nóng chia cho số token có thể tái sử dụng, trong đó mỗi độ dài chiếm một nửa trọng số; K chiếm 20% của P. Tài liệu API của DeepSeek trình bày về bộ nhớ đệm ngữ cảnh.
| Tiền tố | Cửa sổ | Khởi tạo | +5 s | +30 s | +120 s | Đối chứng lạnh |
|---|---|---|---|---|---|---|
| 8k | Cửa sổ 1 | 0 | 7,808 | 7,808 | 7,808 | 0 |
| 8k | Cửa sổ 2 | 0 | 7,808 | 7,808 | 7,808 | 0 |
| 8k | Cửa sổ 3 | 0 | 7,808 | 7,808 | 7,808 | 0 |
| 32k | Cửa sổ 1 | 0 | 31,872 | 31,872 | 31,872 | 0 |
| 32k | Cửa sổ 2 | 0 | 31,872 | 31,872 | 31,872 | 0 |
| 32k | Cửa sổ 3 | 0 | 31,872 | 31,872 | 31,872 | 0 |
Trong số các yêu cầu nóng 8k, có 9/9 yêu cầu trúng bộ nhớ đệm và mỗi yêu cầu đọc 7,808 token: tổng cộng đọc 70,272 trên 72,261 token có thể tái sử dụng, đạt 97.25. Trong số các yêu cầu nóng 32k, có 9/9 yêu cầu trúng bộ nhớ đệm và mỗi yêu cầu đọc 31,872 token: tổng cộng 286,848 trên 288,270, đạt 99.51. Các yêu cầu đối chứng lạnh không đọc dữ liệu từ bộ nhớ đệm. K đạt 98.38 trên cả hai độ dài.
So sánh với bốn nhà cung cấp còn lại
R — độ ổn định dịch vụ: 100
300 yêu cầu bao gồm văn bản ngắn, đầu vào dài 10k, gọi công cụ và lịch sử nhiều lượt, được gửi với một yêu cầu đồng thời qua ba cửa sổ. Chỉ kiểm tra tính hợp lệ và đầy đủ ngay lần thử đầu tiên — không kiểm tra tính chính xác của câu trả lời — và không thử lại. Lỗi về chất lượng câu trả lời và tốc độ được tính trong Q và P, không tính lại trong R.
| Loại yêu cầu | Thành công ngay lần thử đầu tiên |
|---|---|
| Văn bản ngắn | 120/120 |
| Đầu vào dài 10k | 90/90 |
| Gọi công cụ | 60/60 |
| Lịch sử nhiều lượt | 30/30 |
| Tổng · khoảng tin cậy 95% 98.78%–100% | 300/300 |
Cả 300 yêu cầu đều trả về phản hồi hợp lệ, đầy đủ ngay ở lần thử đầu tiên. R 100 chỉ bao gồm 300 yêu cầu chuyên biệt này; điều đó không có nghĩa là toàn bộ tuyến không gặp lỗi. Với 300 lần thành công, cận dưới của khoảng tin cậy 95% là 98.78%, nên bằng chứng cho thấy tỷ lệ lỗi có khả năng dưới 1.22%.
So sánh với bốn nhà cung cấp còn lại
R chỉ bao gồm 300 yêu cầu chuyên biệt; lỗi về chất lượng câu trả lời và tốc độ được ghi nhận trong Q và P, không tính lại trong R.
| Nhà cung cấp | Tỷ lệ thành công ngay lần thử đầu tiên | Khoảng tin cậy 95% |
|---|---|---|
| ByteDance | 300/300 | 98.78%–100% |
| Baidu | 300/300 | 98.78%–100% |
| Alibaba Cloud | 300/300 | 98.78%–100% |
| DeepSeek chính thức | 300/300 | 98.78%–100% |
| Fireworks | 300/300 | 98.78%–100% |
Câu hỏi thường gặp
Đây có phải là kết nối trực tiếp đến API của DeepSeek không?
Không. Các yêu cầu đi qua tuyến nhà cung cấp DeepSeek chính thức của AIHubMix; chúng không được gửi trực tiếp đến API của DeepSeek.
Tại sao kênh DeepSeek chính thức được dùng làm mức cơ sở Q?
Đây là kênh chính thức của DeepSeek cho cùng một model, vì vậy kết quả về chất lượng câu trả lời của bốn nhà cung cấp còn lại được thể hiện dưới dạng chênh lệch so với kênh này. Vai trò làm mức cơ sở không hàm ý thứ hạng về chất lượng câu trả lời.
Điều gì đã xảy ra trong khoảng đo tốc độ đầu tiên với một yêu cầu chạy đồng thời?
15 trong số 30 yêu cầu không hợp lệ: 12 trả về 503, 2 chạm thời hạn và 1 gặp thời gian chờ đọc. Chúng được tính là vô hạn, nên trung vị là 1.87 s; chỉ tính các yêu cầu hợp lệ thì trung vị là 1.72 s.
27 lượt kiểm tra hàm không hợp lệ là gì?
Các lượt kiểm tra này phụ thuộc vào số lượng token chính xác: đầu vào dài, giới hạn ngữ cảnh, số lượng token đầu vào gốc và tính nhất quán của đầu vào bộ nhớ đệm. Mẫu số lượng token gốc được cố định ở phía kiểm thử không khớp với mức sử dụng mà kênh này báo cáo, nên các lượt kiểm tra bị loại khỏi mẫu số thay vì bị chấm là thất bại.
Tại sao R 100 không đảm bảo tuyến này không gặp lỗi?
R chỉ bao gồm 300 yêu cầu kiểm tra độ ổn định chuyên biệt. Lỗi trong các lượt chạy đánh giá chất lượng câu trả lời và tốc độ được ghi nhận trong Q và P. Với 300/300 lần thành công, cận dưới của khoảng tin cậy 95% là 98.78%, nên tỷ lệ lỗi có khả năng dưới 1.22%, chứ không thể khẳng định là bằng không.
Bài kiểm tra bộ nhớ đệm phân biệt các lần đọc nóng với lần đọc lạnh như thế nào?
Mỗi nhóm khởi tạo một tiền tố 8k hoặc 32k, lặp lại tiền tố sau 5, 30 và 120 giây với câu hỏi cuối mới, rồi gửi một tiền tố mới làm đối chứng lạnh. Cả hai độ dài đều trúng bộ nhớ đệm trong 9/9 yêu cầu nóng, còn mọi lượt đọc đối chứng lạnh đều có 0 token được lưu trong bộ nhớ đệm.
Đọc tiếp: loạt bài DeepSeek V4.1 Flash
- Q của ByteDance chỉ chênh 0.40 điểm so với mức cơ sở này, trong khi kết quả hỗ trợ hàm và bộ nhớ đệm khác biệt: DeepSeek V4.1 Flash trên ByteDance: gọi công cụ khớp, cách tính phí thì không.
- Baidu bị mất yêu cầu do
no_available_channel, ảnh hưởng đến cả Q lẫn P: DeepSeek V4.1 Flash trên Baidu: không có kênh khả dụng ảnh hưởng đến Q và P. - Alibaba Cloud chênh tổng thể 0.37 điểm và không thể phân biệt được: DeepSeek V4.1 Flash trên Alibaba Cloud: token đầu tiên 1.34s, bộ nhớ đệm 99.37.
- Fireworks trúng bộ nhớ đệm 3/9 yêu cầu nóng 8k, so với 9/9 ở đây: DeepSeek V4.1 Flash trên Fireworks: phản hồi stop trống, trúng bộ nhớ đệm 3/9.
