2026-11-03/04，通过 AIHubMix 使用 APB Full 套件，在五家供应商上测试了 DeepSeek V4.1 Flash 1017：每次使用相同的问题、参数和请求脚本。本 APB Profile 仅介绍 ByteDance 的测试结果，并按章节展开。
以下数字是分数，不代表排名，也不构成供应商推荐。Q、F、P、K 和 R 分别列出；总分是汇总指数，不是认证结果，也没有置信区间。评分规则详见 AIHubMix Provider Benchmark Standard v2.0。
五家供应商的分数
粗体标出本文介绍的供应商。供应商顺序固定，不代表排名。K 是 P 的子分项，占 P 的 20%。总分是没有置信区间的汇总指数。DeepSeek 官方渠道和 Alibaba Cloud 相差 0.37，无法区分。
概览
- Q 42.05。BFCL 85.20%，HLE 15.34%，AA-LCR 49.20%。与官方渠道相比，相差 −0.40 个百分点，95% 区间为 −1.46 至 +0.66：无法区分。AA-LCR 有 28 次请求失败，全部发生在窗口 1，并按答错计。
- F 74.98。174 项计分检查中，124 项通过。
reasoning_effort=none不会关闭思考模式。10k token 输入被报告为 10,026 tokens（原生计数为 10,000）；8-token 输入被报告为 34。 - P 84.37。首个正文 token 等待时间：单并发下中位数为 2.12 s，10 路并发下为 2.10 s；TPOT 为 3.43 ms/token；180 个速度请求全部有效。
- K 93.83。8k 热请求命中 9/9；32k 命中 8 次，另有 1 个请求在 300 s 截止时间前未完成。
- R 100。300 个专用请求全部首次尝试即成功。
测试设置
| 项目 | 详情 |
|---|---|
| 模型 | DeepSeek V4.1 Flash 1017 |
| 请求的模型 ID | doubao-deepseek-v4.1-flash-1017 |
| 返回的模型名称 | deepseek-v4-1-flash-261017 |
| 访问路径 | 通过 AIHubMix 使用特定于供应商的模型 ID，并非直接连接供应商账户 |
| 参数 | 非思考模式，temperature 1.0，max_tokens 16,384，超时 300 s，不自动重试 |
| 关闭思考模式 | 答案质量、速度、缓存和稳定性请求使用原生 thinking.type=disabled（对于此供应商，reasoning_effort=none 不会关闭思考模式）；函数调用测试保留 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 前缀各三组） |
请求使用 AIHubMix 的 快速入门路径和特定于供应商的 ID，参数遵循 DeepSeek 的API 文档；其他供应商 ID 列于模型页面。
Q — 答案质量：42.05
答案质量采用三个测试套件：500 个 BFCL 问题，每题 3 轮；250 个 HLE 问题，每题 10 轮；25 个 AA-LCR 问题，每题 10 轮。BFCL 通过自动规则评分；HLE 和 AA-LCR 由模型 deepseek-flash 评判。五家供应商收到的问题相同，三个套件合并计算准确率。由于问题无法评分，移除了 10 个答案，最终有 4,240 个问题实例纳入评分。
| 测试套件 | 问题数 | 正确数 | 准确率 | 失败数 |
|---|---|---|---|---|
| BFCL 工具调用 | 500 × 3 | 1,278/1,500 | 85.20% | 0 |
| HLE 高难度问答 | 250 × 10 | 382/2,490 | 15.34% | 7 |
| AA-LCR 长文档推理 | 25 × 10 | 123/250 | 49.20% | 28 |
| 合计 · 95% 区间 39.70%–44.33% | — | 1,783/4,240 | 42.05% | 35 |
服务失败——请求失败或输出截断——仍计入分母，并按答错计算。HLE 输出有 7 次达到 max_tokens 上限；AA-LCR 有 28 次请求失败，全部发生在窗口 1。BFCL 采用自动评分；HLE 和 AA-LCR 由评判模型评分。
每个 BFCL 问题回答 3 次；表中汇总了 3 轮结果。
| BFCL 类别 | 通过数 | 通过率 |
|---|---|---|
| simple_python — 单个函数，调用及参数正确 | 329/360 | 91.39% |
| multiple — 从多个函数中选择一个 | 268/300 | 89.33% |
| parallel — 多次调用同一个函数 | 271/300 | 90.33% |
| parallel_multiple — 调用多个不同函数 | 207/240 | 86.25% |
| irrelevance — 没有相关函数，不应调用 | 102/150 | 68.00% |
| ahm_multi_turn — 三阶段工具链 | 101/150 | 67.33% |
与其他四家相比
与官方渠道的差值，以百分点表示；误差线显示 95% 区间。区间跨过 0 时，记为无法区分。HLE 和 AA-LCR 的评判模型 deepseek-flash 与受测模型同属 DeepSeek 系列，且未经校准，因此评判结果可能偏宽松。
F — 函数支持：74.98
函数调用测试只考察接口行为是否符合协议，不评估模型回答得好不好。六组共 60 个案例，每个窗口运行一次，总计 180 项检查，并依据各供应商公开的格式进行判定。不适用、无效或未观察到的检查不计入分母。ByteDance 在 174 项计分检查中通过 124 项，按各组权重计算得分为 74.98。
加权分数按各组权重计算，并非通过项数除以 174。
| 组别 | 权重 | 通过数 | 排除数 | 组别得分 |
|---|---|---|---|---|
| 流式输出和消息协议 | 20% | 23/27 | 3 | 85.19 |
| 工具接口 | 20% | 30/30 | — | 100.00 |
| 输出约束和参数 | 20% | 24/30 | — | 80.00 |
| 上下文和状态 | 15% | 14/30 | — | 46.67 |
| 错误和恢复 | 15% | 21/30 | — | 70.00 |
| 计量和缓存协议 | 10% | 12/27 | 3 | 44.44 |
| 总计 · 加权得分 | — | 124/174 | 6 | 74.98 |
“失败窗口数”表示 3 个窗口中未通过该项检查的窗口数。
| 失败案例 | 失败窗口数 | 原因 |
|---|---|---|
| 推理内容未泄漏到正文 — 流式输出和消息协议 | 3/3 | 设置 reasoning_effort=none 后，仍返回了思考内容 |
| 思考配置生效 — 输出约束和参数 | 3/3 | 设置 reasoning_effort=none 后，仍返回了思考内容 |
| 采样多样性 — 输出约束和参数 | 3/3 | temperature 为 0 和 1 时的输出差异不够大，低于预先登记的阈值 |
| 10k 长输入 — 上下文和状态 | 3/3 | 报告的输入为 10,026 tokens；原生计数应为 10,000 |
| 未超出上下文限制 — 上下文和状态 | 3/3 | 报告的输入为 10,026 tokens；原生计数应为 10,000 |
| 32k 长输入 — 上下文和状态 | 3/3 | 报告的输入为 10,026 tokens；原生计数应为 10,000 |
| 100k 长输入 — 上下文和状态 | 3/3 | 报告的输入为 10,026 tokens；原生计数应为 10,000 |
| 超出上下文限制 — 上下文和状态 | 3/3 | 上游连接失败或超时（1）；本应返回参数错误，却返回了 200（2） |
| 12 轮历史 — 上下文和状态 | 1/3 | 上游连接失败或超时 |
| messages 格式错误 — 错误和恢复 | 3/3 | 返回 400，正文为空；没有结构化错误说明 |
| 孤立的工具结果 — 错误和恢复 | 3/3 | 本应返回参数错误，却返回了 200 |
| stream_options 格式错误 — 错误和恢复 | 3/3 | 返回 400，正文为空；没有结构化错误说明 |
| 思考 token 计量 — 计量和缓存协议 | 3/3 | 关闭思考模式后仍报告了思考 token |
| 原生输入计数 — 计量和缓存协议 | 3/3 | 报告了 34 tokens；原生计数应为 8 |
| 输入计数包含工具定义 — 计量和缓存协议 | 3/3 | 不含工具的对照请求，其输入计数已与原生计数不一致 |
| 缓存前后输入计数一致 — 计量和缓存协议 | 3/3 | 重复使用相同前缀时，报告的输入 token 数与原生计数不一致 |
| 流式与非流式输入计数一致 — 计量和缓存协议 | 3/3 | 两者都报告了 34 tokens；原生计数应为 8 |
| 精确文本输出 — 流式输出和消息协议 | 1/3 | 正文末尾多了一个句号；并非要求的精确文本 |
这些检查不计入分母，既不算通过，也不算失败。
| 状态 | 案例 | 数量 | 原因 |
|---|---|---|---|
| 未观察到 | 流式输出停止序列 | 3 | 上一步之后未发送此请求；无法判定 |
| 不适用 | 显式 cache_control | 3 | 预先登记为此接口不支持 |
messages 格式错误和 stream_options 格式错误这两个案例在五家供应商上全部失败：两种情况下都返回 400 且正文为空，因此客户端得不到结构化错误说明。五家供应商都出现的失败，更可能发生在 AIHubMix 网关层，需要单独调查。思考 token 计量也在五家供应商上全部失败，但原因各不相同：关闭思考模式后，ByteDance 和 Fireworks 仍报告了思考 token；另外三家没有返回思考 token 计数。
与其他四家相比
P — 响应速度：84.37
每个请求包含约 10,000 个输入 token，并要求生成约 1,100 个正文输出 token。在三个窗口中，每个窗口分别以单并发和 10 路并发运行 30 个请求：总计 180 个请求。
| 指标 | 结果 |
|---|---|
| 等待首个正文 token（TTFA） | 单并发下中位数为 2.12 s；10 路并发下中位数为 2.10 s |
| 生成速度（TPOT） | 单并发下为 3.43 ms/token；10 路并发下为 3.41 ms/token |
| 有效吞吐量 | 10 路并发下为 1,250.0 token/s |
| 有效请求 | 单并发 90/90；10 路并发 90/90 |
| 分项得分 | TTFA 48.59，TPOT 100.00，吞吐量 100.00；TTFA 和 TPOT 取两个档位中较低的分数；权重分别为 35% / 35% / 30%；响应得分 82.00 |
| P 得分 | 响应得分 82.00，占 80%；缓存 K 93.83，占 20%；总分 84.37 |
TPOT 根据流式输出的分块估算，并非在硬件上逐 token 测量。吞吐量是 10 路并发下的有效输出 token 数除以批次总耗时。
与其他四家相比
五家供应商共用一台机器、一个网络和一个账户。三个窗口按供应商依次安排，因此数据采集时段并未完全重叠；不宜过度解读细微差异。
K — 缓存：93.83
每组发送 5 个请求。第一个请求携带约 8k 或 32k token 的固定前缀，用于填充缓存。第 2–4 个请求保留此前缀，仅更改最后的问题，发送时间分别为 5 s、30 s 和 120 s。第五个请求使用新的前缀，作为冷缓存对照。三个窗口、两种长度、每组 5 个请求，共计 30 个请求。K 的计算方式为热请求中缓存读取的 token 数除以按规则应可复用的 token 数；两种长度的权重相同。K 占 P 的 20%。
| 前缀 | 窗口 | 填充请求 | +5 s | +30 s | +120 s | 冷缓存对照 |
|---|---|---|---|---|---|---|
| 8k | 窗口 1 | 0 | 7,936 | 7,936 | 7,936 | 0 |
| 8k | 窗口 2 | 0 | 7,936 | 7,936 | 7,936 | 0 |
| 8k | 窗口 3 | 0 | 7,936 | 7,936 | 7,936 | 0 |
| 32k | 窗口 1 | 0 | 32,000 | 32,000 | 32,000 | 0 |
| 32k | 窗口 2 | 0 | 32,000 | 32,000 | 失败 | 0 |
| 32k | 窗口 3 | 0 | 32,000 | 32,000 | 32,000 | 0 |
这些值是服务器报告的缓存读取 token 数。
全部 9 个 8k 热请求均命中，每个请求读取 7,936 个 token。9 个 32k 热请求中有 8 个命中，每个读取 32,000 个 token；有一个请求失败。两种长度等权计算，K 为 93.83。冷请求未读取缓存，因此冷热请求区分明确。失败的是窗口 2 中 32k 组的第 4 个请求，它未能在 300 s 截止时间前完成。
与其他四家相比
R — 服务稳定性：100
这 300 个请求分为四种类型——短文本、长输入、工具调用和多轮历史记录——并在三个窗口中以单并发运行。只有首次尝试返回有效且完整的响应，请求才计为成功；不检查答案正确性，也不进行重试。答案质量和速度部分中的失败计入 Q 和 P，不会再次计入 R。
| 请求类型 | 首次尝试成功率 |
|---|---|
| 短文本 | 120/120 |
| 10k 长输入 | 90/90 |
| 工具调用 | 60/60 |
| 多轮历史记录 | 30/30 |
| 总计 · 95% 置信区间 98.78%–100% | 300/300 |
全部 300 个请求均在首次尝试时返回了有效且完整的响应。R = 100 仅描述这 300 个专门测试的请求，并不意味着整个链路毫无失败。95% 置信区间的下限为 98.78%：300 次成功只能说明失败率很可能低于 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% |
常见问题
reasoning_effort=none 是否确实没能关闭思考模式？
是。在三个窗口中，使用 reasoning_effort=none 的请求仍返回了思考内容，因此检查结果为 3/3 未通过。答案质量、速度、缓存和稳定性测试使用的是原生 thinking.type=disabled 开关。函数测试套件有意保留 reasoning_effort=none，以检验该参数是否生效。
BFCL 准确率为 85.20%。为什么 Q 只有 42.05？
Q 汇总了三个难度截然不同的测试套件。BFCL 答对 1,278 道（共 1,500 道），HLE 答对 382 道（共 2,490 道），AA-LCR 答对 123 道（共 250 道）。合计 4,240 个计分问题实例中答对 1,783 个，即 42.05%。HLE 的 15.34% 拉低了汇总结果。
35 次 Q 服务失败是否计入分数？
是。请求失败和输出截断仍计入分母，并按答错处理。7 个 HLE 答案因 max_tokens 限制而被截断；28 个 AA-LCR 请求失败，全部发生在窗口 1。
为什么输入 token 计量很重要？
因为计量结果应与模型的原生计数一致。一个 10k-token 输入被报告为 10,026 个 token（原生计数为 10,000），而一个 8-token 输入被报告为 34。没有工具的对照请求也已出现不一致，而且流式输出和非流式输出报告的都是 34。5 项计量检查全部未通过（3/3）。
32k 缓存结果是未命中还是失败？
是失败。9 个 32k 热请求中有 8 个命中，并读取了 32,000 个 token。唯一的未命中是窗口 2 中的第 4 个请求，它未能在 300 s 截止时间前完成。8k 组的命中率为 9/9，每次读取 7,936 个 token。
ByteDance 的答案质量与官方渠道相比，能否区分出差异？
不能。综合准确率比官方渠道低 0.40 个百分点，95% 置信区间为 −1.46 至 +0.66。该区间包含 0，因此两者无法区分。这仅描述本批测试结果，不构成排名。
继续阅读：DeepSeek V4.1 Flash 系列
- 本文中的 Q 基准是官方渠道；该渠道自己的测试运行（包括 15 次无效的单并发探测）详见 DeepSeek V4.1 Flash 官方渠道测试：94.00 F，15 次无效探测。
- Baidu 是唯一一家 Q 置信区间低于官方渠道的供应商；导致这一结果的渠道故障详见 DeepSeek V4.1 Flash 在 Baidu 上的测试：无可用渠道达到 Q 和 P。
- Alibaba Cloud 的缓存数据可与本文报告的 93.83 对照查看：DeepSeek V4.1 Flash 在 Alibaba Cloud 上的测试：首 token 延迟 1.34s，缓存命中率 99.37。
- Fireworks 也出现了本文提到的思考模式和 token 计量问题，此外还有空的停止回复：DeepSeek V4.1 Flash 在 Fireworks 上的测试：空停止回复，缓存命中 3/9。
