为什么你的本地 LLM 感觉比它实际更笨

原文 ↗ Hacker News 讨论 ↗

许多用户发现，运行在自己硬件上的大语言模型会显得比云端系统更弱，这并不是因为模型本身一定更差，而是因为配置上的坑，比如错误的聊天模板、过激进的量化、过小的上下文窗口，以及不理想的采样设置。参与者比较了 llama.cpp、Ollama、vLLM 和各种量化方案，指出流行运行器中的默认设置可能会悄悄削弱推理、工具调用和长上下文表现。讨论还权衡了本地运行强大模型的代价——在消费级硬件上往往发热、嘈杂且缓慢——与把工作卸载到云 GPU 之间的取舍；一个反复出现的主题是，精心配置和面向任务的基准测试，比模型名称或参数规模本身更重要。

硬件、散热和速度

  • 很多人反映，Qwen 3.8 27B 和 Gemma 4 在较新的 Mac 和 GPU 上表现惊人地好，但会带来明显发热、风扇噪音和较高的电池消耗。
  • MacBook Pro（M1–M5，32–128 GB RAM）在 27B 模型上的速度约为 ~12–60 tok/s；稠密模型通常“可用但很慢”，尤其是在较大的上下文下。
  • 用户会通过省电模式、风扇控制工具、笔记本散热垫，或把推理任务卸载到家用服务器来缓解发热。
  • 也有人更偏好 GPU 云实例（Vast.ai、DO、Linode），价格约 ~$2/小时，借助脚本和隧道按需启动，用于更严肃的工作。

为什么本地 LLM 会感觉“很笨”

  • 一个反复出现的观点是：糟糕的聊天模板和非厂商默认采样参数，即使量化本身没问题，也会显著降低质量。
  • 一些运行器会悄悄回退到通用模板（例如 ChatML），让模型表现得没那么强。
  • 量化级别和 KV cache 压缩会强烈影响推理能力，尤其是在长上下文中；一些低质量量化（例如某些 W4A16/NVFP4）被点名批评。
  • 也有人强调应坚持使用更高质量的量化（Q8、好的 GGUF 方案），如果准确性重要，就避免对 KV cache 做量化。

Ollama vs llama.cpp vs vLLM/其他

  • 对 Ollama 的批评包括：相比 llama.cpp/vLLM/SGLang 功能更新滞后、默认设置可疑（上下文较小、量化不透明、性能更慢）、注册表混乱、可调参数有限。
  • 也有人认为 Ollama 用起来很方便，只是它隐藏了重要细节，导致用户误判模型质量。
  • llama.cpp（及其变体）因可靠性、性能和细粒度控制而受到称赞，不过如果没有好的指引，配置可能并不轻松。

用例以及与云模型相比的价值

  • 正面体验：本地模型可用于代码审查、语气检查、工具/Agent 工作、CTF/逆向挑战以及私有工作流。
  • 负面体验：本地模型通常太慢，或者能力不如前沿云模型（Claude、GPT、Gemini），尤其是在编码和复杂推理方面。
  • 有些人认为，只有完全装入 VRAM 的未量化 BF16 模型才真正值得；另一些人则对精心选择的 4-bit 量化感到满意。

元话题：基准测试与适配

  • 大家强烈强调，应构建面向任务的基准和测试框架，而不是依赖排行榜式的总分。
  • 也有人提到可以针对公司自己的代码/工单做后训练或类似 RL 的微调，不过投入与回报是否划算仍有争论。