30B 模型，真能塞进 12GB 显存？
想在自己的电脑上跑大模型，常见的第一道门槛不是速度，而是“装不下”。如今，一份模型页面给出了一组很抢眼的数字：Ternary Nemotron 3.5 Lightning 30B-A3B 的 GGUF 文件，据称能在 12GB GPU 上运行，同时支持 368K 上下文，并达到每秒生成 172 个 token。
这里的 token，可以粗略理解为模型读写文字时使用的小单位。若这些结果能够复现，它意味着消费级显卡可能装下更大、能读更长材料的本地模型。不过，目前所有核心数字都来自 Hugging Face 用户 boro64 的单一页面，缺少独立测试；页面所列来源与作者字段的关系也不够清楚。因此，这更像一份值得验证的性能报告，而不是已经坐实的普遍结论。
“30B”不等于每次都算30B
模型全名里的 30B-A3B 很关键。它是一个 MoE，也就是“混合专家”模型：可以把它想成拥有多个专业小组的机构，每次接到任务，只叫其中一部分人上场。
30B 表示模型总参数约 300 亿；A3B 表示处理每个 token 时，约有 30 亿参数被激活。这样可以减少当次计算量，但其余权重并没有消失，仍然需要存放或调入。所以，“12GB 跑 30B”不能理解成普通的 300 亿参数 dense 模型——即每次都动用全部参数的模型——直接完整塞进显存。
另一个关键是 ternary（三值量化）。它把模型权重约束到三个离散取值，理论平均存储量常被概括为约 1.58 bit。可以把它理解为：原本记录得很细的数字，现在改用三个档位表示，以精度换容量。实际文件和运行内存仍会包含元数据、缓存和其他高精度部分，因此“1.58-bit”也不等于所有内存都严格按这个比例缩小。
这条路线并非突然出现。编辑部整理的 Microsoft Research 与 BitNet GitHub 资料显示，微软团队从 2023 年的 BitNet，推进到 2024 年提出权重取值为 的 BitNet b1.58，之后又发布了可运行的推理工具与正式模型。此次 Nemotron 的看点，是把三值权重、MoE 和 12GB 显存门槛放到了一起。
172和7000，不能混着看
页面宣称该模型达到 172 tok/s 的 decode，以及 7000+ tok/s 的 prefill。这是两个不同阶段。
prefill 是模型先把整段提示词读进去；decode 是随后逐个生成回答。前者像快速浏览材料，后者才是实际往外写答案。因此，7000+ tok/s 不能理解成模型每秒能生成七千多个 token。对聊天体感更直接的数字是 172 tok/s，但页面没有给出对应的 GPU 型号、提示词长度、批量设置或可复现实测日志。
368K context 指模型一次最多可以接收约 36.8 万个 token。窗口很大，不代表模型能同样准确地利用其中每一处信息；它也不自动证明，最长窗口可以完全放进 12GB 显存。长文本会产生额外缓存，而页面没有说明是否借用了 CPU 内存，也没有说明上述速度是否在 368K 条件下测得。
真正有意思的是兼容性
页面称，同一个模型文件可用于 Stock llama.cpp 和 PrismML fork / Bonsai 两套推理引擎，并列出 Stock llama.cpp b11555+、b11796 与 Bonsai b10793 的验证记录。作者还称，这是 maple-preview 之后第二个能在 Stock llama.cpp 中运行的 ternary MoE 模型。
这点可能比单个峰值数字更重要。如果一个文件能直接适配常用本地推理工具，三值模型就不只是一项压缩实验，而更接近日常可用的软件包。本刊此前连续关注过 2-bit 量化的 74B MoE、装入 RTX 5090 的 1.66 bpw 模型，以及 prefill 与 decode 的口径差异。这次的主张把容量竞赛继续推进到 12GB 显卡，但证据也明显更薄。
局限与未知
- 全部性能结论来自一个页面，尚无独立信源交叉验证；“validated”“第二个”等说法应视为发布者自述。
- 页面没有披露 GPU 型号、文件大小、显存峰值、CPU/RAM 卸载情况及完整测试配置，暂时无法判断 12GB、368K 与两项速度能否同时成立。
- 材料没有提供量化前后的质量对比，因此目前只能讨论“能否装下和跑起来”，不能据此判断压缩后回答能力保留了多少。