一年前，运行万亿参数的语言模型意味着一整间机房。机架、冷却系统，以及一笔需要专门开会讨论的电费账单。后来 AMD 发布了一篇开发者技术文章，展示了四台摆在桌面上的迷你 PC（那种你一次能拎两台的尺寸）完成同样的工作。四个一模一样的小盒子，用线缆连在一起，运行着一个参数数量比你在城市街道上能看到的星星还多的模型。
标题不言自明：「没有云。没有数据中心。」而且这是真的。AMD 确实在四台 Framework Desktop 系统 上运行了它，里面装的还是消费级芯片。
但标题略过了一部分，而恰恰是这一部分决定了它究竟是一座里程碑还是一个魔术把戏。有一个架构细节让「万亿参数」在技术上站得住脚，有一个隐情决定了你能否真正用上这东西，还有一个理由，让它的意义比鼓吹和反对的声音所认可的都要大。
简短版本
- 这个模型是 Kimi K2.5，采用 Mixture-of-Experts 设计：总共 1.04 万亿参数，但任意一个 token 上只有约 320 亿个参数会被激活。「万亿参数模型」的说法是准确的；而每个 token 的实际计算量更接近一个 32B 级别的工作负载。
- 这个集群每秒生成大约 8 到 9.5 个 token，首 token 时延则从 39.7 秒到 239.1 秒不等，取决于你的提示词有多长。用于批处理工作绰绰有余，用于交互式编程循环则痛苦至极。
- 改变的不是速度。而是统一内存把前沿规模的推理搬到了你买得到、摆得上架子的硬件上——这个门类过去的起步价是「拥有一座数据中心」。
AMD 究竟做了什么
一旦把整套配置摊开来看，几乎让人觉得平淡无奇。四台 Framework Desktop 机器，每台搭载一颗 Ryzen AI Max+ 395 和 128 GB 的 LPDDR5X 统一内存。在 BIOS 中，每个节点最多可划出 96 GB 作为专用 VRAM，四个节点合计 384 GB；AMD 的 Linux 操作指南随后通过 TTM/内核设置将其提升至每节点 120 GB，即总共 480 GB。这一点很关键，因为 AMD 所用的 Kimi K2.5 UD_Q2_K_XL GGUF 构建版本标注的大小是 375 GB，而非 240 GB。
把它们粘合在一起的是以 RPC 模式运行的 llama.cpp：一个控制器节点加三个 RPC 服务器，模型分布在全部四台机器上。AMD 列出的互联方式是 5 Gbps Ethernet，正好对应 Framework Desktop 内置的 5Gbit Ethernet 端口。这就是整套装置。没有奇异的互联方案，没有定制主板，没有任何你今天下午订不到的东西。
这一切中最有意思的词是 统一。在一台普通 PC 上，你的 CPU 内存和 GPU 的 VRAM 是两个独立的池子，一个对 VRAM 来说太大的模型要么溢出到缓慢的系统内存，要么干脆跑不起来。统一内存推倒了这堵墙：GPU 可以寻址整块内存，而这正是一台 4.5 升的桌面机能装下这么大模型一部分的全部原因。
AMD 自家的 技术文章 详细介绍了配置。它没怎么讲到的，是为什么「万亿参数」承担的修辞分量比它看上去要重。
玄机：为什么「万亿参数」是真的，却不是全部真相
规格表倚重却没解释清楚的一点是：Kimi K2.5 是一个 Mixture-of-Experts 模型，这改变了「万亿参数」在实践中的含义。
一个稠密模型，也就是大多数人脑海里浮现的那种，对每个 token 都会运行全部参数。一个 700 亿参数的稠密模型，对它产出的每个词都要做 700 亿参数量级的运算。Mixture-of-Experts 模型的构建方式则不同。Kimi K2.5 拥有 384 个独立的「专家」，每个 token 激活其中 8 个外加一个共享专家，分布在 61 层之中。所以尽管这个模型总共携带 1.04 万亿参数，但任意一次前向传播中只有约 320 亿个会被点亮。一个路由器挑选唤醒哪些专家；其余的就在那里待着，对那个 token 什么也不做。
那么「在四台迷你 PC 上运行万亿参数模型」诚实吗？是的，你确实需要足够的内存来容纳全部 1.04 万亿参数，而这块内存正是难点所在。但你的硬件每个 token 必须完成的计算量是一项 32B 级别的活儿，而不是 1T 级别的。
这把双刃剑两头都割人，而有意思的地方就在这里。它让这个演示比听上去 更 令人印象深刻，因为在消费级盒子上把一个完整的万亿参数模型装进内存，才是他们真正攻克的硬骨头。同时它也让这件事比标题暗示的 更不 令人印象深刻，因为实际的每 token 工作负载，是单台盒子在更小的 MoE 模型上早已能更快嚼下来的东西。一个 120B 的 MoE 模型在 这其中一个节点上能跑出每秒 50 多个 token。万亿参数这个数字是真的，但它秀的是内存，而不是算力。
要点是： 当你为一个模型选配硬件时，激活参数量才是你的机器每个 token 必须供给的部分，而不是盒子上的总量。
隐情：每秒 8 个 token 和 40 秒到 4 分钟的等待究竟意味着什么
每秒 8 个 token 是决定一切的数字，所以请花点时间细品。AMD 的文章报告称，集群在 8,192-token 上下文下生成约 8.30 t/s，稳态下约 9.45 t/s，提示词处理约 100.77 t/s。就其本身而言，这些都是不错、公道的数字。
真正令人难受的是首 token 时延。在模型吐出第一个词之前，它得先读完你的提示词，而 AMD 自家的基准测试表把这段等待标为：4,096-token 提示词 39.7 秒，8,192-token 提示词 90.5 秒，启用 Flash Attention 的 16,384-token 提示词 239.1 秒。所以你敲下一个问题，然后等待。可能要等将近四分钟，才有任何东西回来。
对一个交互式编程循环来说，这很难受，而 Hacker News 讨论 中的开发者们直言不讳地说了出来：在第一个 token 之前一分多钟的死寂，根本不符合任何人借助助手写代码的方式。但把工作负载反过来看。如果你是在通宵跑批处理作业、异步处理文档、生成稍后才读的内容，或者在做隐私推理——其全部意义就在于任何东西都不离开这栋楼——那么每秒 8 个 token 完全可以接受。反正你也没盯着屏幕看。
注脚： 别指望这些数字能开箱即现。这套硬件上的 ROCm 软件栈对版本敏感，而且咬人咬得很实在： 一个 GitHub issue 记录了 一台 Strix Halo 系统在 ROCm 7.1.1 和 Linux 内核 6.14 下做 LLM 推理时，GPU 卡在空闲频率，慢吞吞地只跑出 0.5 t/s。这不是说「AMD 坏掉了」，但它确实意味着已公布的性能依赖于一套非常特定的软件栈，你可能得在 ROCm、内核和固件的组合之间一路追逐，才能让你的装置跑出文章里的数字。
反对声音搞错的另一件事，是成本。人们一直把它叫作「一万美元的集群」，但没人把那当成一份固定的物料清单来公布。你自己算算：四台 128 GB 的 Framework Desktop 按 1,999 美元的首发价，单是机器就约 8,000 美元，而 2026 年 3 月 Liliputing 的一份快照 把一台 128GB/1TB 的 Framework Desktop 配置列为 2,851 美元，四台在不算组网的情况下约为 11,400 美元。再加上几百美元的交换机和线缆，实际区间更接近大约 8.2K 到 11.7K 美元，取决于配置、购买日期以及你已经有的东西。这不是小钱。但也不是一间机房。
我对整件事的结论落在这里：这个集群是能用的。每秒八个 token 加一分多钟的等待，究竟是一场胜利还是一个玩具，完全取决于你想搭建什么。它不是一台交互式编程工作站。它也不是一个玩具。它是一台为某种需要耐心的特定工作而生的真机器，而假装它比这更多或更少，正是这场争论里每个人最终各说各话、彼此错过的根源。
这件事到底落在哪里
诚实的表述不是「AMD 击败了 Nvidia」。而是说，这是面向不同人群的一款不同产品。想要这东西的读者，是那个需要隐私、想要离线、或不愿永远按 token 付费的人，而不是那个追求尽可能最快响应的人。
而反对整个尝试的最有力论点值得一个直截了当的回答：你大可以直接调 Kimi 的 API。Artificial Analysis 目前把 Kimi 自家的 K2.5 端点 列在每秒约 56 到 60 个 token、混合价格约每百万 token 0.49 美元，而 Kimi 的官方 API 平台 列出的 K2.5 定价为：缓存命中输入 token 每百万 0.10 美元，输入 token 每百万 0.60 美元，输出 token 每百万 3.00 美元。第三方 K2.5 服务商根据路由可能更快或更便宜，但基本结论是一样的：API 比集群更快，免去了照看硬件的麻烦，对大多数人在大多数日子里都是正确的选择。
所以本地方案只有在以下三件事之一成立时才说得通：数据不能外流（隐私）、连接不能假定存在（离线），或者 token 用量足够高且足够持续，以至于自己拥有这台机器比永远租用更划算（规模化成本）。在这三者之外，API 取胜。在这三者之内，集群是唯一能把活儿干成的东西。
| 维度 | AMD 四节点集群 | Kimi API / 云端路线 |
|---|---|---|
| 生成速度 | 约 8 到 9.5 t/s | 在 Kimi 自家 K2.5 端点上约 56 到 60 t/s |
| 首 token 时延 | 39.7 到 239.1 秒 | 取决于服务商，低得多 |
| 成本模型 | 约 8.2K 到 11.7K 美元的硬件 | 按 token 计费的 API 定价 |
| 隐私 / 离线 | 完全本地 | 由服务商托管 |
| 最契合的用例 | 私有、离线、批处理工作 | 交互式 / API 使用 |
需要说明的是，Nvidia 的 DGX Spark 是这里显而易见的「那要不试试它」选项，而且它在 AMD 集群拿不下的某些维度上胜出。那是另一场完全独立的较量，我会在别处展开。如果你想了解硬件对云这道选择题里租用的那一面， Cloudzy 的 GPU VPS 页面是更实用的对比点。
真正重要的那部分
剥去 token 速率和价格之争，剩下一个事实屹立不倒：运行万亿参数模型的硬件，如今是一个架子，而不是一栋楼。
这就是那个转变，在速度的口角声中很容易被忽略。一年前，能运行 1.04 万亿参数模型的人这一 门类 是「数据中心运营商」。句号。如今它包括任何拿得出大约一万美元和一些耐心的人。这条线挪动的可不止一点：一整群新的人刚刚走过了一扇曾经上着锁的门。
它打开的东西才是有意思的部分。完全运行在你自己拥有的硬件上的私有智能体。在飞机上或在物理隔离环境后面也能工作的推理。物理上无法「回家报告」的模型，因为根本无处可呼。一种 AI 的经济学，其中一个 token 的边际成本是电费，而不是一条计量的 API 线路。一年前，这些在消费级硬件上没有一项是触手可及的，而统一内存正是那个把它们够到了的东西。
我见过这种套路够多次了，对「这将改变一切」抱有戒心。通常它不会；通常那只是去年那玩意儿换了个新 logo。这一次不同，原因不在于它快。它之所以不同，是因为地板挪动了。前沿规模本地推理那个缓慢、昂贵、需要耐心的版本现在存在了，而快速版本只是接下来几代硬件把它磨下去的时间问题。难点从来都不会是速度。难点是准入，而准入刚刚发生了。
这里的里程碑不是速度。而是谁被允许进入这个房间。 运行前沿规模模型的机器过去是一栋楼。如今它是架子上的四个盒子。
常见问题
你真的能在一个迷你 PC 集群上运行万亿参数模型吗？
可以，但有一个重要的前提。AMD 在四台 Ryzen AI Max+ 395 迷你 PC 上运行了 Kimi K2.5，一个 1.04 万亿参数的模型。在 BIOS 中，这四台系统总共可划出约 384 GB 的专用 VRAM；AMD 的 Linux 操作指南随后通过 TTM/内核设置将分配提升至总共 480 GB。但 Kimi K2.5 是一个 Mixture-of-Experts 模型：在那 1.04 万亿参数中，任意一个 token 上只有约 320 亿个会被激活。你需要内存来容纳全部参数，但每个 token 的计算量更接近一个 320 亿参数的工作负载。
Kimi K2.5 是什么，以及为什么 MoE 架构在这里至关重要？
Kimi K2.5 是来自 Moonshot AI 的一个开放权重语言模型，总参数 1.04 万亿、每次前向传播激活 320 亿，构建于 Mixture-of-Experts 设计之上（384 个专家，每个 token 激活 8 个外加一个共享）。这个架构之所以重要，是因为决定你的硬件对每个 token 必须计算多少的，是激活参数量而非总量。这正是一个纸面上有万亿参数的模型，竟然能在消费级盒子上运行的原因。
每秒 8 个 token 对本地 AI 来说够快吗？
这完全取决于工作负载。对于批处理、异步作业、离线使用，或任何东西都不能离开你硬件的隐私推理来说，每秒 8 个 token 没问题——你又不是盯着屏幕看。对于交互式编程来说，它很难受，主要是因为这个集群上的首 token 时延，根据提示词长度从约 40 秒到将近 4 分钟不等，而第一个词之前的那段死寂会扼杀一个迭代循环。
为什么不干脆用 Kimi 的 API 呢？
对大多数人来说，你应该用。在当前的 Artificial Analysis 数据中，Kimi 自家的 K2.5 端点比本地集群快得多，而第三方 K2.5 服务商还可能更快或更便宜。本地硬件只有在你需要隐私（数据不能外流）、离线能力（不能假定有连接）或规模化成本（持续的高用量，自己拥有胜过租用）时才说得通。在这些情形之外，API 是更好的选择。
