本地大模型跑起来之后：硬件之外还有五件事没人告诉你

本地部署的教程通常止步于「跑起来了」。但真正的挑战从那一刻开始。

下面是部署之后最常见的五个坑，以及各自的解法。

一、量化不是「越低越好」

跑得动 ≠ 跑得好。量化的选择需要看任务：

• Q8 / FP8：几乎无损，显存足够就选它；
• Q5 / Q4_K_M：通用场景甜点区，质量损失小，显存占用降 40–50%；
• Q3 及以下：只在显存极其紧张时用，指令跟随和长文本表现会明显退化。

特别提醒两点：第一，小模型对量化更敏感，一个 4B 模型量化到 Q4 后能力可能掉一个档；第二，不同量化实现（GPTQ / AWQ / GGUF 的 K-quants）质量不一，别只看参数量，实测同一批任务再决定。

二、上下文长度和显存是非线性的

很多人按「7B 模型大概 8G 显存」下单，然后把上下文开到 32K，结果爆显存。

原因：KV Cache 随上下文长度线性增长。一个 7B 模型在 32K 上下文下，KV Cache 可能就要几 GB，而且并发的每个请求都要各自一份。真正的算法是：

显存 ≈ 模型权重 + KV Cache × 并发数 + 运行时开销

调参顺序应该是：先定并发，再定上下文，最后选量化。反过来一定会踩坑。

三、服务化比模型本身更花时间

单机跑个 demo 用 llama.cpp 或 Ollama 就够，但一旦要对接业务系统，就必须考虑：

• API 兼容：业务代码最好走 OpenAI 兼容接口，便于日后切换；
• 排队与超时：本地模型会独占 GPU，多个请求会互相拖慢，必须有队列；
• 失败重试：GPU OOM 是常态，要有降级到云 API 的兜底；
• 多模型共存：一个小模型做分类、一个大模型做生成，需要能切换加载，而切换会带来几十秒的空窗。

这套东西的工作量经常比「把模型跑起来」大十倍。

四、prompt 需要重新适配

本地开源模型对同一段提示词的反应和云上的旗舰模型差别很大：

• 对格式指令的服从性普遍偏弱，JSON 输出更容易跑偏；
• 对长系统提示的遵守能力弱，规则要更精简；
• 中文能力在小参数模型上参差不齐，同一系列不同量化版本表现可能不同。

所以从云切换到本地时，提示词必须重测一遍。建议把测试集固化下来，这样每次换模型/换量化都能跑一遍回归。

五、长期运维是最容易被低估的成本

云 API 你不需要关心这些东西，本地全都要管：

• 驱动与框架升级：CUDA、推理框架版本互相挑剔，升级一次可能停服半天；
• 模型更新：开源模型迭代很快，每次更新都要重跑评测、可能重调提示词；
• 监控：显存占用、温度、推理延迟、队列长度，都要有看板；
• 故障率：消费级显卡长期满载，风扇和电源是真实故障点；
• 备份与回滚：模型权重、配置、量化版本必须版本化，否则出问题无法回滚。

粗略估算：一个稳定运行一年以上的本地推理服务，运维投入大约是初期搭建投入的 2–3 倍。

什么时候真的值得本地部署

三条判据，满足两条以上再考虑：

1. 数据不能出内网：这是最硬的理由，没什么替代方案；
2. 调用量极大且稳定：单次成本能压到云 API 的三分之一以下；
3. 有明确的定制需求：需要微调、需要离线、需要极低延迟。

如果只是为了「不想付 API 钱」，大概率算不过来——除非你真的会算电费、折旧和人力。

结论

本地大模型的真正门槛从来不在装机。量化选型、显存规划、服务化、提示词适配、长期运维，这五件事里任何一件没做好，最终结果都是「跑起来了但用不起来」。先想清楚运维谁来做，再决定要不要买卡。