统一内存让迷你PC可运行70B大模型而大GPU却不行

背景

桌上放两台机器，每台约 2,000 美元。一台是搭载 NVIDIA RTX 5090 的塔式主机：32GB 有史以来最快的消费级显存，带宽 1,792 GB/s。另一台是如同平装书大小的迷你 PC：AMD Ryzen AI Max+ 395 "Strix Halo" 盒子，拥有 128GB 焊接内存，带宽约 256 GB/s。现在让它们各运行一个 700 亿参数的模型。RTX 5090 做不到——一个 70B 模型做合理的 4-bit 量化需要约 40GB，而 40 放不进 32。小迷你 PC 却毫无怨言地加载了模型，然后以慢速读者的速度生成答案。这个悖论就是整个迷你 PC 品类的缩影：这些盒子能装下速度快得多的 GPU 装不下的模型，代价是速度。理解其中原因归结为两个概念：统一内存（unified memory），以及两个朝相反方向拉动的数字。

核心内容

什么是「统一内存」

在普通台式机中，CPU 有自己的系统 RAM，显卡有自己的独立 VRAM，数据通过 PCIe 总线在两者之间穿梭。模型必须完全放入 GPU 的 VRAM 才能在 GPU 上运行——这就是为什么即使你安装再多系统 RAM，24GB 的显卡也会设置一个硬性的 24GB 天花板。

统一内存机器打破了这种分割。CPU、集成 GPU 和 NPU 共享同一个焊接到主板上的 LPDDR5X 内存池。没有独立的 VRAM，因此几乎整个池都可以分配给模型。购买 128GB 配置，你就拥有了接近 128GB 的「VRAM」让模型运行，价格相当于一块中端显卡。苹果多年来一直以这种方式构建 Mac；AMD 的 Strix Halo、NVIDIA 的 DGX Spark、Intel 的 Core Ultra 以及 Qualcomm 的 Snapdragon X 现在都采用了相同设计。这就是迷你 PC 突然进入本地 LLM 讨论的原因：容量大，而且便宜。

决定一切的两个数字

一台机器是否适合本地 LLM 取决于两个经常被混淆的规格：

• 容量（多少 GB 内存）：决定模型能否加载。这是统一内存迷你 PC 胜出的地方。
• 内存带宽（每秒多少 GB）：决定模型加载后生成文本的速度。这是它们与真正 GPU 相比惨败的地方。

以下是当前格局。带宽数据为理论峰值（实际交付带宽更低，后文会说明）。容量为可用的最高统一配置。

（来源：厂商规格表、Chips and Cheese、NotebookCheck、TechPowerUp。带宽 = 理论峰值。）

读取这张表可以看到两个故事。在迷你 PC 行中，容量上升到 128GB（M3 Ultra 上可达 512GB），而带宽保持在 120~270 GB/s 之间。在 GPU 行中则相反：带宽 900~1800 GB/s，但容量限制在 24~32GB，除非你花 8,500 美元买一块工作站显卡。迷你 PC 和二手 RTX 3090 不是同一个尺度上的两个点——它们是对立面。

为何是带宽而非算力决定速度

要理解为什么快速 GPU 和大容量迷你 PC 表现如此不同，你需要屋顶线模型（roofline model，Williams, Waterman, and Patterson, 2009），这是推理性能的标准方法。它说一个工作负载要么受限于芯片计算有多快，要么受限于从内存中移动数据有多快，取决于哪个先用完。哪一个命中取决于每读取一个字节你做了多少数学运算。

文本生成每字节做的数学运算非常少。为了生成一个 token，机器需要从内存中读取几乎整个模型一次，然后对它做少量算术。因此时钟由内存带宽而不是算力决定。苹果自己的机器学习团队在其 MLX 文档中明确写道：「生成后续 token 受限于内存带宽，而非计算能力。」学术版本也一样。Pope 等人的《Efficiently Scaling Transformer Inference》（2022）将生成延迟建模为主要由从内存流式传输权重的时间主导。

这给了你任何机器的粗略速度上限：

