uzu：把模型推理放进 App 进程的 Rust 引擎，四个语言绑定怎么选

uzu 要解决的是「模型不进服务器」这件事

云端推理的账单和数据流向是绑在一起的：请求发出去，输入就离开了设备，费用也按调用量计。uzu 的 README 把卖点写得直接，零延迟、完整数据隐私、无推理成本，三条指向同一个前提，模型跑在应用自己的进程里。它的目标读者因此不是训练模型的人，而是要在 iOS、macOS 或桌面端交付对话功能的应用开发者。仓库 topics 里同时出现 llm、tts 与 metal，说明覆盖面不止文本对话，但 README 给出的示例只有聊天，其余能力要靠官网的模型列表页。这一点值得注意：README 里的 Broad model support 指向 trymirai.com/local-models，具体支持哪些模型、哪些是文本哪些是语音，必须去那边看，仓库正文没有列出。

一次推理要经过 Engine、model、download、chat 四步

从 README 的 Rust 示例看，调用链是固定的四段。先 Engine::new(EngineConfig::default()) 建引擎，再 engine.model(标识字符串) 取模型句柄，然后 engine.download(&model) 返回一个可迭代对象，用 next() 逐条拿进度，最后 engine.chat(model, ChatConfig) 建会话，session.reply(messages, ChatReplyConfig) 拿回复。模型标识写成 alibaba:qwen3.5:0.8b:mirai:mirai-m:4，冒号分段的命名空间式写法，说明引擎内部有一层标识到实际权重与配置的映射，README 提到的 unified model configurations 指的应该就是这层。下载被显式建模成异步流而不是一个阻塞调用，这个设计对移动端有意义：进度能直接接到 UI 上，示例里就是用回车加 ANSI 清行符原地刷新百分比。回复对象同时带 reasoning() 和 text()，说明推理侧区分了思考内容与最终输出，取的时候要分别处理，示例里对 reasoning 用了 unwrap_or_default()，也就是允许为空。

四套绑定的 API 形状并不一致

把四个示例并排看，差异比想象中大。Rust 用 Engine::new 和 engine.model(...).await?，返回 Result，模型找不到时用 ok_or("Model not found") 转成错误。Python 改成 Engine.create(engine_config)，模型不存在时返回 None，代码里是 if model is None: return。Swift 又是 Engine.create(config:) 加 try await，模型标识参数标签是 identifier:，下载流用 for try await 遍历 iterator()，回复取 reply.last?.message。TypeScript 用 EngineConfig.create() 和 Engine.create()，但下载那行是 for await (const update of await engine.download(model))，直接迭代返回对象本身，没有 iterator() 这一层。同一个引擎，四套语言里同步与异步的边界、空值的表达方式、错误是抛还是返回，全都不一样。跨端团队如果打算共用一套调用约定，这份差异得先对齐，否则抽象层会做得很别扭。

统一内存是 Apple 平台的红利，也是边界

README 的功能列表里有一条，Utilizes unified memory on Apple devices。配合 Swift 徽章上的 iOS | macOS 和 Package.swift，可以判断 Apple 平台是它的一等公民。统一内存意味着 CPU 与 GPU 共享同一块物理内存，权重不需要在两侧各存一份，也不需要显式拷贝，这对端侧模型的内存占用是实打实的改善。但这条红利只在 Apple 硬件上成立。README 与徽章里出现的绑定是 Rust、Python、Swift、TypeScript，没有 Android、没有 Linux 服务端的原生绑定，也没有 CUDA 或 ROCm 的字样。Rust 绑定本身可以编译到任何 Rust 支持的平台，但引擎内部是否真的为其他平台提供了加速后端，这份材料里看不出来。如果你的目标设备不是 Apple 生态，先假设统一内存这条优势与你无关，再去官网确认有没有别的后端。

装起来容易，装完之后依赖的是 Git 分支

四条安装路径都很短。Rust 在 Cargo.toml 里写 uzu = { git = "https://github.com/trymirai/uzu", branch = "main", package = "uzu" }。Python 是 uv add uzu==0.5.26。Swift 在 dependencies 里加 .package(url: "https://github.com/trymirai/uzu.git", from: "0.5.26")，对应 Package.swift 里声明 Swift 5.9 与 iOS、macOS 平台。TypeScript 是 pnpm add @trymirai/uzu@0.5.26。这里有个实际取舍：Rust 侧给的是 branch = "main" 的 Git 依赖，不是 crates.io 上的版本号，意味着构建结果会随上游 main 分支变动，CI 缓存和可复现构建都要额外处理。另外三个语言走的是发布包并锁定了具体版本，Python 与 TypeScript 的徽章都标在 0.5.26。同一个项目，Rust 用户拿到的是滚动分支，其他语言用户拿到的是固定版本，这个不对称在团队里容易造成「我这边能跑你那边不行」的排查成本。

版本节奏决定了升级成本，0.5.x 不是稳定版

近期发布是 0.5.26、0.5.25、0.5.23，日期分别是 9 月 6 日、9 月 4 日、9 月 3 日，最后推送是 9 月 9 日。三天里出了三个版本，主版本号还停在 0，按语义化版本的惯例，0.x 阶段允许破坏性改动出现在次版本号里。对采用者来说，这意味着 from: "0.5.26" 这种写法在 Swift 里锁的是 0.5.x 区间，理论上仍可能吃到 0.5.27 的行为变化。Python 与 TypeScript 示例用的是精确版本，反而是更稳的选择。仓库里有一个 crates/legacy/uzu 的路径出现在徽章链接中，legacy 这个词说明绑定层经历过一次结构调整，老代码迁移时值得留意导入路径有没有变。许可方面，LICENSE 是 MIT，允许商用与修改，具体义务以仓库里的 LICENSE 原文为准，这里不做法律层面的解读。

什么时候该用别的工具

uzu 的前提是模型要在应用进程里跑。如果你的推理本来就放在自建服务器上、要跑几十亿参数以上的模型、或者需要多租户并发调度，本地引擎的整套设计都用不上，直接选服务端推理框架更省事。另一个分界是平台：Apple 生态之外，这份材料没有给出对等的加速后端证据，Android 团队现在拿它当主力方案风险偏高。至于具体该换成什么，取决于你的约束在哪一侧，服务端调度、Android 端侧、还是跨平台的模型格式兼容，这三类需求对应的项目完全不同，本文没有足够材料替你做这个对比。真正能确定的只有一条：uzu 把「模型标识」当成配置的核心抽象，模型支持范围由这个抽象和官网列表决定，而不是由引擎的通用性决定。选型前先确认你要的模型在不在那份列表里，比比较引擎特性更早一步。

编辑结论

如果你的产品要在端侧跑对话模型，且团队能接受 Rust 生态与 Git 依赖，uzu 值得先做一次最小验证：用 README 里的 alibaba:qwen3.5:0.8b:mirai:mirai-m:4 这个模型标识跑通 Engine.create、engine.model、engine.download、engine.chat 四步，确认模型下载落在哪个目录、断网后能否复用缓存、以及目标平台上是否真的走统一内存。如果目标平台是 Linux 服务器或 Android，README 与徽章里都没有对应绑定的证据，现在不该把它排进选型。如果团队没有人愿意跟 Rust 的 Git 依赖和快速迭代的版本号，也不适合。真正要先验证的是模型标识的解析规则和版本升级时 API 是否稳定，这两点决定了它能不能进生产分支。

官方来源

1. License: MIT
2. Project website
3. README
4. Releases
5. trymirai/uzu on GitHub