本地模型 on 向叔记事簿

AI 写博客这件事，后来还是得做成工程（三）

Fri, 03 Apr 2026 21:06:02 +0800

翻了一圈现在仓库里的配置，我反而更确定一件事：这套东西最后拼的不是单个模型有多强，而是每一层到底该让谁来承担成本。

最明显的一个信号就是，当前生效的 published.runtime.json 还是 2026 年 4 月 2 日生成的 minimax-m2，但 2026 年 4 月 3 日 16:38 的 5f17088 已经把 blog-style-suite 的默认 provider 切到了本地 LM Studio 里的 gemma-4-26b-a4b。这看起来像前后不一致，其实不是，它恰好说明了这条流水线开始有了分工。

这组文章到这里，前两篇已经把边界铺开了。第一篇讲的是 blog-writer 为什么会长出来，第二篇讲的是 blog-style-suite 怎么把风格学习和 token 成本拆开。最后这一篇，就收在最现实的问题上：本地模型、在线模型、Minimax，到底该放在哪个工位上。

训练风格数据，不值得每一步都烧在线模型

风格数据这件事，一旦开始认真做，token 很快就会变成现实问题。

不是你想不想省，而是你如果不分工，这套东西根本跑不久。

以前最容易出现的误区，就是让一个在线模型把所有活都包了。

扫历史文章
做筛选
做归类
评分
抽样本
压风格
最后再去写稿

这么干的最大问题，不是“模型不够强”，而是每一步都在烧同一档成本。

现在回头看，真正合理的做法应该是反过来想：哪些步骤必须在线，哪些步骤其实应该尽量本地化，哪些步骤甚至根本不该交给模型。

只要这个边界不清楚，再强的模型进来，最后也只是在帮你重复做一堆本来能预处理掉的活。

本地模型更适合脏活、重活和反复试错

我现在越来越愿意把本地模型定义成生产侧的体力层。

它不一定最强，也不一定每次都最漂亮，但它特别适合承担这些事情：

反复试跑的构建
风格数据的多轮压缩实验
配置改动后的重新扫描
对已有结构做低风险重算

这类活的共同点很明显。

不是单次价值极高，而是要反复跑、能容忍试错、并且最好别每一轮都重新付高价。

当前 scripts/blog-style-suite/config.json 已经切到了 lm-studio-gemma4，这本身就说明判断在变。不是说本地 gemma 一定比在线模型更强，而是生产侧这条链路，终于开始优先考虑“跑得起、跑得勤、能反复改”。

这一点，其实和我前面写过的弱模型别硬上强活是同一个逻辑。

本地模型不一定适合总包复杂写稿，但很适合接那些脏活、重活、批量活。风格数据的预处理，本来就更像这一类任务。

在线模型更适合收口，不适合包办一切

说本地模型适合生产侧，不等于在线模型就没价值了。

在线模型真正值钱的地方，恰恰是最后那一下收口。

比如：

根据最新资料补事实
在更大上下文里整理论证
处理需要联网核验的时间敏感信息
把已经准备好的结构化风格资产，转成一篇能发出来的文章

这些动作对表达质量、事实整合、上下文理解要求更高，在线模型放在这里更值。

也就是说，强模型更像总装线最后那几道工序。它不是不可以往前多干点，但如果你让它从头扫到尾，整个成本结构很快就会走形。

这也是为什么 blog-writer 在设计上只读发布位 published.runtime.json，而不是写稿时再去切 provider、再去回扫 suite 目录。消费侧越轻，越适合让更强的模型专心把文章收好。

Minimax 的意义，不只是多接了一个 provider

很多人看到 Minimax，第一反应可能是：无非又多接了一个模型。

我觉得不是。

Minimax 真正有价值的地方，是它把“多 provider 输出，同一发布契约消费”这条路走通了。

2026 年 4 月 2 日 10:18 的 9f15199 把 blog-style-suite 改成了多模型配置，输出按 provider 隔离。后面 README 和 runtime 结构也一直在强调一件事：suite 可以生成很多份结果，但真正生效的只有人工挑出来的 published.runtime.json。

这个边界特别重要。

因为一旦边界明确了，Minimax 的角色就不再是“必须绑定在写稿流程里”，而变成了：

