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

dev.to · AI#本地模型#Apple Silicon#性能优化

Editor brief · 编辑速览

在8GB内存Apple Silicon设备上，8B量化模型因内存压力导致交换频繁，实际响应反而比4B模型更慢，tok/s仅6.8，冷启动即卡顿。

文章思维导图

Knowledge map

拖拽缩放

Full translation

完整中文译文

我在一台小 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：

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

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