LLM Inference

如果你最近还在把“LLM 推理优化”等同于量化，我建议停一下。 量化当然重要，尤其是本地部署和消费级 GPU 场景。但 Google 刚发的 Gemma 4 多 token 预测（Multi-Token Prediction, MTP）让我更确信一件事：下一轮推理加速的主战场，不只是在“把模型压小”，而是在减少大模型被调用的次数。 Google 在官方博客里说，Gemma 4 通过 MTP drafters 在推理阶段最高可以做到 up to 3x faster。这个数字本身很抓眼球，但我更关心它背后的工程含义：如果草稿器能一次猜中多个后续 token，大模型就不必老老实实一个 token 一个 token 地跑完整前向传播。 说白了就是：以前是大模型每吐一个字都要“亲自审批”；现在是小模型先写一小段，大模型批量盖章。 为什么“一个 token 一次前向”这么浪费 自回归 LLM 的默认解码方式很朴素：给定上下文，预测下一个 token；把这个 token 拼回上下文，再预测下一个。这个循环看起来合理，但对硬件很不友好。 每生成一个 token，模型都要访问大量权重。对于 27B、70B 这种规模，瓶颈往往不是矩阵乘法算不动，而是显存带宽和调度开销被小步循环吃掉。你可以把它理解成：GPU 明明适合一次搬一大车货，结果我们让它每次只送一个快递。 这也是为什么我之前写 DFlash + DDTree 投机解码 时，最看重的不是某个 benchmark 数字，而是“平均接受长度”。只要一次验证能接受更多 token，大模型前向次数就会下降，吞吐自然上来。 Gemma 4 的 MTP 走的是同一条大方向，但实现路径更靠近模型训练本身。 传统 speculative decoding 通常需要一个独立的小 draft model。经典论文 Speculative Sampling 的思路就是：小模型先生成候选，大模型并行验证，最后用修正过的采样过程保证输出分布不变。这套方法很漂亮，但工程上有两个麻烦：你要维护两个模型，还要处理 tokenizer、KV cache、调度和显存布局。 MTP 的反直觉之处在于，它不一定非要靠“另一个完整小模型”来猜。Meta 的论文 Better & Faster Large Language Models via Multi-token Prediction 提出，在训练时让模型不只预测下一个 token，而是同时预测未来多个 token。技术上可以看成在共享 trunk 上接多个输出 head，训练目标从“只看一步”扩展到“顺手看几步”。 ...

一个 27B 参数的大模型，在一张 2021 年买的游戏显卡上能跑多快？ Lucebox 团队给出了一个让很多人没想到的数字：207.6 token/s。用的还是 Qwen3.5-27B 官方模型，不是蒸馏，不是 INT8 量化残血版——就是 Q4_K_M 量化版本，目标加草稿模型全部加载在一张 24 GB VRAM 的 RTX 3090 上。 这个成绩靠的不是等英伟达下一代消费级显卡，而是对解码算法本身动刀子。 为什么自回归解码是瓶颈 大多数人聊 LLM 推理优化，会先想到量化、KV cache 压缩、batch 并行。但对单卡消费级 GPU 来说，这些都已经做到头了——Q4_K_M 量化能压缩到约 16 GB，再压下去效果肉眼可见地降。 问题出在自回归解码本身。每生成一个 token，GPU 要完整跑一遍 27B 参数的前向传播。27B 参数在 Q4_K_M 下大约 16 GB，VRAM 带宽是 936 GB/s——每次解码都要把这 16 GB 从显存读一遍，理论带宽利用率撑死不到 20%。这是机械式的物理限制，不是软件优化能绕过去的。 speculative decoding（投机解码）解决的就是这个问题：用一个小草稿模型一次生成多个候选 token，再用大模型一次验证整串。如果草稿猜得准，大模型只跑一次就能吐出五六个 token，GPU 计算资源用得更充分。 DFlash：块扩散草稿，比 Chain EAGLE 更容易命中 主流投机解码方案是 EAGLE（及其 chain 版），草稿模型做自回归预测，每步大约能接受 3 个 token。DFlash（2026） 换了个思路：用块扩散（block diffusion） 做草稿——一个 5 层非因果的去噪网络，同时预测多个位置，而不是逐个生成。 ...

引言：一个「只修皮毛」的工具为什么获得 16 万星 2023 年，Ollama 以「Docker for LLMs」的定位进入开发者视野——一行命令下载模型，本地跑起来。这种低门槛让它迅速积累了 16.9 万 GitHub Stars，成为本地运行大模型的事实标准。 然而，它的底层问题正在被更多开发者意识到：许可证归属争议长达一年未处理、自研后端性能反而低于 llama.cpp 30-50%、模型格式产生供应商锁定……这些问题在 Hacker News 上引发了大量讨论，HN 热帖当天获得 603 分。 本文不是「二选一」的观点稿，而是一次基于事实的深度拆解——为什么 Ollama 的工程实践存在系统性缺陷，以及真正值得投入生产的替代方案是什么。 背景：llama.cpp 才是本地 LLM 的真正引擎 要理解 Ollama 的问题，先要了解它依赖的底层技术。 llama.cpp 由 Georgi Gerganov 于 2023 年 3 月用一个晚间编写，最初只是一个将 LLaMA 模型跑在消费级硬件上的 C++ 推理引擎。它的核心创新是 GGUF 量化格式——让数十亿参数的大模型能够在普通电脑的 CPU 和 GPU 上高效运行。 今天，llama.cpp 拥有： 104,116 Stars，450+ 贡献者 MIT 许可证，完全开源 2026 年 2 月，ggml.ai 项目并入 Hugging Face，确保长期可持续发展 可以说，没有 llama.cpp，就没有本地 LLM 生态的今天。 问题是：Ollama 几乎从未承认这一点。 问题一：长达 400 天的许可证争议 Ollama 于 2023 年 6 月公开，基于 MIT 许可证开源。然而，其二进制发布包中包含 llama.cpp 代码，却从未附带 llama.cpp 要求的版权声明——这是 MIT 许可证的唯一主要义务。 ...