AI 基础设施并不适合把所有代码都改写成 Rust。真正值得迁移的，通常是高频调用、边界复杂、需要隔离且对延迟敏感的基础组件。
Rust 的价值也不只是“比 Python 快”：它把内存安全、资源控制和可部署性组合到了一起；WASI Preview 2 则进一步把这种能力封装为可跨运行时加载的组件。
本文从 AI 基础设施出发，解释 Rust、WebAssembly 与 WASI Preview 2 的适用边界，并给出一条可以落地的组件化路线。
一、AI 基础设施为什么需要 Rust
典型的 AI 服务链路通常包含多个阶段：
请求接入
├── 身份认证与租户限流
├── Prompt 预处理
├── Tokenizer
├── 模型路由与策略判断
├── 推理调用
├── 输出过滤与结构化
└── 日志、计量与审计
真正消耗 GPU 的可能只有中间的模型推理。其余环节却经常运行在请求主路径上，并且具有以下特征：
- 每个请求都要执行；
- 输入来自用户或外部系统；
- 需要严格控制内存、CPU 和超时；
- 可能由不同团队开发或动态更新；
- 不能因为一个插件崩溃而拖垮整个网关。
核心观点一：Rust 适合 AI 基础设施中的“边界组件”，而不是替代整个 AI 技术栈。
机制在于，Rust 将内存安全检查前移到编译期，同时通过所有权模型减少悬垂指针、数据竞争和手动释放错误。对于 Tokenizer、JSON 转换、规则过滤、协议适配这类 CPU 密集且边界清晰的代码，收益比重写训练框架更直接。
例如，Hugging Face 的 tokenizers 就提供 Rust 实现并被 Python、Node.js 等语言调用。它并没有取代 Python 的模型编排，而是把性能敏感的底层工作下沉到 Rust。
适用边界也很明确：如果瓶颈是 GPU kernel、模型并行或 CUDA 通信，Rust 不能凭空消除 GPU 瓶颈；如果业务逻辑仍在快速试验，过早重写可能降低迭代速度。
二、从原生 Rust 到 WASI Preview 2
1. Rust 原生服务
Rust 原生服务直接使用操作系统网络、文件和线程能力，通常通过 Tokio、Axum 或 Hyper 构建。
它的优势是性能和生态完整，适合：
- 推理网关；
- 高并发 API 服务；
- 模型下载器；
- 节点代理；
- 需要访问 GPU、文件系统或操作系统网络栈的控制面服务。
缺点是隔离边界主要依赖进程、容器和操作系统权限。若允许第三方团队提交插件，直接加载动态库或运行脚本会放大供应链风险。
2. WebAssembly 与组件模型
WebAssembly（Wasm）最初是面向浏览器的可移植字节码。现在它也被用于服务器端插件和沙箱执行。
传统 Wasm 模块通常通过线性内存和导出函数交互，接口容易退化成：
传入指针 + 长度
返回指针 + 长度
这要求宿主和模块共同约定内存布局，字符串、列表、错误处理都需要自行编码。
组件模型（Component Model）试图解决这一问题。它通过 WIT（WebAssembly Interface Types）描述语言无关的接口，例如：
package ai:plugin@0.1.0;
interface policy {
record request {
tenant: string,
prompt: string,
}
record decision {
allowed: bool,
reason: option<string>,
}
check: func(input: request) -> decision;
}
world ai-policy {
export policy;
}
这里的 string、record、option 不再由调用方手动解释指针，而是由组件模型定义数据交换规则。
WASI Preview 2 是基于组件模型的一套标准化接口集合，当前关键能力包括文件、网络、随机数、时钟等资源访问。Rust 工具链可以使用 wasm32-wasip2 目标构建组件；Wasmtime 则是常见的服务端执行运行时。
核心观点二：WASI Preview 2 的主要价值不是“让 Wasm 更快”，而是为插件提供稳定的能力边界。
机制是“接口描述 + 能力注入 + 运行时隔离”：
- WIT 定义插件能够导入和导出的接口；
- 宿主只提供明确授权的 WASI 能力；
- Wasmtime 负责实例化组件、传递参数和管理资源；
- 插件无法自动获得宿主的全部文件、网络和进程权限。
这对 AI 基础设施特别有用。例如，输出过滤插件只需要读取请求内容和配置，不应拥有任意网络访问权；模型路由插件可能需要读取模型目录，但不应拥有宿主机写权限。
三、组件如何被加载和调用
下面是一个简化的 Rust 组件实现。实际工程通常由 wit-bindgen 或 cargo-component 根据 WIT 生成绑定代码。
// lib.rs
// 由 WIT 生成的接口绑定通常放在 bindings 模块中。
// 生成代码负责把 WIT 的 string、record 转换为 Rust 类型。
mod bindings {
wit_bindgen::generate!({
path: "../wit",
world: "ai-policy",
});
}
use bindings::exports::ai::plugin::policy::{
Guest, Request, Decision,
};
struct Policy;
impl Guest for Policy {
fn check(input: Request) -> Decision {
// 示例规则：生产环境中应使用结构化策略，而不是简单字符串匹配。
let blocked = input.prompt.contains("secret-key");
Decision {
allowed: !blocked,
reason: if blocked {
Some("prompt contains a restricted pattern".to_string())
} else {
None
},
}
}
}
bindings::export!(Policy with_types_in bindings);
构建时可以使用 Rust 的 wasm32-wasip2 目标：
rustup target add wasm32-wasip2
cargo build \
--target wasm32-wasip2 \
--release
这里需要注意：生成的文件是否是组件，取决于构建工具链和组件适配步骤。不能仅因为文件后缀是 .wasm，就认为它已经是符合 WIT 接口的组件。工程中应使用 wasm-tools component wit 或相应运行时命令检查产物。
宿主侧的逻辑可以抽象成：
读取组件制品
-> 校验哈希或签名
-> 创建 Wasmtime Engine
-> 配置资源限制
-> 仅挂载允许的 WASI 能力
-> 实例化组件
-> 调用 check()
-> 记录耗时、错误和资源使用
核心观点三：Wasm 插件的安全性不来自文件格式，而来自宿主对能力和资源的主动限制。
如果宿主开放了完整文件系统、任意网络和无限内存，那么组件模型并不能自动替代安全策略。Wasm 解决的是执行边界，身份认证、制品签名、依赖审计和租户隔离仍需由平台完成。
四、Rust、WASI 组件与 Python 如何选型
可以据此做出三个结论：
核心观点四：高性能核心服务优先使用原生 Rust，受控扩展点优先使用 WASI 组件，模型实验和编排仍可保留 Python。
机制是把“性能、隔离、迭代速度”拆开处理，而不是强迫一种语言承担所有职责。
一个合理的架构可能是：
Python / TypeScript
负责实验、工作流与模型调用
Rust 原生服务
负责网关、调度、Token 处理、连接池
WASI Preview 2 组件
负责租户策略、内容过滤、格式转换、路由插件
GPU 推理服务
负责模型执行与显存管理
不适合使用 WASI 组件的情况包括：
- 插件必须直接访问 CUDA、NCCL 或设备驱动；
- 需要共享大块 GPU 显存；
- 接口仍在频繁变化；
- 组件内部依赖完整操作系统功能；
- 额外的序列化和实例化开销超过了隔离收益。
五、AI 正在如何改变 Rust 基础设施开发
AI 对 Rust 的影响并不是简单地“自动生成更多代码”，而是改变了开发重点。
第一，AI 可以降低 Rust 的学习门槛。开发者可以让代码助手解释生命周期、生成错误处理骨架、补全 WIT 接口和测试用例。但生成代码必须经过 cargo check、cargo clippy、单元测试以及运行时测试，不能把编译通过等同于资源安全。
第二，AI 使插件数量增长更快。过去一个团队维护少量规则，现在可以让模型生成大量数据清洗、Prompt 检查和协议适配插件。这反而提高了平台对制品签名、版本兼容、沙箱策略和可观测性的要求。
第三，AI 推理链路中的数据格式变得更复杂。结构化输出、工具调用和多模态输入都会增加跨语言数据交换。WIT 这类显式接口描述比“大家约定 JSON 字段”更适合长期维护，但需要严格管理接口版本。
核心观点五：AI 降低了组件生产成本，却提高了组件治理成本。
例如，一个模型生成的过滤器可能逻辑正确，却存在：
- 无界字符串拼接；
- 大输入导致内存峰值；
- 错误被吞掉后默认放行；
- 兼容旧接口但改变业务语义；
- 日志中泄露 Prompt 或密钥。
因此，AI 生成的 Rust/Wasm 组件应当进入和普通软件相同的供应链：格式检查、依赖扫描、模糊测试、资源测试、签名发布和灰度加载。
六、最容易踩的坑：把“沙箱”误解成“无限安全”
一个常见错误是：把第三方组件放进 Wasmtime，就认为它不会影响服务。
实际可能出现以下现象：
- 组件可以访问宿主开放的网络接口；
- 输入长度没有上限，导致内存持续增长；
- 单次调用没有超时，线程被长期占用；
- 组件版本升级后改变 WIT 语义；
- 宿主复用实例时，状态泄露到下一个租户。
规避方式应当是组合治理：
接口层：限制输入长度、字段数量与版本范围
运行时：配置燃料、内存、表和实例数量上限
能力层：只注入必要的文件、网络和时钟接口
生命周期：按请求或租户决定实例是否复用
供应链：锁定依赖、校验哈希、签名验证
观测层：记录调用耗时、拒绝原因和资源峰值
需要特别区分“计算限制”和“时间限制”。Wasm 的指令燃料可以帮助限制执行量，但外部 I/O、宿主函数调用和等待操作仍然需要超时与取消机制。只配置燃料而没有请求级取消，不能解决所有卡死问题。
七、工程落地路线
可以按以下顺序推进，而不是一开始就迁移整个 AI 平台。
第一步：选择低耦合组件
优先选择输入输出清晰、无需 GPU 的模块：
- Prompt 脱敏；
- JSON 结构化；
- Token 计量；
- 租户策略；
- 输出格式校验；
- 模型路由规则。
先测量 P50、P95 延迟、内存峰值、失败率和部署复杂度，避免只比较单次函数执行速度。
第二步：固定接口
使用 WIT 描述输入、输出和错误语义，并为接口建立兼容规则：
新增字段：默认可选
删除字段：至少跨一个兼容周期
改变语义：升级接口包版本
错误处理：禁止用空字符串代替失败
接口稳定比语言选择更重要。WIT 设计不清楚，换成组件后只会把问题固定得更早。
第三步：建立宿主能力模型
为每类插件定义能力清单：
policy-plugin:
- stdin-like request data
- clock
- no network
- no filesystem
routing-plugin:
- model metadata
- read-only configuration
- bounded network access
不要直接把宿主的全部 WASI 接口暴露给所有插件。
第四步：加入测试和供应链
至少覆盖：
- 正常输入与异常输入；
- 超长 Prompt；
- Unicode 和多字节字符串；
- 组件重复调用；
- 超时与取消；
- 内存上限；
- WIT 版本兼容；
- 恶意或错误插件。
运行时可选择 Wasmtime；构建阶段使用 Rust 1.82+ 的 wasm32-wasip2 目标，并检查产物是否为组件，而不是普通核心 Wasm 模块。
八、知识地图与学习路径
建议按“语言基础—运行时—接口—平台治理”学习。
- Rust 基础
掌握所有权、借用、生命周期、错误处理、Trait 和异步运行时。动手写一个带边界检查的 JSON 处理服务。
- WebAssembly 基础
理解线性内存、模块、导入导出和实例化。使用 wasm-tools 查看模块与组件的区别。
- WASI Preview 2 与 WIT
学习接口定义、资源类型、世界（World）和能力授权。先实现一个无网络、无文件权限的策略组件。
- Wasmtime 宿主开发
学习组件加载、实例复用、超时、资源限制和错误传播。将组件接入一个 Rust 网关。
- AI 基础设施治理
增加 Prompt 脱敏、Token 计量、策略插件和模型路由，观察组件边界对延迟、隔离和发布流程的影响。
进阶资料应优先阅读 Rust 官方发布说明、WebAssembly Component Model 与 WASI 规范、Wasmtime 文档，以及实际项目的接口和测试代码。不要只依赖代码生成工具或教程中的最小示例。
总结：Rust 最适合成为 AI 基础设施的高性能控制层，WASI Preview 2 适合把边界清晰的扩展点做成可隔离组件；二者都不能替代 GPU 推理栈和完整的平台治理。
落地时先固定接口、限制能力、测量资源，再决定是否组件化。你会优先把 AI 系统中的哪类模块做成 WASI 插件：策略过滤、Token 处理，还是模型路由？
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
AI infrastructure is not suitable for rewriting all codes into Rust. What is truly worthwhile to move is often HF calls, complex borders, isolation and delayed-sensitive base components.
Rust's value is not just "quicker than Python": it combines memory security, resource control and deployability; while Wasi Preview 2 further encapsulates this capability as a component to be loaded while running.
This paper explains the applicable boundary between Rust, WebAssembly and WASI Preview 2 from the AI infrastructure and gives a component route to land.
I. AI Why infrastructure needs Rust
Typical AI service links usually have multiple stages:
Request access.
Ideas - Identification and Tenant rate limit
Prompt Preprocessing
├── Tokenizer
Idea - Model route and strategy judgement
Ideas call
Ideas - Output Filter and Structure
Log, metering and auditing
The real consumption of GPU may be only the middle model. The rest of the chain is often on the main route of the request and has the following characteristics:
- Each request is executed;
- Inputs from users or external systems;
- Need for strict control of memory, CPU and timeout;
- Possible development or dynamic updating by different teams;
- The entire gateway cannot be dragged down by a plug crash.
Core point one: Rust fits the "boundary components" in the AI infrastructure rather than replacing the entire AI technology warehouse.
The mechanism is that Rust moves the memory security check before it is compiled, while reducing pins, data competition and manual release errors through ownership models. For the Tokenizer, JSON conversions, rules filtering, protocol adaptations, such as CPUs, which are dense and border clear, the revenue-based training framework is more direct.
For example, Hugging Face tokenizers offer Rust to achieve and be called by Python, Node.js, etc. Instead of replacing Python's modeling, it sunk performance-sensitive bottom jobs to Rust.
The applicable boundary is also clear: if the bottlenecks are GPU kernel, model parallel or CUDA communications, Rust cannot eliminate the GPU bottlenecks in a vacuum; if business logic is still being tested quickly, premature rewrite may reduce iterative speed.
II. Rust to Wasi Preview 2
Rust Native Service
Rust services directly use the operating system network, file and thread capabilities, usually built through Tokio, Axum or Hyper.
Its advantages are performance and ecological integrity, suitable for:
- Delineation gateway;
- High-quality API services;
- Model downloaders;
- Nodal agent;
- Needed access to GPU, file systems or control services of the network stack of operating systems.
The disadvantage is that the separation boundary relies primarily on the process, the packaging and the operating system permission. If third-party teams are allowed to submit plugins, the supply chain risks are magnified by directly loading the dynamic library or running script.
WebAssembly and Component Model
WebAssembly (Wasm) was originally a portable byte code for browsers. It is now also used for server end plugins and sandbox execution.
Traditional Wasm modules are usually interactive through linear memory and export functions, and interfaces are prone to degradation:
Import pointer + length
Return Pointer + Length
This requires that the host and the module agree on the memory layout, and that the string, the list, and the error process require a self-encoding.
The Component Model (Component Model) attempts to address this problem. It describes non-linguistic interfaces through WIT, e.g.:
package ai:plugin@0.1.0;
interface policy {
record request {
tenant: string,
prompt: string,
}
record decision {
allowed: bool,
reason: option<string>,
}
check: func(input: request) -> decision;
}
world ai-policy {
export policy;
}
The string, record, option here is no longer the caller's manual explanation pointer, but the component model defines the data exchange rules.
WASI Preview 2 is a standardized set of interfaces based on the module model, with current key capabilities including access to documents, networks, random numbers, clocks, etc. Rust Tool Chains can build components using the goal 32-wasip2; Wasmtime is the common service-end running time.
Core point two: The main value of Wasi Preview 2 is not “make Wasm faster”, but rather provides a stable capacity boundary for the plugin.
The mechanism is "Interface Description + Capability Injection + Runtime Segregation":
- WIT defines an interface that can be imported and exported;
- The host only provides a clearly authorized WASHI capability;
- Wasmtime is responsible for case-based components, transmission parameters and management of resources;
- The plugin cannot automatically obtain all host files, networks and processes permission.
This is particularly useful for AI infrastructure. For example, the output filter plugin only needs to read the requested content and configuration and should not have any access to the network; model route plugins may need to read the model directory, but should not have a host writing permission.
How the components are loaded and called
The following is a simplified Rust component. The actual project is usually a Wit-bindgen or cargo-component-generated binding code based on WIT.
// lib.rs
/ / WIT-generated interface binding is usually in the bindings module.
/ / Generating code converts the WIT string, record to the Rust type.
mod bindings {
wit_bindgen::generate!({
path: "../wit",
world: "ai-policy",
});
}
use bindings::exports::ai::plugin::policy::{
Guest, Request, Decision,
};
struct Policy;
impl Guest for Policy {
fn check(input: Request) -> Decision {
/ Example rule: Structured strategies should be used in the production environment instead of simple string matching.
let blocked = input.prompt.contains("secret-key");
Decision {
allowed: !blocked,
reason: if blocked {
Some("prompt contains a restricted pattern".to_string())
} else {
None
},
}
}
}
bindings::export!(Policy with_types_in bindings);
Build with Rust's goal:
rustup target add wasm32-wasip2
cargo build \
--target wasm32-wasip2 \
--release
Note that the resulting document is a component depending on the construction of the tool chain and the adaptation of the component. The file cannot be considered to be part of a WIT interface simply because it is suffixed with.wasm. In the project, the product should be inspected using the asm-tools computer bit or when running accordingly.
The logic of the host side can be abstract:
Read component products
- > Verify Hash or Sign
- Create Wasmtime Engineering
- >Resource constraints
- > Mount only permitted WASI capabilities
- > Empirical Component
- Call check.
- >Record time, error and resource use
Core point three: The security of the Wasm plugin is not derived from file formats, but from the host ' s proactive limitations on capacity and resources.
A component model does not automatically replace a security strategy if the host has access to a complete documentation system, any network and unlimited memory. Wasm addresses the enforcement boundary, and identification, signature of products, reliance on audits and segregation of tenants still need to be completed by the Platform.
IV. How Rust, WASI components and Python are selected
Three conclusions can be drawn:
Core view four: The high performance core services give priority to native Rust, the controlled extension points give priority to the WASI component, and the model experiments and layouts can remain with Python.
The mechanism is to remove “performance, isolation, iterative speed” rather than forcing a language to assume all its responsibilities.
A reasonable structure could be:
Python / TypeScript
It's for experiments, workflow and models.
Rust Native Service
Gateway, dispatch, Token processing, connect pool
WASI Preview 2 Component
Responsible for tenant strategy, content filtering, formatting, router plugins
GPU reason service
Responsible for model implementation and VRAM management
Not fit to use WASI components include:
- Plugin must have direct access to CUDA, NCCL or device-driven;
- Need to share large pieces of GPU VRAM;
- The interface is still subject to frequent changes;
- Reliance on full operating system functionality within components;
- Additional sequencing and exemplifying expenses exceed the benefits of isolation.
V. AI How to Change Rust Infrastructure Development
The effect of AI on Rust is not simply to "auto generate more codes" but to change the focus of development.
First, AI can lower Rust's learning threshold. The developer can ask the code assistant to explain the life cycle, create an error-processing skeleton, complete the WIT interface and test examples. However, the generation code has to go through cargo check, cargo clippy, unit testing and running time testing, and cannot be equivalent to resource security.
Second, AI increases the number of plugins faster. A small number of rules were maintained by a team in the past, which now allows models to generate large amounts of data cleansing, Prompt checks and protocol matching plugins. This in turn increases the requirements of the Platform for the signature, compatibility, sandbox strategy and observability of products.
Thirdly, the data format in AI ' s reasoning chain has become more complex. Structured output, tool call and multi-modular input will add to the exchange of data across languages. The description of such visible interfaces is more appropriate for long-term maintenance than "the agreement of all" JSON Z109Z, but requires rigorous management of the interface version.
Core point five: AI reduced the cost of component production but increased the cost of component governance.
For example, a model-generated filter may be logical but exists:
- Unlimited stringing;
- Core peaks due to large input;
- Default release when the error is swallowed;
- Compatibility with old interfaces and changes in business syntax;
- Disclosure of Prompt or key in the log.
Therefore, the Rust/Wasm components generated by AI should enter the same supply chain as ordinary software: format checking, reliance on scanning, fuzzy testing, resource testing, signature publish and ash loading.
VI. The easiest pit to step on: Misreading the sandbox as “unlimited security”
A common error is the placement of third-party components in Wasmtime, which is assumed to have no impact on services.
The following may actually occur:
- Component access to host-open network interfaces;
- There is no limit on the length of the input, which results in a sustained increase in memory;
- Single calls without timeout and long-term occupancy of circuits;
- Changes in the WIT semantics following the upgrading of the component version;
- When the host returns the example, the status is disclosed to the next tenant.
The circumvention should be a combination of governance:
Interface layer: limit input length, field number and version range
Run-time: maximum number of fuel, memory, tables and examples configured
Capacity level: only necessary files, networks and clock interfaces are injected
Life cycle: determine whether the example is reused on request or by tenants
Supply chain: lock-in, Hashi verification, signature authentication
Observatories: recording call times, rejection reasons and resource peaks
A special distinction needs to be made between “calculated limits” and “time limits”. Wasm's command fuel can help limit implementation, but external I/O, host function calls and waiting operations still require timeout and cancellation mechanisms. Fuel alone, without the request for cancellation, could not resolve all the problems of card death.
VII. PROBABILATION TRAINING
You can proceed in the following order instead of moving the entire AI platform from the beginning.
Step 1: Select low-coding components
Prefer modules with clear output without GPU:
- Prompt desensitization;
- Structure of JSON;
- Token Measurement;
- Tenant strategy;
- Output format verification;
- Model router rules.
First measure P50, P95 delays, memory peaks, failure rates and deployment complexity to avoid only comparing the speed of a single function.
Step 2: Fixed interface
Use WIT to describe input, output and error syntax and create compatible rules for interfaces:
Add field: Default Optional
Delete field: Cross at least one compatible cycle
Change semantics: upgrade interface package version
Error processing: Disable use of empty strings instead of failure
Stable interfaces are more important than language selection. The WIT design is unclear, and the replacement of the components will only fix the problem earlier.
Step 3: Building a host capacity model
Define a list of capabilities for each type of plugin:
policy-plugin:
- stdin-like request data
- clock
- no network
- no filesystem
routing-plugin:
- model metadata
- read-only configuration
- bounded network access
Do not expose all host WASI interfaces directly to all plugins.
Step 4: Join testing and supply chain
At least cover:
- Normal and unusual inputs;
- Overlong Prompt;
- Unicode and multibyte strings;
- Component duplicate call;
- timeout and cancellation;
- Memory ceilings;
- WIT version compatibility;
- Malicious or erroneous plugins.
Runs to select Wasmtime; use the Rust 1.82+ goal as the original 32-wasip2 target and check if the product is a component rather than a normal core Wasm module.
Knowledge maps and learning pathways
It is recommended that learning be based on “linguistic basis - running time - interface - platform governance”.
- Rust Base
When taking ownership, loan, life cycle, error, Trait and walk. Write a JSON processing service with a border check.
- WebAssembly Base
Understand linear memory, modules, import export and exemplification. Views the differences between modules and components using im-tools.
- Wasi Preview 2 and WIT
Learning interface definition, resource type, World and competency empowerment. A web-free, non-documented permission strategy component is first achieved.
- Wasmtime host development
The learning component is loaded, case reuse, timeout, resource limitations and error dissemination. Access component to a Rust gateway.
- AI Infrastructure governance
Add Prompt desensitization, Token metrology, tactical plugins and model routing to observe the effects of component boundaries on delay, isolation and publish processes.
Progress information should be given priority by reading Rust Official publish Notes, WebAssembly Component Model and WASI norms, Wasmtime documents, and interfaces and test codes for actual projects. Do not rely only on the smallest example of a code generation tool or tutorial.
Summarizing: Rust is best placed to be a high performance control layer for AI infrastructure, Wasi Preview 2 is well suited to make clear border extension points into separable components; neither can replace GPU reasoning and complete platform governance.
On landing, the interface is fixed, the capacity limited, the resources measured, before the componentization is determined. You'll give priority to the type of modules in the AI system as a WASI plugin: policy filtering, Token processing, or model routing?
Auto-fetched and translated by AI Atlas. All rights belong to the original author.