GLM-5 vs DeepSeek V3 vs GPT-5：开发者速度与成本对比

嘿，我是 Dora。促使我写这篇文章的其实是件小事：一个本该五分钟搞定的摘要任务拖了十五分钟，因为第一次响应在开头就卡住了。这不完全是模型的问题——token 流式传输、服务器负载，诸如此类——但它提醒了我，“准确性”并不是唯一会让一天变得一团糟的因素。

于是我开始认真思考一个一直萦绕我的问题：在现实世界中，GLM-5、DeepSeek 和 GPT-5 用起来到底是什么感觉？不是看图表，而是响应时间、不会让你大吃一惊的成本，以及在任务有三四个环节时的可靠性。这篇文章是我把这些想法冷静地写下来的尝试，同时要说明的是：你的技术栈、所在地区以及对边缘情况的容忍度，都会改变这幅图景。

我会保持务实：GLM-5 vs DeepSeek vs GPT-5，超越炒作和常见的跑分截图。

跑分之外，还要比什么

跑分是一项基本检验，而非终点。我真正在意的那些测试并不光鲜：

关键时刻的延迟：首 token 时间（TTFT）和稳定吞吐量。一个”思考时间更长”的模型不是问题；一个在开始之前就空转的模型才往往是。
与工作形态匹配的成本：每百万 token 的定价只是起点，但上下文浪费、重试和工具调用可能让实际花费翻倍。
失败模式：当提示词略有偏差、工具超时或输入超长时，模型的表现如何。
可控性：温度参数能否真正改变输出的多样性，系统提示词能否保持稳定，函数调用在 schema 边缘情况下是否会摇摆不定。
高负载下的表现退化：一分钟内的第三次调用，或批量任务中的第一百个请求。

对于 GLM-5、DeepSeek 和 GPT-5，我寻找的是一种不张扬的胜任感：不会在错误的时候让我惊讶的模型。我也记录了每个模型的弱点，因为围绕已知弱点进行设计，比围绕营销承诺进行设计要容易得多。

推理速度（TTFT + 吞吐量）

我关注两个时刻：第一个 token 何时出现，以及后续内容跟进的速度。

TTFT：这告诉我模型是在积极响应，还是让我干等。在交互式工具（起草文案、客服对话）中，快速的 TTFT 感觉像是一种体贴。
吞吐量：一旦开始，它能否在长输出时保持稳定的节奏而不出现卡顿？

我在实践中观察到的（2026 年 2 月，混合美区/欧区端点）：

GLM-5：在短提示词上 TTFT 始终很快。在长上下文（超过约 30–40k token）下，启动稍慢，但流式传输平稳。起草文案和编辑代码时给人一种”无波澜”的好感。如果你想要具体数字和并排的延迟数据，我发现这篇 GLM-5 推理速度基准测试分析很有参考价值。
DeepSeek（尤其是 R1/V3 变体）：TTFT 出人意料地快，即使在轻度批量负载下也是如此。在非常长的生成任务中，偶尔会出现流式传输的微停顿，但恢复很顺畅。
GPT-5：在某些端点上启动比预期慢，但随后以非常稳定的流式传输弥补了这一点。在涉及工具调用时，切换开销很低，这对多步骤流程很有帮助。

我反复提醒自己的一点：地区和网关的影响和原始模型本身一样大。如果你通过聚合器路由请求，请开启流式传输，并在探索性运行时适当降低 max_tokens。这能减少空转时间，同时不影响质量。

每百万 token 的成本

定价表只是起点，不是你最终付的账单。以下三个杠杆对我实际成本的影响，超出了我的预期：

上下文浪费：每次调用都发送相同的系统前言和工具 schema 会不断累积。通过缓存或精简 schema，很快就能看到回报。
重试策略：在繁忙时段，一次激进的限流重试可能悄悄让花费翻倍。
输出长度管控：将 max_tokens 设置为一个合理的上限（并让模型在函数调用时停止），比任何折扣码都更有效。

截至本月：

DeepSeek 一直在推进激进的定价策略，尤其是推理变体。它对批量工作流很友好，但前提是你要留意其输出风格偶尔的波动。
GLM-5 处于一个务实的中间位置。不是最便宜的，但可预测，而当财务部门要求预测时，可预测性本身就有价值。
GPT-5 的定价在公开层面仍处于变动之中。实践中，我以 GPT-4.1/4o 的价格范围作为下限来估算预算，并为 GPT-5 的推理层级预留了余量。如果你今天需要一个确定的成本上限，这是最需要压力测试的那个。

