纯 Rust LLM 完工:零 Python,加听觉、记忆与多智能体

在 v3.0.0 版本的文章末尾，我写了一个简短的“下一步计划”清单：正式发布到 crates.io、稀疏/分组 MoE 调度、多节点训练、更完整的 OpenAI API 兼容性，以及音频——这是当时唯一还没有人涉足的模态。

在这五个计划中，有四个在本次发布中实现了。

而第五个，我故意推翻了。这个反转，其实比任何单一新功能都更能说明本次发布的故事。

aarambh-studio v4.0.0 正式发布——历经十五个阶段、十八个 Pull Request、一次架构品牌重塑，以及一个我在两个版本前写下清单时未曾预料到的决定：这是最后一个计划中的版本。它不是暂停，不是“等我理清 v5 思路再说”的搁置，而是有意的完结，并且我把原因都写了下来。

依然是 Rust。依然以 Candle 作为唯一的张量后端。依赖图中依然没有哪怕一行 Python 代码。

• aarambh-studio v4.0.0（原 aarambh-ai）是从零开始用 Rust 构建的完整 LLM 流水线的第四个，也是最后一个计划发布的版本——涵盖从预训练到服务部署，零 Python 依赖。
• 它通过多头潜在注意力（MLA）完善了注意力机制家族，新增了原生音频理解、CUDA 上的稀疏 MoE 调度、多节点训练、测试时计算扩展、RLAIF、沙盒化多智能体工具执行、从零构建的 RAG、模型合并、公共推理服务器、红队评估以及自动生成的模型卡片。
• 工作区扩展到了 21 个 crate（较 v3 的 19 个增加了 2 个）——其中 2 个是全新的，2 个进行了扩展，0 个重命名，0 个删除。
• 项目的 crates.io 发布政策发生了反转，而非扩展：永久仅提供源码，此决定为最终决定。
• 没有任何预训练权重、检查点、适配器或 GGUF 文件会随任何版本（包括本版本）发布。你需要训练并对齐你自己的模型。

aarambh-studio（梵文 aarambh，意为“开始”）是一个仅包含解码器的 Transformer LLM 应用程序，作为 Rust 工作区构建在 Candle 张量后端之上。它以前叫 aarambh-ai。

v1.0.0 是纯文本基础：预训练、SFT、LoRA/QLoRA、GRPO 对齐、INT4/GGUF 量化、Flash Attention v2 CUDA 内核、思维引擎、安全护栏以及支持 CPU 的自学习。

v2.0.0 使其具备多模态和自服务能力——视觉、MoE、多 GPU 训练、DPO、投机解码、语法约束的工具调用，以及其自有的 OpenAI 兼容服务器。

v3.0.0 重建了注意力机制本身——Gated DeltaNet、DeepSeek 稀疏注意力、细粒度 MoE、原生视频和文档理解，以及长程工具链。

v4.0.0 为这一系列画上了句号。更名发生在本次发布的第一个 PR 中——因为到了这个阶段，该项目已经不再是一个你可以通过 cargo add 随意引入部分代码的研究仓库，而是变成了一个实际运行的、自包含的应用程序。

以下是本次发布中我认为比任何单个阶段都更有趣的部分。

在 v3.0.0 的文章中，我将“这次来真的：发布到 crates.io”列为一个已知边界和 v4 的候选目标。我是认真的。在 Rust 社区的标准下，一个从不发布到 crates.io 的 Rust 项目看起来就像没写完。

然后我真正坐下来规划 v4 时，问了一个诚实的问题：发布什么？aarambh-studio 不是某个可以导入到别人的 Cargo.toml 中的库。它是一个应用程序——一个背后有 20 个内部 crate 的 CLI 二进制文件，这些 crate 没有一个是被设计为可独立使用的。

将它们发布到 crates.io 不会让项目更好用，它只是在勾选一个根本不适用于当前项目性质的复选框。

因此，v4.0.0 不会发布到 crates.io。它永久性地确认，以后也绝不会发布。所有 21 个工作区包都设置 publish = false。之前每个版本的发布政策都暗示这终将改变，而 v4.0.0 明确表示：不，这才是从一开始就正确的答案，只是我们之前没有这么最终定调。

我把这部分放在前面，是因为同样的自律贯穿了本次发布的其余部分——去衡量，而不是假设，并且要敢于公开承认你宣布的计划是错误的。

