Mac mini本地跑8B模型反而比4B更差

我在一台小 Mac mini 上做了一次显而易见的本地 LLM 升级：从 4B 模型切换到 8B 模型。

这台机器是一台 8GB Apple Silicon mini，运行着一套个人助手栈。之前使用 mlx-community/Qwen3-4B-4bit 通过 Swama 的 OpenAI 兼容端点已经跑通了：

4B weights: ~2.3GB
warm plain reply: ~1s
warm tool-call round: ~3-4s model time
full tool response: ~7-18s, depending on external APIs

于是我拉取了 8B 量化模型，想看看额外的算力是否值得。

第一个最简单的请求就足以说明问题：

8B weights: ~4.3GB
"say hello": 14s
throughput: 6.8 tok/s
swap churn: ~1.6GB in/out
free memory: basically zero

这不是边界情况。这已经是最便宜的可能 prompt 了。

真正的助手请求要更重：system prompt、近期的对话、tool schemas，可能还有一轮 tool 调用，然后才是最终回答。如果 8B 模型在 hello 这个级别就开始 swap，那在应用其余部分还在运行的情况下去处理天气/tool/家庭状态请求，它肯定撑不住。

烦人的地方在于，这个模型选择纸面上看是合理的。8B 应该更聪明。单独看可能确实如此。但本地 AI 工作不是模型排行榜工作。它涉及的是内存压力、冷启动、prompt prefill、tool 可靠性，以及请求结束后机器是否还能正常使用。

修复方案并不花哨：

MAX_HISTORY_MESSAGES = 10

@lru_cache(maxsize=1)
def get_ai_handler():
    return SwamaAIHandler()

限制 prompt 历史记录。复用 handler。把长期记忆作为蒸馏过的事实来存储，而不是原始对话回放。使用那个能常驻内存且响应足够快的 4B 模型。

我还不得不加上一些无聊的生产环境 guardrails：

• 运行真正的 Swama 二进制文件，而不是符号链接，因为首次推理时加载 MLX 的 metallib 会崩溃
• 保持模型处于热状态，因为空闲驱逐后的冷启动代价很高
• 从流式响应中剥离 <think> 块，因为在 tool 调用之后 /no_think 不够用
• 在 prompt 中加入偏向 tool 使用的偏置以获取实时数据，因为小模型如果你放任它，会自信地用过时权重来回答

教训很简单：在微型本地硬件上，最好的模型是那个在模型之外还为产品留出足够机器资源的模型。

4B 模型上线了。8B 模型被删掉了。