DeepSeek V4 Flash九家服务商延迟对比：测试方法与选型指南

DeepSeek V4 Flash 0731 这版模型最近有一轮很值得看的横向对比，主题是九家服务商的 latency。这类测试为什么值得盯？因为把同一个模型换成不同服务商后，首字延迟和生成速度可能差得比模型切换还明显。适合看的读者有两类：一类是要把 V4 Flash 接进 Codex、Claude Code、OpenCode 或自己的 API 服务里做代码补全；另一类是在做应用选型，想知道低延迟和高稳定性到底该看哪些指标。

下面按我从单条请求跑到批量对比的顺序拆一遍。重点不是告诉你哪家快，而是给你一套能自己在本地复现、能用来做服务商选型、也能在日常巡检中持续跑起来的延迟测试方法。

1. 九家服务商跑同一个模型，为什么还要单独测延迟

1.1 这里说的 latency 不是单一指标

很多人看模型评测只盯“每秒生成多少 token”，但实际接入应用时，体验是由几个不同时段叠加出来的。

第一个是首 token 延迟（TTFT），从请求发出去到收到第一个有效 token 的时间。代码助手、搜索引擎、对话机器人这类对“开始响应”很敏感的场景，主要就受这个指标影响。你问一个问题，如果光标一直不动，用户会觉得服务挂了；一旦开始吐字，哪怕后面速度一般，心理等待感也会明显降低。

第二个是生成速度，也就是稳定输出阶段的 tokens/s，或者相邻 token 之间的间隔。写长文档、重构代码、批量总结时，这个指标决定了最终要等多久。

第三个是端到端延迟，从发起请求到收到完整回复的总时间。它和 TTFT、生成速度都有关，但也会被网络往返、队列等待、上游限流、重试机制影响。

九家服务商的对比如果只给一个平均总耗时，其实很难用。你需要看的是首字延迟的分布、生成阶段的波动、错误率和尾部延迟。

1.2 为什么延迟会差这么多

同一个模型，模型参数本身是一样的，但服务商之间的运行环境差异很大：

• 推理卡型号不同。高端卡和普通卡在处理同样模型时，算力和显存带宽不一样。
• 服务框架不同。vLLM、SGLang 以及厂商自研推理服务，在连续批处理、KV Cache 管理、调度策略上会有差异。
• 是否开启前缀缓存。如果请求里的 system prompt 和公共上下文很长，服务商有没有做 prefix cache，直接影响 prefill 耗时。
• 网络位置不同。服务端离你越远，每一轮流式数据到达本地的延迟越大。
• 当前负载不同。同样是深夜测试和白天高峰测试，排队等待时间是两回事。
• 是否做了量化或精度裁剪。有的服务商用 FP16 跑，有的用 INT8 或更激进的量化来降低单卡成本。

所以九家服务商跑同一模型，延迟不可能完全一致。只看平均值还不够，还要看这个平均值是在什么时间段、什么请求长度、多少并发下测出来的。

1.3 九家对比真正有价值的部分

九家同时测试，价值在于能看出“排序”和“波动”，而不是得到一个让你直接抄作业的固定数值。

如果你只在一家测，得到 2 秒 TTFT，你很难判断这是模型本身的问题还是服务商的问题。但如果你固定同一套 prompt、同一个模型版本、同一类请求长度，去九家跑同样次数，那么理想情况下，唯一变量就是服务商。这时候哪家快、哪家稳定、哪家在某个时段开始抖动，就非常直观。

需要注意，这类对比也不能完全脱离业务场景。模型版本、max_tokens、stream 开关、是否多轮、是否携带长上下文，都会改变最终的 latency 排序。适合短对话的服务商，不一定适合超长代码文件补全。

2. 先搭一套可复用的延迟测试环境

2.1 固定环境，比测试脚本更重要

我自己做过不少接口对比，最容易犯的错就是今天在本机跑、明天换到服务器跑，或者一会用 5G、一会用办公网。最后出来的数据差异其实来自网络，而不是服务商。

所以开始前先固定这些条件：

测试机放在哪里也很关键。代码助手通常跑在开发者的电脑上，但如果你做的是服务端调用，最好从目标服务器所在地测。否则你测出来的延迟是“你的电脑到服务商的延迟”，而不是“你用户到服务商的延迟”。

2.2 设计一组有区分度的请求

不建议只用一个“你好”来测延迟。常见做法是准备三组输入：

• 短输入短输出：模拟简单问答，主要看网络开销和基础 TTFT。
• 长输入短输出：模拟带着系统提示词或长上下文提问，看 prefill 对首字延迟的影响。
• 中等输入长输出：模拟代码生成或长文本续写，看稳定生成阶段的吞吐。