v3.0.0 用 Gated DeltaNet（常量大小循环状态）替换了模型的大部分注意力层，并保留少数层使用 DeepSeek 稀疏注意力（DSA）。Phase 41 增加了第三种：多头潜在注意力（MLA），即 DeepSeek-V2 推广的用于降低推理时 KV 缓存成本的机制。

从概念上讲，它的核心思想是：不再为每个头缓存全尺寸的键和值投影，而是在缓存存储任何内容之前，将它们向下投影到一个小得多的共享潜在向量中，然后在读取时从该潜在表示重建注意力所需的内容。

缓存保存的是压缩后的潜在向量，而不是完整的 K/V 张量——因此长对话占用的内存会缩减，且不会影响模型能关注到的上下文范围。

对我而言，在实际中最重要的一点是，它与 v3 中使 Gated DeltaNet 具备可采纳性的原理相同：MLA 可以通过继续预训练改造到现有的检查点上。你不需要为了采用它而丢弃 v1、v2 或 v3 的训练成果。

随着 MLA 的加入，v4.0 的注意力堆栈成为一个完整的四路家族——全缩放点积、Gated DeltaNet、DSA 和 MLA——可通过 TOML 按层选择，并保留了密集回退机制以确保正确性优先。一个新的 eval --kv-cache-report 标志可以量化每层的节省量，因此“实质性地削减了 KV 内存”是一个你可以打印出来的数字，而不是一句需要你盲信的空话。

视觉在 v2 落地，视频和文档在 v3 落地。Phase 42 填补了剩下的模态空白：音频。

一个冻结的音频频谱图转换器搭配一个可训练的投影器，将原始声音转换为与视觉产生的相同类型的 Token 空间嵌入。其融合机制与图像和视频帧拼接到序列中的方式故意保持完全一致，因此解码器不需要知道也不关心它的某些上下文是来自波形而不是图片。

需要提前说明的诚实边界：解码仅支持纯 Rust 的 WAV PCM。没有 FFmpeg 绑定，没有 MP3、FLAC 或 Ogg。这不是疏忽——这与 v3 中管理视频解码的规则一致：“不调用系统编解码器，没有隐藏的 C 依赖”，现在将其一致地应用到了新格式上。

一个新的保留 Token  标记了流中的边界，并且音频的 DoRA/QDoRA 微调与每个其他模态已经使用的 VLM 训练代码路径完全相同。一条训练路径，现在支持四种模态而不是三种。

v2 和 v3 都随带了采用密集掩码调度的混合专家系统：每个专家在每个 Token 上都进行计算，被掩码，然后由路由器加权。这很正确、简单，并且刻意不是高效版本——我在之前两篇文章中都明确指出了这是一个已知的、有记录的权衡。

Phase 43 在 CUDA 上解决了这个问题：真正的稀疏调度，只有实际路由到特定专家的 Token 才会接触该专家的权重。CPU 路径保留了原始的密集掩码矩阵乘法实现，因为稀疏调度的真正优势只有在硬件级别的 gather/scatter 操作下才会显现，而正确性优先的 CPU 可移植性仍然很重要。

这两条路径通过逐层的密集与稀疏数值测试被证明是等效的——这同样是“衡量声明，而不仅仅是发布想法”的本能在每个版本中的体现。

Phase 45 增加了一类推理时技术，它们以额外的计算换取更好的答案，且不触碰模型权重：最佳 N 次采样、自洽性（N 次生成中的多数投票）、基于验证器的选择，以及一个带有 trait 接口的启发式过程奖励评分器（为未来训练好的头部留出空间）。

在本版本中这仅限于文本，并且我刻意称其为启发式，而不是把它包装成一个它本身并不是的训练好的奖励模型。

Phase 46 将 RLAIF 作为第三种对齐信号加入，与 GRPO 和 DPO 并列：一个评判模型对偏好对进行评分，这些分数被送入现有的 DPO 管道，而不需要新的训练循环。它被刻意与自学习循环分开——这与 v4 的模型合并功能使用的框架相同：离线的、经过衡量的，在评估测试证明其有效之前，永远不假设它有帮助。

我认为这是整个发布中工程故事最有趣的阶段。

Phase 47 增加了沙盒化工具执行——通过 agent --execute-tools 选择性启用，仅限于操作员授权的闭世界命名能力集（如 read_file_in_workdir）。不是任意代码，不是 Shell 访问，而是一个由运行者决定的模型被允许执行的固定菜单。

