2026-11-03/04，APB Full 套件通过 AIHubMix，在五家供应商上测试了 DeepSeek V4.1 Flash 1017。所有供应商使用相同的问题、参数和请求脚本；五家供应商的条目见模型页面。此 APB Profile 仅涵盖 DeepSeek 官方渠道。该渠道通过 AIHubMix 的 DeepSeek 官方供应商路由接入，并非直接连接 DeepSeek API。
本文仅报告分数，不对供应商排名或作出推荐：Q 42.45、F 94.00、P 86.14、K 98.38、R 100。Q、F、P 和 R 是四个部分的分数；K 是 P 的子分数。总分 73.76 是汇总指数，不是认证结果，也没有置信区间。评分标准为 AIHubMix Provider Benchmark Standard v2.0。
五家供应商的分数
粗体标出本文测试的供应商。供应商顺序固定，并非排名。K 是 P 的子分数，占 20%，单独列出以供参考。总分是没有置信区间的汇总指数。DeepSeek 官方渠道与 Alibaba Cloud 的总分相差 0.37，无法区分。
一览
- 回答质量：Q 42.45。 BFCL 86.13%、HLE 15.06%、AA-LCR 53.20%。有 7 个 HLE 输出触及 max_tokens 上限而被截断，并计为错误。该渠道是其他四家供应商的 Q 基线。
- 函数支持：F 94.00。计入评分的 147 项检查中，137 项通过。另有 27 项依赖精确 token 数量的检查被判定为无效，并从分母中排除。
- 响应速度：P 86.14。首次单并发窗口的 30 个请求中有 15 个无效（12 × 503、2 × deadline、1 × read timeout），按无穷大计；首 token 中位数为 1.87 s（仅有效请求为 1.72 s）；10 并发为 1.72 s；TPOT 为 2.84 ms。
- 缓存：K 98.38。8k 和 32k 下的全部 18 个热请求均命中；冷请求对照组未读取缓存。
- 服务稳定性：R 100。专门用于稳定性测试的 300 个请求均在首次尝试时成功。
测试设置
请求通过 AIHubMix 发出，并选择 DeepSeek 官方供应商路由；快速入门介绍了接入配置。
| 项目 | 详情 |
|---|---|
| 模型 | DeepSeek V4.1 Flash 1017 |
| 请求的模型 ID | deepseek-flash |
| 返回的模型名称 | deepseek-flash |
| 接入路由 | AIHubMix DeepSeek 官方供应商路由；并非直接连接 DeepSeek API |
| 参数 | 非思考模式，temperature 1.0，max_tokens 16,384，超时 300 s，不自动重试 |
| 关闭思考模式 | 所有请求均使用 reasoning_effort=none |
| 时间 | 2026-11-03 18:07 – 11-04 16:33 UTC+8；五家供应商共用一台 Mac mini、同一网络和同一账户 |
| 样本 | 回答质量 4,250 次尝试（BFCL 500 × 3、HLE 250 × 10、AA-LCR 25 × 10）；函数用例 60 × 3 个窗口；速度测试 90 个单并发请求和 90 个 10 并发请求；稳定性测试 300 个请求；缓存测试 30 个请求（8k 和 32k 前缀各三组） |
Q — 回答质量：42.45
该套件汇总了 BFCL 500 个问题 × 3 次运行、HLE 250 × 10 和 AA-LCR 25 × 10。BFCL 使用自动规则评分；HLE 和 AA-LCR 由评判模型 deepseek-flash评分。五家供应商回答了相同的问题。有 10 个答案无法评分，因此被剔除，最终留下 4,240 次计分尝试。
| 基准测试 | 问题数 | 正确数 | 准确率 | 失败数 |
|---|---|---|---|---|
| BFCL 工具调用 | 500 × 3 | 1,292/1,500 | 86.13% | 0 |
| HLE 高难度问答 | 250 × 10 | 375/2,490 | 15.06% | 7 |
| AA-LCR 长文档推理 | 25 × 10 | 133/250 | 53.20% | 0 |
| 总计 · 95% 置信区间 40.08%–44.73% | 4,240 次计分 | 1,800/4,240 | 42.45% | 7 |
服务失败——请求失败或输出被截断——仍计入分母，并算作错误。这里包括 7 个触及 max_tokens 上限的 HLE 输出。BFCL 使用自动评分；HLE 和 AA-LCR 使用评判模型评分。
BFCL 的分母为三次运行的总数。
| BFCL 类别 | 通过数 | 通过率 |
|---|---|---|
| simple_python — 调用一个函数，函数和参数均正确 | 334/360 | 92.78% |
| multiple — 从多个函数中选出正确的函数 | 268/300 | 89.33% |
| parallel — 并行多次调用同一个函数 | 271/300 | 90.33% |
| parallel_multiple — 并行调用多个不同的函数 | 207/240 | 86.25% |
| irrelevance — 没有相关函数，不应调用任何函数 | 113/150 | 75.33% |
| ahm_multi_turn — 三阶段工具调用链 | 99/150 | 66.00% |
与其他四家相比
每项差值均以此基线为参照，以百分点表示；误差线显示 95% 区间。区间跨过 0 表示无法区分。评判模型与被测模型属于同一 DeepSeek 系列，且未经校准，因此 HLE 和 AA-LCR 的评分可能偏宽松。
F — 函数支持：94.00
函数用例测试的是协议行为，而非回答质量。六组共 60 个用例，在三个窗口中各运行一次，总计 180 项检查；评分依据是各供应商文档所规定的格式。不适用、无效和未观测到的检查不计入分母。该渠道在计分的 147 项检查中通过 137 项，加权得分为 94.00；加权得分并非简单的 137/147。
| 组别 | 权重 | 通过数 | 排除数 | 组得分 |
|---|---|---|---|---|
| 流式输出和消息协议 | 20% | 27/27 | 3 | 100.00 |
| 工具接口 | 20% | 30/30 | — | 100.00 |
| 输出约束和参数 | 20% | 30/30 | — | 100.00 |
| 上下文和状态 | 15% | 14/15 | 15 | 93.33 |
| 错误和恢复 | 15% | 24/30 | — | 80.00 |
| 计量和缓存协议 | 10% | 12/15 | 15 | 80.00 |
| 总计 · 加权 | — | 137/147 | 33 | 94.00 |
加权得分按各组权重计算，并非通过数除以 147。
| 失败用例 | 失败窗口数 | 原因 |
|---|---|---|
| 格式错误的消息（错误和恢复） | 3/3 | 返回 400，但响应正文为空，没有结构化错误说明 |
| 格式错误的 stream_options（错误和恢复） | 3/3 | 返回 400，但响应正文为空，没有结构化错误说明 |
| 思考 token 计量（计量和缓存协议） | 3/3 | 未返回思考 token 数量 |
| 请求隔离（上下文和状态） | 1/3 | 第一步未按要求仅回复 STORED，因此无法继续进行隔离检查 |
排除的检查既不计为通过，也不计为失败。
| 状态 | 用例 | 数量 | 原因 |
|---|---|---|---|
| 未观测到 | 流式输出停止序列 | 3 | 由于上一步之后未发送此步骤的请求，因此无法进行判断 |
| 无效 | 10k 长输入；上下文限制内；32k 长输入；100k 长输入；超出上下文限制；原生输入计数；工具定义计入输入；缓存前后输入计数一致；流式输出和非流式输出的输入计数一致 | 27 | 测试端固定的原生计数模板与此渠道报告的用量不匹配，因此依赖精确计数的检查被判定为无效，并从分母中排除 |
| 不适用 | 显式 cache_control | 3 | 已预先登记为此接口不支持 |
27 项无效检查包括列表中的长输入、上下文限制、原生计数和缓存一致性用例。由于固定模板与此渠道报告的用量不匹配，所有依赖精确计数的检查均被排除，而未计分。
有两个用例在五家供应商上均失败：格式错误的 messages 和格式错误的 stream_options。两者都返回 400，且响应正文为空，因此客户端没有收到结构化错误说明。共同的失败模式更可能指向 AIHubMix 网关层，需要单独调查。五家供应商的思考 token 计量也都失败，但原因不同：ByteDance 和 Fireworks 在关闭思考模式后仍报告思考 token，而另外三家则没有返回思考 token 数量。
与其他四家相比
P — 响应速度：86.14
每个请求携带约 10,000 个输入 token，并要求生成约 1,100 个输出 token。三个窗口分别发送 30 个单并发请求和 30 个 10 并发请求，总计 180 个。
| 指标 | 数值 |
|---|---|
| 首 token TTFA | 单并发：中位数 1.87 s（有效请求中位数 1.72 s）。10 并发：中位数 1.72 s |
| TPOT | 单并发：2.84 ms/token。10 并发：2.67 ms/token |
| 有效吞吐量（goodput） | 10 并发：1,546.0 token/s |
| 有效请求 | 单并发 75/90（窗口 1：15/30）；10 并发 90/90。无效请求：12 × 503 service_unavailable_error、2 × deadline reached、1 × read timeout |
| 分项得分 | TTFA 51.65、TPOT 100.00、吞吐量 100.00；TTFA 和 TPOT 取两个档位中的较低值，权重分别为 35% / 35% / 30%；响应得分 83.08 |
| P 的构成 | 响应得分 83.08，占 80%；缓存 K 98.38，占 20%；P 86.14 |
15 个无效请求全部出现在第一个单并发窗口：12 个返回 503，2 个超时，1 个发生读取超时。无效请求按无穷大计，因此报告的中位数为 1.87 s。仅计算有效请求时，中位数为 1.72 s。10 并发时，中位数同样为 1.72 s。单并发下 TPOT 为 2.84 ms/token，10 并发下为 2.67 ms/token。
与其他四家相比
五家供应商共用一台 Mac mini、同一网络和同一账户。三个窗口按供应商依次安排，因此各数据采集时段并未完全重叠；不应过度解读细微差距。
K — 缓存：98.38
每组发送五个请求。第一个请求写入固定的 8k 或 32k 前缀。第二到第四个请求保留此前缀，仅更改最后的问题，间隔分别为 5、30 和 120 秒。第五个请求使用新前缀作为冷请求对照。三个窗口 × 两种长度，共 30 个请求。K 的计算方式是热请求读取的缓存 token 数除以预期可复用的 token 数，两种长度各占一半；K 占 P 的 20%。DeepSeek 的API 文档介绍了上下文缓存。
| 前缀 | 窗口 | 写入请求 | +5 s | +30 s | +120 s | 冷请求对照 |
|---|---|---|---|---|---|---|
| 8k | 窗口 1 | 0 | 7,808 | 7,808 | 7,808 | 0 |
| 8k | 窗口 2 | 0 | 7,808 | 7,808 | 7,808 | 0 |
| 8k | 窗口 3 | 0 | 7,808 | 7,808 | 7,808 | 0 |
| 32k | 窗口 1 | 0 | 31,872 | 31,872 | 31,872 | 0 |
| 32k | 窗口 2 | 0 | 31,872 | 31,872 | 31,872 | 0 |
| 32k | 窗口 3 | 0 | 31,872 | 31,872 | 31,872 | 0 |
8k 热请求 9/9 命中，每个请求读取 7,808 个 token：读取总数为 70,272，预期可复用数为 72,261，得分 97.25。32k 热请求 9/9 命中，每个请求读取 31,872 个 token：读取总数为 286,848，预期可复用数为 288,270，得分 99.51。冷请求对照组未读取缓存。两种长度的 K 综合得分为 98.38。
与其他四家相比
R — 服务稳定性：100
300 个请求覆盖短文本、10k 长输入、工具调用和多轮历史记录，在三个窗口中以单并发发送。只检查首次尝试的有效性和完整性，不检查回答正确性，也不重试。回答质量和速度测试中的失败计入 Q 和 P，不会在 R 中重复计入。
| 请求类型 | 首次尝试成功率 |
|---|---|
| 短文本 | 120/120 |
| 10k 长输入 | 90/90 |
| 工具调用 | 60/60 |
| 多轮历史记录 | 30/30 |
| 总计 · 95% 置信区间 98.78%–100% | 300/300 |
全部 300 个请求均在首次尝试时返回了有效且完整的响应。R 100 仅涵盖这 300 个专门测试的请求；这并不意味着整个链路没有失败。300 次全部成功时，95% 置信区间的下界为 98.78%，因此证据表明失败率很可能低于 1.22%。
与其他四家相比
R 仅涵盖这 300 个专门测试的请求；答案质量和速度方面的失败记录在 Q 和 P 中，不会在 R 中重复计算。
| 供应商 | 首次尝试成功率 | 95% 置信区间 |
|---|---|---|
| ByteDance | 300/300 | 98.78%–100% |
| Baidu | 300/300 | 98.78%–100% |
| Alibaba Cloud | 300/300 | 98.78%–100% |
| DeepSeek 官方 | 300/300 | 98.78%–100% |
| Fireworks | 300/300 | 98.78%–100% |
常见问题
这是直接连接 DeepSeek 的 API 吗？
不是。请求经由 AIHubMix 的 DeepSeek 官方供应商路由发送，并非直接发送到 DeepSeek 的 API。
为什么将 DeepSeek 官方渠道作为 Q 基线？
这是同一模型的 DeepSeek 官方渠道，因此其他四家供应商的答案质量结果均以它为基准，表示为与其的差异。作为基线并不代表答案质量排名。
首次单并发速度测试窗口发生了什么？
30 个请求中有 15 个无效：12 个返回 503，2 个超出截止时间，1 个发生读取超时。它们按无穷大计，因此中位数为 1.87 s；仅计算有效请求时，中位数为 1.72 s。
27 项无效的函数检查是什么？
这些检查依赖精确的 token 数量：长输入、上下文限制、原生输入计数和缓存输入一致性。测试端固定的原生计数模板与该渠道报告的用量不匹配，因此这些检查被排除在分母之外，而不是计为失败。
为什么 R 100 不能保证路由完全没有失败？
R 仅涵盖 300 个专门的稳定性测试请求。答案质量和速度测试期间的失败记录在 Q 和 P 中。300 次全部成功时，95% 置信区间的下界为 98.78%，因此失败率很可能低于 1.22%，但这并不能证明失败率为零。
缓存测试如何区分热读和冷读？
每组先写入一个 8k 或 32k 前缀，然后在 5、30 和 120 秒后重复使用该前缀并提出新的最后一个问题，接着发送一个新前缀作为冷读对照。两种长度的热读请求均为 9 次中命中 9 次，每个冷读对照请求读取的缓存 token 数均为零。
继续阅读：DeepSeek V4.1 Flash 系列
- ByteDance 的 Q 与此基线相差 0.40 分以内，但其函数支持和缓存结果有所不同：ByteDance 上的 DeepSeek V4.1 Flash：工具调用一致，计量不一致。
- Baidu 的请求因
no_available_channel而失败，这同时反映在 Q 和 P 中：Baidu 上的 DeepSeek V4.1 Flash：无可用渠道影响 Q 和 P。 - Alibaba Cloud 的总体结果相差 0.37，且差异无法区分：Alibaba Cloud 上的 DeepSeek V4.1 Flash：首 token 耗时 1.34s，缓存命中率 99.37。
- Fireworks 在 8k 热请求中仅命中 9 次中的 3 次，而此处为 9 次中的 9 次：Fireworks 上的 DeepSeek V4.1 Flash：空停止回复，缓存命中 3/9。