它可以参与生产侧的对比
可以用来生成一版 runtime
可以和本地模型产物横向比较
最后由人工决定哪一版发布

这就把 provider 从“系统依赖”变成了“可替换部件”。

我觉得这是 Minimax 在这套工程里最有意思的意义。它不是来统治整条链路的，它是来验证这条链路到底有没有把接口收干净。

真正的分工，不是按模型强弱分，是按任务类型分

我现在更认同一种很土，但很管用的划分法。

规则和硬约束

交给本地脚本。

能用 scanner.py、write_post.py、write_post_series.py 这种确定性工具解决的，就别让模型掺和。

风格数据生产

优先交给本地模型或成本更低的 provider。

因为这里最重要的是可重复、可试错、可缓存，不是单次输出必须最华丽。

最终写稿和事实收口

交给更适合长上下文整合、表达收束、联网补事实的模型。

这一层才是在线模型最值得花钱的地方。

这么一拆，很多原来纠结的问题反而没那么复杂了。你不需要每天争论“到底哪个模型最强”，你只需要问一句：这个任务属于哪一层。

到最后，最值钱的不是模型，而是边界清楚

第三篇我就收在这里。

blog-writer 和 blog-style-suite 这套东西一路演化下来，我觉得最值钱的，不是又接了谁、又换了谁、又试了哪个 provider。

最值钱的是边界终于越来越清楚了。

blog-writer 管消费侧
blog-style-suite 管生产侧
published.runtime.json 是发布位
本地模型更适合反复跑的脏活和重活
在线模型更适合最后的收口
Minimax 这类在线 provider 更像可替换部件，而不是系统中枢

边界一清楚，整个工作流就顺了。

你不会再指望一个模型包打天下，也不会再把每一步都堆到最贵那一层去做。到最后，这件事看起来是在选模型，实际上是在给不同类型的任务安排工位。

说白了，单点更强当然好。

但长期跑下来，边界清楚，往往比单点更强更重要。

参考资料

仓库提交：9f1519967981c5eef7bd1eb407b0406ac542ebd0
仓库提交：5f17088391ee858b88fc50df884bc0103ff0b3c1
仓库文件：scripts/blog-style-suite/config.json
生效运行时：.agents/data/blog-writing/published.runtime.json
相关旧文：重度AI编程的一段日子
相关旧文：终归还是回到国产模型
相关旧文：弱模型别硬上强活

写作附记

原始提示词

$blog-writer 本次的内容比较多，拆分成系列文章：去年就有很多稿子是通过大模型写的，那会是自己写个大纲或者问题清单，然后AI出稿子，复制内容到本地 md 文档，填写头信息，标签信息、发布文章；近期 codex 用了很多，发现 codex 里面的联网搜索能力很强，那我是不是能写个 skill，将这些事情自动化，此时诞生了 skill blog-writer 的第一稿，我还想着让 AI 学习我以前文章的风格，这就导致 blog-writer 运行的时候，很费 token，后续我针对 blog-writer 进行了多个版本的优化，拆分了 数据模块，数据生成的模块，原本数据生成的模块还是独立的 skill，写着写着，我就发现，更适合做成 Python 项目，此时就有了 blog-style-suite，然后我又发现，训练风格数据，也是比较费 token，我就想着用本地的大模型，对接了本地的大模型，我又想到了对比下本地大模型和在线版本的区别，又对接了 minimax；blog-style-suite 和 blog-writer 的演化历史可以分析的 git 提价记录。顺带基于本地 blog-writer、blog-style-suite 的代码，可以讲讲里面的设计思路，是如何做到了节约 token，数据结构是如何设计的，核心的设计思路。Token 富裕完全能生吃历史文章，预处理能节约很多 token

写作思路摘要

第三篇不再重复讲架构，而是把“模型分工”这个现实问题单独收口。
直接用当前仓库里 published.runtime.json 还是 minimax-m2、config.json 已切到本地 gemma4 这个事实开篇，减少空话。
重点不是证明谁更强，而是说明为什么不同任务该由不同成本层来承担。
把 Minimax 放在“可替换 provider”这个位置上讲，是为了把它的意义拉回工程边界，而不是模型榜单。
结尾回到“边界清楚比单点更强更重要”这个总判断，作为整组文章的收口。

弱模型别硬上强活

