LLM推理速度优化指南：从精度选型到引擎调优

LLM 推理速度，是本地模型和线上服务都会撞上的真问题。Frontier.fast 从项目定位看，目标很直接：把 LLM 速度往前推。不管是降低首字延迟、提高每秒生成 token 数，还是提升批量吞吐，这类项目想解决的都不是模型能力不够，而是模型跑起来之后的工程效率。如果你在做 LLM 应用开发、想在本地跑模型做验证，或者正在为线上推理服务挑方案，这里想把速度这件事拆透：它由哪些环节决定、怎么测才准、哪些参数值得调、哪些地方会莫名其妙拖慢速度。

先给一个核心判断：LLM 快慢不是单一指标，也不是一门心思换引擎就能解决的。很多人抱怨“生成太慢”，实际上可能是显存不足触发了交换、prompt 太长导致预填充阶段爆炸、并发太高排队严重，甚至只是量化位宽没有选对，输出质量反而变差。把这些问题分开看，速度优化才有的放矢。

1. 为什么“推高 LLM 速度”成了热门方向

1.1 速度问题是一整条链路，不是模型一个点

一个 LLM 请求从发起到结束，中间经过的环节比大多数人想的要多：

• 输入文本先经过分词，转成 token id；
• token 序列进入模型，一层一层做矩阵计算；
• 计算过程要反复读取模型权重，显存或内存的带宽直接决定速度上限；
• 每生成一个新 token，都要结合前面所有上下文重新算一遍；
• 如果应用里接了 RAG、Agent、工具调用，还要额外算上检索、拼装 prompt、调用外部接口的时间。

所以模型架构只是其中一环。社区里像 Frontier.fast 这类项目，实际优化对象各不相同：有的优化底层算子，有的优化显存复用，有的优化 batch 调度，有的优化 KV cache。看到“速度提升”的宣传，第一件事不是跑分，而是先搞清楚它优化的是哪一段，和你的场景是否匹配。

1.2 哪些人最该关注 LLM 推理速度

第一类是本地跑模型的用户。8GB、16GB 显卡或 Mac 统一内存环境下，最怕的不是模型不聪明，而是显存不够导致跑不动，或者每生成一个 token 都要等很久。

第二类是 LLM 应用开发者。RAG 问答、Agent 多轮调用、批量文档分析，每一个请求都在消耗时间。处理速度直接决定用户等待时间，也决定服务成本——同样的任务，慢一倍就多占一倍资源。

第三类是负责部署和运维的人。他们必须同时看延迟、吞吐、显存占用、稳定性，而不是只看单条任务跑得快不快。第四类是做实验和评测的人，他们需要一套可重复的测速方法，否则同一个模型换一个环境，数据就完全不可比。

1.3 对“速度推前型”项目的合理预期

Frontier.fast 这类把目标写在“push the frontier of LLM speed forward”上的项目，通常不是只做一个功能的小工具，而是围绕推理速度做整体优化。具体实现了哪些算子、支持哪些硬件，我这里不展开罗列——不同版本差异很大，直接照着别人分享的功能清单去对号入座容易踩空。

更稳妥的做法是：先看它解决了哪一类速度瓶颈，再用自己的任务去验证。判断一个速度优化项目值不值得用，我一般看三件事：第一，它有没有说明适用的硬件和精度范围；第二，它有没有给出可复现的测速方法；第三，它有没有区分首字延迟和生成速度。这三个问题都回答清楚了，项目才算得上“能验证”。

2. 先拆清楚 LLM 推理的几个时间组成

2.1 Prefill 阶段决定首字延迟

LLM 生成回答不是一次算完。用户输入 prompt 之后，模型会把整段 prompt 并行计算一遍，把中间结果缓存下来，这一步叫 prefill，也就是预填充。它的耗时决定了你从点下发送到看到第一个字的时间。

prompt 越长，prefill 越慢。长文档问答、RAG 检索后拼接大段上下文，都会让首字延迟明显上升。如果你做的是本地知识库问答，比如在笔记工具里整理文档并让模型逐条回答，这类场景对首字延迟非常敏感，因为你是边看边等，等着第一个字出现的时间很长的话，体验会非常差。

2.2 Decode 阶段决定每秒生成速度

prefill 结束之后，模型进入逐 token 生成阶段，也就是 decode。每生成一个 token，都要把当前序列重新算一遍，这个串行过程决定了“每秒生成多少个 token”。

这个速度受模型大小、精度、硬件带宽、上下文长度、KV cache 命中情况等多个因素影响。把两个阶段分开看很有用：首字慢，问题多半在 prefill、网络或排队；首字出来很快，但光标一直跳得慢，那是 decode 的问题。

2.3 三个关键指标不要混在一起

• TTFT（Time To First Token）：从请求发出到收到第一个 token 的时间，代表“用户的等待感”。
• tokens/s：生成阶段的每秒输出 token 数，代表“光标跳动的速度”。
• 总耗时：TTFT 加上生成耗时，再加上可能存在的排队时间，代表“一个任务最终完成的时间”。

