本地模型最容易被误用成两件事：一是把它当成云端大模型的廉价替代品，二是把它当成一个装好以后偶尔问两句的新玩具。前者会失望，后者会浪费。

在一台普通高配开发机上，本地模型真正适合的位置，是进入那些每天都会出现、但不值得每次都打开复杂工具的小任务：解释一段日志、给截图写说明、把零散记录整理成结构化摘要、为文章配图做初步检查、把命令输出翻译成人话。

这篇文章接着前两篇，把已经装好的 qwen3:4b、qwen3:8b、gemma4:e4b 和 gemma4:12b 放进三个真实工作流里。目标不是证明它们多强，而是找出一套可以长期保留在本机上的用法。

本地模型该处理什么

我现在对本地模型有一个比较朴素的判断标准：

能在 10 秒内给出有用结果、输入数据又不需要特别大的上下文，这类任务最适合放到本地。

它不一定要一次回答得完美，但要足够快，足够稳定，足够容易接进脚本。只要它能把一个反复发生的小动作从“手动判断”变成“自动预处理”，本地模型就有价值。

反过来，下面这些任务不适合直接交给本地小模型：

• 需要严格事实准确、且事实会频繁变化的问题
• 要一次读完整个大型代码仓库的问题
• 需要长上下文、多轮严密推理的复杂方案设计
• 需要法律、医疗、金融等高风险判断的问题
• 输出必须一次可上线、不能人工复核的内容

所以这套工作流的核心不是“让本地模型替我决定”，而是“让本地模型替我先整理一遍”。

工作流一：开发辅助

开发时最常见的碎片任务，不是让模型写一个完整系统，而是这些小动作：

• 解释一段报错日志
• 把命令输出整理成排查步骤
• 给一段函数写更清楚的注释
• 把一段 shell 命令改成更稳的版本
• 从一段提交说明里提取影响范围

这类任务最适合 qwen3:8b。它比 qwen3:4b 稳，速度又没有慢到影响节奏。热启动后，通常不到一秒就开始进入推理阶段，生成速度大约在 20 多 tok/s，足够做日常辅助。

我会把它封装成一个非常克制的本地命令，而不是每次手写长 prompt。比如“解释日志”的 prompt 可以固定成这样：

你是一个资深工程师。请阅读下面的日志，只做三件事：
1. 用一句话说明最可能的根因；
2. 按优先级列出 3 个排查动作；
3. 如果信息不足，明确说明还缺什么。

日志：
{{LOG_TEXT}}

调用时显式关闭思考输出：

curl http://127.0.0.1:11434/api/chat \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "qwen3:8b",
    "think": false,
    "stream": false,
    "messages": [
      {"role": "user", "content": "你是一个资深工程师。请用三点解释这段错误日志的排查方向：..."}
    ]
  }'

这里最重要的不是模型名字，而是 prompt 的边界要小。不要让它“全面分析系统”，而是让它“解释这段日志”。输入越具体，本地模型越像一个可靠的小工具。

qwen3:4b 则适合更轻的开发任务，比如给提交信息分类、判断日志级别、给短代码片段生成标题。它的显存占用只有 2.7GB 左右，速度能到 40 tok/s 附近，很适合做批量流水线里的前置判断。

工作流二：截图和视频素材初筛

本地多模态模型的价值非常直接：很多截图、图表、录屏和临时素材并不适合随手上传到外部服务，但又确实需要被快速理解。

比如：

• 看一张控制台截图，先识别错误区域
• 看一张架构图，生成初步文字说明
• 看一张文章配图，判断主题是否跑偏
• 给图片生成 alt 文本
• 把一张图表转成可读摘要
• 把一段屏幕录制抽帧后生成摘要

这类任务我会优先交给 gemma4:e4b。它的定位不是“最终判断器”，而是“第一遍读图的人”：先把画面中可见的对象、文字、结构和可能用途列出来，再由人决定哪些可信、哪些要删掉。

完整的图片识别 prompt、原始输出、视频低隐私抽帧和模型返回文本，我已经放在上一篇基准测试文章里：《本地四个开源模型跑了一遍：Qwen3、Gemma 4 在 8GB 显存上的真实表现》。这篇不再重复贴同一批结果，只保留工作流层面的规则。

我现在会把图片理解任务固定成这个输出结构：

请观察这张图片，并按下面格式输出：

1. 一句话主题：概括图片在表达什么。
2. 可见元素：列出你确实能看到的对象、界面或文字。
3. 技术信息：判断图片和哪些技术主题有关。
4. 适合用途：说明它适合放在什么文章或场景里。
5. 不确定点：明确说明哪些内容无法仅凭图片确认。

请只根据图片回答，不要编造看不到的信息。

视频则不直接喂给模型，而是先抽帧。这里有两个工程规则：

1. 如果视频里有清晰人物，公开文章里不要直接展示这些帧；优先选择环境、物件、界面、背影、低清晰度远景等低隐私帧。
2. 让模型明确输出“局限”，尤其是抽帧会丢失音频、动作连续性、人物互动和完整时间线。

一个可复用的抽帧命令是：

mkdir -p frames
ffmpeg -i input.mp4 -vf fps=1/5 frames/frame-%02d.png