Thu, 02 Apr 2026 22:05:00 +0800

最近把一些边角活往 MiniMax 和本地模型上迁，越用越觉得，这事不能老拿“最强模型”那套标准去衡量。

我的判断很直接，弱模型别硬上强活。MiniMax 这类模型，能力弱是弱，拿去做复杂编码、长链路推理、模糊需求拆解，确实差点意思。但如果你让它做数据清洗、文档编写、方案资料搜索，这类活它是完全能接住的。同样的逻辑，本地 12B 左右的模型也一样，翻译、格式改写、批量清洗，反而是它们真正适合待的位置。

说白了，不是模型没价值，而是别把它放错工位。

真正的问题，不是模型强不强，而是活对不对

很多人聊大模型，默认脑子里想的都是最难那档任务。

独立写复杂工程
一口气拆完整个系统
处理长上下文里的多轮推理
边搜索边规划边执行

这些当然重要。但现实工作里，真正常年堆在你桌上的，很多反而不是这种活。

更多的是：

把一堆脏字段洗干净
把零散资料整理成可读文档
把长文改成摘要、FAQ、提纲
把中英文混杂内容统一格式
从多个网页里找资料，再顺手归纳成一份方案草稿

这类任务，最需要的不是“模型像天才一样思考”，而是三件事：

指令遵循别太离谱
输出结构尽量稳定
成本足够低，低到你愿意反复用

这就是为什么我一直觉得，弱模型不是没用，它只是不能被拿去跟旗舰模型打同一种仗。

MiniMax 真正合适的，是这些活

先说 MiniMax。

官方对 MiniMax-M2.5 的定位其实很高，新闻稿和开放平台文档里都把它往编程、工具调用、搜索、办公生产力这些场景上推，甚至强调速度和价格优势。这些说法我不是完全不信，但我更愿意把它拆开看。

在我这里，MiniMax 真正顺手的，不是“最复杂的开发任务”，而是下面这些：

数据清洗

很多数据清洗，说穿了就是半结构化文本体力活。

名称归一
字段映射
异常值标注
分类打标
表格字段补全

这类工作最怕的不是模型“笨”，而是格式不稳、输出发散。只要模型能比较老实地按 JSON、表格、固定模版吐结果，其实就够用了。强模型当然也能做，但拿最贵那档模型去洗字段，很多时候不划算。

文档编写

文档这活很烦，不是难，是烦。

接口变了，流程变了，字段改了，说明文档就得跟着改。这个过程其实不太需要模型有多强的创造力，反而更需要它别乱发挥，别把原本明确的东西改得似是而非。

MiniMax 做这类事，经常比想象中靠谱。尤其是当你已经把上下文准备好了，它更像一个能干活的文档助理，而不是一个真正的工程师。

方案资料搜索

官方自己也在推搜索和工具调用，这方向没问题。

很多时候我们不是要模型“凭空想出答案”，而是要它把网页、文档、公告、资料先找回来，再顺手理一遍。这个场景里，MiniMax 这类便宜模型的价值就很明显了，因为搜索、摘要、整合，本来就是高频杂活。

所以我的实际看法是：MiniMax 不是不行，而是它更适合做生产链路里的脏活、累活、重复活。你让它打杂，它常常是合格的；你让它总包整个工程，失望概率就会上来。

本地 12B 模型，最适合搬回来的也是这些活

再往下看，本地部署其实是同一个逻辑。

很多人一说本地模型，就会忍不住想一个问题：能不能替代云端旗舰？

我觉得这个问题一开始就问偏了。

本地 12B 左右的模型，真正有现实价值的，不是“证明自己也能做最强那档任务”，而是把那些稳定、重复、敏感、低利润但高频的活搬回来。

翻译

这是本地模型最顺手的场景之一。

像 Qwen2.5 官方博客里就明确提到，它对长文本生成、结构化数据理解、JSON 输出都有增强，而且支持超过 29 种语言。这个组合天生就适合翻译、双语改写、格式统一、术语规范化这类工作。

技术文档、字段说明、产品介绍、接口注释，这些东西往往结构稳定、术语固定，本地模型不一定翻得最优雅，但通常够用。

数据清洗

这也是本地模型特别有现实感的地方。

