它算的到底是什么

一条本地语音对话链路要同时装下三个模型：把你说的话转成文字的 STT、 想清楚该回什么的 LLM、把答案念出来的 TTS。 它们是同时驻留的，不是排队轮流上场，所以体积要加起来看。

这个页面做的是一道乘法：参数量 × 每参数字节数。 一个 1.7B 的模型以 bf16 保存，每个参数占 2 字节，权重就是 1.7 × 10⁹ × 2 ≈ 3.4 GB（约 3.17 GiB）。 换成 4bit，每个参数只占半字节，同一个模型的权重降到四分之一。就这么简单，没有别的魔法。

算出来的数只是下限。推理跑起来之后，显存里还要放激活值、KV cache、 音频缓冲区，加上运行时和框架自己的那一份开销，而这部分在 GGML、torch、MLX、ONNX 上 差别很大——同一个模型换个后端，实际占用能差出一大截。所以页面上那个数字的正确读法是 「至少要这么多」，而不是「就要这么多」。

为什么值得先算这一步

因为它能在你下载十几 GB 权重之前，先把明显不成立的组合筛掉。 如果三段权重的下限已经超过了你的显存总量，那么后面的一切优化都是徒劳， 这个结论不需要实测就能下——下限突破了，实际值只会更高。

反过来，如果下限只占了显存的一小半，那也不等于能跑， 只是说明「值得下下来试试」。这两个方向的推断强度完全不对称，用的时候要分清楚。

怎么用

第一步，选 STT。默认给的是 nvidia/parakeet-tdt-0.6b-v3， 0.6B 参数，这个数就写在模型名里。它的默认计算精度是 float16， 对应页面上的 fp16 档。

第二步，选 TTS。默认是 Qwen/Qwen3-TTS-12Hz-1.7B-CustomVoice，1.7B。 清单里还有 hexgrad/Kokoro-82M，82M 参数——换成它，TTS 这一段的体积会小一个数量级。 Qwen3-TTS 的两个后端各有各的量化参数：GGML 侧默认 BF16，MLX 侧默认 6bit， 这也是页面上把 6bit 单列一档的原因。

第三步，决定 LLM 放哪。如果 LLM 走云端 API，就把「LLM 也放在本地跑」这个勾去掉， 这一段权重不落到你的机器上。想本地跑就选一个参数量——清单里给了 4B 和 31B 两个示例， 用的是仓库 README 里出现过的模型。

第四步，跑实测。页面给的下限只是让你有个数量级的概念， 真正要拿的数字在你自己的机器上。

三件容易搞混的事

第一，GB 和 GiB 不是一回事。参数量乘出来的是十进制的字节数， 而显存和内存通常按二进制单位报（1 GiB = 1024³ 字节）。1.2 × 10⁹ 字节写成 GiB 是 1.12， 差了大约 7%。页面统一用 GiB，和你在 nvidia-smi 或活动监视器里看到的口径对齐。

第二，量化文件通常比乘法结果略大。真实的量化权重里往往有一部分不量化 （嵌入层、归一化参数），还要存缩放因子和零点。所以「参数量 × 位宽」是下限里的下限， 实际文件会大一点。

第三，默认只有一条流水线。仓库的 --num_pipelines 默认是 1， 也就是默认只承载一个并发会话。要服务多个用户，这个参数得动——而并发起来之后， KV cache 和音频缓冲这些「权重之外的部分」会跟着涨，权重本身却不会重复加载。 这正说明为什么不能拿权重体积当占用预算。

什么情况下这个页面不适用

MoE 模型。混合专家模型的总参数量和每次推理实际激活的参数量是两个数， 权重要全部装进内存，但计算只走一部分。这个页面按总参数量算体积下限，对 MoE 依然成立， 但你不能反过来用它推断算力需求。

模型名里没有参数量的情况。比如 GGUF 打包里的 E4B 这类标注， 或者你手上只有一个文件名的检查点。这时候参数量得去模型页面上找，找不到就别猜—— 猜出来的数乘上去，结果只是一个精确的错误。

需要延迟或吞吐结论的时候。体积和速度是两件事。 一个模型装得下不代表跑得动，跑得动也不代表首包够快。 这个页面不碰速度，因为我们没有任何实测数据可以支撑那类数字。

算完之后

拿到下限之后的下一步是把模型拉下来实跑，记录峰值占用，然后用「实测值 ÷ 下限」 得到一个属于你这台机器、这个后端的经验倍数。有了这个倍数， 以后换模型时就能用下限乘一下做粗估——但那是你的倍数， 换后端、换并发数就要重测。 想先把整条链路的参数搞明白，可以看 语音对话链路专题里的部署与选型文章。