他们花了两周优化代码、加缓存、调参数。延迟降了30%。但跟竞争对手比——还是慢了2倍。

最后CTO拍板：用Rust重写。三个工程师，六周。

新版本的延迟只有原来的八分之一。显存占用降低了40%。上线到现在跑了10个月，没出过一次内存相关的bug。

这个故事在AI Infra圈子不是什么秘密。几乎所有走到一定规模的团队，都会撞上同一堵墙——Python撑不住了。

今天不是说Python不好。Python是AI领域当之无愧的第一语言。PyTorch、vLLM、HuggingFace、LangChain——整个AI生态长在Python上。

问题不是Python不好——是它在你需要极致性能的时候，给不了你。

相同的任务，Rust的执行耗时是Python的5%到15%。差距最大的在HTTP路由和显存管理。这不是微优化——是数量级的差距。

Python的罪不是慢——是GIL

很多人说Python慢是因为它是解释型语言。这话只说对了一半。

真正的罪魁祸首是GIL（全局解释器锁）。GIL保证同一时刻只有一个线程在执行Python字节码。这意味着你用Python写再多线程代码——本质上还是单核在执行。

在推理服务中，这意味着什么？

你用一个Python线程处理请求的时候，其他9个线程在旁边等着。你的GPU计算是并行的——但你的CPU调度是串行的。两者之间的不匹配造成了大量的等待和缓冲区膨胀。

Rust没有这个问题。它的所有权系统和零成本抽象让你写出安全且并行的代码。没有GC暂停，没有GIL锁——你写的代码就是机器执行的代码。

问题不在慢——在什么时候开始慢

团队早期用Python完全正确。因为早期最大的瓶颈不是性能——是验证方向对不对。

Python和Rust在开发周期上的侧重点完全不同。Python在前期快，Rust在后期稳。

但是在某个时间点——也许是日均请求量超过10万，也许是模型参数量超过70B，也许是你开始做毫秒级的延迟优化——你会发现Python的边界到了。

这个时间点，每个团队都会遇到。区别只在于你提前准备了，还是到了才手忙脚乱。

怎么选：一张表讲清楚

蓝色=Python优势区，红色=Rust优势区。分界线以上的场景两种都可以，分界线以下有明确优势方。

一个简单的判断标准：

• 快速原型/POC验证→ Python。别犹豫。用Rust做原型等于用挖掘机挖花盆。
• 数据预处理/ETL→ Python。Pandas和Ray的生态无可替代。
• 推理服务/高并发→ Rust+Python混合。Python调PyTorch做推理计算，Rust处理HTTP路由和请求调度。vLLM就是这么做的——核心调度用C++/Rust，上层API用Python。
• 框架核心/调度引擎→ Rust。这是纯性能敏感路径，Python在这里没有位置。
• CLI工具/Agent→ Rust。单二进制部署、跨平台、启动快。用户体验和性能都好得多。
• 监控/指标采集→ Rust或Go。Prometheus Exporter这类高频低延迟任务不适合Python。