如果你接入的是代码场景，可以单独准备一个“补全函数、增加注释、重构类名”的真实代码片段。这类请求既能让流式输出有明显节奏，也能看出模型在思考模式下是否先输出 reasoning_content 再输出正式内容。

2.3 用脚本发起第一次真实请求

先用最朴素的 Python 脚本打通线路，确保 base_url、模型名、鉴权方式都没问题。

import os import httpx BASE_URL = os.getenv("DS_BASE_URL", "https://api.example.com/v1") API_KEY = os.getenv("DS_API_KEY") MODEL = "deepseek-v4-flash" payload = { "model": MODEL, "messages": [{"role": "user", "content": "用一句话解释什么是 cache。"}], "max_tokens": 256, "stream": True, } headers = { "Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json", } def run_once(): url = f"{BASE_URL}/chat/completions" with httpx.stream("POST", url, json=payload, headers=headers, timeout=60) as resp: if resp.status_code != 200: print("HTTP", resp.status_code, resp.read().decode()) return for line in resp.iter_lines(): if not line or not line.startswith("data:"): continue data_str = line[5:].strip() if data_str == "[DONE]": break # 这里先只打印原始结构，确认字段后再做计时统计 print(data_str) if __name__ == "__main__": run_once()

第一次跑先不要加复杂的统计逻辑。先看能不能拿到 200 响应，能不能持续收到data:行，最后有没有收到[DONE]。

如果收到的delta里有reasoning_content，说明这个版本在思考模式下会先输出推理内容。计时时要单独区分：是从请求发出去到第一个内容 token 算，还是到第一个可见回答 token 算。不同统计口径会得出完全不同的“延迟”。

3. 单条请求跑通后，用统计口径替代单次结果

3.1 单次快不代表稳定

很多博主做对比，会挑一次“跑得漂亮”的结果截图。真实项目里不能这么干。单次请求受到网络波动、服务商排队、机器调度影响，方差可能非常大。你今天测到 300ms，不代表明天还是 300ms；你并发到 10 条时，可能就变成 3 秒。

所以我建议至少在每个服务商跑 10 到 20 条请求，有条件就跑 50 条，然后统计下面几个值：

• p50：中位数，代表大多数时候的体验。
• p95：代表负载较高时的最差体验。
• p99：代表极端尾部延迟。
• 错误率：包括 HTTP 4xx、5xx、超时、连接中断。
• 平均生成速度：统计非流式场景下完整输出的耗时，再除以输出 token 数。

判断一个服务商能不能用，不能只看 p50。代码助手这种业务，用户能明显感知到 p95；如果 p95 比 p50 高出一大截，说明服务商在突发流量下会明显抖动。

3.2 把计时逻辑做成可复用函数

单条通了之后，再封装成测多次的函数。下面是一个简化版本：

import time import json import statistics import httpx def measure_once(client_payload, base_url, headers, max_wait=60): start = time.perf_counter() first_content_time = None decoded_content = [] url = f"{base_url}/chat/completions" with httpx.stream( "POST", url, json=client_payload, headers=headers, timeout=max_wait, ) as resp: if resp.status_code != 200: return {"error": resp.status_code, "body": resp.read().decode()} for line in resp.iter_lines(): if not line or not line.startswith("data:"): continue raw = line[5:].strip() if raw == "[DONE]": break try: chunk = json.loads(raw) except json.JSONDecodeError: continue choices = chunk.get("choices") or [] if not choices: continue delta = choices[0].get("delta") or {} # 如果只想统计正式回答内容，可以忽略 reasoning_content if not first_content_time and delta.get("content"): first_content_time = time.perf_counter() if delta.get("content"): decoded_content.append(delta["content"]) end = time.perf_counter() return { "end_to_end_seconds": end - start, "first_content_seconds": (first_content_time - start) if first_content_time else None, "text": "".join(decoded_content), "output_chars": len("".join(decoded_content)), }

这里有一个容易被忽略的点：httpx.stream进入with时，并不代表响应已经开始到达。真正的网络首包是在你第一次迭代 line 时才可能被读取。所以用这个脚本统计的first_content_seconds，已经包含连接建立、发送请求、服务端排队和 prefill 的时间，对选型足够用了。但如果想精确拆分网络耗时和服务端耗时，就要用更底层的工具记录 TCP 连接和响应头到达时间。

3.3 统计后先检查异常样本

跑完 20 条，不建议直接求平均值。先把明显异常挑出来看：

• 有没有一条响应直接超时？
• 有没有 HTTP 429 限流？
• 有没有某次第一条data:等了特别久？
• 有没有连接被服务端中断？
• 有没有内容中途截断，但没有收到[DONE]？

这些问题单看平均延迟很难暴露。尤其限流，服务商通常不会直接报错，而是让请求继续排长队，最终表现为“某一次特别慢”。如果你把这种数据也放进平均值里，你会误以为服务商能力不够。