Phase 48 在此基础上构建了多智能体编排：一个编排进程可以将独立的子任务委派给多个并行的沙盒子链，然后通过现有的工具结果摄取路径将它们的结果合并回来，并递归应用。

一旦你允许这种委派，你就创造了一种让权限悄然扩大的方式——一个子智能体做了其编排者最初根本没有被授权做的事情。

修复方法是一个简单的调用：AuthorizationScope::intersect。子智能体的作用域永远只是其父级作用域的子集。它通过委派永远不会增长，只会缩小。

除此之外，还有两个由操作员设置的硬性界限——最大子智能体数量和最大总执行时间预算——并且子链默认顺序运行。真正的并行执行需要 Send + Sync 的 ChainDecoder，这超出了本版本的范围；诚实地声明顺序执行，好过在线程安全上悄悄偷工减料。

Phase 49 增加了一个新 crate：aarambh-studio-retrieve——包含分块、嵌入头、可导航的小世界图 ANN 索引，以及生成前的提示增强，核心索引不依赖任何外部向量数据库。

我最喜欢的一个细节：默认测试的嵌入器是无权重的——基于哈希的嵌入，而不是训练好的。这意味着整个检索流水线可以端到端运行，而不需要先有训练好的嵌入检查点。你可以在第一天就搭建 RAG，在你训练任何东西之前，然后一旦有了值得训练的模型，再换入学习到的嵌入器。

Phase 50 增加了一个完整的模型合并工具包——线性平均、SLERP、任务向量算术、TIES-Merging 和 DARE——在执行任何写入之前进行严格的形状和模式验证，优先使用 CPU 的 f32 数学运算，质量由评估测试判断，绝不靠假设。

在结构上值得强调的是：这不需要新的 crate。它是现有 aarambh-studio-weights crate 中的一个新 merge.rs 模块，该 crate 已经负责处理 SafeTensors 和 GGUF。这与 v2 中保持视觉功能不接触 Transformer 核心，以及 v3 中保持遗忘诊断不需要新依赖的本能相同——新能力，现有层级，对上下层零干扰。

Phase 51 扩展了 v2 中的 OpenAI 兼容服务器，增加了可选择的多租户 API 密钥认证、按密钥的 RPM/TPM 速率限制、按租户的进行中请求隔离，以及在 LRU 驱逐策略和可配置内存上限下的提示前缀 KV 缓存与最长前缀复用。

v2 中仅限环回、未经身份验证的单用户模式仍然是默认设置——这些都不是强制的，也没有把项目变成托管产品。没有计费，没有自动扩缩容。依然是自托管的，跑在你自己的硬件上。

Phase 52 赋予了模型一等公民的系统角色标记。听起来微不足道，直到你想起项目自 v2 以来一直执行的规则：Token ID 只能追加，永远不能重新分配。

ID 7 自 v2.0.0 起就是 IMAGE，并且永远是 IMAGE——所以新的 SYSTEM 标记必须占用下一个空闲的 ID 17。它搭配了 tokenizer 配置和检查点元数据上的 chat_template_version 标签，如果检查点与其 tokenizer 在版本上不一致，启动时会触发大声报错。

我发布了该标记的第一个版本，然后不得不回去重命名那个字面字符串本身——它最初读起来不像一个真正的聊天模板 Token——最后它以 ーパー 的形式落地。一行代码的修复。但这比多智能体编排器花了更多仔细的思考，这告诉你在这类项目中，真正的难点往往藏在哪里。

Phase 53 针对完整的 v4.0 攻击面运行了一次系统性、端到端的红队测试——安全层和系统轮次优先级、闭世界工具执行边界、编排器的硬性界限，以及公共服务器的认证/速率限制/租户隔离面。

这是一个包含 24 个案例的语料库，全部手工编写或仅来源于免费的公开材料，每个案例都有标记的预期结果。失败的案例会在报告中直接暴露——绝不会被默默丢弃。

Phase 54 随后使该报告成为强制性的：模型卡片是由评估测试记分卡、红队报告和静态元数据组装而成的，而不是手写的——因此卡片不会悄悄与背后的数据脱节。如果没有红队报告，或者报告不干净，生成过程会大声报错失败。一个检查点如果没有干净的红队通过记录，就无法获得模型卡片。这是一个真正的硬性门控，不是走过场。