如果你要进行同类比较，请衡量”每有效输出的实际成本”，而不是 token 数。一个贵 1.2 倍但能将修改次数减半的模型，在我看来是赢家。

推理与代码质量

我没有跑排行榜。我跑的是我实际在做的工作：结构化写作、小型代码工具和多工具智能体流程。两个维度最为重要。

单任务准确性

在专注任务上（例如，“把这段 JSON 转换成类型化接口”，“提炼这些会议记录并列出行动项”），GPT-5 感觉是最完善的。它需要更少的引导才能遵循严格的格式，函数调用也更可靠地保持在 schema 范围内。

DeepSeek 在能够逐步展开的推理任务上表现良好。我注意到它有轻微的过度阐述倾向，这对起草来说没问题，但对严格的输出来说不够理想——除非我限制 max_tokens 并明确要求简洁。 GLM-5 落在一个平静的中间位置：少一些花哨，遵从性稳定，在差异较小时代码编辑也很扎实。在使用模糊提示词冷启动时，它有时比我期望的更保守，但收紧系统提示词后就解决了。

多步骤智能体可靠性

当工具进入场景——搜索、爬取、数据库读取——问题就从”答案好不好”变成了”循环能否存活？”

GPT-5：擅长规划短链路，并在工具超时时恢复。它会重新请求缺失的字段，而不是胡乱猜测。小事一桩，却大大保护了理智。
DeepSeek：链路紧凑高效。偶尔在两个工具能力重叠时会自信地走错方向。在系统提示词中添加明确的工具选择规则有所帮助。
GLM-5：在 schema 定义良好时非常稳定。如果工具返回了意外的数据结构，它会选择谨慎并请求澄清。相比无声的幻觉，我更喜欢这种方式。

这一开始并没有节省我的时间——事实上，构建这些护栏又花了一个下午——但经过几次运行后，我注意到它减少了心理负担。更少的神秘故障，更少的”它为什么这么做？“时刻。

按工作负载类型匹配最佳模型

这不是一个加冕仪式，而是一个匹配练习。以下是这周每个模型最适合的场景。

实时应用 → ?

如果屏幕另一端有人在等待，我偏向于快速 TTFT 和可预测的风格。

轻量对话、起草、客服侧边栏：GLM-5 或 DeepSeek。两者都感觉灵活。DeepSeek 首 token 速度略快；GLM-5 在会话中往往能保持一致的语气。
重度工具助手：GPT-5。其规划能力和 schema 稳定性减少了边缘情况下的卡顿。如果预算紧张，先用 DeepSeek 做原型，再在最关键的端点换成 GPT-5。

批量处理 → ?

对于大型离线任务（数百到数千条项目）：

如果你能容忍小幅度的风格漂移，DeepSeek 在成本效率上胜出。添加严格的输出 schema 和差异检查。
当你更在意减少异常值，并愿意为统一性多付一点时，GLM-5 是稳健的默认选择。
GPT-5 是过杀，除非任务确实需要更深度的推理或每条项目的多跳检索。当真的需要时，重跑率下降足以证明其合理性。

多模态流水线 → ?

对于图像+文本或音频+文本的流程，连接部分比宣传册更重要。

GPT-5：在我的测试中，模态与工具之间的切换最为顺畅。如果你的流水线在提取、推理和生成之间跳转，这种顺畅度会带来实际收益。
DeepSeek：快速且胜任。对于 OCR + 摘要或图注 + 标签，它保持了较低的延迟。
GLM-5：在结构化图像转文本任务上可靠。如果一致性胜过创意（想想发票解析或产品数据清洗），我会首先选择它。

一个设计提示：将中间结果流式传输到你的日志中。这是在上线前发现模态不匹配问题的最简单方法。

WaveSpeed 跨三款模型的定价比较

我尝试将 WaveSpeed 作为一个定价理性层——不是银弹，只是一种更冷静地思考花销的方式。

突出的不是魔法折扣，而是其运作机制：

固定路由：将 GPT-5 绑定到需要其规划能力的端点，将直接摘要任务发给 DeepSeek，将结构化编辑保留给 GLM-5。一张账单，更少的意外。
上下文缓存：系统提示词和工具 schema 不会在每次调用时重新发送。在我的测试中，这平均将输入 token 减少了三分之一。不够光鲜，但这种节省日积月累。
边缘护栏：如果模型偏离了 schema，WaveSpeed 会提前捕获并向同一供应商重试。任务进行中不会出现供应商轮盘赌。

价格方面，比较很简单：