4. 九家服务商的排序怎么读，才不会选错对象

4.1 先把九家按网络位置和服务形态分组

拿到九家数据后，不要直接拉一张“快慢排行榜”。它们可能并不是同一类服务，适合的接入方式也不同。

有些服务商只是“转发”能力，它们本身不提供推理卡，底层调用的是其他大型云厂商的资源。这种情况下你测到的延迟会多一跳，稳定性也依赖上游。如果做生产项目，先搞清楚它是不是自建推理。

4.2 看排名，也看排名变化

如果一天内不同时段各测一轮，有些服务商在凌晨排名靠前，到白天高峰期就掉到后面。这种排名变化比单次排名更有价值。

你在做选型时可以这样做：

1. 选 3 个固定时段：上午、下午、晚间。
2. 每个时段跑同一组 20 条请求。
3. 对比 p50 排序和 p95 排序。
4. 看是否出现“某家 p50 很快，但 p95 极高”的反差。

如果某个服务商在这三种时段都稳定排在前面，那它大概率是真的适合你的场景。如果只有凌晨快，其他时间都慢，说明它的晚高峰调度能力有限。

4.3 不要把模型横向对比和厂商对比混在一起

搜索热词里有大量“豆包、元宝、千问、deepseek 哪个好”的问题，这类问题适合做模型能力对比，但不适合做服务商延迟选型。

DeepSeek V4 Flash 0731 延迟对比的前提是模型不变，服务商变。如果你想去比较 V4 Flash 和 Kimi 2.7 Code 哪个写代码更好，那是另一套评测，评测对象不再是 latency，而是代码正确率、指令遵循能力和输出格式。两件事不要放在同一张表里解释，否则谁也用不上。

5. 接入代码助手时，延迟问题会变成协议兼容问题

5.1 代码工具默认走的不一定是你模型平台的路

Codex、Claude Code、OpenCode 这类工具，很多默认只适配某几家模型厂商。想接入 DeepSeek V4 Flash，通常要通过 base_url 改写指向你选的模型服务商，同时把模型名改成deepseek-v4-flash。

正常工作流程是：

# 不同工具配置方式不同，但核心参数大致一样 export DEEPSEEK_API_KEY="你的 API Key" export DEEPSEEK_BASE_URL="https://你的模型服务商地址/v1" export DEEPSEEK_MODEL="deepseek-v4-flash"

如果只填了 API Key 和模型名，但 base_url 没改，工具会默认请求它自己内置的地址，自然找不到模型。这类问题不是延迟问题，但往往会以“请求特别慢”“一直转圈”的形式出现，排查时先看日志里实际请求的 URL。

5.2 多轮对话时报 400，先检查 reasoning_content 有没有回传

代码助手几乎都是多轮对话。用户第一次提问，模型返回结果后，工具会把对话历史保存下来。等用户第二次提问时，工具会把历史消息原样发回 API。

问题就出在 V4 Flash 如果开启了 thinking 模式，第一条 assistant 消息里可能带有reasoning_content。下一次请求时，有些服务商要求把这一段内容一起回传，否则会报 400。

真实报错里你会看到类似这样的信息：

upstream_status: http 400 cause: the `reasoning_content` in the thinking mode must be passed back to the API

我的排查顺序一般是：

1. 先看报错是本地工具报的，还是上游 API 返回的。
2. 如果是上游 API 返回，看upstream_status和cause字段。
3. 检查多轮消息里 assistant 消息是否缺少reasoning_content。
4. 检查消息顺序是否为 user、assistant、user，不能把 assistant 消息漏掉。
5. 检查模型名是否完整，deepseek-v4-flash不要写成deepseek-v4。

这个 400 经常被误解成“服务商有问题”或者“并发太高”。实际上就是历史消息结构不符合模型 API 要求。只要在本地缓存历史时，把 assistant 消息里的reasoning_content一并存下来，并在下次请求时放回消息体，问题就会消失。

5.3 多轮对话变慢，不一定是服务商在劣化

还有一个常见现象：第一轮很快，第二轮开始变慢，到第五轮几乎卡顿。这不一定代表服务商变差。

主要原因有两个：

一是输入上下文越来越长。每轮都会把历史代码、历史输出拼接进请求，prefill 时间会线性增加。TTFT 变慢是正常现象。

二是代码工具会自动附加系统提示词或代码库索引内容。上下文达到数万 token 后，首字延迟自然比短请求高很多。

如果你要测“多轮延迟”，就不能只拿单轮请求时间当结论。要在脚本里模拟三轮、五轮甚至十轮对话，并且统计每一轮的 TTFT。

6. 如果不想走服务商，本地部署 V4 Flash 需要重新测什么

