10 月底发生的事
10 月 27 日，Latent Space 放出一档 107 分钟的节目，嘉宾是 Anthropic 平台工程负责人 Katelyn Lesse 和平台产品负责人 Angela Jiang，主题很直接：他们是怎么把 Claude 的 Messages API 整体搬进 Rust 的。
节目中被反复引用的一句话是："as of last week we fully rolled out the messages API written in Rust"。以 10 月 27 日录制时间倒推，全量上线发生在 10 月 19 日到 26 日那一周。
两个数字也出自节目：CPU 用量下降 40% 到 50%，首 token 延迟（TTFT）改善 10% 到 20%。嘉宾自己给出的定性是 ballpark，也就是口头估计，并不是基准测试的结论。
被替换的是 Messages API 原本的 Python 单体。嘉宾的原话是 "very CPU inefficient"。新代码的主体由 Claude 完成，人负责系统设计和验证。如果你日常也在接 Claude 这类大模型 API，RouteFast.ai 这类模型 API 中转可以当作多模型接入的备选方案。
事件迅速传遍整个行业，但 Anthropic 官方账号至今没有确认过任何一个数字。
他们怎么做的
最反直觉的一点：不是分模块慢慢迁，而是整体一次性移植。
嘉宾的原话说得很直白：分块迁移 "easily a multi-year effort"（轻轻松松就是好几年）。他们的做法是把整个 API 在 Rust 里 fork 一份，然后 "slowly turn it on"，灰度切流。
验证手段是影子流量。Rust 版本上线后不直接承接生产请求，而是和 Python 版本并行跑同一份流量，逐个 diff 两边的输出。嘉宾原话："we literally built an entire fork of the entire API in Rust, and then started running shadow traffic through it and verifying that the outputs"。
切流依靠 feature flag 加负载均衡，开关式的。
另一个纪律是纯移植。嘉宾明确说 "We resisted the urge to add features"——移植期间不给 Rust 版加任何新功能，防止两边行为漂移。执行移植的是一个小型专职团队（嘉宾称为 "little SWAT team"，人数没有公布），其他团队继续在 Python 侧迭代功能，SWAT 团队负责对新增代码做静态分析。嘉宾形容他们的态度："They would yell at you because you built a feature over here and you didn't consider Rust over there"。
团队起点是零 Rust 工程师。原话是："We don't have a single Rust developer in the room."推进过程中 "hired a couple of people who have more experience with Rust"，补进来两位有经验的 Rust 开发。
分工上，嘉宾把整个项目拆成 plan、implementation、verification 三段：计划怎么做、谁写代码、怎么确认写对了。原话简洁明了："Claude is gonna write the code. The humans design the system."
AI 写代码当然是话题，但真正让这次换栈站得住的，是影子流量加 diff 验证加开关切流这套机制——这套方法论不依赖 AI，哪怕十年前想整体迁移一个 API，照样能用。
40 到 50% 到底意味着什么
先说数字本身。CPU 那组数字的原话是：主持人问 "order of magnitude of savings on the CPU side"，嘉宾答 "ballpark. I guess I would say, like, we've saved somewhere like 40 to 50%"。没有方法学，没有负载构成，没有前后对比数据，也没有测试时长。
TTFT 那组是 "somewhere between 10 and 20%"，特指 time to first token，嘉宾还补充了一句：长时运行的负载上改善更大。这个数字属于 API 服务层，不含模型生成速度本身——推理时长的优化另算。
再说为什么他们死磕 CPU。嘉宾的原话："CPU for Anthropic as a whole is a zero-sum game"——Anthropic 和云厂商谈的是固定 CPU 配额，内部要在研究沙箱和产品沙箱之间做容量规划。CPU 省下来的部分，就是能多服务的那部分。所以省 40% 到 50% CPU，对他们来说是直接的生产力，不是工程炫技。
数字的可信度边界需要写清楚：截至 11 月 3 日，Anthropic 的工程博客和 changelog 没有发布过任何重复这些数字的内容。九家二手报道的数字全部溯源到同一档节目，没有一家给出独立实测。在这些数字被官方基准坐实之前，它们的准确说法是「官方自报、未独立复现」。
Rust 生态同一周在做什么
同一个季度还有一件并列的事：10 月 1 日，Rust 1.99.0 稳定了 C 兼容变参函数。官方博客原文是："Rust could already call externally-defined variadic functions (e.g., libc::printf). With Rust 1.99, these functions can now be written in Rust itself."
过去 Rust 只能调用 C 的变参函数，不能定义。1.99 把这条补齐，... 的类型是 VaList，跨目标与 C 的 va_list ABI 兼容。
语言侧在补 C 互操作的最后一块短板，业务侧把 LLM 公司的核心服务层往 Rust 上搬，两个日期差 26 天。这是并列事实，不构成因果。
放在 Rust 的基建位置来看：2026 年，Rust 已经从「系统语言候选」变成大厂服务层的实际选项。而这次换栈的门槛，已经不在语言本身，而在验证方法学。
三个不能过满的地方
数字层面：40 到 50% 和 10 到 20% 都是播客口头 ballpark，官方未发基准，独立复现查无。
归因层面：节目文字稿是自动转写、无说话人标签，Rust 段落归属到 Lesse 是二手源的推断。嘉宾回忆「一年前加入时 Messages API 是 Python 单体、跑在单个 GCP 区」，两家中英文报道对这句话的归属说法不一致，成稿只能写「两位嘉宾之一回忆」。
范围层面：这次是纯移植。嘉宾明确下一步才是重架构——服务端保存会话状态，调用方不再来回传全量历史。重架构的时间表未公布。
FAQ
Claude 写代码，人完全不碰吗？
不。人做系统设计、写 plan、定验证方法，Claude 做实现。嘉宾原话把写码和系统设计分得很开："Claude is gonna write the code. The humans design the system."
为什么选 Rust，不是 Go？
节目里嘉宾的原话只有一句："choosing Rust was a crazy decision at the time"，理由是 CPU 效率。完整的选型过程，官方没有展开。
影子流量怎么保证正确？
Rust 版不直接接生产，和 Python 版并行跑同一份流量，diff 两边输出。开关用 feature flag 加负载均衡灰度；移植期间纯移植不加功能，专职团队对 Python 侧新增代码做静态分析，防止行为漂移。
40 到 50% 这个数字可信吗？
九家二手源数字完全一致，但全部溯源到同一档播客，没有独立实测。准确表述是「官方自报、未独立复现」，在官方发布基准之前，别当成已证实的性能数据。
普通团队能抄什么？
能抄的是方法论：整体 fork、影子流量 diff、开关切流、纯移植纪律。这套和 AI 无关。抄不了的是让 Claude 直接写整个生产服务的实现——那依赖你手上的模型能力和验证基建。
资料出处
Latent Space 节目页与官方文字稿：https://latent.space/p/how_anthropic_ships_the_1_llm_in_the_world_safely_separating_the_brain_from_the_hands/
Rust 1.99.0 官方公告：https://blog.rust-lang.org/2026/10/01/Rust-1.99.0
交叉核验的九家二手源（CellCog、InfoQ 中文、Cocoloop、explainx、lilithai 等）数字全部一致，均溯源至该节目；截至 2026-11-03，Anthropic 官方博客与 changelog 未重复过这些数字。
如果你对 Rust 服务端实践或 API 迁移有想法，欢迎到云栈社区聊聊。
发表于 前天 17:03
|
查看: 1|
回复: 0
/1 
