Theo 测量编程延迟后重新评价 Gemini 4 Carbon

在此前关于 Gemini 4 Carbon 的视频中，我的评价比自己原本打算的更积极。我重视它在某些安全工作中似乎限制较少，但回顾自己的使用记录后，我认为自己低估了它在编程工作流中的延迟。

在我审查的可比工作中，Carbon 的速度持续比我使用的其他模型慢约五倍。这是我自己任务中的观察，并非经过控制的普适基准。我认为这一差异足以改变我的推荐。

价格也让我担忧：我说该模型的价格计划在 12 月 1 日翻倍。我还想区分模型本身的能力和托管服务的使用体验。DeepMind 的一些人愿意听取反馈，据我了解他们正在处理速度问题。

我此前使用的一张图衡量的是服务器接受请求后到响应完成的时间。其中许多任务并非多轮智能体工作流。这种视角遗漏了编程智能体反复发起模型请求和工具调用时会一再出现的延迟。

我检查了九轮审查，多种模型在每轮同时收到相同任务说明。画面显示 Carbon 完成了其中四轮，平均用时 16 分 44 秒；在相同四轮中，Opus 用时 3 分 31 秒，GPT-6.1 Sol 用时 3 分 6 秒。其余五轮中，父智能体停止等待 Carbon。

我曾修改智能体指令：如果还有其他工作要做，就不要继续等待 Carbon。这意味着未完成的运行无法告诉我们那些审查完成本来需要多久。我没有等待全部运行结束，因此无法精确测量完整差距。

输出速度和工具调用行为都可能造成延迟，但我认为样本中最大的问题出现在响应开始之前。在展示的编程线程中，Carbon 平均需要约 11 秒才开始响应。在许多步骤中重复等待，可能显著延长智能体任务。

我实时演示了一个步骤，并与其他模型比较。这个例子只是一次响应及其工具调用，并非完整编程任务。我还说，在我的部分工作中 Carbon 需要更多步骤，这会使重复的启动延迟进一步累积。

我以前也见过托管延迟问题：我描述了一段时期，Azure 托管的 OpenAI 模型有时需要比平常长得多的时间才输出第一个词元。我说该问题后来得到修复，也希望 Google 团队获得足够信息来调查这次的问题。

在与一位 Google 开发者讨论时，我建议减少重复请求的开销，并将其与另一种编程工具使用的持久连接作比较。对方指出，生成输出前处理长提示词的预填充也需要时间。我同意，仅改变网络传输方式可能无法解决问题。

进一步查看后，我说 Carbon 有时等待开始响应的时间，比另一个模型完成响应的时间还长。我也观察到相同文件被反复读取。两种行为都可能增加任务总耗时，但各自的原因和影响仍需进一步调查。

我另外提出提示词缓存问题。画面展示的一项 Gemini 4 Argon 测试中，228 轮有 167 轮完全命中缓存，而展示的其他模型均为 228 轮全部命中。画面估计缓存未命中会增加成本。这是该工作负载的结果，并非每次 Gemini 请求的实测未命中率。

一位 Google 代表回应说，他们的工作负载没有显示相同行为。我表示愿意分享提示词、环境和运行记录，帮助团队复现并修复问题。另一条回应承认延迟与成本之间存在权衡，并表示服务应该做得更好。

我还讨论了用户报告的订阅访问和托管 API 端点之间的差异，以及推理强度出现在模型标识符中造成的集成摩擦。这些报告需要针对具体端点和工作负载评估，不能单独确定我观察到的延迟原因。

我修正后的结论是：对于我目前的编程工作流，延迟、成本和可靠性问题加在一起，超过了我发现的优点。我希望有更多能力强的竞争者，也欢迎改进，但目前不会把这个模型用于日常工作。