★ FEATURED ARTICLE 不要急着跟我吵“Rust到底能不能写业务”我们先看这几件正在发生、却没多少人把它们放在一起说的事。我平时主要用Python做模型开发和线上服务落地。过去一年我连续在好几条生产链路里发现那些“不显山不露水但天天在跑”的AI基础设施组件正在朝着Rust迁移。注意不是“有人写了篇性能对比博客然后大家嗨一下”的那种氛围而是真实的、已经在线上的替换。如果给这件事找一个简单解释我会说AI基础设施里那些最注重并发、内存、延迟和静态可验证性的部分正在放弃Python的动态灵活也正在摆脱C/C的“安全债”而Rust正好把这两端都接住了。这篇文章说的是三个信号。它们分别是数据处理层、推理运行时层、以及服务骨架层。三个信号不是孤立的它们指向的是同一个结论AI基建的技术底座正在经历一轮从静态语言到另一种静态语言的更替只不过这一次换到的是Rust。1. 信号一在分词、索引、向量检索这些“地基”里Rust已经悄悄成了底座1.1 分词层外面是Python里面是Rust先提一个我判断“基建切换”的第一个信号源分词器。如果你做过大模型相关工作几乎每天都会接触各种分词工具。早期这些工具大多以Python字符串处理和正则为核心后来为了性能很多实现改用C再后来一批面向大模型的分词器则直接选择了Rust。原因其实不难理解。分词是整个pipeline上调用频率最高的环节之一。一次请求进来先要把文本切成token这个动作发生在任何模型推理之前。切分的快慢直接决定单条请求的排队时间。而分词逻辑本身又属于典型的“计算量不大但调用次数极多”的场景它最需要的不是模型训练那种“大力出奇迹”而是稳定的低延迟和极低的内存分配开销。Rust在这种场景很占便宜无GC意味着不会在高峰请求时突然被垃圾回收线程打断内存布局可控意味着能写出类似C的高效遍历代码但又不至于像C那样容易越界或悬垂。更实际的一点是Rust的线程安全模型在服务端场景里特别省心同一个tokenizer实例可以放心地被多线程共享而不用担心锁竞争或者数据竞争。我自己在一个语音转写项目的预处理链路里踩过类似的坑。最初使用某个基于Python实现的分词组件单条文本片段的分词耗时大约在3到8毫秒波动。后来把调用点改成Rust重写后的等价实现同样的硬件P99直接从7毫秒降到了1.5毫秒以内。这个量级的变化不会改变模型本身的精度但对高并发网关来说直接决定了你能不能把吞吐再翻一倍。很多同行会问为什么不是换成C实现答案很现实缺少内存安全保证。线上服务里一个内存越界可能把整个worker打崩而Rust在编译期就把这一类问题挡掉了大部分。翻译成白话就是C把“不要翻车”的希望寄托在人的细心Rust把“不要翻车”做成了编译器规则。1.2 向量检索与索引层Rust开始占据“默认选项”的位置第二个信号来自我称之为“地基中的地基”的向量数据库和索引层。大模型应用兴起之后检索增强、本地记忆、知识库问答这些场景都在依赖向量检索。过去做向量索引绕不开一些传统框架但那套底层往往是用C写的。最近几年新出现的几个向量数据库从第一个commit开始就选了Rust。它们背后的理由很务实检索类服务通常被要求常驻内存内存占用越低单机容纳的向量越多成本越低。高并发下的实时写入和查询需要严格控制的线程行为Rust的异步生态和并发原语刚好能用上。向量索引结构本身就复杂容易写出底层未定义行为Rust可以把“索引文件损坏”这类风险压到极低。从生产角度讲向量检索服务是否稳定影响的是整个RAG链路。早期我们调试检索服务时经常碰到索引进程崩掉的情况。当时排障靠看core dump后来整个检索模块改用Rust实现后这类崩溃几乎绝迹。倒不是说Rust写的代码一定没bug而是大部分会导致进程崩溃的bug在写代码阶段就被编译器拦住了。这给运维带来的价值不用多吹半夜不用被报警叫醒团队也不用把精力花在“为什么进程没了”这种玄学问题上。Rust在这里的定位不是“性能黑魔法”而是“可以让团队睡得着觉的静态保障”。1.3 地基迁移的核心逻辑性能是结果安全才是入场券把分词器和向量索引放在一起看你会发现一个共同逻辑性能优势当然重要但真正推动切换的其实是可控性。AI基建的特点决定了它不能频繁崩溃不能有不可控的停顿不能在压力翻倍时靠运气撑住。Rust恰好同时提供了“可控的内存”和“静态的安全验证”这就比光有性能的数据更有吸引力。从这个信号能得出的判断是只要某个组件对线上可靠性要求高于对快速迭代的要求同时又是高并发、低延迟、高内存敏感那么它就有强烈的理由换到Rust。这波趋势不是从热门框架扩散到边缘组件反而是从边缘组件逐步向上、向内渗透先落地在最不起眼但最高频的模块里。2. 信号二推理运行时正在从Python跨到Rust性能和成本看得到摸得着2.1 一批以Rust为底座的推理框架已经跑起来了信号一说的还是基础设施外层的东西信号二则直接指向AI系统里最核心的组件推理运行时。模型训练阶段因为生态和历史惯性短时间内还是Python的天下。但推理阶段的逻辑不太一样它需要把线上流量扛住需要尽量压低每次推理的成本需要把模型跑在各种各样的硬件环境下。这种诉求下Python做胶水层勉强够用但跑到靠近硬件的地方就力不从心了。这几年涌现出的Rust推理框架走的是和传统Python深度学习框架完全不同的路线。它们可以做CPU推理也可以做GPU推理可以加载各种量化的模型权重还支持在嵌入式环境里部署。更关键的是运行时和Python调用层分离得很干净核心用Rust做计算与调度再通过绑定暴露给上层应用。我在一些实际业务里对比过Python派生框架和Rust类推理框架的差别。同一个模型相仿的量化等级下Rust推理框架的显存占用通常能低一截预热时间也短。尤其在CPU部署场景Rust实现的无锁或轻锁调度能让多个请求更平滑地共享算力而不是像传统运行时那样出现明显的排队毛刺。2.2 为什么推理层会成为“转向Rust”的关键信号在众多AI环节里推理运行时是最不可能因为“赶时髦”而换语言的。原因很简单换运行时的成本极高模型兼容性、算子实现、量化格式、部署工具链都需要一一对齐。一个团队肯在推理层尝试Rust方案一定是因为算过账之后发现收益够大。收益主要体现在四个维度延迟降低。Rust运行时在请求分发和内存管理上有优势单次请求的开销更小。吞吐提高。并发处理能力更强特别是在多实例、多卡协同推理的场景下。资源占用下降。内存占用更少同样一台机器能扛住更多并发或者能省下实例数。长期维护成本变低。内存安全让推理服务不那么容易在极端输入下崩溃。在云服务账单按小时计算的现实里哪怕只是把一个模型的显存占用减少两个GB一个月省下来的成本都非常直观。这也是为什么很多做私有化部署的团队在选型时越来越愿意把Rust推理框架放进对比名单。2.3 边缘部署和WASM场景是另一个隐藏推手推理层向Rust迁移还有一个容易被忽略的推动力来自边缘部署。大模型不只在数据中心跑很多场景需要在本地设备、浏览器、甚至嵌入式设备里完成推理。Rust对WebAssembly的支持相当成熟而WASM正是浏览器端和插件生态里跑AI推理的主要载体之一。只要模型权重和推理逻辑能编译到WASM用户就不需要把数据上传到服务器本地就能完成计算。这个特性对隐私敏感场景很有吸引力。我见过一些团队把轻量化模型封成WASM模块放到客户端本地跑推理服务端只做结果校验。这种架构难以用Python实现因为Python本身不太适合直接编译成WASM并且保持推理性能Rust却天然合适。于是推理层向Rust迁移的驱动力又多了一条它不只是为了省成本还打开了新的部署形态。2.4 推理迁移的观察小结从框架应用来看推理层是“Rust正在成为AI基建默认选项”的最强信号。因为这一层再也没有“以后再说”的缓冲模型跑不动就是跑不动服务器成本高就是成本高。当一个足够重要的团队决定在推理运行时里认真考虑Rust时它背后的技术选型风向已经变了。3. 信号三AI网关、调度、可观测性这些“服务骨架”也开始把Rust当生产主力3.1 网关和推理代理新服务的第一行代码就是Rust第三个信号来自AI系统和外界交互的那一层API网关、推理代理、模型路由、流量治理。做AI应用的人都知道当多个模型并存、多版本上线、多租户共用一个集群时光有推理引擎不够还需要一个聪明的“交通指挥”。这个交通指挥负责把请求分发到正确的模型实例对不同的调用方做计费、限流、鉴权和灰度同时还承担着容错恢复的职责。在早期的AI工程实践里这部分往往用网关框架来做或者干脆用脚本拼业务。但业务一复杂就出问题并发上不去、内存泄漏、规则引擎卡顿最难受的是出了问题无法在发布前可靠地预判。Rust进场之后这个场景的变化异常明显。新的网关和推理代理项目不再把“快速上线”当第一优先级而是先追求“在极端流量下不出幺蛾子”。这恰恰是Rust擅长的事情类型系统能把配置错误挡在编译期所有权模型能杜绝内存泄漏里最常见的那一类异步运行时则能处理大量并发连接而不至于线程爆炸。我们线上曾经遇到过一个很典型的困境某个推理代理服务只要QPS超过某个临界值内存就一路涨到OOM。后来换成了Rust实现的路由层问题从根上消失了。不是说换语言能自动解决业务bug而是Rust的静态检查让最阴暗角落里的资源滥用无处藏身。3.2 可观测性和调度系统Rust开始承担“系统之眼”的角色如果说网关是AI服务的入口那可观测性就是AI服务的眼睛。指标的采集、链路的追踪、日志的流式处理和聚合这些组件往往要处理每秒成千上万条事件还要做到低开销。用一个高开销的语言去做观测本身就是一种悖论。现在市面上越来越多可观测性组件开始采用Rust实现。它们承担的角色不是“给开发者写业务逻辑”而是“以极低的前置损耗收集并处理所有系统的运行数据”。这背后的逻辑等同于地基逻辑观测系统本身的负载不能影响被观测系统的性能否则观测行为就变成了破坏行为。调度系统也是同样的道理。AI训练集群、推理实例的编排调度需要迅速感知资源状态并做出决策。传统的调度器要么用Go要么用Java它们在常规业务上够用但在“大规模高密度AI集群调度”的场景里Rust的低内存占用和强并发能力能带来实打实的优势。更值得一提的是调度系统一旦崩了整个集群都可能不可用所以语言层面的安全性在这里优先级极高。3.3 从“服务骨架”看到的变化从网关到观测再到调度这三类组件有一个共同特点它们都不是为某一个具体模型服务的而是为了整个AI系统能稳定运行而存在的。它们长期不被关注一旦出问题影响面却极大。这类组件转向Rust说明什么说明Rust已经不只是算法工程师手里的“性能补丁”而是基础设施团队在搭建“从请求进来到推理结束再到账单计量”的全链路时愿意信任的默认基底。信号三比信号一和信号二更有分量因为骨架一旦定型后续所有新服务都会沿用这套技术土壤。4. 为什么偏偏是“现在”Rust生态终于补齐了AI基建的拼图4.1 库生态从“能用”到“真好用”的时间点到了关注Rust的人都知道语言本身出现得并不晚但早年想用Rust做AI基建会遇到一个尴尬要么缺库要么库不够稳。现在情况已经完全不同。几个关键拼图是这几年陆续到位的异步运行时成熟了网络服务和高并发网关不再需要自己手搓事件循环。Python绑定和打包工具链成熟了Rust核心可以无缝暴露成Python扩展这对AI团队是最友好的过渡方式。机器学习相关的库和推理运行时开始出现并进入生产验证前端验证不再是个大坑。编译目标覆盖了主流服务器、GPU以及WASM一端连数据中心一端连浏览器。生态补齐带来的结果是什么呢团队不需要从零开始造轮子也不需要担心“选Rust之后没人维护库”。当基础设施所需的关键组件都有了活跃维护版本选Rust的决策从“挑战自我”变成了“常规选择”。4.2 人才和组织土壤也开始适应语言迁移从来不只是技术问题更是人才问题。过去几年越来越多的后端工程师和基础设施工程师把Rust写进简历里。这倒不是说所有Python工程师都要立刻切换而是说招聘方可以更从容地组建一支“Rust基建小分队”用来攻坚那些最核心的性能敏感模块。我观察到的一个组织上的细节是很多AI团队并不是整体迁移而是分开两条线。算法工程师继续用Python做实验和快速迭代平台工程师负责把成熟逻辑用Rust下沉。这个分工在几年前听起来很别扭现在却成了很自然的事。这与AI基建本身的发展节奏也有关。早期AI工程的重心是“模型能不能用”现在的重心是“模型跑得好不好、贵不贵”。前者用Python足够后者就需要更硬核的底层能力。团队开始愿意为“底层能力”单独立项、单独配置人力这个组织信号比技术信号更能说明趋势的持久性。4.3 为什么赶在这个时间点集中爆发还有一个角度值得聊AI基建对“成本”的敏感度变了。模型规模变大之后同样的业务量对推理延迟和算力资源的需求呈指数上升。过去一个服务用Python写能跑就行现在同样的流量如果用Python跑GPU白白等CPU的情况会变得很明显如果用C重写又面临安全性和人力成本的挑战。Rust恰好把一个“还能跑”的系统变成“高效且还能长期维护”的系统。于是成本敏感成了Rust的催化剂。当每一毫秒延迟都对应真金白银当每一次崩溃都意味着收入损失团队就会认真评估那些看起来“学习曲线陡峭”的选项。Rust在数据中心里的总体拥有成本放在AI业务规模里算下来往往比表面上的“开发速度慢”划算得多。5. 作为应用开发者现在可以怎么跟上这轮迁移5.1 不要急着推翻重来先做“热路径迁移”聊完了趋势聊点实在的。我不是建议你现在就把所有Python代码删掉改用Rust重写。实际上多数AI项目最适合的策略是保留Python作为上层表达层把调用最频繁、性能瓶颈最明显的若干“热路径”迁移到Rust。所谓热路径简单说就是一条请求处理链路里被反复执行的代码段通常包括预处理、分词、向量索引查询、数据编解码、鉴权加密等。这些模块的特点是大流量、高频率、对延迟敏感而且逻辑相对固定。把它们下沉成Rust扩展能立刻兑现收益同时不会动摇整个系统的可用性。我建议从这几个方向入手对高并发网关做一次profile找出CPU时间消耗最高的那个函数。对推理服务的数据预处理阶段做统计找出所有不必要的数据拷贝和重复计算。对向量检索或全文检索部分评估是否值得替换成Rust实现的索引。对日志和指标采集链路检查序列化和传输开销。先做最小验证跑通后再逐步扩大范围是风险最低的路线。5.2 用PyO3在十几分钟内给Python加一个Rust热路径给不熟悉Rust与Python协作的同行一个速成示例。假设我们要把一段分词字符串处理逻辑搬到Rust里最快的方式是使用一个叫PyO3的库来写Python扩展模块。先用cargo初始化一个项目cargo new --lib fast_text cd fast_text然后在Cargo.toml里加上PyO3依赖[package] name fast_text version 0.1.0 edition 2021 [lib] name fast_text crate-type [cdylib] [dependencies] pyo3 { version 0.20, features [extension-module] }在src/lib.rs里写一个极简的对字符串按标点切割的函数use pyo3::prelude::*; #[pyfunction] fn split_text(text: str) - VecString { text.split(|c: char| !c.is_alphanumeric() !c.is_whitespace()) .filter(|s| !s.is_empty()) .map(|s| s.to_string()) .collect() } #[pymodule] fn fast_text(m: Bound_, PyModule) - PyResult() { m.add_function(wrap_pyfunction!(split_text, m)?)?; Ok(()) }然后在项目里用另一个叫maturin的工具完成编译安装maturin develop --release完成后Python端可以直接导入调用import fast_text result fast_text.split_text(hello world, this is an AI system!) print(result)就这么简单。核心逻辑用Rust写暴露给外部的是Python接口业务代码基本不用改但底层已经在用Rust执行了。这个例子里我用的是最朴素的字符串分割真实场景中可以换成trie字典、正则编译后的匹配器、JSON解析器或任何性能敏感的库函数。这个组合拳的意义在于AI团队不需要一夜之间全面转型只要围绕性能瓶颈做局部替换就能享受Rust带来的收益。5.3 哪些东西最好不要急着“Rust化”说完了能做的说一些不该做的。至少在我的经验里下面几类场景不适合立刻换Rust模型训练和探索性实验。这个阶段变量变化太快Python的交互式体验仍然无可替代。依赖大量成熟Python生态实现的部分。比如复杂的数据科学算法已有太多经过验证的Python库直接用就好。业务逻辑频繁改动、还没定型的功能。Rust的静态类型虽然安全但频繁改接口的成本也高。团队完全没有Rust经验且缺乏时间学的情况。强行上马容易变成“用写Java/写Python的思维写Rust”体验反而更差。如果你所在的团队目前没有Rust积累比较务实的启动方式是找一个已退休或维护中的小型内部工具用Rust重写当作练手和踩坑项目。不要一上来就挑最核心的生产链路过手否则压不住学习成本带来的阵痛。5.4 几个我常用的迁移实战套路最后分享几个我用下来比较顺的套路。第一先跑性能基线。拿到一条线上热路径用profiler记下各段耗时和内存分配次数再用同样的场景在Rust实现上复测用数据说话。如果没有基线数据迁移完成后你很难说服自己和团队“这事值了”。第二做好测试基准。用同一份测试数据分别在Python和Rust实现上跑对比延迟分布特别是P99而不要只看平均值。平均值会掩盖长尾问题P99才是线上用户体感最真实的指标。第三小心数据边界。Rust和Python之间传递大量字符串或字节数据时尽量减少拷贝次数。如果数据量很大可以考虑直接暴露内存视图而不是在两边反复转换避免原本用于提速的迁移因为序列化开销而变慢。第四团队里保留一个Rust指导教师角色。不需要人人精通Rust但至少要有一两个人能搞定借用检查器和生命周期这类核心概念。这个人不一定是全职Rust开发但必须能在关键时刻帮别人把编译错误讲明白。6. 迁移边界几个让我印象深刻的观察聊到这儿三个信号和一个行动建议都讲完了。最后说点带个人色彩的观察。第一个观察是这次迁移和以前“追新框架”完全不一样。追新框架通常是把一个库换成另一个库但语言层的迁移更深它改变的是团队写代码的方式、排查问题的方式和做技术决策的边界。新的语言会把某些问题进行前置比如内存安全性、并发正确性这些问题以前可能要等到线上事故才会暴露现在编译期就暴露了。从这个意义上说Rust带来的不只是性能还有一种把工程问题往前挪的能力。第二个观察是AI基建的Rust化并不同时意味着Python的退场。我反而觉得Rust在AI基建里越普及Python作为上层开发语言的位置就越稳固。因为上层需要表达力强、修改快、生态广的语言而底层需要可靠、高效、并发安全的语言。两者是分工关系不是替代关系。那些复杂的模型研究依然绕不开Python但当基础设施足够高效时Python能更快地完成更复杂的实验这其实是双赢。第三个观察是关于团队和个人技术路线的。如果你现在处于“熟悉Python但想往系统层走一步”的位置花时间掌握Rust会是一笔非常划算的投资。倒不是说你马上要用Rust找工作而是当基建团队开始讨论并发、安全、极致性能这些话题时你能听懂他们在讲什么能参与决策能知道哪条路更值得做技术选型。这种参与感在AI基建正在换底的窗口期里比任何单一技术栈都值钱。我没法告诉你哪一天Python会完全退出AI基建也没法告诉你Rust会取代所有C。但从我看到的生产趋势来说Rust已经走进了AI基建最核心的地带而且每一块拼图都在加速到位。如果你是做AI工程或者平台的现在动手在某个小模块里试试Rust会比一年后再动从容得多。
阅读完成 · 觉得有帮助？
