三台迷你主机硬跑70B大模型！场面十分尴尬

作者 | Tofu

来源 | 至顶AI实验室

三台迷你主机，跑起了单台根本装不下的70B 大模型。

这三台主机就是华硕今年新推出的NUC 16 Pro，官方定位就是冲着本地部署大模型来的。不过每台机器都只有64GB 内存，单看配置似乎并没有很特别。但把三台放在一起，就有点意思了：它们合力加载了一个约75GB 的Llama 3.3 70B dense 模型。

过去两年，本地AI 的想象一直卡在这样一个问题上：大模型能不能离开云端，真正跑进个人电脑、工作站和办公室小服务器里？

YouTube视频博主Alex Ziskind 这次的实验，相当于把这个问题又往前推了一步：当一台机器的内存已经装不下模型时，几台小机器连在一起，能不能临时拼出一台更大的本地AI 设备？

把三台迷你PC，改造成一个AI集群

Alex拿到的是华硕新发布的NUC 16 Pro。它看起来只是一个和Mac mini差不多大的桌面设备，但配置已经相当激进。

这台机器可以搭载Intel Core Ultra Series 3 处理器，是华硕在2026 年3 月正式发布的新一代NUC 迷你主机，在国内的首发价格是10999元。官方给它的定位是面向本地AI、边缘AI 和企业轻量部署的Copilot+ PC：最高可选Core Ultra X9，平台AI 性能最高180 TOPS，X7/X9 版本支持最高96GB LPDDR5x 内存。

Alex Ziskind手里的版本是Core Ultra X7 358H；内部还有新一代Arc B390 GPU，以及独立NPU，也就是专门用于AI 加速的神经网络处理单元。每台机器配有64GB 内存，接口也很丰富：双Thunderbolt、双HDMI、多个USB-A、双以太网口，还支持Wi-Fi 7。

如果只把它当作开发机，它已经足够体面。写代码、跑IDE、做本地服务、调小模型，都不再是几年前迷你PC那种“能用但别太指望”的状态。

不过Alex 想试试更刺激的。

他把三台NUC 连接起来，尝试拆分同一个大模型。问题的起点很简单：一台64GB 内存的NUC 16 Pro 装不下一个75GB 左右的70B dense 模型，但三台加起来就有192GB 内存。既然内存总量够了，模型能否被切成几块，分别塞进三台机器里运行？

本地AI 的理想状态，一直是开发者拥有自己的模型、自己的数据和自己的推理环境，不必每次调用都依赖云端API，也不用担心数据上传之后的隐私边界。但当模型规模变大，单机内存和显存很快就会成为硬限制。Alex 的实验，其实是在验证一种更便宜、更灵活的可能性：几台桌面小机器能不能临时拼出一个“小型AI 机房”。

GPU能加速，但只加速了一半

在真正组集群之前，Alex 先做了单机测试。

他要弄清楚一个基础问题：这套硬件里面，CPU、GPU、NPU 到底谁更适合跑大语言模型？

第一组结果很漂亮。使用GPU 之后，模型处理prompt 的速度明显提升。原本CPU 读取上下文的速度大约是每秒1000 多个token，切到Arc GPU 后提升到约2200 tokens/s，接近翻倍。

这对于真实开发场景很重要。

当一个代码助手读取整个项目文件、分析长文档、总结一段很长的上下文时，模型首先要做的就是prompt processing。这个阶段可以并行计算，GPU 的吞吐能力能够发挥出来，所以速度提升明显。

真正尴尬的地方出现在第二阶段。

模型开始逐字生成答案后，CPU 和GPU 的速度几乎一样，大约都在46 tokens/s 左右。GPU 算力更强，却没有让生成速度明显变快。

原因在于，大语言模型推理有两种瓶颈。处理prompt 时，算力很关键；生成token 时，内存带宽更关键。每生成一个新token，模型都要不断访问权重和缓存。在这类集成架构上，CPU 和GPU 共用同一套内存，最终速度被内存带宽卡住。

Alex把它称为memory wall，内存墙。

这也是本地AI 硬件经常被忽视的问题。很多产品会强调TOPS、GPU 核心数、AI 加速单元，但在大模型生成环节，单纯堆算力无法绕过内存访问压力。算得再快，数据喂不上来，token 生成速度就很难上去。

NPU省电，却输在生态和效率

既然GPU 在生成阶段被内存卡住，那专门为AI 设计的NPU 会不会更好？

