实测 Claude Sonnet 5 vs Claude Sonnet 4.6:别只看发布公告,API 跑起来才知道差距

实测 Claude Sonnet 5 vs Claude Sonnet 4.6:别只看发布公告,API 跑起来才知道差距

先说结论:

  • 这两个模型都能通过 Crazyrouter 的 OpenAI-compatible 接口正常调用。
  • 这组测试里,Claude Sonnet 5 的延迟明显更低,整体更适合做默认候选。
  • Claude Sonnet 4.6 也能用,但延迟波动大,部分请求慢到 100 秒以上。
  • 如果你要上生产,不能只看“模型发布了”,一定要自己跑 API、看延迟、看格式、看稳定性。

这篇不是官方 benchmark,也不是纯理论分析。它更像一个开发者接新模型前会做的真实探活测试。

一、测试环境

接口:

POST https://crazyrouter.com/v1/chat/completions

测试模型:

claude-sonnet-5 claude-sonnet-4-6

测试内容一共 6 类,每类跑 2 次,总计 24 个请求:

  1. 工程推理
  2. 代码调试
  3. 严格 JSON 输出
  4. 中文写作
  5. 长文本总结
  6. 产品判断

参数设置都比较常规,没有刻意压榨模型,基本就是线上开发者会用到的那种调用方式。

二、总体结果

模型请求数成功数错误数成功率平均延迟中位延迟最快最慢近似 p95
claude-sonnet-512120100%13.10s12.63s10.32s18.88s14.64s
claude-sonnet-4-612120100%46.14s42.91s12.15s105.29s78.76s

一句话:

  • Sonnet 5:更快、更稳。
  • Sonnet 4.6:能用,但慢得不太适合直接做默认模型。

三、分任务结果

任务Sonnet 5 平均延迟Sonnet 4.6 平均延迟
工程推理14.60s29.99s
代码调试12.56s77.11s
严格 JSON13.35s72.04s
中文写作14.25s37.12s
长文本总结10.86s17.68s
产品判断12.96s42.91s

这里最夸张的是两个场景:

  • 代码调试
  • 严格 JSON 输出

Sonnet 5 基本都在 10 到 15 秒内结束。
Sonnet 4.6 不仅慢,而且波动大,最长直接到 105 秒。

如果你做的是网页产品、聊天产品、客服助手,这种延迟差距用户会非常敏感。

四、几个具体观察

1)工程推理:Sonnet 5 更克制

在 AI Gateway 路由策略任务里,Sonnet 5 的建议更像工程决策,关注点更集中:

  • p95 延迟
  • 错误率
  • 成本
  • 上下文窗口
  • 冷却时间

Sonnet 4.6 也能答对,但更容易展开,篇幅更长。

2)代码调试:两个都能抓到关键问题

这段代码的核心 bug 是并发保护不够:

  • self.calls没有锁
  • 检查和写入不是原子操作
  • await asyncio.sleep()后没有重新检查窗口
  • 多个 coroutine 并发时会突破限流

Sonnet 5 的回答更直接,先定位 race condition,再给修正版。

Sonnet 4.6 也能指出问题,但耗时更长,回答更啰嗦。

3)严格 JSON:两者都不算完美

我在 system prompt 里明确要求:

Return only valid JSON. No markdown.

但实际结果是:

  • Sonnet 5 第一次没有直接吐 JSON,而是先解释原因
  • Sonnet 4.6 返回了 JSON 内容,但外面包着 markdown code fence

这说明一个很现实的问题:

如果你真的依赖 JSON 输出,不要只靠 prompt。

生产环境最好加上:

  • JSON schema 校验
  • 服务端 parse 校验
  • 失败重试
  • 对 code fence 做清洗

4)中文写作:Sonnet 5 更适合直接发

中文写作任务是解释:

为什么不能只看模型发布公告,必须实际跑 API。

Sonnet 5 的表达更像一篇可以直接发的回答,结构更清楚,语气更自然。
Sonnet 4.6 的内容更像草稿素材,信息量更足,但也更长。

五、一个容易踩坑的点

这次测试里有一个非常关键的现象:

gpt-5-nano虽然返回了 HTTP 200,但 visible content 为空。

这说明:

  • HTTP 200 不等于业务成功
  • 模型可调用,不代表输出可直接用
  • 上线前必须检查 finish_reason、内容是否为空、结构是否符合预期

这点对所有模型切换都适用,不只是 Claude。

六、如果要上线,我会怎么做

如果我是产品负责人,我不会一把切 100%,而是这样做:

  1. 先让内部用户和高频开发者试用
  2. 对 5% 到 10% 的普通请求做 canary
  3. 监控 p50、p95、错误率、重试率、JSON 失败率
  4. 如果 p95 连续异常,自动回滚
  5. 对强格式依赖的场景,先 opt-in,不要默认替换

七、给开发者的建议

每次新模型上线,至少测这几项:

  • 能不能调通
  • 延迟分布怎么样
  • 输出会不会被截断
  • JSON / tool call 稳不稳
  • 能不能跑真实业务 prompt
  • 成本是不是可接受

官网公告只能告诉你“模型发布了”。
API 实测才能告诉你“你的业务里它到底能不能用”。

八、总结

这次通过 Crazyrouter 实测claude-sonnet-5claude-sonnet-4-6,结论很明确:

  • 两个模型都能正常调用,24 次请求 0 错误
  • Sonnet 5 延迟明显更低,平均 13.10s
  • Sonnet 4.6 平均 46.14s,波动偏大
  • Sonnet 5 更适合做默认候选
  • JSON 输出不能只靠 prompt,工程层必须兜底

如果你只是体验新模型,Sonnet 5 可以直接试。
如果你要上生产,先跑自己的真实业务测试,再决定是否切换。

模型发布是新闻,模型可用性是工程事实。
这两者之间,最好隔一层自己的测试脚本。