很多表格、文档、业务资料，你未必想扔到云端。尤其是内部数据、客户资料、会议纪要、半成品方案，这些东西一旦涉及隐私和权限，本地跑就会让人安心很多。

这时候本地 12B 左右模型的意义，不是“它有多聪明”，而是“它就在我机器上，而且能稳定干完这类脏活”。

固定格式改写

比如：

会议纪要整理成固定模版
商品标题清洗成统一命名规范
bug 描述改写成工单格式
中英混杂文本清成单语版本

这类任务的特点都很一致：规则清晰，批量大，重复高，单次价值不高，但总量很烦。

这正是本地模型最该干的活。

3060 12GB 到底能不能带 12B 左右的模型

这件事我更愿意写得现实一点：能带，但别想得太美。

Google 在 Gemma 3 官方文档里给过一张很有参考价值的显存表。Gemma 3 12B 大致需要：

20 GB 左右显存加载全精度版本
12.2 GB 左右加载中等量化版本
8.7 GB 左右加载更低显存占用版本

官方也专门提醒，这只是模型加载占用，不包含提示词和运行时额外开销。

这句话很关键。

它意味着什么？

意味着像 3060 12GB 这种卡，跑 12B 左右模型不是不可能，但前提通常是：

你跑的是量化版
上下文不要拉太长
任务别太复杂
你接受速度一般，甚至偏慢

如果你愿意接受这些前提，那本地 12B 确实是能跑起来的。至少做翻译、摘要、表格清洗、固定格式转换，这类任务并不夸张。

另外，Qwen2.5-14B-Instruct-GGUF 的官方仓库本身也提供了多种量化格式，这其实已经把思路说得很清楚了：这一档模型，本来就是面向本地推理生态在做适配。

所以我的结论一直都不是“3060 12GB 能轻松驾驭 12B 模型”，而是：

它能把这类模型带起来，但更适合跑低预期、高重复、重隐私的工作。

便宜模型和本地模型，省下来的不只是 API 钱

很多人聊这件事，第一反应总是省钱。

当然，省钱很重要。但我觉得更大的价值，其实是你开始敢把以前懒得做的一堆边角活交出去。

以前你可能不会为了几百条数据清洗，专门写一轮脚本。也不会为了几十页中英文资料统一格式，手工一点点改。更不会为了临时出一份方案搜集材料，把网页挨个读完再整理。

现在不一样了。

只要成本足够低，门槛足够低，这些原本“不值得动手”的活，就一下子变得值得了。你不再纠结“要不要做”，而是直接扔给便宜模型或者本地模型先跑一遍。

这才是我眼里最现实的变化。

强模型负责攻坚，弱模型负责打杂，本地模型负责兜底和批处理。

这么分工，整个工作流才顺。

结尾

所以最后还是那句话，别老想着让一个模型包打天下。

MiniMax 这类模型，能力弱是弱，但不是废。你拿它去硬刚复杂工程、模糊需求、多轮推理，当然容易失望；你拿它去做数据清洗、文档编写、方案资料搜索，反而常常挺顺手。

本地 12B 左右的模型也一样。它们不是为了证明“我已经不需要云端旗舰了”，而是为了把一些稳定、重复、敏感、批量大的活，老老实实搬回自己机器上。

说白了，别让弱模型去做它不擅长的事。

把工位放对，它们就有现实价值。

参考资料

写作附记

原始提示词

minimax 的大模型，能力弱是弱，做一些数据清洗的工作、文档编写、方案资料搜索还是没问题的; 同样的逻辑，本地部署大模型，做一些翻译类的工作，数据清洗的工作也是不错的，模型的参数量在 12b 左右，本地 3060 12GB 的显卡也能带得动

写作思路摘要

保留了“弱模型别硬上强活”这个核心判断，没有写成模型榜单对比。
MiniMax 部分主要依据官方对编程、搜索、办公的定位，再把判断压回数据清洗、文档、资料搜索这些现实任务。
本地模型部分选了 Qwen2.5 和 Gemma 3 两个官方来源，一个支撑多语言与结构化输出，一个支撑 12B 与显存占用。
对 3060 12GB 的表述刻意写成“能带，但别想得太美”，避免把量化推理写成绝对结论。
结尾把强模型、弱模型、本地模型重新按分工收口，主线更集中。