Alex很快遇到了第一个问题：常用的Llama.cpp 不能调用这颗NPU。为了让NPU 参与测试，他只能换到Intel 自家的OpenVINO。

小模型可以跑，大模型却不顺利。更尴尬的是，Intel 自己预先构建好的OpenVINO 模型，放到Intel 自己的NPU 上居然也会失败。Alex 最后只能自己重新转换模型，才把测试跑通。

这很像今天很多AI PC 硬件的现实状态：芯片已经发布，宣传很漂亮，但开发者真正用起来时，软件栈还处在追赶阶段。

跑通之后，NPU 的特征也比较清晰。它的功耗最低，发热更小，机器更安静。测试中，NPU 生成时大约消耗17W，GPU 大约24W，CPU 接近30W。

单看功耗，NPU 很有优势。

但如果看“每生成一个token 消耗多少能量”，GPU 反而赢了。因为GPU 速度更快，完成同样任务所需时间更短，摊到每个token 上，总能耗更低。

这给AI PC 的NPU 叙事泼了一盆冷水。NPU 很适合低功耗、轻量化、后台型AI 任务，也适合长时间安静运行。但在当前软件和模型适配状态下，它还没有成为本地大模型推理的主力。

更尴尬的是，同一块Intel GPU 上，Llama.cpp + Vulkan 的速度明显超过Intel 自家的OpenVINO。前者大约34 tokens/s，后者只有大约14 tokens/s，差距达到2.5 倍左右。

可见，硬件强不强是一回事，但软件能不能把它榨出来，就是另一回事了。

模型切分成功了，速度却被砍半

单机摸底完成后，Alex 开始把三台NUC 接成集群。

他先拿一个单台机器也能装下的Qwen-3-35B 模型做测试。理论上，多台机器一起参与推理，速度应该更快，然而结果却完全相反。

单机运行时，这个模型大约有35 tokens/s；拆到三台机器上之后，只剩约17 tokens/s，几乎砍半。

这里暴露了模型切分集群的核心问题。

当一个模型被拆到多台机器上，每生成一个token，都要在不同机器之间传递中间数据。第一台算完，把结果发给第二台；第二台继续算，再发给第三台；第三台算完后，还要继续进入下一轮。每一个token，都伴随着多次跨机器通信。

在这种模式下，增加机器并不一定增加速度，反而可能增加网络开销。Alex 原本想获得更多算力，结果先获得了一堆通信流量。

这也解释了为什么普通以太网拼出来的小型AI 集群，很难靠模型切分获得明显加速。对于大模型推理而言，机器之间的延迟和通信方式非常关键。没有RDMA 这类低延迟技术，模型切分更多是在解决“装不装得下”的问题，而不是解决“跑得快不快”的问题。

随后，Alex拿出了真正的重头戏：Llama 3.3 70B。

这是一个dense 模型，量化后大小大约75GB，单台64GB 内存的NUC 无法加载。但三台机器合起来有192GB 内存，模型可以被拆分到三台机器中。

这一次，它真的跑起来了。

只不过，速度只有约1.4 tokens/s，慢到并不适合日常使用。但实验意义很明确：三台桌面迷你PC 合力运行了单台机器物理上无法容纳的大模型。

这证明了模型切分集群的价值边界：它能扩展容量，让更大的模型启动；速度表现则高度依赖内存、网络和软件栈。

Thunderbolt没能救场

Alex接着尝试了一个看起来很合理的改进：既然2.5G 以太网太慢，那就换更快的Thunderbolt。

每台NUC 都有两个Thunderbolt 接口，他把三台机器接成三角形拓扑，让每台机器都能直接连接另外两台。Thunderbolt 带宽达到20Gbps 级别，理论上远高于普通2.5G 网口。

结果几乎没有变化。

70B模型在以太网下是1.43 tokens/s，换成Thunderbolt 后仍然是1.43 tokens/s。小模型的情况甚至更糟，不仅速度没有提升，还出现崩溃。

这个结果再次说明，瓶颈不只是“线够不够粗”。

大模型切分带来的通信压力，很多时候体现在大量小消息的往返、同步和延迟上。更高的带宽像是把高速公路拓宽了，但真正堵车的地方可能在路口、调度和红绿灯。

这也是本地集群最容易误判的地方。很多人会凭直觉认为，只要机器够多、连接够快，模型就会跑得更快。Alex 的测试表明，至少在这类迷你PC 和当前软件栈上，事实并没有这么简单。

每台机器各跑一份模型

