统一内存，详解：为何迷你PC能运行大型GPU无法运行的70B模型

# 统一内存详解：为什么迷你PC能跑大GPU跑不了的70B模型（以及哪里会变慢） 把两台机器放在桌上，每台大约2000美元。一台是塔式机箱，搭载 NVIDIA RTX 5090（https://vettedconsumer.com/rtx-5090-a-32gb-ai-powerhouse-or-an-expensive-way-to-game/）：32GB 有史以来最快的消费级显存，带宽 1,792 GB/s。另一台是巴掌大小的迷你PC，搭载 AMD Ryzen AI Max+ 395 "Strix Halo"，焊死了128GB内存，带宽约 256 GB/s。现在让它们各自运行一个700亿参数的模型。 RTX 5090做不到。一个70B模型采用合理的4位量化大约需要40GB，40装不进32里。而那台小迷你PC毫无怨言地加载了它，然后以慢读的速度回答。这个悖论就是整个迷你PC品类的缩影：这些盒子能*装下*一个更快GPU装不下的模型，代价是速度慢。理解这一点，关键在于一个概念——统一内存，以及两个朝相反方向拉动的数字。 我们自己并没有对这些盒子进行基准测试。以下内容综合了供应商规格、推理文献以及用户实测数据，所有来源都在文末列出。 ## "统一内存"是什么意思 在普通的台式机中，CPU有自己的系统内存，显卡有自己独立的显存，数据通过PCIe总线在两者之间传输。模型必须完全放入GPU的显存才能在GPU上运行，这就是为什么无论你装了多少系统内存，24GB的卡就硬性设定了24GB的上限。 而统一内存的机器则抛弃了这种分割。CPU、集成GPU和NPU都共享同一个焊死的LPDDR5X内存池。没有独立的显存，因此几乎整个内存池都可以分配给模型使用。买128GB配置，你就拥有接近128GB的"显存"来容纳模型，价格大约相当于一块中端显卡。苹果多年来一直这样制造Mac；AMD的Strix Halo、NVIDIA的DGX Spark、Intel的Core Ultra和Qualcomm的Snapdragon X现在也都这么做。这就是迷你PC突然进入本地LLM讨论的原因：容量大，还便宜。 ## 决定一切的两个数字 一台机器是否适合运行本地LLM，取决于人们经常混淆的两个规格： - **容量**（多少GB内存）：决定了*模型能否加载*。这是统一内存迷你PC赢的地方。 - **内存带宽**（每秒多少GB）：决定了*加载后生成文本的速度*。这是它们远远输给真正GPU的地方。 以下是当前的格局。带宽数据是理论峰值（实际交付的带宽更低，这一点我们稍后会谈到）。容量是可用的最高统一配置。 | 机器（SoC） | 内存总线 | 峰值带宽 | 最大统一内存 | | :--- | :--- | :--- | :--- | | Intel "Lunar Lake" (Core Ultra 200V) | 128位 LPDDR5X-8533 | ~137 GB/s | 32 GB | | Qualcomm Snapdragon X2 Elite | 128位 LPDDR5X | ~152 GB/s | 最高128 GB | | Intel "Panther Lake" (Core Ultra X) | 128位 LPDDR5X-9600 | ~154 GB/s | 96 GB | | Qualcomm Snapdragon X2 Elite Extreme | 192位 LPDDR5X | ~228 GB/s | 最高128 GB | | AMD Ryzen AI Max+ 395 "Strix Halo" | 256位 LPDDR5X-8000 | 256 GB/s | 128 GB | | NVIDIA DGX Spark (GB10) | 256位 LPDDR5X-8533 | 273 GB/s | 128 GB | | Apple M4 (Mac mini) | 128位 | 120 GB/s | 32 GB | | Apple M4 Pro (Mac mini) | 256位 | 273 GB/s | 64 GB | | Apple M4 Max (Mac Studio) | 384至512位 | 410至546 GB/s | 128 GB | | Apple M3 Ultra (Mac Studio) | 1024位 | 819 GB/s | 最高512 GB | | **对比：独立GPU（快得多，容量小得多）** | | | | | RTX 3090 / 4090 | 384位 GDDR6X | 936 / 1,008 GB/s | 24 GB | | RTX 5090 | 512位 GDDR7 | 1,792 GB/s | 32 GB | | RTX PRO 6000 Blackwell (~$8,500) | 512位 GDDR7 | 1,792 GB/s | 96 GB | | 来源：供应商规格表、Chips and Cheese、NotebookCheck、TechPowerUp。带宽 = 理论峰值。 | 把表格当作两个故事来读。在迷你PC的行里，容量攀升至128GB（M3 Ultra上可达512GB），而带宽保持在约120到270 GB/s之间。在GPU的行里，情况正好相反：带宽900到1,800 GB/s，但容量被限制在24到32GB，直到你买得起8500美元的工作站显卡。一台迷你PC和一块二手RTX 3090（https://vettedconsumer.com/the-used-rtx-3090-in-2026-why-a-five-year-old-gpu-is-still-local-ais-best-deal/）并不是同一尺度上的两个点。它们是相反的。 ## 为什么是带宽而非算力决定了速度 要理解为什么快的GPU和空间大的迷你PC表现如此不同，你需要了解**屋顶线模型**（https://doi.org/10.1145/1498765.1498785?ref=vettedconsumer.com）（Williams, Waterman, and Patterson, 2009），这是分析性能的标准方法。它指出，一个工作负载要么受限于芯片的计算速度，要么受限于从内存搬运数据的速度，看哪个先耗尽。哪个瓶颈起作用，取决于你每读取一个字节要执行多少数学运算。 文本生成几乎不费算力。为了生成一个token，机器需要从内存中读取整个模型一次，然后对其进行少量的算术运算。因此，时钟是由内存带宽设定的，而不是算力。苹果自己的机器学习团队在他们MLX文章（https://machinelearning.apple.com/research/exploring-llms-mlx-m5?ref=vettedconsumer.com）中明确写道："生成后续token受限于内存带宽，而非计算能力。"学术版也是一样。Pope等人2022年的论文"Efficiently Scaling Transformer Inference"（https://arxiv.org/abs/2211.05102?ref=vettedconsumer.com）将生成延迟建模为主要由从内存流式加载权重的时间决定。 这就给出了任何机器的粗略速度上限： > **解码token/秒 ≈ 内存带宽 ÷ 每个token读取的字节数** 对于一个稠密的70B模型，4位量化（每个token大约读取40GB），在256 GB/s的Strix Halo盒子上，计算为256 ÷ 40，理论上限约6 token/s，实际更低。在819 GB/s的M3 Ultra上，同样的模型得到819 ÷ 40，约20 token/s。在1,792 GB/s的RTX 5090上，上限大约45，但模型根本装不下。迷你PC的慢不是驱动问题或芯片弱。就是对带宽数字的算术运算。 有一个重要的例外值得一提，因为这是迷你PC的最佳技巧：**混合专家模型**（https://vettedconsumer.com/mixture-of-experts-moe-explained-why-active-parameters-decide-what-runs-on-your-machine/）。像Qwen3-30B-A3B这样的MoE模型有300亿参数，但每个token只激活大约30亿，因此每个token读取大约2GB，而不是40GB。在同一台处理稠密70B模型只有5 token/s的Strix Halo盒子上，用户测得该MoE模型大约有72 token/s。如果你想让迷你PC感觉很快，就在上面运行MoE模型。 ## 没人写在宣传册上的陷阱：提示处理 解码速度是每个人都会引用的数字。而在迷你PC上毁了体验的，是另一个数字：提示处理，也叫预填充，即读取你的输入并返回第一个词所用的时间。 预填充与解码相反。它需要并行处理整个提示，对原始算力要求很高，因此受限于芯片的TFLOPS，而不是带宽。Splitwise论文（Patel等人，2023（https://arxiv.org/abs/2311.18677?ref=vettedconsumer.com））清晰地划出了界限：LLM推理是"计算密集型的提示计算，以及内存密集型的token生成"。两个阶段，两个不同的瓶颈。 这正是迷你PC的痛处，因为它们的集成GPU只有独立显卡算力的一小部分。解码看着还行，但预填充会急剧下降。用户在Strix Halo上用llama.cpp进行的基准测试显示了这种差异（单次运行，未平均，且对驱动版本敏感）： | Strix Halo上的模型（Q4） | 提示处理 | 文本生成 | | :--- | :--- | :--- | | Llama 2 7B | 1,014 tok/s | 45.8 tok/s | | Qwen3 30B-A3B (MoE) | 605 tok/s | 72.0 tok/s | | Shisa V2 70B (稠密) | 94.7 tok/s | 5.0 tok/s | | 用户实测，Level1Techs论坛基准测试帖子。单次运行；仅供参考。 | 看看稠密70B那一行。提示处理速度95 tok/s意味着一个4000 token的文档（一封长邮件线程、一个代码文件、几页笔记）需要大约40秒来读取，*然后模型才开始说话*。《The Register》的实际对比发现了同样的模式，并指出"随着上下文窗口变大，差距会大幅扩大，因为提示处理变成计算受限"如果你的使用场景是长文档或大代码库，那么你遇到的瓶颈将不是每秒token数，而是这个。 ## NPU基本上是个幌子 这些芯片中的每一个都标榜一个很高的NPU TOPS数字，买家理所当然地认为NPU就是运行AI的部件。对于本地LLM对话来说，它基本上没用。两个原因。 第一，NPU与所有其他部件共享同一块内存。由于解码受限于内存带宽，将工作转移到NPU并不会提高上限，只是把同一个瓶颈搬了个位置。对这些芯片的特性研究（Chen等人，2025（https://arxiv.org/abs/2501.14794?ref=vettedconsumer.com））发现，单流解码在CPU、GPU和NPU上都受限于内存带宽，无法充分利用NPU的并行计算能力。 第二，人们使用的软件，llama.cpp和Ollama，并不驱动NPU。Intel的OpenVINO路径最近才加入llama.cpp，并且带有实验级别的限制。AMD的NPU根本没有主流的本地LLM后端。《The Register》尝试了AMD自家的NPU卸载，一个7B模型生成速度只有"4-5 token/s，而我们预期应该接近40"。NPU在持续运行的小型视觉和音频任务上更有用，而不是用来跑聊天机器人。 ## 用户反馈的情况 抛开营销宣传，现场报告是一致的。在容量方面，胜利是真实的：ServeTheHome对128GB Strix Halo盒子的评测指出，它运行了Llama 3.3 70B，这个模型"需要超过50GB的显存"，是"即使是NVIDIA L40S这类GPU"也无法装下的。这就是购买它的理由。 在速度方面，稠密70B模型的单位数token速度是预期值。两个独立来源得出了相近的数字：ServeTheHome测得Llama 3.3 70B为3.7到3.8 tok/s，一个被广泛引用的Framework论坛测试者测得稠密70B为5.0 tok/s。可用于批处理任务和有耐心的聊天，不适合任何交互式使用。 在软件方面，AMD的盒子以及其他品牌的盒子（程度稍轻）仍然需要耐心。《The Register》的测试者遇到了需要调整内核才能解决的GPU挂起，必须从源码编译部分软件栈，一位用户报告说一次官方ROCm更新在一夜之间将一个模型上的提示处理速度*减半*。NVIDIA的DGX Spark在这方面更顺畅，"几乎所有在CUDA上运行的软件"都能工作，但价格昂贵，其273 GB/s的内存将解码速度限制在同样个位数到低两位数的范围内，尽管其GPU强大得多。 ## 那么，哪款迷你PC，适合什么用途 | 你的目标 | 选择 | | :--- | :--- | | 快速运行最高约8B的模型，低功耗，始终在线 | 任何32GB统一内存盒子（Mac mini M4, Lunar/Panther Lake, Snapdragon X2）。这个规模的模型带宽够用。 | | 良好运行30B级别的MoE模型 | 64至128GB统一内存盒子。MoE保持解码速度快（60至70+ tok/s），尽管带宽不高。 | | 便宜地*至少能运行*稠密70B模型，用于批处理或有耐心的用户 | 128GB Strix Halo（Framework Desktop, GMKtec EVO-X2, Beelink GTR9）或64GB+ Mac。预期4到6 tok/s。 | | *快速*运行稠密70B模型，或处理长提示 | 不是迷你PC。选择48GB双GPU配置，或租用云端GPU。带宽和预填充算力是关键。 | | 本地运行前沿规模模型（200B+） | 只有Mac Studio M3 Ultra（最高512GB）是单机箱选项，MoE模型使其可行。否则使用API。 | 一句话概括：统一内存的迷你PC是容量机器，不是速度机器。当你要运行的模型对你买得起的任何GPU来说都太大，而你能接受慢读的速度和缓慢的提示输入时，它就找到了自己的位置。当模型能装进真正的GPU时，GPU在每一个重要维度上都赢。根据模型选机器，而不是根据贴纸上的TOPS来选。 要了解某台特定机器能运行什么以及多快，请将你的配置输入"我能运行它吗？"计算器（https://vettedconsumer.com/can-i-run-it/），使用量化选择器（https://vettedconsumer.com/quant-picker/）选择合适的文件大小，以及硬件速查表（https://vettedconsumer.com/the-local-llm-hardware-cheat-sheet-which-box-runs-which-model/）将模型大小映射到能装下它的最便宜盒子。 ## 来源及我们的研究方法 我们没有亲测过这些硬件。本文综合了主要规格、推理文献以及用户实测的基准测试。框架是屋顶线模型（Williams, Waterman, Patterson, CACM 2009（https://doi.org/10.1145/1498765.1498785?ref=vettedconsumer.com））。预填充与解码的区分基于Splitwise（Patel等人，2023）（https://arxiv.org/abs/2311.18677?ref=vettedconsumer.com）和Efficiently Scaling Transformer Inference（Pope等人，2022）（https://arxiv.org/abs/2211.05102?ref=vettedconsumer.com），内存带宽受限的解码点由苹果的MLX团队（https://machinelearning.apple.com/research/exploring-llms-mlx-m5?ref=vettedconsumer.com）亲自证实。NPU分析参考了Chen等人（2025）关于移动SoC LLM推理的论文（https://arxiv.org/abs/2501.14794?ref=vettedconsumer.com）。硬件规格来自供应商规格表、Chips and Cheese、NotebookCheck和TechPowerUp。用户及评测者数据来自ServeTheHome（https://www.servethehome.com/gmktec-evo-x2-review-an-amd-ryzen-ai-max-395-powerhouse/3/?ref=vettedconsumer.com）、Framework社区论坛（https://community.frame.work/t/amd-strix-halo-ryzen-ai-max-395-gpu-llm-performance-tests/72521?ref=vettedconsumer.com）、Level1Techs基准测试帖子（https://forum.level1techs.com/t/strix-halo-ryzen-ai-max-395-llm-benchmark-results/233796?ref=vettedconsumer.com）以及The Register（https://www.theregister.com/2025/12/25/amd_strix_halo_nvidia_spark/?ref=vettedconsumer.com）。用户数据是单次测量，因模型、量化、运行时和驱动版本而异。 - 带宽，而非TFLOPS（https://vettedconsumer.com/bandwidth-not-tflops-what-sets-your-local-llm-speed-and-why-the-newest-card-isnt-always-fastest/）：为什么内存数字设定你的速度 - 提示处理 vs 生成（https://vettedconsumer.com/prompt-processing-vs-generation-why-your-box-is-fast-at-one-and-slow-at-the-other/）：两个阶段的深入解析 - 运行70B模型实际需要多少显存（https://vettedconsumer.com/how-much-vram-do-you-actually-need-to-run-a-70b-model-locally/）：容量计算 - Strix Halo vs DGX Spark（https://vettedconsumer.com/strix-halo-vs-dgx-spark-running-70b-locally-according-to-people-who-own-both/）：两大统一内存盒子正面对决 - 混合专家模型，详解（https://vettedconsumer.com/mixture-of-experts-moe-explained-why-active-parameters-decide-what-runs-on-your-machine/）：为什么MoE模型在这些盒子上跑得快