6.1 本地部署可以降低网络影响，但代价不小

有的人看到九家服务商延迟差距很大，会想干脆本地部署 DeepSeek V4 Flash。这个思路合理，但要注意，本地部署换来的不是“零延迟”，而是把变量从网络和服务商负载，转移到了你自己的显卡、显存、CPU 和推理框架配置上。

本地推理至少需要准备：

• 足够的显存来加载模型权重和 KV Cache。
• 足够的系统内存做加载和预处理。
• 足够快的磁盘来加载模型文件。
• 一个支持目标模型的推理框架，比如 vLLM、SGLang、llama.cpp 或厂商提供的原生部署包。
• 如果使用国产加速卡，还需要确认底层驱动、算子库和推理框架版本是否匹配。

6.2 本地部署不能直接参考九家云端数据

服务商云端通常使用大规模并行推理，单用户请求只是它整个批处理中的一份。本地部署一次只服务你自己，或者少数并发请求，表现出的延迟曲线和云端完全不同。

本地部署要重点测试这几个指标：

• 模型加载耗时：这影响服务重启时间，不直接影响单次推理。
• 首 token 延迟：在显存充足和显存不足两种情况下差距很大。
• tokens/s：反映推理吞吐。
• 连续多轮请求后的显存增长：如果显存不足，服务可能崩溃或频繁重新调度。
• 并发请求数从 1 加到 4 时，单请求延迟会如何变化。

如果只是自己一个人用，本地部署可能更可控；如果要把服务开放给多人使用，你要面临请求排队、并发控制、显存隔离、服务重启等问题，复杂度会比调 API 高很多。

6.3 国产加速卡部署要以官方适配为准

搜索词里有人提到昇腾 910B4 部署 DeepSeek V4 Flash。这个方向值得关注，尤其在使用国产算力环境的团队中。

但注意一点：国产加速卡部署不能只看模型能不能加载，还要看算子是否兼容、是否支持流式输出、是否能跑高并发。不要用一张“部署成功截图”就判断生产可用，至少要跑一轮长输出压测，确认没有中途算子报错、显存泄漏和输出乱码。

如果厂商已经提供了部署脚本，严格按官方推荐的框架版本和驱动版本执行，不要自己随手升级依赖。每次升级驱动后都要重新跑一遍延迟回归，否则可能模型能启动，但性能明显回落。

7. 把延迟测试做成日常巡检，比一次对比更有价值

7.1 建立你自己的延迟基准

九家服务商的测试只是起点。服务商会调整底层资源、增加模型版本、改变调度策略，你一个月前拿到的高分，下个月可能就不成立。

我建议把测试脚本固定下来，每周或每两周跑一轮，持续记录：

• 各服务商的 p50、p95、错误率。
• 模型名和请求参数是否变化。
• 服务商返回的 usage 字段是否异常。
• 是否出现新的 API 版本要求。

如果只是在选型时跑一次，那叫尝鲜；如果能定时跑，那才叫监控。

7.2 设置适合自己业务的阈值

不同业务对延迟的容忍度不同。给一个通用参考值很危险，因为请求长度、模型配置都会影响结果。

但你可以给自己设定相对阈值和绝对阈值。

相对阈值是相对自身均值：如果 p95 连续三次超过前一天均值的 2 倍，就值得关注。绝对阈值则和产品体验绑定：代码助手场景下，如果 TTFT 长时间超过某个用户不能忍受的值，就要考虑切换或降级。

不需要一开始就上很重的监控系统。先用一个脚本每天定时跑，把结果追加到 JSON 或 CSV 文件，就能看到趋势。

7.3 多条服务商线路要做容灾

如果你在九家里选了主用服务商，不要只配一个。模型服务商偶尔会故障、限流或变更接口，线上应用至少准备一个备用服务商。

容灾切换不能靠手动改环境变量。要做到：

• 请求失败时自动重试一次。
• 重试如果仍失败，切换到备用服务商。
• 记录主服务商和备用服务商的响应时间。
• 备用服务商也别一直不用，每周定时发几条探活请求。

我见过很多团队只做“主备切换”，但备胎从来没测过，等故障发生时才发现备用服务商的模型名已经失效，或者 API Key 权限没开。运维巡检里最容易被忽略的，就是没坏的那条路。

最后把话说得更直白一点：DeepSeek V4 Flash 0731 的九家 latency 对比，真正有价值的不是那张排行榜，而是你能不能理解排行榜背后的统计口径、网络位置、上下文长度和协议兼容性。先把单条请求跑通，再跑 20 条看 p95；先固定环境，再切换服务商；先检查多轮消息结构，再怀疑模型能力。这套流程做完，你自己就能判断该选哪家，不用等别人更新下一轮数据。