有的引擎会用投机解码这类技术，让一个小模型先快速草稿，大模型再批量验证，从而提升 decode 速度。但它对 prompt 类型、草稿模型质量、硬件算力都有要求，不是所有场景都能稳定提速。看到这类功能时，先在自己的任务上跑一轮再说。

3. 精度选型是影响速度的第一个大坑：fp16、bf16、fp32

3.1 三种精度的存储和计算差异

大模型推理时，权重和中间结果用不同精度存储，速度和效果会明显不同。这也是社区里讨论“LLM 精度问题”时最常见的三个名词。

• fp32：32 位单精度浮点数，数值范围大、精度高，但显存占用高，计算慢。大模型全量跑 fp32 基本不现实，一般只用于小模型调试。
• fp16：16 位半精度浮点数，显存占用只有 fp32 一半，计算通常更快，但动态范围小，数值容易溢出。
• bf16：也是 16 位，但指数位和 fp32 一样多，动态范围大，很多现代加速硬件都有专门支持。

3.2 为什么 bf16 在大模型里越来越常见

bf16 保留了 fp32 的动态范围，又只有 fp32 一半的位宽，所以大模型加载、推理时更省显存。但它尾数位少，精度其实比 fp16 还要粗，并不是全面“更好”，而是更适合大模型这种对数值范围敏感、对极小精度不敏感的场景。

实际跑推理时，很多引擎默认的精度就是 fp16 或 bf16。你需要自己确认当前的方案到底是哪个，因为同样一个引擎，切换精度之后，速度和显存占用都会变。

3.3 量化能提速度，但不是免费的

比 fp16 更低的是 int8、int4 量化，把权重压成整数格式，能显著降低显存占用，同时提升计算速度。代价是输出质量可能下降，尤其在长文本、数学推理、多轮对话里。

看到“量化后速度提升”的结果，不能只盯 tokens/s，还要用同样的 prompt 对比输出内容，看是否有格式丢失、逻辑错误、重复输出等问题。如果项目本身经过微调，量化后可能更敏感，验证时要额外加上和微调任务相关的测试样本。

3.4 精度选择的判断标准

• 内存或显存够用，先跑 fp16 或 bf16，不要一上来就量化。
• 内存不够，先试 int8；再不行才考虑 int4。
• 量化后必须做质量回归，不能只看速度。
• 同一个模型在不同精度下的速度差异，要拿你自己的机器实测，网上数据只能参考。

4. 推理引擎和框架怎么选，直接决定速度上限

4.1 常见推理引擎的类型和定位

• llama.cpp 系列：以 CPU/GPU 混合运行为特点，量化支持好，适合本地、低显存环境。
• vLLM 这类服务化引擎：面向线上高并发，连续批处理和 KV cache 管理做得比较细。
• Ollama、LM Studio 这类封装工具：本地安装简单，适合学习和快速验证，但可调参数相对少。
• ONNX Runtime、TensorRT 等：针对特定硬件做深度优化，性能上限高，但适配成本也高。

同样的模型在不同引擎上的速度可能差很多。某个引擎“支持”某个模型，和“支持得好”是两回事，必须拿自己的硬件和任务去实测。网上经常有人讨论“最佳 Mac LLM 推理引擎”，实际上没有统一答案，同一个模型在 M1、M2、M3 上的表现差异也很大，只能自己试。

4.2 框架层为什么会影响速度

只跑单个请求时，不同引擎的差距可能不大。一旦上并发，batch 策略、显存调度、队列管理就会拉开差距。常见的手段包括：

• 连续批处理：一个请求算完立刻补新请求，提高硬件利用率；
• KV cache 复用：把历史缓存存下来，避免多轮对话重复计算；
• 请求合并：把多个短 prompt 拼成一个 batch，提高吞吐。

LLM 应用为什么需要编排框架，也和速度有关。Agent 要调用几次工具、MCP 服务要访问哪些资源、RAG 检索多少片段、多轮对话带多长历史，都会影响模型推理压力。编排框架本身不直接加速模型，但可以减少无效推理：缓存重复问题、压缩历史、按需检索，端到端耗时往往能降下来。

4.3 本地环境怎么选：Mac、Windows、Linux 的差异

Mac 上主要靠统一内存和 Apple Silicon 的推理加速，MPS、Metal 相关引擎支持普遍较好。内存越大，能跑的模型越大，但同一模型在 M1、M2、M3 上的速度差异也很大。

Windows 上常见 NVIDIA 显卡加 CUDA 环境，或者纯 CPU 跑小模型。Linux 服务器更适合 vLLM 这类服务化部署，尤其是多卡、高并发场景。

如果想让局域网内其他设备访问本地模型，需要让模型服务进程监听对应网卡地址，并设置合适的访问控制和鉴权，不要把服务直接暴露到公网。这部分不是速度问题，但很容易在联调时拖慢整体进度。

5. 从单条测速到批量场景：怎么验证速度提升

5.1 先跑最小样例

拿到任何新项目或新引擎，第一步不是调参数，而是跑通最小样例：模型能加载、输出能正常打印、日志没有报错。

很多人直接跳过这一步，因为“系统能启动就行”。但很多问题恰恰是启动没问题、一跑推理就崩。先跑通一条最简单的请求，后面再做任何对比测试，才有可靠的基线。

