AI 基础设施的"去 Python 化"：Rust 与 C# 的两条替代路径
一、一个数字引发的思考：0.05ms
上周，LiteLLM 发布了一篇技术博客，宣布正在用 Rust 重写核心网关。
数字很震撼：
| 指标 | Python 版 | Rust 版 | 差距 |
|---|---|---|---|
| 每请求延迟 | ~7.5ms | ~0.05ms | 150 倍 |
| 吞吐量（50 并发） | 453 req/s | 6,782 req/s | 15 倍 |
| 峰值内存 | 358.9MB | 31.7MB | 11 倍 |
0.05ms 意味着什么？网关本身的开销基本消失了。你的请求从进来再到转发给上游 LLM，中间只花了 50 微秒。瓶颈完全在 LLM 那边，不在网关这里。
31.7MB 意味着什么？一个吃 32MB 的进程，你根本注意不到它在跑。部署到生产环境，每个 pod 都省几百 MB，跨区域、跨副本一乘，云账单差异巨大。
但如果我们只看 LiteLLM 这一个案例，会误以为"这只是某家公司的性能优化"。把时间线拉长，你会发现一个更底层的趋势：AI 基础设施正在分层重构，Python 正在被系统性替代。
二、Rust 的替代逻辑：Python 运行时层的"性能替代"
2.1 为什么管道层必须 Rust 化？
AI 工具链里有一类组件不做模型推理，但负责把数据搬到正确的地方——路由、转发、检索、格式化、持久化。这些活的共同特征：高频、低延迟、内存敏感、长期稳定运行。
而 Python 在这些场景下有几个结构性问题：
第一，GIL（全局解释器锁）。Python 的多线程在高并发 I/O 场景下基本是摆设。AI Gateway 是什么？就是高并发 I/O——同时几百个请求进来，每个都要转发给不同的 LLM 提供商。GIL 让 Python 先天吃亏。
第二，内存不可控。引用计数 + 垃圾回收，长时间运行的服务内存会慢慢涨，涨到 OOM kill。LiteLLM 的原话："Python proxy's memory consumption multiplies across every pod, region, and retry, causing OOM kills at critical moments."——最关键的时候它崩了。
第三，部署体积。Python 服务需要解释器、依赖、虚拟环境。Rust 编译出来就是一个二进制文件，扔上去就能跑。
2.2 这不是个案，是趋势
如果你关注 AI 基础设施的演进，会发现 Rust 已经渗透到了各个管道层：
- 终端 Agent 层：Claude Code 的 harness 生态里，CodeWhale、oh-my-pi 都是 Rust 写的
- 记忆引擎层：AgentMemory 核心检索路径用 Rust 优化，全文检索从百毫秒级降到个位数毫秒
- AI Gateway 层：LiteLLM 正在 Rust 化，此前还有多个开源网关项目已经迁移
这些项目的共同点：它们都是 AI 工具链里的"管道"。Rust 的所有权系统在编译期就干掉了数据竞争和内存泄漏，没有 GC，内存分配是确定性的，编译产物是单二进制文件——这些设计目标恰好命中了 AI 管道层的核心矛盾。
2.3 LiteLLM 的迁移策略：最值得学的不是技术，是节奏
LiteLLM 没有一夜重写。它分了四个阶段，每个阶段都能独立上线、拿到收益：
Stage 0：纯 Python（FastAPI）—— 当前状态
Stage 1：Rust 核心 + Python I/O
Rust 负责数据转换（请求/响应/流式块/token 计数）
Python 仍然负责网络、数据库、认证
通过 PyO3 桥接
Stage 2：FastAPI 变成薄壳
认证、限流、回调还在 Python
整个转发路径变成一次 Rust 调用
Stage 3：纯 Rust 服务器（axum/hyper）
Python 彻底退出热路径
用户的 Python 插件通过可选 sidecar 继续运行
路由按风险排序迁移：先迁最简单的 OCR，再迁 /v1/messages（加流式复杂度），最后迁 /chat/completions（最大表面积：工具调用、多模态）。每条路由迁移前过"一致性检查"——Rust 版本输出必须和 Python 版本完全一致才能激活。
这不是技术决策，是工程决策。技术上用 Rust 重写不难，难的是怎么在生产环境里一步步替换，不翻车。时间表：半年，四步走。
2.4 但 Rust 不是银弹
150 倍这个数字需要看测试条件——LiteLLM 的 benchmark 用的是 mock upstream（模拟上游 LLM），只测网关本身转发性能。在真实场景下，你的瓶颈在 LLM 那边（动辄几秒），网关从 7.5ms 降到 0.05ms 的体感差异没有 150 倍那么夸张。它解决的是"网关自身不成为瓶颈"和"内存不爆炸"。
Rust 的开发成本也是真实的。学习曲线、编译时间、类型系统的严格程度，都意味着开发速度会比 Python 慢。LiteLLM 能推进这个迁移，说明团队已有足够的 Rust 能力——不是每个团队都能做这件事。
最终形态里，用户的 Python 插件仍然通过 sidecar 运行。这暗示了一个事实：Python 在 AI 生态里的位置短时间内不会被 Rust 取代，它会被"推到它擅长的层"——运行时归 Rust，用户自定义逻辑和快速原型归 Python。这个分工比"全 Rust"更健康。
三、C#/.NET 的替代逻辑：企业 AI 全栈的"生态替代"
如果说 Rust 是在"管道层"与 Python 正面竞争性能，C#/.NET 走的是另一条更隐蔽的路——让企业级 AI 应用彻底不需要 Python。
3.1 推理层：原地替代，无需桥接
.NET 10 引入原生 ONNX 支持，ML.NET 作为本地推理引擎，让 C# 应用可以直接运行模型推理。对于企业业务场景（分类、异常检测、推荐），这消除了"Python 做模型、C# 做业务"的架构割裂。
你不需要一个 Python 微服务来做推理，C# 应用自己就能跑。
3.2 编排层：Microsoft Agent Framework 的原生 C# 生态
2025 年 10 月，Microsoft 将 Semantic Kernel 和 AutoGen 合并为统一的 Microsoft Agent Framework。这不是简单的 SDK 更新，而是一个战略信号：
- C# 是最成熟的 SDK 语言（Python/Java 次之）
- 与 Azure OpenAI、Ollama 等提供商深度集成
- 与 .NET Aspire 的云原生 AI 部署能力打通
- 内置 Agent Governance Toolkit（运行时安全层，亚毫秒级策略执行）
这意味着：在 .NET 企业生态中，AI Agent 的编排、规划、记忆、工具调用全部可以用 C# 原生完成。不需要引入 Python 技术栈，不需要维护两套语言环境，不需要在 C# 和 Python 之间做序列化/反序列化的性能损耗。
3.3 性能：不如 Rust 极致，但足够好
| 维度 | Rust (Axum) | ASP.NET Core | Python (FastAPI) |
|---|---|---|---|
| 吞吐量 | ~500k req/s | ~150-300k req/s | ~10-20k req/s |
| 内存占用 | 5-30MB | 50-200MB | 200-500MB |
| 启动时间 | 毫秒级 | 秒级（JIT） | 秒级（解释器） |
| 开发效率 | 低（所有权系统） | 高（成熟生态） | 极高（动态类型） |
C# 的 GC 虽然存在，但 .NET 8/10 的 Server GC 已大幅优化，对大多数企业 API 场景不是瓶颈。更重要的是：
- 依赖注入、中间件管道、OpenAPI 集成、身份认证——这些在 .NET 里是一行配置的事，在 Rust 里需要手动组装
- 观测性、合规、治理、Azure 生态集成——这些是企业级刚需，Rust 生态目前欠缺
- .NET 开发者可以直接上手，学习曲线远低于 Rust
3.4 关键差异：Rust 是"管道工"，C# 是"建筑师"
| 维度 | Rust | C#/.NET |
|---|---|---|
| 替代 Python 的层面 | 运行时基础设施（网关、路由、代理） | 企业应用全栈（推理+编排+业务） |
| 核心优势 | 极致性能、内存确定性、无 GC | 开发效率、企业生态、Azure 集成 |
| 与 Python 的关系 | Python 退居"插件层"（Sidecar） | Python 可能根本不出现在架构中 |
| 适用场景 | 高并发 I/O、边缘计算、Serverless | 企业业务系统、Azure 云原生、合规场景 |
| 学习曲线 | 陡峭（所有权系统） | 平缓（.NET 开发者可直接上手） |
| 部署形态 | 单二进制，<10MB | 运行时依赖，但容器化/云原生支持成熟 |
四、两条路径的交汇点：AI 基础设施正在分层重构
过去十年，AI 领域发生过两次基础设施迁移：
- 从 CPU 到 GPU：训练模型跑不动了，GPU 接管了计算层
- 从单机到分布式：模型太大了，分布式训练和推理成了标配
现在正在发生第三次：AI 工具链的运行时，正在从 Python 向 Rust 和 C# 分层迁移。
但不是 Python 不行了，而是 AI 的规模上来了之后，Python 作为"全能胶水"的物理极限到了。就像 JavaScript 在浏览器端的物理极限到了之后，WebAssembly 出现了——不是因为 JS 不好，是因为场景变了。
Rust 抢的是"运行时管道"：网关、路由、代理、记忆引擎、知识图谱检索——这些高频、低延迟、内存敏感的组件，Python 的 GIL 和 GC 是结构性瓶颈。
C# 抢的是"企业应用栈"：在 .NET/Azure 生态中，Microsoft Agent Framework 提供了完整的 AI 能力，企业不需要为了 AI 引入 Python 技术栈，避免了架构割裂和运维复杂度。
Python 不会消失，但它的角色正在被重新定义——从"AI 基础设施的默认选择"变成"特定层的选择"：模型训练、数据科学、快速原型、用户自定义插件。
五、Python 角色演变：从"全屏"到"一角"
这个演变不是"消灭 Python"，而是让每一层用对材料。
- AI 1.0（2015-2020）：Python 是唯一的胶水，训练、推理、部署、工具链全部用它写。这是实验阶段，快速迭代比性能重要。
- AI 2.0（2020-2025）：规模上来了，Python 的物理极限暴露。Rust 进入管道层，C# 进入应用层，Python 退守训练层。这是生产过渡阶段。
- AI 3.0（2025-2030）：分层专业化成熟。Rust 浇地基（管道），C# 盖楼（应用），Python 留在阁楼（训练/原型/插件）。这是架构成熟阶段。
六、对技术选型的启示
如果你在做 AI Gateway / 代理层 / 记忆引擎
- 优先考虑 Rust：如果极致性能、内存确定性、长期稳定运行是核心诉求，Rust 是事实标准
- 参考 LiteLLM 的四阶段迁移：不要一夜重写，分阶段替换，每阶段都能独立上线
- 保留 Python Sidecar：用户自定义逻辑和快速原型仍用 Python，不要追求"纯 Rust"的虚荣
如果你在做企业级 AI 应用 / Agent 平台
- 优先考虑 C#/.NET：如果已经在 .NET 生态中，Microsoft Agent Framework 提供了完整的 AI 能力，无需引入 Python
- 利用 .NET 10 的 NativeAOT：如果确实需要极致启动性能，NativeAOT 可以生成接近原生的二进制，减少启动时间和体积
- 关注 Azure 集成：.NET + Azure OpenAI + .NET Aspire 是一套完整的云原生 AI 部署方案
如果你在做混合架构（如 OpenClaw.NET 的 MetaSkill 系统）
- 网关层：考虑 Rust 组件或 C# NativeAOT，追求极致性能
- 编排层：C#/.NET 的企业级生态（Agent Framework、Semantic Kernel）更实用
- 模型层：Python 仍是最优选择，但通过 ONNX/ML.NET 可以在 C# 中做本地推理，减少跨语言调用
七、写在最后
LiteLLM 的 0.05ms 和 31.7MB 不是一个孤立的数据点，它是一个信号：当 AI 从实验走向生产，它脚下的地板得换材料了。
Python/TypeScript 搭了脚手架，Rust 浇了地基，C# 盖了楼。
三条路径不是互斥，而是分层协作：
- Rust 负责最底层的、性能敏感的管道
- C#/.NET 负责企业级的、生态完整的应用栈
- Python 负责模型训练、数据科学、快速原型——它擅长的层
未来的 AI 基础设施，不是"谁替代谁"的单选题，而是"谁该在哪一层"的分层架构。认清每一层的核心矛盾，选择最合适的材料，才是工程的本质。
参考链接
- LiteLLM Rust 迁移博客：https://docs.litellm.ai/blog/litellm-rust-launch
- Microsoft Agent Framework：https://devblogs.microsoft.com/agent-framework/
- .NET 10 AI 新特性：https://learn.microsoft.com/en-us/dotnet/ai/whats-new
- Semantic Kernel 合并公告：https://devblogs.microsoft.com/semantic-kernel/semantic-kernel-and-autogen-join-forces/
欢迎大家扫描下面二维码成为我的客户，扶你上云
浙公网安备 33010602011771号