最后一个阶段是发布本身。21 个工作区包全部升级到 4.0.0——版本号从 4.0.0-alpha.14 跃升，Cargo.lock 重新生成了 21 个匹配的成员条目，每个发布命令都带 --locked 运行。

发布审计脚本得到了扩展，以检查 ROADMAP_V4.md 中是否有未勾选的任务，并断言所有四个 v4 涉及的 crate（aarambh-studio-audio、aarambh-studio-retrieve、aarambh-studio-agent、aarambh-studio-serve）确实存在于工作区中，以防 v4 的部分内容在发布前被悄悄砍掉。

RELEASE.md 本身在这里也得到了一个微小、诚实的修正——它仍然指向早期草稿中过时的 phase40_release_audit.sh 脚本名称，并被修正为了实际的 scripts/phase28_release_audit.sh。细节虽小。但这正是在“最终”版本中容易放过，而我在这个版本中绝不想放过的那种细节。

权限在委派过程中必须收缩，绝不能增长。多智能体编排的 AuthorizationScope::intersect 设计一旦命名就显得显而易见。但把边界条件弄对——子智能体的作用域严格作为父级的子集，绝不可能是同级或超集——这是区分沙盒功能和伪装成沙盒功能的权限提升漏洞的关键。

红队门控只有在它能真正阻止某些事情时才有效。当红队报告缺失或脏乱时，让模型卡片生成变成一个软警告是很容易的。让它大声失败且没有覆盖选项，这才把“我们跑了安全测试”变成了“没有它，检查点在字面意义上就不能声称自己是安全的”。

无权重不等于无假设。为 RAG 选择基于哈希的默认嵌入器以便流水线无需训练检查点就能工作，这是容易的部分。确保这个决定是明确的——记录为默认值，而不是被默默当作唯一选项——这更重要，因为如果没有人写下来它是可替换的，“无权重”就会悄悄变成“永久未训练”。

推翻公开承诺比做出承诺更难。在 v3 文章中写“这次来真的：发布到 crates.io”很容易。在 v4 发布说明中回去准确解释为什么那是错误的计划——而不是悄悄放弃并希望没人注意到——花掉的文字比大多数实际功能还要多。

与 v1 到 v3 相同的分发政策，现在被声明为最终决定而非临时决定：所有 21 个工作区 crate 保持 publish = false，GitHub 的自动源码存档是唯一的发布资产，并且不附带任何预训练检查点、适配器、分词器、优化器状态或 GGUF 文件。你需要自己训练、对齐、量化和部署。

• MoE 稀疏调度仅限 CUDA；CPU 保留正确性优先的密集掩码路径。
• 多节点训练仅支持数据并行——不支持模型并行或流水线并行——且具有单次重试容错策略。
• 测试时计算扩展仅限文本，其过程奖励评分器是有记录的启发式算法，不是训练好的模型。
• 工具执行严格限于闭世界的命名能力——绝不支持任意代码或 Shell 访问。
• 多智能体子链默认顺序运行；真正的并行执行明确不在本版本范围内。
• RAG 的核心索引是从零构建的纯 Rust 图 ANN——不允许使用外部向量数据库。
• 视频仍仅限视觉 H.264 MP4；音频仍仅限 WAV PCM；文档仍基于像素，无 OCR 或表格解析器。
• 公共服务器使自托管多租户成为可能——它不是一个托管产品。没有计费，没有自动扩缩容。
• crates.io 发布不是推迟到未来版本。根据设计，它永远不会发生。

现在有 21 个 crate，比 v3 的 19 个有所增加。两个是全新的（aarambh-studio-audio、aarambh-studio-retrieve），两个在原地扩展（aarambh-studio-agent、aarambh-studio-serve），零重命名，零删除。

模型合并——一个我原本以为需要自己独立 crate 的庞大功能——最终作为现有 crate 中的一个新模块落地。这与严格的、编译器强制执行的 crate 分层在每次发布中带来的回报相同：一个方向的增长不会悄悄破坏另一个方向。

但 crate 的数量其实不是本节的重点。真正的重点是这个：

当 v1.0.0 发布时，悬而未决的问题是：你到底能不能在 Rust 中构建一个可用的 LLM 流水线，而且栈中没有任何 Python。v2 问的是，这个代码库能否在不导致架构崩溃的情况下向多个方向扩展。v3 问的是一个更难的同类问题，通过重建所有其他东西所依赖的部分来考验。

