Trong hai ngày 2026-11-03/04, DeepSeek V4.1 Flash 1017 được thử nghiệm trên năm nhà cung cấp thông qua AIHubMix bằng bộ kiểm thử APB Full: mỗi lần đều dùng cùng câu hỏi, tham số và tập lệnh yêu cầu. Hồ sơ APB này chỉ bao gồm lượt chạy trên ByteDance, trình bày theo từng mục.
Các con số dưới đây là điểm số, không phải bảng xếp hạng hay khuyến nghị nhà cung cấp. Q, F, P, K và R được trình bày trước; điểm tổng thể là chỉ số tóm tắt, không phải chứng nhận và không có khoảng tin cậy. Quy tắc tính điểm được xác định trong AIHubMix Provider Benchmark Standard v2.0.
Điểm số trên năm nhà cung cấp
Chữ đậm đánh dấu nhà cung cấp của 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 thành phần của P và chiếm 20% điểm này. Điểm tổng thể là chỉ số tóm tắt, không có khoảng tin cậy. Kênh chính thức của DeepSeek và Alibaba Cloud chênh nhau 0.37 điểm và không thể phân biệt được.
Tổng quan nhanh
- Q 42.05. BFCL 85.20%, HLE 15.34%, AA-LCR 49.20%. Chênh lệch so với kênh chính thức là −0.40 điểm phần trăm, với khoảng 95% từ −1.46 đến +0.66: không thể phân biệt được. AA-LCR có 28 yêu cầu thất bại, tất cả đều ở cửa sổ 1 và được tính là sai.
- F 74.98. Có 124/174 lượt kiểm tra được tính điểm đạt yêu cầu.
reasoning_effort=nonekhông tắt chế độ suy luận. Đầu vào 10k token được báo cáo là 10,026 token (số lượng gốc là 10,000); đầu vào 8 token được báo cáo là 34. - P 84.37. Token đầu tiên của nội dung phản hồi: trung vị 2.12 s ở mức đồng thời đơn và 2.10 s ở mức đồng thời 10 luồng; TPOT 3.43 ms/token; cả 180 yêu cầu đo tốc độ đều hợp lệ.
- K 93.83. Các yêu cầu nóng 8k đạt 9/9; mức 32k trúng bộ nhớ đệm 8 lần, còn một yêu cầu không hoàn tất trước thời hạn 300 s.
- R 100. Cả 300 yêu cầu chuyên biệt đều thành công ngay lần thử đầu tiên.
Thiết lập kiểm thử
| Hạng mục | Chi tiết |
|---|---|
| Model | DeepSeek V4.1 Flash 1017 |
| ID model được yêu cầu | doubao-deepseek-v4.1-flash-1017 |
| Tên model được trả về | deepseek-v4-1-flash-261017 |
| Tuyến truy cập | Thông qua AIHubMix bằng ID model riêng của nhà cung cấp, không kết nối trực tiếp với tài khoản của nhà cung cấp |
| Tham số | Chế độ không suy luận, temperature 1.0, max_tokens 16,384, timeout 300 s, không tự động thử lại |
| Tắt suy luận | Các yêu cầu về chất lượng câu trả lời, tốc độ, bộ nhớ đệm và độ ổn định dùng thinking.type=disabled nguyên bản (với nhà cung cấp này, reasoning_effort=none không tắt suy luận); các trường hợp gọi hàm vẫn giữ reasoning_effort=none để kiểm tra tham số có hiệu lực hay không |
| 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 máy Mac mini, một mạng và một tài khoản |
| Mẫu | Chất lượng câu trả lời: 4,250 lượt câu hỏi (BFCL 500 × 3, HLE 250 × 10, AA-LCR 25 × 10); chức năng: 60 trường hợp × 3 cửa sổ; tốc độ: 90 yêu cầu đồng thời đơn và 90 yêu cầu đồng thời 10 luồng; độ ổn định: 300; bộ nhớ đệm: 30 (mỗi độ dài tiền tố 8k và 32k có ba nhóm) |
Các yêu cầu sử dụng tuyến bắt đầu nhanh của AIHubMix cùng ID riêng của nhà cung cấp; tham số tuân theo tài liệu API của DeepSeek. ID của các nhà cung cấp khác được liệt kê trên trang model.
Q — chất lượng câu trả lời: 42.05
Chất lượng câu trả lời dựa trên ba bộ kiểm thử: 500 câu hỏi BFCL với 3 lượt mỗi câu, 250 câu hỏi HLE với 10 lượt mỗi câu và 25 câu hỏi AA-LCR với 10 lượt mỗi câu. BFCL được chấm bằng quy tắc tự động; HLE và AA-LCR do model deepseek-flash đánh giá. Cả năm nhà cung cấp đều nhận cùng câu hỏi, và kết quả của ba bộ được gộp thành một độ chính xác. Mười câu trả lời bị loại vì không thể chấm câu hỏi tương ứng, còn lại 4,240 lượt câu hỏi được chấm.
| Bộ kiểm thử | Câu hỏi | Đúng | Độ chính xác | Thất bại |
|---|---|---|---|---|
| Gọi công cụ BFCL | 500 × 3 | 1,278/1,500 | 85.20% | 0 |
| Hỏi đáp khó HLE | 250 × 10 | 382/2,490 | 15.34% | 7 |
| Suy luận tài liệu dài AA-LCR | 25 × 10 | 123/250 | 49.20% | 28 |
| Gộp chung · khoảng 95% 39.70%–44.33% | — | 1,783/4,240 | 42.05% | 35 |
Lỗi dịch vụ — yêu cầu thất bại hoặc đầu ra bị cắt cụt — vẫn nằm trong mẫu số và được tính là sai. Đầu ra HLE chạm giới hạn max_tokens 7 lần; AA-LCR có 28 yêu cầu thất bại, tất cả đều ở cửa sổ 1. BFCL được chấm tự động; HLE và AA-LCR được chấm bởi giám khảo.
Mỗi câu hỏi BFCL được trả lời 3 lần; bảng cộng gộp cả 3 lượt.
| Nhóm BFCL | Đạt | Tỷ lệ đạt |
|---|---|---|
| simple_python — một hàm, lời gọi và đối số chính xác | 329/360 | 91.39% |
| multiple — chọn một trong nhiều hàm | 268/300 | 89.33% |
| parallel — gọi cùng một hàm nhiều lần | 271/300 | 90.33% |
| parallel_multiple — gọi nhiều hàm khác nhau | 207/240 | 86.25% |
| irrelevance — không có hàm nào phù hợp, không nên gọi hàm | 102/150 | 68.00% |
| ahm_multi_turn — chuỗi công cụ gồm ba giai đoạn | 101/150 | 67.33% |
So sánh với bốn nhà cung cấp còn lại
Chênh lệch so với kênh chính thức tính theo điểm phần trăm, với khoảng 95% được thể hiện bằng các thanh sai số. Khoảng cắt qua 0 được ghi nhận là không thể phân biệt. Giám khảo cho HLE và AA-LCR là deepseek-flash, thuộc cùng họ DeepSeek với model được kiểm thử và chưa được hiệu chỉnh, vì vậy đánh giá có thể dễ dãi.
F — hỗ trợ chức năng: 74.98
Bộ kiểm thử chức năng chỉ xem xét hành vi giao diện có khớp với giao thức hay không, không đánh giá chất lượng câu trả lời của model. Sáu mươi trường hợp thuộc sáu nhóm được chạy ba lần, mỗi lần một cửa sổ: tổng cộng 180 lượt kiểm tra, đối chiếu với định dạng được từng nhà cung cấp tài liệu hóa. Các lượt kiểm tra không áp dụng, không hợp lệ hoặc không quan sát được sẽ bị loại khỏi mẫu số. ByteDance đạt 124 trong 174 lượt kiểm tra được tính và đạt 74.98 theo trọng số nhóm.
Điểm có trọng số áp dụng trọng số của từng nhóm; đây không phải số lượt kiểm tra đạt chia cho 174.
| Nhóm | Trọng số | Đạt | Loại trừ | Điểm nhóm |
|---|---|---|---|---|
| Truyền phát và giao thức thông điệp | 20% | 23/27 | 3 | 85.19 |
| Giao diện công cụ | 20% | 30/30 | — | 100.00 |
| Ràng buộc đầu ra và tham số | 20% | 24/30 | — | 80.00 |
| Ngữ cảnh và trạng thái | 15% | 14/30 | — | 46.67 |
| Lỗi và khôi phục | 15% | 21/30 | — | 70.00 |
| Giao thức tính token và bộ nhớ đệm | 10% | 12/27 | 3 | 44.44 |
| Tổng · điểm có trọng số | — | 124/174 | 6 | 74.98 |
“Số cửa sổ thất bại” là số cửa sổ trong 3 cửa sổ không vượt qua lượt kiểm tra.
| Trường hợp thất bại | Số cửa sổ thất bại | Lý do |
|---|---|---|
| Không để lộ nội dung suy luận — truyền phát và giao thức thông điệp | 3/3 | Với reasoning_effort=none, nội dung suy luận vẫn được trả về |
| Cấu hình suy luận có hiệu lực — ràng buộc đầu ra và tham số | 3/3 | Với reasoning_effort=none, nội dung suy luận vẫn được trả về |
| Đa dạng lấy mẫu — ràng buộc đầu ra và tham số | 3/3 | Đầu ra ở temperature 0 và 1 không khác nhau đủ nhiều; thấp hơn ngưỡng đăng ký trước |
| Đầu vào dài 10k — ngữ cảnh và trạng thái | 3/3 | Đầu vào được báo cáo là 10,026 token; số lượng gốc phải là 10,000 |
| Nằm trong giới hạn ngữ cảnh — ngữ cảnh và trạng thái | 3/3 | Đầu vào được báo cáo là 10,026 token; số lượng gốc phải là 10,000 |
| Đầu vào dài 32k — ngữ cảnh và trạng thái | 3/3 | Đầu vào được báo cáo là 10,026 token; số lượng gốc phải là 10,000 |
| Đầu vào dài 100k — ngữ cảnh và trạng thái | 3/3 | Đầu vào được báo cáo là 10,026 token; số lượng gốc phải là 10,000 |
| Vượt giới hạn ngữ cảnh — ngữ cảnh và trạng thái | 3/3 | Lỗi kết nối đến hệ thống thượng nguồn hoặc hết thời gian chờ (1); lẽ ra phải trả về lỗi tham số nhưng lại trả về 200 (2) |
| Lịch sử 12 lượt — ngữ cảnh và trạng thái | 1/3 | Lỗi kết nối đến hệ thống thượng nguồn hoặc hết thời gian chờ |
| Lỗi định dạng messages — lỗi và khôi phục | 3/3 | Trả về 400 với nội dung trống; không có giải thích lỗi có cấu trúc |
| Kết quả công cụ không có lời gọi tương ứng — lỗi và khôi phục | 3/3 | Lẽ ra phải trả về lỗi tham số nhưng lại trả về 200 |
| Lỗi định dạng stream_options — lỗi và khôi phục | 3/3 | Trả về 400 với nội dung trống; không có giải thích lỗi có cấu trúc |
| Tính token suy luận — giao thức tính token và bộ nhớ đệm | 3/3 | Báo cáo token suy luận sau khi đã tắt suy luận |
| Số lượng đầu vào gốc — giao thức tính token và bộ nhớ đệm | 3/3 | Báo cáo 34 token; số lượng gốc phải là 8 |
| Tính định nghĩa công cụ vào đầu vào — giao thức tính token và bộ nhớ đệm | 3/3 | Yêu cầu đối chứng không có công cụ đã không khớp với số lượng đầu vào gốc |
| Số lượng đầu vào nhất quán trước và sau khi dùng bộ nhớ đệm — giao thức tính token và bộ nhớ đệm | 3/3 | Khi lặp lại cùng một tiền tố, số token đầu vào được báo cáo không khớp với số lượng gốc |
| Số lượng đầu vào nhất quán giữa chế độ truyền phát và không truyền phát — giao thức tính token và bộ nhớ đệm | 3/3 | Cả hai đều báo cáo 34 token; số lượng gốc phải là 8 |
| Đầu ra văn bản chính xác — truyền phát và giao thức thông điệp | 1/3 | Có thêm một dấu chấm ở cuối nội dung; không đúng chính xác văn bản được yêu cầu |
Các lượt kiểm tra này bị loại khỏi mẫu số; không được tính là đạt cũng không tính là thất bại.
| Trạng thái | Trường hợp | Số lượng | Lý do |
|---|---|---|---|
| Không quan sát được | Chuỗi dừng khi truyền phát | 3 | Không gửi yêu cầu này sau bước trước đó; không thể đánh giá |
| Không áp dụng | cache_control tường minh | 3 | Được đăng ký trước là không được giao diện này hỗ trợ |
Các trường hợp lỗi định dạng messages và stream_options đều thất bại trên cả năm nhà cung cấp: cả hai đều trả về 400 với nội dung trống, khiến máy khách không nhận được giải thích lỗi có cấu trúc. Lỗi xuất hiện trên cả năm có khả năng nằm ở lớp cổng AIHubMix hơn và cần được điều tra riêng. Lượt kiểm tra tính token suy luận cũng thất bại trên cả năm, nhưng vì các lý do khác nhau: ByteDance và Fireworks báo cáo token suy luận sau khi đã tắt suy luận; ba nhà cung cấp còn lại không trả về số lượng token suy luận.
So sánh với bốn nhà cung cấp còn lại
P — tốc độ phản hồi: 84.37
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 văn bản trong phần nội dung đầu ra. Trong mỗi cửa sổ trong ba cửa sổ, 30 yêu cầu chạy ở mức đồng thời đơn và 30 yêu cầu ở mức đồng thời 10 luồng: tổng cộng 180 yêu cầu.
| Chỉ số | Kết quả |
|---|---|
| Thời gian chờ token đầu tiên của nội dung (TTFA) | Trung vị 2.12 s ở mức đồng thời đơn; trung vị 2.10 s ở mức đồng thời 10 luồng |
| Tốc độ tạo sinh (TPOT) | 3.43 ms/token ở mức đồng thời đơn; 3.41 ms/token ở mức đồng thời 10 luồng |
| Thông lượng thực tế | 1,250.0 token/s ở mức đồng thời 10 luồng |
| Yêu cầu hợp lệ | 90/90 ở mức đồng thời đơn; 90/90 ở mức đồng thời 10 luồng |
| Điểm thành phần | TTFA 48.59, TPOT 100.00, thông lượng 100.00; TTFA và TPOT lấy mức thấp hơn trong hai cấp; trọng số 35% / 35% / 30%; điểm phản hồi 82.00 |
| Điểm P | Điểm phản hồi 82.00 với trọng số 80%, bộ nhớ đệm K 93.83 với trọng số 20%; tổng cộng 84.37 |
TPOT được ước tính từ các khối truyền phát, không được đo trên từng token bằng phần cứng. Thông lượng là số token đầu ra hợp lệ ở mức đồng thời 10 luồng chia cho thời gian thực hiện toàn bộ lô.
So sánh với bốn nhà cung cấp còn lại
Cả năm dùng chung một máy, 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 giai đoạn 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: 93.83
Mỗi nhóm gửi năm yêu cầu. Yêu cầu đầu tiên mang theo tiền tố cố định khoảng 8k hoặc 32k token để khởi tạo bộ nhớ đệm. Các yêu cầu 2–4 giữ nguyên tiền tố và chỉ thay đổi câu hỏi cuối, tại các mốc 5 s, 30 s và 120 s. 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 và năm yêu cầu mỗi nhóm tạo thành 30 yêu cầu. K là số token đọc từ bộ nhớ đệm trong các yêu cầu nóng chia cho số token lẽ ra có thể tái sử dụng theo quy tắc, với hai độ dài có trọng số bằng nhau; K chiếm 20% P.
| 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,936 | 7,936 | 7,936 | 0 |
| 8k | Cửa sổ 2 | 0 | 7,936 | 7,936 | 7,936 | 0 |
| 8k | Cửa sổ 3 | 0 | 7,936 | 7,936 | 7,936 | 0 |
| 32k | Cửa sổ 1 | 0 | 32,000 | 32,000 | 32,000 | 0 |
| 32k | Cửa sổ 2 | 0 | 32,000 | 32,000 | thất bại | 0 |
| 32k | Cửa sổ 3 | 0 | 32,000 | 32,000 | 32,000 | 0 |
Giá trị là số token đọc từ bộ nhớ đệm do máy chủ báo cáo.
Cả chín yêu cầu nóng 8k đều trúng bộ nhớ đệm, mỗi yêu cầu đọc 7,936 token. Tám trong số chín yêu cầu nóng 32k trúng bộ nhớ đệm, mỗi yêu cầu đọc 32,000 token; một yêu cầu thất bại. K là 93.83 khi tính trọng số ngang nhau cho hai độ dài. Yêu cầu lạnh không đọc dữ liệu từ bộ nhớ đệm, nên nhóm nóng và lạnh được tách biệt rõ ràng. Yêu cầu thất bại là yêu cầu thứ tư trong nhóm 32k ở cửa sổ 2, đã chạm thời hạn 300 s mà chưa hoàn tất.
So với bốn nhà cung cấp còn lại
R — độ ổn định dịch vụ: 100
300 yêu cầu thuộc bốn loại — văn bản ngắn, đầu vào dài, gọi công cụ và lịch sử nhiều lượt — và được chạy ở mức đồng thời đơn trong ba cửa sổ. Một yêu cầu chỉ được tính là thành công nếu lần thử đầu tiên trả về phản hồi hợp lệ, hoàn chỉnh; không kiểm tra độ chính xác của câu trả lời và không thử lại. Các lỗi trong phần chất lượng câu trả lời và tốc độ được tính vào Q và P, không tính lại vào R.
| Loại yêu cầu | Thành công ở 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ệ, hoàn chỉnh ngay ở lần thử đầu tiên. R = 100 chỉ mô tả 300 yêu cầu được thực hiện riêng này; điều đó không có nghĩa toàn bộ chuỗi không có lỗi. Cận dưới của khoảng tin cậy 95% là 98.78%: với 300 lần thành công, ta chỉ có thể kết luận rằng tỷ lệ lỗi có khả năng thấp hơn 1.22%.
So với bốn nhà cung cấp còn lại
R chỉ bao gồm 300 yêu cầu được thực hiện riêng này; các lỗi trong phần chất lượng câu trả lời và tốc độ được ghi nhận vào Q và P, không tính lại vào R.
| Nhà cung cấp | Thành công ở 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 official | 300/300 | 98.78%–100% |
| Fireworks | 300/300 | 98.78%–100% |
Câu hỏi thường gặp
reasoning_effort=none có thực sự không tắt được chế độ suy luận không?
Đúng vậy. Trong cả ba cửa sổ, các yêu cầu có reasoning_effort=none vẫn trả về nội dung suy luận, nên cả 3/3 lượt kiểm tra đều thất bại. Các yêu cầu về chất lượng câu trả lời, tốc độ, bộ nhớ đệm và độ ổn định thay vào đó sử dụng công tắc thinking.type=disabled gốc. Bộ kiểm thử hàm cố ý giữ reasoning_effort=none để kiểm tra xem tham số này có hiệu lực hay không.
Độ chính xác BFCL là 85.20%. Tại sao Q lại là 42.05?
Q gộp ba bộ kiểm thử có độ khó rất khác nhau. BFCL có 1,278 câu đúng trên 1,500 câu, HLE có 382 trên 2,490, còn AA-LCR có 123 trên 250. Tổng cộng, 1,783 trong số 4,240 lượt câu hỏi được chấm có đáp án đúng: 42.05%. Mức 15.34% của HLE kéo con số tổng hợp xuống.
35 lỗi dịch vụ trong Q có được tính vào điểm số không?
Có. Các yêu cầu lỗi và đầu ra bị cắt cụt vẫn nằm trong mẫu số và được tính là sai. Bảy câu trả lời HLE bị cắt ở max_tokens; 28 yêu cầu AA-LCR thất bại, tất cả đều ở cửa sổ 1.
Tại sao việc tính toán token đầu vào lại quan trọng?
Vì cách tính phí phải khớp với số lượng gốc của mô hình. Đầu vào 10k token được báo cáo là 10,026 token (số lượng gốc là 10,000), còn đầu vào 8 token được báo cáo là 34. Yêu cầu đối chứng không dùng công cụ vốn đã cho kết quả không khớp, và cả truyền phát lẫn không truyền phát đều báo cáo 34. Cả 3/3 lượt kiểm tra tính phí token đều thất bại.
Kết quả bộ nhớ đệm 32k là lượt không trúng hay là lỗi?
Là lỗi. Tám trong số chín yêu cầu nóng 32k trúng bộ nhớ đệm và đọc 32,000 token. Lượt không trúng là yêu cầu thứ tư trong cửa sổ 2, đã chạm thời hạn 300 s mà chưa hoàn tất. Nhóm 8k trúng bộ nhớ đệm cả 9/9 lượt, với 7,936 token.
Chất lượng câu trả lời của ByteDance có khác biệt rõ rệt so với kênh chính thức không?
Không. Độ chính xác tổng hợp thấp hơn kênh chính thức 0.40 điểm, với khoảng tin cậy 95% từ −1.46 đến +0.66. Khoảng này bao gồm 0, nên không thể phân biệt hai bên. Kết quả này chỉ mô tả lô dữ liệu này, không phải là xếp hạng.
Đọc tiếp: loạt bài DeepSeek V4.1 Flash
- Mốc Q trong bài viết này là kênh chính thức; đợt chạy riêng của kênh này, bao gồm 15 phép thử đồng thời đơn không hợp lệ, được trình bày trong DeepSeek V4.1 Flash trên kênh chính thức: F 94.00, 15 phép thử không hợp lệ.
- Baidu là nhà cung cấp duy nhất có khoảng Q nằm dưới kênh chính thức; các lỗi kênh đứng sau kết quả đó được trình bày trong DeepSeek V4.1 Flash trên Baidu: không có kênh khả dụng nào đạt Q và P.
- Các số liệu bộ nhớ đệm của Alibaba Cloud được đặt cạnh mức 93.83 được báo cáo ở đây: DeepSeek V4.1 Flash trên Alibaba Cloud: token đầu tiên trong 1.34s, bộ nhớ đệm đạt 99.37.
- Fireworks cũng gặp các lỗi về suy luận và tính toán token như trong bài này, đồng thời có thêm phản hồi dừng trống: DeepSeek V4.1 Flash trên Fireworks: phản hồi dừng trống, 3/9 lượt trúng bộ nhớ đệm.
