本地跑大模型终于不折腾了:Vicki Boykis 那篇 989 分 HN 帖,总结了哪些真正重要的变化

Vicki Boykis 刚发了一篇长文,回顾了过去一年本地跑大模型的真实体验变化。在 HN 上拿了 989 分,说明不只我一个人觉得这话题值得聊。

她提到几个我比较有共鸣的点:

定量化模型已经够用了

Qwen 3.6、Gemma 4、Llama 4 这些量化版本在 FP8/Int4 下,推理质量衰退其实很有限。如果只是代码补全、翻译、文档分析、短分类,6-8GB VRAM 的卡完全够跑 27B~70B 的量化版。一年前这还是个奢望。

推理引擎成熟得很快

llama.cpp、vLLM、SGLang 这些引擎现在对消费级卡的支持已经很到位了。KV cache 管理、prompt caching、量化推理、tensor parallelism 这些都稳定了。不像以前每篇教程都要自己手动搞一堆 patch。

工具链补上了最后一公里

之前最大的痛不是模型跑不动,而是怎么接入已有工具。现在 ollama / LocalAI / Open WebUI 这些把 API 兼容层做好了。本地跑个模型,跟调用 OpenAI 接口的体验差距越来越小。

不过她也点出了一些还没解决的事:

  • 多模态还是吃显存:能跑的模型多了,但视觉模型在消费级卡上仍然得很小心调度
  • 长上下文依然贵:KV cache 占的显存随 token 数线性增长,几个方案的 prefix caching 命中率还不稳定
  • 工具调用/Agent 场景开销大:本地跑 agent 时,每轮工具调用都带上下文,推理链越长,延迟和成本越容易失控

对我来说,这篇文章最实在的结论是:2026 年中,本地跑模型从「能不能跑」变成了「怎么用得划算」。对个人开发者和团队来说,这个拐点意味着部署决策需要重新算账了。

你觉得本地跑的收益现在够大了吗?还是说看场景——哪些场景值得本地跑,哪些还是老老实实走 API 更省心?


延伸阅读:

test reply - ping

如果只是内部知识库,rerank/embedding/小模型分类先优化,可能比直接换更大的生成模型划算。

多租户其实挺麻烦的。一个用户突然丢超长上下文,其他短请求的延迟也会被拖住。

1 个赞

这类栈如果没有统一日志,很难定位到底是模型慢、排队慢还是下游工具慢。生产里可观测性比 demo 重要太多。

本地部署还要看显存碎片和重启恢复。跑一天稳定,和跑一个压测脚本,是两件事。

我现在算成本会把缓存命中率单独列一栏,不然长 system prompt 的场景很容易被低估。

有没有人试过把 vLLM 和 SGLang 混用?不同模型可能最优后端不一样,但维护复杂度会上去。