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、一会用办公网。最后出来的数据差异其实来自网络而不是服务商。所以开始前先固定这些条件条件固定方式测试机地理位置尽量固定在同一台机器或同一地域的云服务器网络线路使用同一网络出口避免跨地域切换API 版本确认调用的是同一模型名和同一接口协议请求内容使用固定 system prompt、固定用户输入输出长度设置 max_tokens避免有的服务商提前结束采样参数能固定 temperature 就固定追求创造性时结果不稳定单次间隔每条请求之间加间隔避免触发限流测试时段分多时段采样至少包含高峰和非高峰测试机放在哪里也很关键。代码助手通常跑在开发者的电脑上但如果你做的是服务端调用最好从目标服务器所在地测。否则你测出来的延迟是“你的电脑到服务商的延迟”而不是“你用户到服务商的延迟”。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: fBearer {API_KEY}, Content-Type: application/json, } def run_once(): url f{BASE_URL}/chat/completions with httpx.stream(POST, url, jsonpayload, headersheaders, timeout60) 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_wait60): start time.perf_counter() first_content_time None decoded_content [] url f{base_url}/chat/completions with httpx.stream( POST, url, jsonclient_payload, headersheaders, timeoutmax_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 先把九家按网络位置和服务形态分组拿到九家数据后不要直接拉一张“快慢排行榜”。它们可能并不是同一类服务适合的接入方式也不同。服务形态常见特征选型重点国内云厂商开放的模型 API接口风格接近 OpenAI文档完整看鉴权、限流、审批流程第三方模型广场或聚合平台可能同时托管多个模型看是否支持流式、是否自动切换国际模型 API 平台节点多在海外国内网络可能不稳定看网络链路而不是只看推理性能代码工具自带的模型配置只需填 base_url、model、API Key看多轮消息兼容性有些服务商只是“转发”能力它们本身不提供推理卡底层调用的是其他大型云厂商的资源。这种情况下你测到的延迟会多一跳稳定性也依赖上游。如果做生产项目先搞清楚它是不是自建推理。4.2 看排名也看排名变化如果一天内不同时段各测一轮有些服务商在凌晨排名靠前到白天高峰期就掉到后面。这种排名变化比单次排名更有价值。你在做选型时可以这样做选 3 个固定时段上午、下午、晚间。每个时段跑同一组 20 条请求。对比 p50 排序和 p95 排序。看是否出现“某家 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_URLhttps://你的模型服务商地址/v1 export DEEPSEEK_MODELdeepseek-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我的排查顺序一般是先看报错是本地工具报的还是上游 API 返回的。如果是上游 API 返回看upstream_status和cause字段。检查多轮消息里 assistant 消息是否缺少reasoning_content。检查消息顺序是否为 user、assistant、user不能把 assistant 消息漏掉。检查模型名是否完整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先固定环境再切换服务商先检查多轮消息结构再怀疑模型能力。这套流程做完你自己就能判断该选哪家不用等别人更新下一轮数据。