解码 token/秒 ≈ 内存带宽 ÷ 每次 token 读取的字节数

对于 4-bit 的稠密 70B 模型（每次 token 读取约 40GB），在带宽 256 GB/s 的 Strix Halo 盒子上，就是 256 ÷ 40 ≈ 6 tokens/s（上限，实际更低）。在 819 GB/s 的 M3 Ultra 上，同一模型得到 819 ÷ 40 ≈ 20。在 1,792 GB/s 的 RTX 5090 上，上限约为 45，但模型根本放不进去。迷你 PC 的缓慢不是驱动问题或芯片弱——而是带宽数字上的算术。

有一个重要的例外值得了解，因为这是迷你 PC 的最佳技巧：混合专家模型（Mixture-of-Experts, MoE）。像 Qwen3-30B-A3B 这样的 MoE 拥有 30B 参数，但每个 token 只激活约 3B，因此每次 token 读取约 2GB 而不是 40GB。在同一个在稠密 70B 上以 5 tokens/s 爬行的 Strix Halo 盒子上，用户测得该 MoE 约为 72 tokens/s。如果你想让迷你 PC 感觉快，就在上面运行 MoE 模型。

没人写在盒子上的问题：提示处理（Prompt Processing）

解码速度是每个人都会引用的数字。而在迷你 PC 上破坏体验的另一个数字是：提示处理（也称为 prefill），即模型在输出第一个词之前读取你的输入所花费的时间。

Prefill 与解码相反。它并行处理整个 prompt，对原始计算能力要求很高，因此受限于芯片的 FLOPS，而不是带宽。Splitwise 论文（Patel et al., 2023）清晰划出了界线：LLM 推理是「一个计算密集型的 prompt 计算阶段，和一个内存密集型的 token 生成阶段」。两个阶段，两个不同的瓶颈。

这正是迷你 PC 最痛苦的地方，因为它们的集成 GPU 的算力只有独立显卡的一个零头。解码可能看起来尚可接受，而 prefill 会崩塌。用户对 Strix Halo 使用 llama.cpp 的基准测试显示了这种分割（单次运行，未取平均，且对驱动版本敏感）：

（用户测量，Level1Techs 论坛基准测试线程。单次运行，仅作方向性参考。）

看稠密 70B 那一行。提示处理速度为 95 tok/s 意味着一个 4,000 token 的文档（一封长邮件线程、一个代码文件、几页笔记）需要大约 40 秒才能被模型读取，然后才输出第一个词。The Register 的实操比较发现了相同的模式，并指出当上下文窗口更大时差距「会大幅扩大，因为 prompt 处理变成计算受限」。如果你的用例是长文档或大型代码库，那么这才是你会撞上的墙，而不是 tokens/s。

NPU 多数情况下是红鲱鱼

每一款这些芯片都标榜着巨大的 NPU TOPS 数字，买家合理认为 NPU 就是运行 AI 的部分。对于本地 LLM 聊天，它基本上没什么用。有两个原因。

第一，NPU 与其他部件共享同一块内存。由于解码受限于内存带宽，将工作转移到 NPU 并不能提高上限，只是移动了同一个瓶颈。一项对这些芯片的特征化研究（Chen et al., 2025）发现，单流解码在 CPU、GPU 和 NPU 上都是内存带宽受限，无法有效利用 NPU 的并行计算能力。

第二，人们使用的软件——llama.cpp 和 Ollama——并不驱动 NPU。Intel 的 OpenVINO 路径最近才进入 llama.cpp，且带着实验级的限制。AMD 的 NPU 根本没有主流的本地 LLM 后端。当 The Register 尝试 AMD 自己的 NPU 卸载时，一个 7B 模型生成速度只有「4-5 tokens/s，而我们原本期望接近 40」。NPU 在小型、始终在线的视觉和音频任务中发挥价值，而不是运行聊天机器人。

用户报告的内容

抛开营销，实际报告是一致的。在容量上，胜利是真实的：ServeTheHome 对 128GB Strix Halo 盒子的评测指出，它运行了 Llama 3.