实验到这里，模型切分这条路已经很清楚：它适合扩容，不适合加速。

Alex最后换了一种集群思路。

如果模型本身能装进单台机器，就不要拆模型。让每台机器都加载一份完整模型，然后把不同请求分发给不同机器。这样，每台机器独立处理任务，集群提升的是总吞吐量。

这一次结果终于变得好看了。

单台机器在负载下大约能处理196 tokens/s；三台机器一起服务，吞吐量接近500 tokens/s，提升到约2.5 倍。

这类架构更接近办公室或小团队本地AI 服务的真实需求。一个人问代码，一个人总结文档，一个人做知识库检索，三台机器各自处理不同请求，体验会明显更好。

Alex最后给出的规则很直接：想运行单机装不下的大模型，就拆分模型；想提升多用户、多请求吞吐，就复制模型并分发任务。这两种集群方式解决的是不同问题，如果把它们混在一起，很容易对本地AI 集群产生误解。

至顶AI实验室洞察

这次实验没有证明三台迷你PC 可以替代专业GPU 服务器，也没有证明AI PC 集群马上会成为主流。它真正说明的是，本地AI 正在进入一个更具体的阶段。

单机能做什么，集群能做什么，NPU 能做什么，GPU 又被什么限制，这些问题正在被真实测试拆开。

对NUC 16 Pro 这类硬件来说，硬件能力已经有明显进步。迷你PC 可以跑本地模型，可以承担开发任务，也可以通过集群方式服务团队。但软件栈仍然存在不少粗糙地带。OpenVINO 对自家NPU 和GPU 的释放还不够充分，Llama.cpp 虽然更快，却还不能调用NPU。硬件已经摆上桌，生态还在缺席。

这也是它和NVIDIA GB10 这类桌面AI 超级计算机最大的区别。GB10 从设计之初就瞄准大模型本地开发。以DGX Spark 为例，它把Grace Blackwell 超级芯片、128GB 统一内存、最高1 PFLOP FP4 AI 性能，以及NVIDIA 自家的AI 软件栈打包在一起，目标就是让开发者在桌面上完成模型测试、推理验证和轻量微调。

更关键的是，GB10 这条路线一开始就把节点互联考虑进去了。DGX Spark 机身后面带有ConnectX-7 和QSFP 网络接口，官方明确给出连接方案，至顶AI 实验室也尝试过把三台DGX Spark 连接起来。当然，它用的也不是普通网线或Thunderbolt 线缆，而是200G QSFP 级别的DAC 线缆，还需要对应的网络配置、NCCL 通信和RDMA/RoCE 链路配合。

所以，Alex 这次实验的价值更像是在回答一个更接地气的问题：买不起专为大模型设计的桌面AI 超算，这样几台迷你主机能否成为“平替”？

我想答案已经很清楚了。

常见问题

Q：三台迷你PC 跑起70B，是不是说明AI PC 已经能替代桌面AI 超算了？

A：还到不了这一步。三台NUC 16 Pro 能把单台装不下的70B 模型跑起来，说明普通AI PC 已经可以通过集群方式突破单机内存限制。但它的生成速度只有约1.4 tokens/s，更多是在证明“能不能跑”，还谈不上“好不好用”。像NVIDIA GB10 / DGX Spark 这类产品，从芯片、统一内存、互连到软件栈，都是围绕大模型开发设计的，稳定性和效率仍然是另一套级别。

Q：既然三台机器一起跑，为什么速度反而变慢？

A：因为它采用的是模型切分。一个模型被拆到三台机器上后，每生成一个token，都要在机器之间来回传递数据。这样做扩大了可用内存，但也引入了网络通信、同步和延迟开销。对于大模型推理来说，瓶颈常常不只是算力，还有内存带宽和节点之间的通信效率。所以三台机器一起上，不一定让单次生成更快。

Q：这种小型AI 集群到底适合什么场景？

A：它更适合两类场景。第一类，是模型太大，单台机器装不下，只能通过切分先让它跑起来，适合实验、验证和技术探索。第二类，是模型本身能装进单机，每台机器各跑一份完整模型，再把不同用户请求分发过去，这样可以提升整体吞吐，更适合办公室、本地开发团队或小型私有AI 服务。真正要追求低延迟、高稳定和少折腾，大模型专用设备依然更省心。

END本文来自至顶AI实验室，一个专注于对AI计算机、工作站及各类AI相关硬件设备，开展基于真实使用场景评测的研究机构。