本地跑模型的账本与取舍
杂货铺 · 第048篇
欢迎来到我的小铺。今天聊聊本地跑模型的账本与取舍。
最近降温了。桌上两台 DGX Spark 的发热量一直不小，夏天那会风扇转速拉满也压不太住。这几天天气一凉，温度终于能自然地稳在 70 度以下，不用再操心散热的事。
近期 DeepSeek V4.1 Flash、GLM-5.3 Flash 陆续出了新的部署版本，我跟着跑了几天，有些体感想梳理一下。翻资料的过程中，重新看了一遍 Karpathy 这两年提的几个核心思路。
这两套思路，一个 2023 年 9 月提的，一个 2025 年下半年提的。模型进展日新月异，但回头看，他的判断到现在依然站得住。这让人不得不佩服。
正好，网上新出了一份以 Karpathy 公开观点为骨架、由第三方独立整理的本地 LLM 工程综述。不是 Karpathy 亲笔，文档自带免责声明，声明为独立整理，未经本人审阅或背书。有人把他散落在推文、演讲、播客里的观点收集起来，串成了一篇结构化的长文，配上工程细节和数据。我查了一下，引用的观点源头都能追溯到 Karpathy 的原始推文和演讲，行业数据也都真实可查，质量相当高。
读着觉得挺好，梳理出来分享一下。下面既有对这份综述核心框架的转述，也有我自己在工位上跑模型的体感和判断，混在一起讲。
一、破除“能跑”的障眼法
网络上关于本地模型的讨论，最容易让人发笑的，就是把“能打字”等同于“能干活”。
随手翻翻社交平台，经常能看到有人拿着轻薄本甚至掏出一部手机，兴高采烈地展示“本地成功运行大语言模型”。屏幕上光标闪动，一个 1B 或 2B 的超轻量模型在两秒内吐出一句“你好”，顺带背出半首唐诗，评论区便是一片欢腾。
但真坐回工位面对生产流程，没有人需要一台随身打字机去重复百科常识。在真实的业务逻辑里，
“记忆事实”是最廉价的属性，“执行逻辑”才是昂贵的资产。
Karpathy 2023 年 9 月在推文里提出了一个架构隐喻：语言模型是操作系统的内核进程。2025 年下半年他又往前推了一步，提出 Cognitive Core 的概念，未来常驻每台电脑的应该是一个几十亿参数的小模型，原生多模态，主动牺牲百科记忆，把有限的参数全压在能力上。
既然模型是调度内核，它就不该把整个人类文明的历史掌故全焊死在自己的参数文件里。需要事实，去检索；需要知识，去查库。它真正该练的肌肉，是严格遵循输出格式、稳定拆解长任务，以及在材料不足时，克制而诚实地打上一句“无法确认”。
把百科全书的包袱扔给磁盘，模型才能把有限的参数腾出来。压缩进个人硬件吞得下的尺寸，靠的不是更大的显卡，是更聪明的分工。
二、稠密与 MoE 的物理代价
一旦把模型从“摆设”推向“干活”，选型就不再是挑个参数名字那么简单。
在当下的模型版图里，底层架构基本分成了两派。一派是以 Qwen3.8-27B 为代表的稠密模型（Dense）；另一派则是如今遍地开花的混合专家模型（MoE），从几百亿到几千亿参数的巨无霸，再到本地常驻的 DeepSeek-V4.1 Flash、GLM-5.3 Flash 这类主打极速响应的精悍分支，底层其实都是混合专家架构。
这两套架构在本地机箱里交手，本质上是在用截然不同的方式，跟硬件的物理定律做交换。
稠密模型的逻辑极其直白：每一个字生成，全量参数都得老老实实搬出来计算一遍。
它的优势在下限与平稳。在 4 比特量化（Q4_K_M）之后，27B 的文件大小约为 17.4 GB。加上上下文缓存，刚好能把一张 24 GB 显存的显卡吃满。得益于近来推理引擎与底层算子的深入打磨，在 RTX 4090 这类硬件上，它的生成速度早已跨过了早年顿挫的门槛，轻快起来能稳在每秒五六十个 token。更重要的是，它的长文本预处理耗时非常线性，不会因为塞进去一段跨领域的复杂报错就突然脚步凌乱，是单卡环境里最不容易在半夜掉链子的压舱石。
代价在于参数天花板。因为每个字都要完整读取整份权重，受限于单张显卡的容量与物理带宽，如果想在单卡上获得远超 27B 的认知深度，它的参数规模就很难再往上拓宽了。
混合专家架构的核心账本，在于把“总参数”与“激活参数”彻底拆开。庞大的总参数决定了模型的见识与智力上限，但每次吐出一个字，门控机制只动态唤醒其中极小的一部分专家切片。比如总参数几百亿，单次只激活 3B 到 9B。
而所谓的“Flash”型号，并不是一种独立于 MoE 之外的新架构，而是厂商在 MoE 底座上做出的高吞吐、低延迟特化档位。通过进一步压低单次激活参数比、采用混合注意力机制削减缓存体积，把 MoE“小推车快跑”的优势推到了极致。跑下来体感就是这样。
它的交互体感与智力跨度是真正的甜区。正因为单次搬运的参数极少，它在逐字生成时轻盈得近乎夸张，吞吐量极高，同时又保留了大底座带来的逻辑厚度。
但代价分两层。第一层是物理寻址门槛。不管单次激活多少，庞大的总专家库必须完整驻留在物理空间里。稍微大一点的 MoE 模型，单张 24 GB 显卡就捉襟见肘，必须依靠多卡拆分或大容量的统一内存池来托底。
第二层是预处理延迟（Prefill）。不少人在本地跑 MoE 架构的模型时都会遇到一个现象：为什么把长文档或几万行代码喂进去时，光标会在屏幕前停滞好几秒，风扇低沉地拉高转速，而后才突然像决堤一样喷涌出答案？长文本一口气涌入的瞬间，跨领域的复杂输入把原本沉睡的各路专家同时敲醒。在读题这一刻，稀疏激活的优势被摊薄，总线和内存带宽被瞬间填满。我的解释是这样的，原文提到了这个现象，但没有展开讲为什么。
稠密架构用全员上阵的确定性换来了单卡的稳健，混合专家架构则用更大的内存池换取了高上限与快吞吐。它们谁也没能超脱出机箱内的物理尺度。
三、工位上的四级阶梯
看清了底层架构与产品档位的真实边界，不同模型在日常流水线里的分工，就有了严密的界限。
第一级：3B 至 4B 极轻量端侧（毫秒级分拣工）
它能处理的是单次几十到几百字的输入，输出单行或定长短句。挂在版本控制钩子脚本里最合适，敲下提交的瞬间，它读取暂存区的代码差异，半秒钟递出一行没有废话的摘要；或者守在流水线最前哨充当路由器，扫一眼涌进来的任务，决定是分发给本地主力还是递给远端。
但它处理不了嵌套两层以上的业务重构，也别指望它做跨模块的代码联调。强行让它做长程因果推导，它会在三步之内开始自相矛盾。
第二级：27B 稠密模型（单卡稳健值班员）
它能处理数千字上下文、涉及数个函数调用的中等长程任务。单张 24 GB 显卡上最省心的主力，能稳稳吞下带有明确上下文的单文件深层重构；能严格对照一份合同提取几十项结构化数据，并在看不清时老实填写“无法确认”；也能接管包含一两个精确工具的代理工作流。
边界在于必须严格控制外部工具（MCP）的数量。一个工具的定义就是几百字的前置输入，挂上四五个工具，光是读取这些说明书所花的时间，就会让它开口前停顿良久。
第三级：本地 Flash 档位的 MoE 模型（高频交互智囊）
它能处理万字级别的代码模块推理、跨文件逻辑分析、高频对话式编程。像 DeepSeek-V4.1 Flash 和 GLM-5.3 Flash 这类专门针对响应速度做过剪裁的 MoE 模型，最适合充当白班高频打字时的主控台。在上下文长度可控的前提下，它能凭借大底座的眼界和极小激活参数的敏捷，快速给出复杂模块的编写方案与深层纠错，不会打断人的思绪。
但必须克制使用它的前置输入。不至于随手把整个依赖库几万行冗余代码原封不动砸给它，避开长文本预填充阶段把所有专家同时唤醒所带来的带宽拥堵。
第四级：云端超大规模旗舰接口（极低频的疑难会诊室）
全局系统架构选型、本地连续两次纠错失败的死局，才轮到它出场。云端那些参数量动辄上万亿的满血版 MoE 模型，挂在整个流水线的最末端，受路由器的严格阈值控制。它的调用要按次计费，配额要受服务商制约，不能是任何自动化循环里的常备组件，而是一道兜底防线。
四、Night Shift
配了高规格机器的人，很多在新鲜劲过去之后随手关掉了电源，原因往往是算不过账。
这份综述里有一笔冷峻的经济学账，据它估算，一台高端桌面跑本地模型，每个 token 的成本大约是云端 API 的 3 到 4 倍。硬件折旧加电费，跑一宿跟跑一小时，固定成本几乎一样。所以如果机器只在白天被坐前面对话三四个小时，这笔账根本算不平。纯粹为了“白天闲聊几句”，本地部署在商业账面上站不住。
破局点在于一个词：Night Shift。一个实打实的工程决策。
本地算力唯一的护城河，是边际成本为零。跑一次是这点功耗，满载跑一宿也是这点功耗。那就不该让它闲着。
白天积攒下来的几百封待分类工单，可以排在脚本里，挂上多线程在后半夜悄无声息地打标分拣；本地散落了几年的 Markdown 笔记与会议草稿，可以在夜里由它逐段清洗、校对格式、抽出实体关联；清晨六点半，让它把代码仓库昨天的每一次提交记录与深处的未完成项翻检一遍，整理出一份不带任何修饰的清晨开发简报。
综述原文里有一句话，大意是：显卡每天闲二十个小时，问题出在任务列表是空的。
清晨坐回椅子里，终端里已经安安静静躺着昨夜跑完的纯文本。没有调用超额的报错，没有服务商在后台给配额悄悄打折的算计，数据也从未离开过脚踝边的这块硬盘。
从虚妄的“全知打字机”，退回到精打细算的“系统内核”，本地模型的价值，才算真正落进了机箱的物理尺度里。
哞小哞的杂货铺 · 2026 · 048