Ollama用户踩坑实录：90秒冷启动拖垮整个AI工作流

本地部署7B模型，冷启动吃掉90秒，子代理跑36分钟产出垃圾结果——这不是你的配置错了，是Ollama的默认设置根本没打算让你跑生产环境。

这是OpenClaw项目的实战复盘。主代理用Claude Opus，子代理全部走本地Ollama。下面每个坑都是真踩过的，每个解法都是调参调出来的。

5分钟静默杀手：keep_alive的陷阱

Ollama默认5分钟无请求就卸载模型。下次调用时，14B模型重新载入需要60-90秒——你的编排器在这90秒里收不到任何反馈，以为任务卡死了。

子代理任务预期2-3分钟完成，光加载就耗掉一半时间预算。更糟的是网关超时触发后，子代理的工作直接丢失，连报错都看不到。

解法是把keep_alive设为-1，模型常驻内存：

launchctl setenv OLLAMA_KEEP_ALIVE "-1"

36GB内存的M3 Pro可以同时钉住两个8B模型（约10GB），系统和其他应用还有充足余量。但环境变量不够保险——Ollama崩溃、更新、重启后模型照样变冷。

需要预热脚本在开机或重启后自动加载常用模型：

for model in "qwen3:8b" "mistral:7b"; do curl -s http://localhost:11434/api/generate -d "{\"model\": \"$model\", \"prompt\": \"\", \"keep_alive\": -1}"; done

关键策略：只预热高频模型，重型模型（14B代码模型、30B推理模型）按需加载。它们是专科医生，不是全科医生。

100秒上下文税：小模型的隐形开销

OpenClaw给每个子代理注入工作区上下文：AGENTS.md、TOOLS.md、工具定义、系统提示、子代理框架指令。典型配置下，模型看到任务前要先处理100秒的上下文开销。

云模型上下文窗口大、推理快，100秒是背景噪音。7B模型只有32k窗口，在笔记本上跑——这100秒直接吃掉你的token预算和时间预算。

这个开销砍不掉，但可以通过模型选型对冲。Qwen3-8B的上下文处理效率明显高于同规模竞品，在相同注入量下响应更快。

工具调用幻觉：当模型"假装"搜索

子代理被配置为可搜索网页，但本地小模型对工具调用的理解不稳定。常见故障：用户问"Python 3.12有什么新特性"，模型不回答，而是直接触发搜索工具——即使它的训练数据已经覆盖到2024年。

这种"工具滥用"在8B模型上发生率显著高于Claude 3.5 Sonnet。小模型把工具调用当成逃避复杂推理的捷径。

缓解方案是收紧系统提示：明确禁止在知识截止日期内的问题上调用搜索，要求先尝试直接回答。同时给搜索工具加前置判断——"仅当问题涉及实时信息或明确超出知识范围时启用"。

36分钟垃圾时间：超时与重试的博弈

最隐蔽的故障是子代理"假活"：任务在跑，日志在刷，但产出的是循环重复的无效内容。OpenClaw记录到一次极端案例——子代理持续运行36分钟后返回空结果。

编排器的超时设置成了关键参数。设太短， legitimate 长任务被误杀；设太长，垃圾任务占用资源。当前配置采用分层超时：代码生成15分钟，文档处理10分钟，搜索摘要5分钟。

更精细的控制是"进度心跳"——子代理每30秒必须输出进度标记，否则编排器强制终止。这比单纯的时间阈值更能识别僵尸任务。

模型路由：让合适的模型干合适的活

不是所有子代理都需要7B模型。OpenClaw的路由层根据任务类型选择模型：结构化数据提取用3B模型足够，代码审查上14B，复杂推理才动用30B。

路由决策本身也是本地模型跑的——用一个轻量分类器（Qwen3-1.7B）在10毫秒内完成任务类型判断， overhead 可以忽略。

这种"模型即服务"的架构让M3 Pro能同时服务4-6个子代理，平均响应时间从分钟级压到秒级。

一个值得玩味的细节：OpenClaw团队发现，把"你是本地模型，资源有限，请简洁回答"写进系统提示，能让8B模型的输出长度减少40%，幻觉率下降。小模型需要被明确告知自己的约束条件——这和云模型的"你无所不能"提示策略正好相反。

你的本地AI部署卡在哪个环节？是冷启动、上下文开销，还是模型选型的纠结？