欢迎来到我的小铺，今天继续聊本地大模型部署。
上一篇聊了硬件三件套——显存、带宽、算力。那是物理层的事，相当于模型的“外功”。今天往上走一层，聊聊模型的“内功”。
什么叫内功？就是模型为了在你那台有限的机器上跑起来、跑得顺，自己想出来的一堆“偷懒”办法。这些办法，才是本地部署真正有意思的地方——它们解释了为什么同一个模型，有的机器跑得动、有的跑不动，有的快、有的慢。
这六门内功，有的管“装不装得下”（量化、MoE），有的管“跑着跑着翻车”（KV Cache），有的管“快不快”（速度三兄弟、投机解码、并发）。
一、量化：精装版还是口袋版
第一门内功，叫量化。
上一篇埋了个问题：模型这个“货”有多大，取决于“每件货多大”。这个“每件多大”，就是量化决定的。
你就想成同一本书，印成精装版还是口袋版。字还是那些字，内容一样，但精装版（FP16）每个参数用 16 位存储，一本两斤；口袋版（Q4）每个参数只用 4 位，一本半斤。字越印越小，书变轻了，代价是——
有些细节会糊。
你肯定要问：那我全用精装版不就行了？
答案一个字：贵。
这里得说清楚一个容易搞混的事：DeepSeek V4 Flash 284B 这个模型，官方发布时就是混合精度（FP4/FP8），文件大约 167 GB——它出厂就自带“瘦身”。但如果你要跑一个全精度（FP16）的同级别模型，那得 568 GB 起步。而进一步量化到 4bit（Q4），只要约 142 GB。
显存是实打实用钱买的。所以现实逼你只能选：要么跑小模型用精装，要么跑大模型、但得让它“瘦身”用口袋版。
这笔账是：
你用一点点清晰度，换来了把大得多的模型塞进你买得起的机器。
划算还是亏，看你想要“清晰的傻”还是“有点糊的聪明”。
但这里有个坑
网上很多人避而不谈：同样是口袋版，印法不同，清晰度天差地别。
量化不是简单地“把每个数砍成 4 位”——它有好几种“印法”（GPTQ、AWQ、GGUF 等），每种对“哪些参数可以压、哪些不能压”的判断不一样。有的印法会先测一遍模型、找出哪些权重对精度敏感、给它们多留几位；有的印法图省事，一刀切。
同一档位、不同印法，出来的质量能差一个档次。
所以选量化版本，不能只看“几 bit”——还得看用的什么印法、有没有公布质量测评。压得太狠或者印法太糙，模型就糊到答非所问、逻辑崩坏，基本废了。
网上有人把 Kimi K3（2.8T 总参数）压到 1.8-bit，文件缩到约 594GB，单机确实“能跑”——但输出质量不足 80%，除了截图发帖说“我跑起来了”，实际根本没法用。
DeepSeek 这类模型对瘦身特别敏感。量化不是“越省越好”，是在质量崩坏之前，找到最省的甜点档位和最靠谱的印法。
二、MoE：284 个专家，每次只上 13 个
第二门内功，解释了“为什么 284B 这么大的模型反而跑得动”。但在讲它之前，得先说清楚模型其实分两种。
第一种：“稠密模型”（Dense）
你可以理解成一家全员上阵的公司——来一单活，所有人全上，一个不落。
早期的大模型几乎都是这种，7B、13B、27B、70B，每次推理全量参数参与计算。由于每次都是全员出动，意味着调动的知识和内容都是完整的。
实测下来，同等参数级别，稠密模型的效果往往好于 MoE——比如千问的 27B 稠密，在知识推理测评上比同家的 35B-A3B 的 MoE 还略胜一筹，就是因为全量参数每次都参与，带的知识更全。
坏处也明显：模型越大，每次干活要搬的权重越多，带宽吃不消。
第二种：“混合专家”（MoE）
这就是 DeepSeek V4 Flash 用的架构。同样一家 284 人的公司，但每次来活只派 13 个人上场，剩下 271 个在家待命。
学问是满的，力气是省的。
这想法不是新东西。1991 年就有人提出了“自适应混合专家”的思路——建一组“专家网络”，加一个“门控网络”来决定每次该叫哪个专家上场。但当时算力连“调度哪个专家”这步都费劲，模型规模也小，拆不拆意义不大，这个思路在论文里躺了三十多年。后来硬件跟上了，几家大厂率先把它工程化做到千亿级，开源社区跟进做出实效，到 2026 年主流大模型已经越来越多采用这个架构。
MoE 解决的核心矛盾是：人们想要模型“知识越多越好”，又不想“每次都花全部力气”。
用 284B 的学问，只付 13B 的力气钱。
为什么在带宽有限时，MoE 比稠密模型划算？
因为上一篇讲过——逐字生成的瓶颈是“翻书速度”（带宽），不是“算力”。
拿两个你可能听说过的模型对比：千问 3.6 的 27B 是稠密模型，每次推理要把 27B 的书全翻一遍；而 DeepSeek V4 Flash 虽然总参数 284B，但因为是 MoE，每次实际只翻 13B 的那几章。
284B 的模型，翻书量反而比 27B 的少一半。
同样的带宽条件下，跑一个 284B 的 MoE，反而比跑一个 27B 的稠密模型还轻快——因为真正要搬的量更少。
但它也有代价。271 个闲人虽然不出力，工位（显存）一点也不能少——他们的本事全得装在仓库里备着。所以 MoE 省的是“干活力气”（计算量和带宽），不是“存人地方”（显存）。
另外，“每次只叫 13 个”这件事本身需要调度开销——得先有个“门卫”判断该叫哪几个专家，这一步也要花一定的算力。
不同模型的 MoE 配置也不同。有的总参数大、每次激活的少（像 DeepSeek V4 Flash，284B 每次激活 13B）；有的总参数更大、每次激活的也多（像 Kimi K3，2.8T 每次激活约 104B）——各有各的算法，不是所有 MoE 都一个套路。
三、KV Cache：装下货，还得留地方停车
第三门内功，是本地部署最常见的隐形坑。它叫 KV Cache，翻译成人话就是：
你给模型留的“对话记忆区”。
你跟模型聊天，它不是聊一句忘一句，得记着前面聊了啥才能接得上。这段记忆也得占显存，而且你聊得越久、上下文越长，它占的地方越大。
打个比方：模型权重是仓库里的货，KV Cache 就是仓库门口的停车场。货卸完了，你以为大功告成，结果发现停车场没留。
停车场有多大？
拿数据说话。每个 token 的记忆大小取决于模型的架构——
传统架构下，一个 400B 级别的模型，每记住一个 token 大约要占 516 KB；DeepSeek 从 V2 开始用了一种叫 MLA 的压缩技术，把每个 token 的记忆压到约 70 KB，小了七倍多，后续 V3、V4 都延续了这个路线。
但即便如此，一个 128K 上下文的对话，KV Cache 也要吃掉好几 GB 的显存。
你开一个超长对话，停车场就可能被占掉一大块，剩下的地方不够再开第二个。
这也是为什么早期模型上下文只有 32K（大约两三万字）——不是工程师不想做长，是上下文越长，停车场越大，显存越撑不住。
现在技术做到 1M 上下文了（相当于一本长篇小说的量），但代价是：一个超长对话就可能吃掉你显存的一大块，你几乎没法同时开好几个长对话。
一个真实场景
你让 AI 当“助手”干个 Agent 活——读一份几十页的合同、查一堆资料、再一步步帮你写结论。它每做一步，都得记住前面所有步骤和读过的所有内容。你看着它干得挺好，结果跑到第几十步，它突然报错了。
为什么？不是它坏了，是停车场满了。
它每一步的记忆都是“一辆车”，越停越多，把车位全占满。再往下，车停不进去，它就没法继续记了。
所以判断一个部署行不行，第一问永远不是“能不能装下模型”，而是：
装下模型之后，还剩多少地方，给记忆停车？
四、速度三兄弟：TTFT、单字速度、端到端
内功讲完了，现在讲讲怎么“看懂”它的表现。部署完，监控面板上会有一堆数字，其实核心就三个：
① TTFT（首字延迟）
你按下回车，到第一个字蹦出来，要等多久。
这就像你按门铃，到屋里的人来开门，中间隔着多久。
TTFT 主要看算力：你把一大段话喂进去，模型得先“读完消化”这一大坨，才能开口。喂得越多，等得越久。
我实测（双机 DGX Spark 部署 V4 Flash Q4）：
喂 713 字，0.5 秒就开口；喂 6700 字，要等 3 秒；喂 33000 字，得等 13 秒。
“喂一本书要等多久”，这是有数可查的。 不同硬件和模型，数字会不同。
② 单字速度（token/s）
门开了之后，它说话有多快。这是“生成期”的语速，主要看带宽，就是上一篇讲过的那条物理天花板。
③ 端到端
两者之和，你从头到尾的真实感受。
一个容易踩的坑
网上看跑分，一定先看清楚人家测的是哪个。有人测的是首字延迟（TTFT），有人只测生成期的单字速度，有人测的是端到端总时间——
同样的模型同样的硬件，换个测法，数字能差好几倍。
看跑分先看测的是什么，别拿苹果跟梨比。
这里有个特别实用的判断：很多人抱怨“本地模型好慢”，其实是病因搞错了。是“开门慢”（TTFT 长，算力不够）还是“说话慢”（生成慢，带宽不够）？
病因不同，药完全不同。 开门慢去加算力，说话慢去换高带宽机器，别搞反了。
五、投机解码：旁边一个小弟，先猜答案
这一节能解释一个很玄学的现象：
为什么同一个模型，写散文慢吞吞，数数却飞快？
影响单字速度的，除了上一篇讲的带宽这条物理天花板，还有一个机制在暗中起作用。
部署完成后，跑一跑各类实际任务（同样在双机 DGX Spark V4 Flash Q4 上）——
写开放性散文约 30 字/秒，做结构化任务（数学、代码）约 57 字/秒，而高度可预测的内容（数数、誊写）能飙到 137 甚至 220 字/秒。
差了快 7 倍。
秘密在一个叫投机解码的机制。这个技术比较新，不是所有模型都带——有的模型在训练时就内建了这个能力，有的需要外挂一个“草稿模型”来配合。
不管哪种方式，原理都一样：主模型旁边站着个“小弟”，负责先猜后面几个字。主模型再批量验证——猜对了就白赚，猜错了重来。
小弟的命中率是有规律的（实测）：
猜第 1 个字，中 68%；第 2 个字，只剩 41%；第 3 个字，23%……到第 5 个字，只有 6%。越猜越没谱。
写散文时，下一步可能性太多，小弟第二张就猜崩了，所以慢；数数时，下一步基本是固定的，小弟五张全中，所以飞快。
这就是 30 和 137 之间的全部秘密。
但要注意：投机解码的加速效果取决于内容的可预测性。如果你跑的是高度不确定的创意写作，小弟几乎帮不上忙，有没有这个机制速度差不多。所以别指望它万能——它是个锦上添花的机制，不是底层提速。
这提醒你一个评测本地模型的规矩：
千万别拿一次跑分说事。 同一个模型，跑不同任务，速度能差 7 倍。要看它在你真实要干的活上，跑得怎么样。
六、并发：一个厨师同时做几道菜
最后一个词——并发，就是“同时服务几个人”。
很多人以为并发就是简单除法：一台机器每秒 100 token，两个人就是每人 50，三个人就是每人 33——
不是这么算的。
打个比方：一个厨师同时做几道菜。
一个厨师做一道菜，全部精力扑上去，最快。但同时做两道菜呢？他得在两口锅之间来回跑——总出菜速度快了（两道菜差不多同时上），但每道菜的单菜速度都慢了一点。做四道菜？总出菜速度更快了，但每道菜更慢，厨师开始手忙脚乱。
做到八个菜、十个菜，厨师彻底忙不过来，每道菜都做不好，总出菜速度反而开始往下掉。
实测数据摆出来（双机 DGX Spark V4 Flash Q4）：
1 路时 37.6 字/秒；2 路时总吞吐 51.5，但摊到每个人只有 25.8；4 路时总吞吐 80.5，每人只剩 20.1。
总量上去了，单人的速度下来了。
而且到了某个临界点，再加人，总量也不涨了——厨师累趴了。
因为带宽是固定的，人一多，大家分着用。所以记住一个结论：
加并发，买的是“总处理量”，不是“每个人的速度”。
如果你就自己一个人用，别瞎加并发，反而拖慢自己。
以上就是我在部署过程中了解到的一些软件层面的东西。说实话，这些概念单独看都不难，但搁在一起、还要在自己机器上一样样踩过来，才知道哪个是甜点、哪个是坑。
下次看到有人晒本地部署跑分，先问三个问题：用的什么量化？上下文多长？跑的是什么任务？——这三个变量任何一个不同，跑分就没有可比性。
软件层面大概就是这些。但知道原理和真正上手，中间还差着不少距离。
哞小哞的杂货铺 · 2026 · 013