5.2 单条测速的正确姿势

• 固定 prompt 长度：首字延迟和 prompt 长度强相关，一直用同一句短句测不出真实表现。
• 固定生成长度：把 max_tokens 限制住，否则生成长度不同，tokens/s 不可比。
• 先做 warmup：第一次推理要加载权重、初始化缓存，速度明显偏慢，先跑一条再计。
• 多次取中位数：单次测速波动很大，至少跑三到五次，看中位数和最大值。

下面是一个用 OpenAI 兼容接口记录请求耗时的示例，具体地址和参数以你实际部署的服务为准：

curl -s -o /dev/null -w "TTFT:%{time_starttransfer}s 总耗时:%{time_total}s\n" \ http://127.0.0.1:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model":"your-model","messages":[{"role":"user","content":"用三句话介绍你自己"}],"max_tokens":256}'

如果要看 prefill 阶段和 decode 阶段分别花了多久，最好用推理引擎自带的日志或 profiling 工具，而不是只看接口总耗时。

5.3 批量场景要看的指标完全不同

单条快不代表批量稳。批量任务里，重点要看：

• 并发升高后 TTFT 会不会飙升；如果排队时间很长，单条再快，用户侧体验也差。
• 显存会不会被多个请求打爆；发生 OOM 之后能不能自动恢复。
• 某个输入格式异常，是否导致整个批次停掉；失败任务能不能跳过或重试。
• 大批量文件处理时，输出命名是否冲突、结果是否会被覆盖。

这些不全是推理引擎本身的问题，但在工程落地里往往比“单条快那么几百毫秒”更关键。

5.4 建立自己的基准测试记录

我建议维护一张简单的基准表，每次调整都记录，前后对比才有意义：

现在社区里已经有不少人像维护 wiki 一样整理各种引擎的基准数据，但那些数据是别人环境里的结果，不能代替自己机器上的记录。只有把环境、输入、参数、输出质量都固定下来，你才能说清“这次优化到底有没有用”。

6. 速度上不去时，按这个顺序排查

6.1 先看现象，再动参数

报错、卡住、无输出、速度慢，是四种不同的问题，处理方式要分开。第一步永远是把日志完整看一遍，确认是推理阶段慢、接口排队慢，还是请求根本没有发到模型。

不要一上来就调并发。并发调大之后，如果瓶颈在显存或带宽，只会让情况更糟。

6.2 先看输入和任务特征

• prompt 是不是特别长；超长输入的 prefill 耗时可能比生成阶段还长。
• 生成长度上限是不是被设得很大；输出 token 数就是实际工作量。
• 应用层是否调用了 RAG、Agent、外部接口；每多一次调用，都会增加端到端耗时，但模型本身的生成速度并没有变化。

6.3 再看资源占用

• 显存快满时，会出现交换或 OOM，速度会断崖式下降。
• Mac 统一内存被占满，同样会拖垮整机。
• GPU 利用率很低但任务很慢，可能是数据搬运、批处理或算子适配问题。
• 磁盘写入慢，日志和结果输出可能变成新的瓶颈。

6.4 再看参数和配置

• batch size 和并发数：从 1、2、4 逐渐往上加，找到吞吐和资源的平衡点。
• 量化位宽：显存吃紧时先考虑降低量化位宽，而不是一味调小 batch。
• 缓存开关：多轮对话能否复用 KV cache，应用层是否做了结果缓存。
• 上下文长度限制：很多模型默认支持超长上下文，但开得越长，显存和耗时越高，用不到那么长就限制住。

6.5 最后看引擎和硬件适配

如果输入、资源、参数都正常，速度还是不达标，就要考虑引擎对当前硬件的适配问题。同样的模型换个引擎，结果可能完全不同。对比时需要保持精度、量化、batch、prompt 一致，否则测出来的差距没有意义。

注意：速度排查的顺序，一定是先确认输入正常、资源充足、参数合理，最后才怀疑功能本身。顺序反了，很容易在错误的方向上浪费几个小时。

7. 实操建议和边界提醒

7.1 先跑稳，再优化

我一般是这个顺序：默认配置跑通、记录基线、做单点优化、重新记录、对比效果。每次只改一个变量。如果把量化、投机解码、上下文压缩、动态 batch 同时打开，出了问题根本定位不到是哪一步引入的。

如果只是学习，默认配置通常够用。如果要长期使用，就要把日志、输出目录和任务队列提前整理好，不要等到批量任务跑崩了再补。

7.2 不同场景的验证重点不同

• 学习与验证：默认配置、单条任务、日志正常，就够了。
• 原型开发：关注接口响应时间，而不是纯引擎速度。
• 生产服务：要看并发吞吐、失败重试、显存监控、输出一致性。
• 批量离线任务：要看总耗时、失败跳过、输出命名、断点续跑。

7.3 几个容易误判的地方

第一个误区是把“支持”当成“稳定”。项目声称支持某个模型、某个格式、某个精度，实际连续跑几十条才会暴露问题。

第二个误区是只盯每秒 token 数。如果输出质量变差、首字延迟很高、并发一