如果是公开写作素材，我不会把所有帧都给模型，而是先人工筛一遍，只保留 6 到 12 张最能表达结构、又不暴露隐私的帧。数量过多会明显拖慢本地模型，也会让输出更容易变成流水账。

这套流程最终应该沉淀成一个小脚本：

1. 抽帧并生成缩略图拼图。
2. 人工或规则过滤掉敏感帧。
3. 调用 gemma4:e4b 生成主题、时间线、可读文字和局限。
4. 把模型输出和原始帧路径一起保存，方便复核。

它更适合处理屏幕录制、教程视频、小段演示视频、文章素材初筛，而不是完整电影或长会议。长视频需要先切片，再分段摘要，最后做二次合并，否则本地模型的上下文和速度都会成为瓶颈。

工作流三：写作整理

写文章时，本地模型不适合替你写观点，但非常适合整理材料。

我会让它做这些事：

• 把测试记录整理成文章大纲
• 从命令输出里提取关键数据
• 给段落生成更自然的小标题
• 检查一篇文章是否前后重复
• 为配图生成说明文字
• 把技术步骤改写成读者能跟上的表达

以本地模型测试文章为例，原始材料可能是这样的。这里不需要把模型原始输出全文塞进工作流文章，真正应该保留的是“输入材料是什么、期望输出结构是什么、哪些结果需要人工复核”：

qwen3:8b cold load 16.822s
think:false response normal
eval_count 51
eval_duration 1.986s
speed 25.68 tok/s
gpu memory about 4.9GB

我不会让模型直接“写一篇文章”，而是让它先整理成结构化笔记：

请把下面的模型测试记录整理成表格字段：
模型、加载时间、生成速度、显存占用、异常现象、适合场景。
不要扩写，不要补充记录里没有的信息。

这类任务用 qwen3:4b 或 qwen3:8b 都可以。区别在于：qwen3:4b 更适合批量整理短记录，qwen3:8b 更适合材料稍长、需要中文表达更稳的场景。

我试过把更长的测试材料直接交给本地模型整理，结果提醒我一件事：整理类任务也要验收输出形态。模型可能把分析过程写进正文，也可能把“约 6.3 倍提升”概括成更夸张的说法。工作流里不能只看它有没有回答，还要检查：

• 表格列是否齐全
• 数值是否来自原始材料
• 是否出现没有依据的新结论
• 是否把不确定判断写成确定结论
• 是否保留了后续复核需要的原始证据

所以写作整理这一步的定位很明确：它负责把材料摊平，把结构搭起来；最终判断、删改、措辞和事实复核仍然由人完成。

一套实用路由

经过这几轮测试，我会把本地模型按任务类型分开，而不是让所有任务都问同一个模型。

任务	默认模型	失败后升级	原因
日志解释	qwen3:8b	云端强模型	中文表达稳，速度够用
提交信息分类	qwen3:4b	qwen3:8b	轻任务，适合批量
测试记录结构化	qwen3:4b	qwen3:8b	输入短，格式固定
截图说明	gemma4:e4b	gemma4:12b	多模态可用，速度好
视频抽帧摘要	gemma4:e4b	人工复核	适合屏幕录制和短视频初筛
复杂图片复核	gemma4:12b	人工复核	描述更细，但较慢
长文最终润色	云端强模型	人工精修	本地小模型上下文和稳定性不够

这张表比单纯的模型排名更有用。因为真实工作里，问题不是“哪个模型最好”，而是“这个任务该交给谁最划算”。

工程化时要守住的几条线

本地模型一旦接进工作流，就要把它当成一个不稳定外部依赖来设计。

第一，调用必须有超时。哪怕模型通常很快，也不能让一个卡住的请求拖住整个流程。

第二，输出必须校验。让模型返回 JSON，就要真的解析 JSON；让模型返回表格，就要检查列是否齐全。

第三，结果必须可回退。模型失败时，脚本应该保留原始输入，给出明确错误，而不是吞掉内容继续往下跑。

第四，不要把不可复核的决定交给本地模型。它可以做初筛、摘要、建议，但最终动作要么人工确认，要么有明确规则兜底。

这些听起来像工程常识，但恰恰是本地模型从“能用”变成“长期可用”的分界线。

下一步

到这里，本地模型已经不只是装好了，而是有了一套初步分工：

• qwen3:4b 做轻量批处理
• qwen3:8b 做日常文字主力
• gemma4:e4b 做默认图像理解
• gemma4:12b 做慢速复核

后续还需要继续补三类测试。

第一类是 CUDA 版 llama.cpp。CPU 基线已经跑过，但它不是这台机器的最佳形态。只有把 GPU 版编译起来，才有资格和 Ollama 做更公平的对比。

第二类是更完整的多模态测试。图片和视频抽帧已经能用，接下来要看音频、长屏幕录制和更多真实图表能不能进入同一个工作流。

第三类是真正的自动化脚本。模型测试文章不能只停在“我手工 curl 了一下”，最终应该沉淀成几个稳定命令：解释日志、读截图、整理测试记录、生成图片说明。能被反复调用，才算真正进入了本地开发环境。