一、一个数字引发的思考：0.05ms
上一周, 有一篇技术方面的博客被发布出来了, 其宣称正在运用Rust来重新编写核心网关。
数字很震撼：
0.05ms究竟意味着什么, 网关自身的开销基本上是消失不见了。你的请求从进入之后再到被转发给上游的LLM, 中间仅仅花费了50微秒。瓶颈完全是在LLM那一边, 而不是在网关这个地方。
31.7MB究竟意味着什么呢? 存在一个吃32MB的进程, 只是那进程以你的察觉来看并无明显运行迹象。当将其部署到生产环境时候, 每个pod各自能省下几百MB, 要是跨区域、跨副本相乘之后, 云账单的差异将会变得极为巨大。
然而要是我们仅仅瞧这单独的案例, 那就会造成误判, 觉得"这不过是某一家公司针对性能进行的优化"。当将时间线予以拉长之时, 你就会所发现的是一个更深层次的趋向: AI基础设施正处于分层重新构建状态, 并且正遭受到系统性的替换。
二、Rust的替换逻辑, 运行时层面的"性能替换", 2.1, 管道层为何一定要被Rust化呢?
在AI工具链之中, 存在着这样一类组件, 它们并不进行模型推理, 然而却承担着将数据搬运至正确位置的职责, 具体而言, 这些职责包括路由、转发、检索、格式化以及持久化。这些工作所具备的共同特性为: 高频、低延迟、内存敏感、能够长期稳定运行。
而 在这些场景下有几个结构性问题：
第一, 存在这所谓的GIL, 也就是全局解释器锁。其多线程在那种高并发I/O的场景之中, 大抵只是形同虚设的存在。那AI究竟是什么东西呢? 它就是处于高并发Ｉ/Ｏ的景象, 也就是在同一时刻会面临几百个请求一同到来, 并且每个请求都得转交给各不相同的LLM提供商。而GIL使得其从一开始就处于不利的局面。
其二, 内存无法受控, 采用引用计数与垃圾回收方式, 长时间运行的服务其内存会逐渐增长, 直至涨到触发OOM kill, 原话为: "proxy's every pod,, and retry, OOM kills at.", 而在最为关键的时刻它出现崩溃。
其三, 是部署的体积, 服务呢, 是需要解释器的, 还有依赖以及虚拟环境, 而Rust编译之后呈现出来的是一个二进制文件, 把它放置上去便能够运行。
2.2 这不是个案，是趋势
要是你留意AI基础设施的发展变化, 就会发觉Rust已深入到各个渠道层次当中:
这些项目存在这样一个共同点, 那就是它们均属于AI工具链里用来称作"管道"东西。Rust的所有权系统在编译阶段将数据竞争以及内存泄漏排除掉了, 并且不存在GC, 内存分配具有确定性, 编译产物是单一的二进制文件, 而这些设计目标恰恰精准地击中了AI管道层的核心矛盾。
2.3 的迁移策略：最值得学的不是技术，是节奏
没有在一个夜晚进行重新编写, 它划分成了四个阶段, 在每一个阶段都能够独立上线并且获取到收益。
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/（添加流式复杂度）, 最后迁移 /chat/（具备最大表面积: 工具调用、多模态）。每一条路由在迁移之前会经过"一致性检查", ------只有当Rust版本输出与已知版本完全一致时才能够被激活。
这并非属于技术方面的决策, 而是工程范畴的决策。从技术角度而言使用 Rust 进行重新编写并非难事, 困难之处在于怎样在生产环境当中一步一步地去替换, 并且不会出现失误。其时间表为: 半年时间, 分四步来实施。
2.4 但 Rust 不是银弹
150倍这个数字, 得看测试的条件, 其用的是mock, 也就是模拟上游LLM, 仅仅测试网关本身的转发性能。置于真实场景里, 瓶颈处在你的LLM那边, 动不动就需要几秒。网关从7.5ms降到0.05ms, 这种体感上的差异, 并没有150倍那么夸张。它所解决的是"网关自身不成为瓶颈"以及"内存不爆炸"的状况。
Rust的开发成本也是实实在在存在着的, 学习曲线方面, 编译时间方面, 类型系统的严格程度方面, 都表明开发速度会相较于其他情况要慢一些, 能够推动这个迁移, 能够说明这个团队已经具备了足够的Rust能力了------毕竟不是每一个团队都有能力做这件事情的。
最终呈现的形态之内, 用户所拥有的插件依旧经由某种方式运行, 这透露出一项暗示成立的事实, 即在人工智能构建的特定总体环境里所处的位置, 短时间范围之内不会被Rust这种编程语言所替代, 它将会被"推送至其自身所擅长的层次", 也就是运行时期的相关事宜归属Rust负责, 而用户能够依据自身需求进行定义设置的逻辑条理以及快速创建最初模型的部分归属于另外一种情况, 这样的一种分工安排相较于"全部使用Rust进行处理"的状况而言更加具备良好的状态发展态势。
三、C# / 的替换逻辑是, 企业 AI 全栈方面的"生态替换"。
若讲 Rust 于管道层那儿和正面展开性能竞争, C#/.NET 走的是另外一条更为隐蔽的路径, 即让企业级 AI 应用全然无需。
3.1 推理层：原地替代，无需桥接
. NET 10引进原生ONNX支持, ML. NET作为本地推理引擎, 使得C#应用能够直接开展模型推理。针对企业业务场景（分类、异常检测、推荐）, 这消除了"做模型、C#做业务"的架构割裂。
你不需要一个 微服务来做推理，C# 应用自己就能跑。
3.2 编排层： Agent 的原生 C# 生态
在2025年10月的时候, 会把相关内容和另外的相关内容合并成统一的一种Agent , 这并非是那种简简单单的SDK更新, 而是属于一个战略方面的信号。
这表明, 企业生态里, AI Agent 的编排是可用 C# 原生达成的, 其规划也能够用 C# 原生来完成, 记忆同样 能用 C# 原生实现, 工具调用也都可以凭借 C# 原生达成。无需引入相关技术栈, 无需对两套语言环境进行维护, 无需在 C# 和相关技术之间承受序列化/反序列化所带来的性能损耗。
3.3 性能：不如 Rust 极致，但足够好
维度
Rust (Axum)
Core
()
吞吐量
~500k req/s
~150-300k req/s
~10-20k req/s
内存占用
5-30MB
50-200MB
200-500MB
启动时间
毫秒级
秒级（JIT）
秒级（解释器）
开发效率
低（所有权系统）
高（成熟生态）
极高（动态类型）
C#之中的GC尽管是存在着的, 10的GC已经得到了大幅度的优化, 对于大多数的企业API场景而言并不是瓶颈。更为重要的是:
3.4个关键差异在于, Rust是那种类似管道工的存在, C#是那种类似建筑师的存在。
维度
Rust
C#/.NET
替代 的层面
运行时基础设施（网关、路由、代理）
企业应用全栈（推理+编排+业务）
核心优势
极致性能、内存确定性、无 GC
开发效率、企业生态、Azure 集成
与 的关系
退居"插件层"（）
可能根本不出现在架构中
适用场景
高并发 I/O、边缘计算、
企业业务系统、Azure 云原生、合规场景
学习曲线
陡峭（所有权系统）
开发者可直接上手）
部署形态
单二进制，
运行时依赖，但容器化/云原生支持成熟
四、两条路径的交汇点：AI 基础设施正在分层重构
过去十年，AI 领域发生过两次基础设施迁移：
从 CPU 到 GPU
：训练模型跑不动了，GPU 接管了计算层
从单机到分布式
：模型太大了，分布式训练和推理成了标配
当下, 正出现第三次, 人工智能工具链的运行时段, 正从, 朝着Rust以及C#进行分层转移。
但并非是不行了哈, 而是当AI的规模提升之后, 作为"全能胶水"的物理极限已然达到了。就如同在浏览器端的物理极限达到后, 出现了这样的情况------并非是因为JS不好, 而是因为场景发生了变化。
GIL以及GC呈结构性瓶颈, 于Rust而言, 所抢夺的实则是"运行时管道", 涵盖网关、路由、代理、记忆引擎、知识图谱检索, 这些皆是具备高频、低延迟以及内存敏感特性的组件。
拿C#去抢到的那个是"企业应用栈" , Agent给出了完整的AI能力, 企业用不着为了AI去引入技术栈, 躲开了架构割裂以及运维复杂度。
它不会消失, 然而它的角色正被重新定义, 从"AI 基础设施的默认选择"转变为"特定层的可选之物", 这特定层涵盖模型训练, 包含数据科学, 涉及快速原型, 还有用户自定义插件。
五、 角色演变：从"全屏"到"一角"
这个演变不是"消灭 "，而是让每一层用对材料。
六、对于技术选型而言会有启示, 是以这样的情况来说, 要是你正从事AI相关工作, 或者是在代理层方面, 如果是在负责记忆引擎, 假使得按做AI相关方向的工作来论, 又或者是在企业级AI实施应用范畴, 针对Agent平台来讲。
如果你在做混合架构（如 的 系统）
七、写在最后
0.05ms 以及 31.7MB 并非是一个孤立存在的数据点, 它们形成了一种信号, 那就是当 AI 从实验阶段迈向生产环节之际, 其脚下的地板需要更换材料了。
/ 搭了脚手架，Rust 浇了地基，C# 盖了楼。
三条路径不是互斥，而是分层协作：
将来的AI基础设施, 并非那种"谁替代谁"的单一选择题情形, 而是属于"谁该处在哪一层"这样的分层架构形式。要明晰清楚每一层的核心矛盾所在, 挑选出最为合适的材料, 这才是工程的本质要点。
参考链接