AI 基础设施的"去 Python 化"：Rust 与 C# 的两条替代路径

image

一、一个数字引发的思考：0.05ms

上周，LiteLLM 发布了一篇技术博客，宣布正在用 Rust 重写核心网关。

数字很震撼：

image

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 继续运行

image

路由按风险排序迁移：先迁最简单的 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 极致，但足够好

C# 的 GC 虽然存在，但 .NET 8/10 的 Server GC 已大幅优化，对大多数企业 API 场景不是瓶颈。更重要的是：

• 依赖注入、中间件管道、OpenAPI 集成、身份认证——这些在 .NET 里是一行配置的事，在 Rust 里需要手动组装
• 观测性、合规、治理、Azure 生态集成——这些是企业级刚需，Rust 生态目前欠缺
• .NET 开发者可以直接上手，学习曲线远低于 Rust

3.4 关键差异：Rust 是"管道工"，C# 是"建筑师"

image

四、两条路径的交汇点：AI 基础设施正在分层重构

过去十年，AI 领域发生过两次基础设施迁移：

1. 从 CPU 到 GPU：训练模型跑不动了，GPU 接管了计算层
2. 从单机到分布式：模型太大了，分布式训练和推理成了标配

现在正在发生第三次：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 留在阁楼（训练/原型/插件）。这是架构成熟阶段。

image

六、对技术选型的启示

如果你在做 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# 中做本地推理，减少跨语言调用

image

七、写在最后

LiteLLM 的 0.05ms 和 31.7MB 不是一个孤立的数据点，它是一个信号：当 AI 从实验走向生产，它脚下的地板得换材料了。

Python/TypeScript 搭了脚手架，Rust 浇了地基，C# 盖了楼。

三条路径不是互斥，而是分层协作：

• Rust 负责最底层的、性能敏感的管道
• C#/.NET 负责企业级的、生态完整的应用栈
• Python 负责模型训练、数据科学、快速原型——它擅长的层

未来的 AI 基础设施，不是"谁替代谁"的单选题，而是"谁该在哪一层"的分层架构。认清每一层的核心矛盾，选择最合适的材料，才是工程的本质。

image

参考链接

• 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/