你有没有遇到过这种情况Demo 跑得好好的语音助手一上生产就被人吐槽反应太慢你翻遍模型规格表每个都说自己低延迟但真到用户盯着屏幕等回复的时候谁快谁慢你心里根本没底。更麻烦的是这种等待是没法靠猜的。你挑了三四个模型文档都说自己快但没人告诉你在你实际用的提示词长度下谁真的能一秒内开口谁在你把文档从 500 字加到 10,000 字之后会突然变慢谁平时看着正常却偶尔卡上十几秒让用户以为你的产品挂了这些恰恰是选型时最该知道的事。但市面上没有一个简单、公开的答案。所以这次我们直接把它测了出来DigitalOcean 无服务器推理上的六个模型包括 Gemma 4、GLM-5.3、Kimi K2.6、DeepSeek V3.2、DeepSeek V4.1 Flash 和 Llama 4 Maverick。每个模型分别测试三种提示词长度总计进行了 380 次调用。所有请求都经过特殊处理以确保不会命中提示缓存。此外我们还针对其中一个模型进行了额外测试专门观察它在最苛刻输入条件下的响应表现。不管你是正准备选模型还是已经上线但心里没底或是正准备使用 DigitalOcean 无服务器推理但不知怎么选模型下面这些测试数据与测试方法应该都能帮你少踩几个坑。如果你看过之后还是不知道该怎么选模型或不知是否该从自己部署大模型迁移到无服务器推理也可直接与 DigitalOcean 中国区战略合作伙伴卓普云aidroplet.com的技术团队聊一聊。TTFT 为什么才是关键首 Token 延迟Time to First TokenTTFT并不等于总响应时间。一个模型可能需要两秒才开始输出但开始之后能迅速流式生成完整答案。在这项测试中它不应该因此被判定为响应慢。反过来如果一个模型开始输出后速度很快却让用户等了五秒才看到第一个字那么对用户而言它的响应就是慢的。因为这五秒才是用户实际感受到的等待时间。对于聊天机器人、语音交互界面以及需要给用户即时反馈的 AI Agent 等交互式应用TTFT 是衡量响应体验的重要指标。它很大程度上决定了产品给人的感觉究竟是“反应灵敏”还是“卡住了”。我们测了什么我们选了六个模型是为了覆盖不同规格而不是图方便Gemma 4小体积本应很快、GLM-5.3推理始终开启关不掉、Kimi K2.6这组里最大的模型一万亿参数、DeepSeek V3.2、DeepSeek V4.1 Flash以及 Llama 4 Maverick。每个模型都接受三种长度的提示词测试短提示词一个简单问题约 20–50 Token。中等长度提示词约 500 Token包含一段文本摘录和一个摘要请求。长提示词约 5,000–10,000 Token包含更长的文本摘录和一个问题。每种模型与提示词长度的组合重复测试 20 次。此外我们还对 DeepSeek V3.2 进行了 20 次额外测试将输入精确控制在 10,000 Token并使用模型自己的 Tokenizer 计算 Token 数量而不是根据字符数估算。由于这是整组测试中输入负载最大的场景我们专门对它进行了更深入的观察。全部测试共进行了 380 次调用。这些测试跑在 DigitalOcean 的 Tier 1 定价档上也就是任何新账户起步时的默认档位。为了确保测试结果不受提示缓存影响我们在每条提示词开头都添加了随机生成的唯一标记。原因在于DigitalOcean 的提示缓存会根据完全一致的前缀进行匹配。缓存命中后请求可能会非常快地返回但这种速度并不能真实反映模型的推理服务性能。如果不确保每次请求的文本都是全新的重复发送的短问题最终可能命中缓存让测得的 TTFT 看起来比实际情况更好。因此这组数据中的每次调用都经过处理确保请求不会命中提示缓存。测量脚本里曾出现的一个 bug第一次完整运行测试时390 条记录中有 127 条没有记录到 TTFT。程序没有报错只是没有留下任何延迟数据。问题出在部分模型会输出两类文本一类是模型的内部推理内容另一类才是最终答案。Kimi K2.6 和 DeepSeek V4.1 Flash 总是先输出推理内容GLM-5.3 在处理较长提示词时也会如此。但最初的测试脚本只监测最终答案完全忽略了推理内容。测试还将每次调用的输出限制在 50 个 Token因为答案最终有多长并不影响第一个 Token 出现的时间。问题恰恰出在这个限制上有些模型把全部输出预算都用在了推理过程上还没来得及生成最终答案输出额度就已经耗尽了。由于脚本只监测答案文本自然就没有记录到任何内容。修复方法是同时检查推理内容和答案内容并记录最先出现的 Token。修复后受影响的 140 次调用重新运行所有记录都成功获得了延迟数据。这里有一个值得注意的细节如果你测试的是带有显式推理输出的模型却只监测最终答案流就可能完全得不到 TTFT 数据即使测到了记录的也可能是“推理结束后到首个答案 Token 出现的时间”而不是通常所说的首 Token 延迟。这两个指标并不相同后者也无法准确反映用户最初的等待体验。测量背后的代码这次测试中有三段关键代码决定了测量结果是否可靠。直接展示它们很有必要因为测试方法是否可信最终取决于代码是否真正实现了它所声称的功能。首先要获得真实的、未命中缓存的 TTFT 数据就必须确保每条提示词对模型而言都是新的而不是重复请求导致缓存命中。解决方法是在每条提示词开头添加随机标记import uuid session_marker str(uuid.uuid4()) full_prompt f[session:{session_marker}]\n{prompt_text}正确地为第一个 Token 计时是拿到真实数据的另一半。下面的代码在请求发出前启动计时器然后逐块流式接收响应在第一段真实内容出现的精确时刻打上时间戳。第一个时间戳之后的一切对 TTFT 都不重要重要的只是在任何东西出现之前等了多久import time start_time time.perf_counter() first_token_time None stream client.chat.completions.create( modelmodel, messages[{role: user, content: full_prompt}], streamTrue, max_tokens50, ) for chunk in stream: if chunk.choices: delta chunk.choices[0].delta content_piece getattr(delta, content, None) or getattr(delta, reasoning_content, None) if content_piece and first_token_time is None: first_token_time time.perf_counter() ttft first_token_time - start_time其中getattr(delta, content, None) or getattr(delta, reasoning_content, None)这一行正是前面提到的 Bug 的修复方案。如果只检查content就会漏掉那些先通过独立字段输出推理内容的模型。同时检查这两个字段并以最先出现的内容为准才能更准确地测量首 Token 延迟。最后一段代码解决的是一个更具体的问题如何让 DeepSeek V3.2 的输入提示词精确达到 10,000 Token而不是只得到一个大致的长度。它会逐句截取原始文本并在每次调整后使用模型自己的 Tokenizer 计算 Token 数量通过不断缩小搜索范围找到最接近 10,000 Token 的截断位置。low, high 1, len(sentences) best_text, best_count, best_diff None, None, float(inf) while low high: mid (low high) // 2 candidate_text .join(sentences[:mid]) question_suffix tok_count count_tokens(candidate_text, deepseek-3.2) diff abs(tok_count - 10000) if diff best_diff: best_text, best_count, best_diff candidate_text, tok_count, diff if tok_count 10000: low mid 1 elif tok_count 10000: high mid - 1 else: break这是一种标准的二分查找算法只不过搜索对象不是排好序的列表而是句子的数量。它可以在较少的步骤内找到合适的截断位置不需要人工反复裁剪文本、估算长度再逐次检查结果。测试数据说明了什么在短提示词上六个模型里有五个靠得很近GLM-5.3 中位数 0.88 秒Kimi K2.6 是 0.90DeepSeek V4.1 Flash 是 0.90Gemma 4 是 0.93Llama 4 Maverick 是 0.98。对于一个简单问题这些模型大多能每次都在一秒内作答。DeepSeek V3.2 的整体表现则稍慢一些。短提示词下它的 TTFT 中位数为 1.43 秒当输入增加到 10,000 Token 时中位数上升至 1.9 秒P90第 90 百分位数达到 4.1 秒。对于大型模型处理长而密集的提示词来说这样的延迟并非完全不可接受。但如果你的应用要求该模型在这类输入规模下也能稳定地实现亚秒级响应就必须提前了解这一点。更值得关注的是我们对 DeepSeek V3.2 的全部 80 次调用进行排查后发现的异常情况。其中有两次请求明显偏慢一次等待了 186.9 秒才收到第一个 Token另一次则等待了 78.3 秒。值得注意的是一旦开始输出这两次请求都能正常生成答案对于输出上限为 50 个 Token 的回复生成过程大约只用了 4 秒。也就是说主要延迟发生在模型开始输出之前而不是生成答案的过程中。我们还检查了相同时间段内其他模型的表现没有发现类似情况。在另外五个模型的 300 次调用中没有一次请求的 TTFT 接近 10 秒。80 次调用中出现了两次异常漫长的等待而且都发生在同一个模型上。这个结果不足以说明模型存在固定比例的故障但在构建依赖快速响应的交互式应用之前确实值得留意。另一个值得关注的发现与 Gemma 4 有关。我们选择它作为体量较小、理论上响应较快的基线模型但随着提示词变长它的响应延迟反而出现了最大的增长。Gemma 4 在短提示词下的 TTFT 中位数为 0.93 秒长提示词下则升至 3.35 秒是所有受测模型中增幅最大的。相比之下其他模型在长提示词下的 TTFT 中位数都低于 2.1 秒。这说明模型参数规模并不能单独决定它处理长提示词时的响应表现。如果你的应用经常需要输入大量上下文仅凭模型大小或短提示词测试结果来判断响应速度很可能得出错误的结论。这组测试无法看出来的是首先测试只使用了一个 DigitalOcean 账户采用前面介绍的默认 Tier 1 配置并在 2026 年 9 月某一天的约 10 分钟内完成。DeepSeek V3.2 的 80 次调用中出现了两次异常漫长的等待这是实际观察到的结果但不能直接将其当作模型的故障率。由于样本数量有限我们没有足够依据断言它会在固定比例的请求中出现问题。更严谨的说法是在这次测试中DeepSeek V3.2 出现了两次长时间等待而其他受测模型没有出现类似情况。其次这些数据只反映了特定时间点的表现。推理服务的容量和请求路由都可能发生变化因此即使使用相同的方法下周重新测试也可能得到不同的结果。本次测试使用的数据、脚本和完整提示词都是公开的。任何拥有 DigitalOcean 账户的人都可以按照相同的方法重复测试观察自己得到的结果。对实际选型有什么参考价值在这组测试中大多数模型处理短、中等长度提示词时都能比较稳定地在一秒内返回首 Token。如果你正在使用这些模型构建对延迟敏感的应用这是一个积极的信号。不过有两点值得纳入实际的系统设计。第一DeepSeek V3.2 偶尔可能出现远超典型水平的首 Token 延迟。如果你用它来处理聊天、语音交互等需要及时反馈的任务就应该考虑设置超时机制和备用模型避免个别请求长时间没有响应。第二不要想当然地认为小模型一定更快或者一定能在长提示词下保持速度优势。Gemma 4 的测试结果就说明模型在短提示词下的表现并不能直接预测它处理长上下文时的表现。如果你正在使用无服务器推理构建需要实时反馈的应用选型时不应该只看模型宣传的性能指标。更可靠的做法是在正式投入生产之前使用真实业务中的提示词长度和请求模式针对候选模型进行实际测试。想在自己的模型和提示词长度下复现这次测试你可以在 DigitalOcean 账户中运行相同的测试流程并将结果与本文的数据进行比较。可以先参考无服务器推理快速入门指南再使用本次测试公开的脚本和原始数据作为起点。本文提到的全部脚本、提示词和原始测试结果都可以在 GitHub 仓库中找到github.com/smukherjee1do/ttft-audit