欢迎来到我的小铺，本周聊聊本地跑大模型这件事。
网上聊"本地部署大模型"，最常见的说法是："显存够大，把模型塞进去，给个测试题，它回复了，看一眼生成速度和内容，然后就结束了。"
我现在可以负责任地说：这跟"我把一卡车货卸进了仓库"然后宣布"我开了一家超市"，是一个道理。
货是进去了，可你货架没搭、收银台没装、门都没开呢。
本地大模型部署的门道，没有那么简单。
最近我把 Mac M3 Ultra 256G置换成两台 DGX Spark，并联部署了 DeepSeek V4 Flash 0731 当本地 API 源，正好借机聊聊本地部署。
本地部署这件事，硬件、软件、调优、生态，哪个都不是省油的灯。我打算分几篇，一块一块来。今天先聊硬件——三样物理上的硬指标：显存、内存带宽、算力。 软件上的弯弯绕，放后面。
一、显存：仓库面积，先解决"装得下"
第一个词——显存。这是所有折腾的起点。
你就把显存想成仓库的面积。模型就是你的货，货有多大，就得租多大的仓。货比仓大，塞不进去，一切免谈。
所以"显存够不够"，翻译成人话就是：
你租的仓库，装不装得下这批货。
模型这个"货"有多大？有个笨办法能估：
货的大小 ≈ 货的件数 × 每件的体积
换成术语，就是"参数量 × 每参数字节数"。参数量就是件数——7B 就是 70 亿件，284B 就是 2840 亿件。至于"每件多大"，那是软件层面的事（量化精度），不在今天这篇的范围内。
"装得下"只是第一道门槛。装下了，跑得动吗？跑得快吗？
真正的问题不在"装不装得下"，在下面这件事。
二、为什么必须是显存？为什么不能是内存、硬盘？
这是硬件篇最核心的问题，也是网上那些"零成本部署"教程最不爱讲、却最要命的一件事。
先说一个反常识的真相：
大模型生成文字，干的最多的一件事，不是"算"，是"搬"。
它每吐出一个字（术语叫 token），都要把模型里"跟这个字相关的知识"从头到尾完整读一遍。你就想象：模型是一本巨大的书，你每写一个字，都得把整本从头翻一遍。不是翻一页，是翻一整本。
既然每写一个字都要"翻一遍书"，那翻书的速度，就直接决定了写字的速度。而"书放在哪"，决定了你能翻多快。
- 显存：书就摊在桌面上，伸手就翻。带宽动辄几百 GB/s，顶级显卡能到每秒上 TB。快。
- 普通内存：书在隔壁房间，你得走过去拿。带宽大概几十到一百 GB/s。慢一个数量级。
- 硬盘（哪怕是 SSD）：书在另一个城市，你得开车去取。顶级 NVMe SSD 顺序读取也就十几个 GB/s。再慢一个数量级。
看出来了吗？这三样东西，容量往往一个比一个大（硬盘最大），但速度一个比一个慢。而大模型要的是"翻得快"，不是"放得多"。
所以网上那些"靠内存跑""靠硬盘跑"的方案，为什么完全没法用？答案就在这：
书放得太远，每写一个字都要跑一趟远路。
显存上能跑出每秒几十个字的速度，换到内存上只剩每秒几个字，换到硬盘上，可能一分钟才蹦一个字。模型是"跑起来"了，可那速度，急死个人。
这就是"为什么必须是显存"的全部答案：不是容量问题，是速度问题。
硬盘再大、内存再便宜，翻书的速度上不去，全白搭。
顺带解释一个词："统一内存"
你会看到有人提"统一内存"——比如苹果 Mac 和 DGX Spark 都爱说这个。
传统 PC 里，CPU 有自己的内存（DDR），GPU 有自己的显存（GDDR），两者之间靠一根叫 PCIe 的桥连接。数据得搬过桥，而桥的带宽远不如显存本身。
统一内存就是 CPU 和 GPU 共享同一块物理内存芯片——没有"搬"这一步了，GPU 直接从这块内存里取数据。
这是为什么 Mac 这类机器能用"内存"跑大模型——不是普通内存变快了，而是 CPU 和 GPU 本来就共用一块内存，没有那座桥的瓶颈。但代价是：这块内存的带宽介于传统内存和专用显存之间——比 DDR 快，但通常低于顶级 HBM 显存。
三、内存带宽：生成速度的物理天花板
第二节其实已经埋了根引线，这一节把它点着。
既然每写一个字都要"翻一遍书"，那写字速度的极限就很好算了：
写字速度 ≈ 翻书速度 ÷ 每写一个字要翻多少书
"翻书速度"就是内存带宽；"每写一个字要翻多少书"就是模型每次实际要搬多少权重。
这个公式，是全文最重要的一个公式，因为它能回答很多看似玄学的问题：
- 为什么同一个模型，在 A 机器上飞快，在 B 机器上龟速？ 十有八九不是软件不行，是 B 机器的"翻书速度"（带宽）太慢。带宽差三倍，速度往往也差将近三倍。
- 为什么有些大模型反而跑得动？ 因为模型内部有个设计（MoE），让它"每次不用翻完整本书，只翻其中一小撮"。翻的量少了，速度自然上去。这是软件层面的聪明，但它的上限，依然被"翻书速度"这条物理天花板压着。
所以记住一件事：
对"逐字生成"这种活来说，内存带宽就是天花板。
它决定了你这台机器，理论上最快能吐多快。别的都能优化，唯独这条物理规律，优化不掉。
四、算力：什么时候才轮到它说话
那"算力"呢？网上天天吹的 TFLOPS、算力大小，是不是最重要的？
不是。
算力在"逐字生成"这个环节，反而不是主角——因为生成一个字，主要是"搬"（读权重），算的东西不多，带宽才是瓶颈。
算力真正登场的，是另外两个场景：
① 开头那一下（术语叫 prefill）。 你把一大段话、甚至一本书喂给模型，它得先把这一大坨内容"读进去、消化掉"，这个过程的计算量很大，算力越高，读完越快。这也是为什么"喂一本书"和"聊一句天"，是两种完全不同的体验——喂书靠算力，聊天靠带宽。
② 生成图片、视频。 这跟文字生成是两码事，纯粹是重计算活，算力（尤其 GPU 的算力）直接决定快慢。
所以选硬件的优先级，对"跑大模型文字"这个用途来说，基本是：
先看显存（装不装得下），再看带宽（跑得快不快），算力排第三（决定开头读入和出图快慢）。
这也是为什么我把算力放在最后——它不是不重要，是得排在显存和带宽后面。
五、回到开头：那台 Mac，到底差在哪
现在可以用硬件篇的框架，回头解释开头那个问题了：
为什么我出掉了一台 Mac M3 Ultra 256G？
先把纸面数据摆出来，有个反直觉的事实：论硬件参数，Mac 其实是赢家。
Mac M3 Ultra 的带宽是 819 GB/s，DGX Spark 单机只有 273 GB/s，差了整整三倍。Mac 单台 256G 统一内存，4bit 量化 284B 的 D4VF 模型塞进去装得下；Spark 单台只有 128G，得两台并联才装得下。如果只看"短问答生成速度"这一项，Mac 反而更快。
那为什么换？因为硬件选型不是单看一个数，是几笔账叠在一起：
账一：Mac 更好，但我需要一台"专职机器"
Mac 是台日常主力机，那 256G 内存不能全给模型——系统要占、软件要占、各种进程要占。模型塞进去，是"跟一家人挤在一起住"。
长上下文一拉长，要搬的数据量暴增，Mac 的表现会往下掉，不如纸面数据那么能打。
而 DGX Spark 是台专用机，我就把它当本地模型的 API 源，别的啥都不跑，甚至能把显示输出都关掉，把更多内存腾给模型。
Mac 确实更好，但我要的是独门独院，不是合租。
DGX Spark 单台装不下就两台并联——这是它的短板，但专职机器的好处，盖过了这个麻烦。
前面这笔账，讲的是"跑文字时用着顺不顺"。但真正压垮 Mac 的，是下面这笔——
账二：视频这条路，Mac 站不起来
跑文字，Mac 还能掰掰手腕；可一旦你想本地跑视频、跑图像生成，事情就变了。
这些模型绝大多数依赖 NVIDIA 的 CUDA 生态，Apple 那套在文字推理上还能凑合，到了视频生成这里，生态压根不带你玩——不是 Mac 性能不够，是这条路没给它铺。
这笔账对我来说是决定性的。最近 MiniMax 开源了 H3 视频模型的基础权重，本地跑视频的门槛在肉眼可见地降低，而线上视频制作的成本又高得吓人——1080P 按秒计费，做得越多越肉疼。
本地一旦跑通，那是长期的账。
与其在 Mac 这条没有视频生态的路上死磕，不如早早上 NVIDIA 的车，把"文字 + 视频"本地化的路一起趟出来。
两笔账叠在一起的结论
Mac 硬件确实更好，但我要的是一台专职干这件事、还得给视频留条路的机器——满足这两条的，只有 NVIDIA 生态。
单看硬件参数，使用体验，Mac 稳赢；但谈到正经的模型部署，Mac 还是有些欠缺。
但这是我的需求，不一定是你的。如果你只是短问答、纯文字用途，Mac 这类统一内存机器完全够用——带宽甚至比 Spark 还宽，短问答速度更快。可如果你要跑长上下文、要给视频留条路、要当专用 API 源给多设备调用——那就得考虑专职机器了。
对号入座，别替我做选择题。
装得下、跑得动、算得快——显存管装，带宽管跑，算力管算。三样东西，优先级从高到低，一条比一条往后排。
下次看到一台机器，先问三个问题：装得下吗？跑得快吗？算得够吗？——按这个顺序问，答案就出来了。
硬件只是第一块。装下了、跑动了，接下来还有软件、部署、生态，每一块都有各自的门道。
哞小哞的杂货铺 · 2026 · 012