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

三台迷你主机，跑起了单台根本装不下的


70B


大模型。

这三台主机就是华硕今年新推出的


NUC 16 Pro


，官方定位就是冲着本地部署大模型来的。不过每台机器都只有


64GB


内存，单看配置似乎并没有很特别。但把三台放在一起，就有点意思了：它们合力加载了一个约


75GB


的


Llama 3.3 70B dense


模型。

过去两年，本地


AI


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

YouTube


视频博主


Alex Ziskind


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


AI


设备？

这台机器可以搭载

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


机房”。

他要弄清楚一个基础问题：这套硬件里面，


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


生成速度就很难上去。

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

倍左右。

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

他先拿一个单台机器也能装下的


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


合力运行了单台机器物理上无法容纳的大模型。

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

每台

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


集群产生误解。

单机能做什么，集群能做什么，


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相关硬件设备，开展基于真实使用场景评测的研究机构。