而 v4 问的是前面几个版本都不需要问的问题：你什么时候停下来？

写在 ROADMAP_V4.md 中的诚实答案是，这个路线图不像 v2 和 v3 的路线图那样带有“超出范围，留待下个版本”的部分。在这份路线图底部没有为 v5 候选名单埋下伏笔。这不是疏忽——这就是重点。

该项目着手解决的核心工程问题——一个完整的 LLM 流水线，包括对齐、多模态、高效服务和安全的工具使用，能否完全从零开始用 Rust 构建，而不包含一行 Python 代码——已经得到了回答、演示和记录，在五十个阶段中一步步完成。

不是每个项目都需要一个无限增长的路线图。有些项目就是应该到达终点，然后真正停下来。

第一篇文章中那串乱码的 50 步输出——“Secondprophebreathety,seeask,argweremanlyremories”——四个版本后，仍然是整个项目诚实的起点。现在不同的是，纪律没有变。它始终是：准确理解某事物崩溃的原因，构建能修复那个特定失败的最小东西，在宣称完成之前衡量它是否真的有帮助。

这种纪律在 v1 中构建了分词器，在 v2 中构建了视觉路径，在 v3 中构建了 Gated DeltaNet，在 v4 的多智能体编排器中构建了授权范围边界。

这一次的不同之处在于，同样的纪律也告诉我要停下来。一个只知道如何不断增长的项目，并不比一个知道如何完成的项目更诚实。如果说有什么不同的话，知道何时完成是更难实践的纪律。

四个版本，五十五个阶段，以及一句乱码的开场白之后——我仍然会做这笔交易。

什么是 aarambh-studio？aarambh-studio（原 aarambh-ai）是一个完全从零开始用 Rust 构建的仅解码器大语言模型应用程序，使用 Candle 张量后端。它在一个代码库中涵盖了预训练、微调、对齐、量化、推理、智能体、检索和服务部署，任何地方都没有 Python 或 PyTorch 依赖。

aarambh-studio v4.0.0 有什么新功能？v4.0.0 增加了作为第三种注意力类型的多头潜在注意力、原生音频理解、CUDA 上的稀疏/分组 MoE 调度、多节点分布式训练、测试时计算扩展、RLAIF 对齐、沙盒化多智能体工具执行、从零构建的检索增强生成、模型合并工具包、公共多租户推理服务器、带有聊天模板版本控制的一等公民系统角色、红队对抗性评估以及自动生成的模型卡片。

aarambh-studio v4.0.0 真的是最终版本吗？是的。它被宣布为最后一个计划发布的版本。截至本次发布，不存在 v5 路线图，并且 ROADMAP_V4.md 刻意没有延续 v2 和 v3 路线图中都包含的“下一版本”范围划分部分。

aarambh-studio v4.0.0 附带预训练模型权重吗？不。与之前的每个版本一样，它仅发布源码。所有 21 个工作区 crate 保持 publish = false，GitHub 的自动源码存档是唯一的发布资产——不包含检查点、适配器、分词器、优化器状态或 GGUF 文件。

aarambh-studio 会被发布到 crates.io 吗？不会。v4.0.0 永久性地确认了这一点。aarambh-studio 是一个应用程序，而不是一个库，该政策现在是最终的，而非暂定的。

aarambh-studio 可以在没有 GPU 的情况下运行吗？可以，在 Tiny 规模下。该流水线可以在仅 CPU 的硬件上进行训练和推理，而 CUDA 支持——包括稀疏 MoE 调度和多节点训练——可用于更大规模。

在哪里可以找到 aarambh-studio 源代码？完整的源代码、发布说明和文档位于 GitHub：github.com/AarambhDevHub/aarambh-studio。

GitHub — aarambh-studio v4.0.0 源码与发布说明：https://github.com/AarambhDevHub/aarambh-studio/releases/tag/v4.0.0

LinkedIn — 系统编程、Rust 与 ML：https://www.linkedin.com/in/darshan-vichhi-rust-developer/

YouTube — Aarambh Dev Hub（Rust 教程与深度解析）：https://www.youtube.com/@AarambhDevHub

如果这篇文章对你有帮助，在 GitHub 仓库上点个 Star 真的能帮助其他开发者找到它。感谢阅读，祝你编码愉快！