LLM 推理速度是本地模型和线上服务都会撞上的真问题。Frontier.fast 从项目定位看目标很直接把 LLM 速度往前推。不管是降低首字延迟、提高每秒生成 token 数还是提升批量吞吐这类项目想解决的都不是模型能力不够而是模型跑起来之后的工程效率。如果你在做 LLM 应用开发、想在本地跑模型做验证或者正在为线上推理服务挑方案这里想把速度这件事拆透它由哪些环节决定、怎么测才准、哪些参数值得调、哪些地方会莫名其妙拖慢速度。先给一个核心判断LLM 快慢不是单一指标也不是一门心思换引擎就能解决的。很多人抱怨“生成太慢”实际上可能是显存不足触发了交换、prompt 太长导致预填充阶段爆炸、并发太高排队严重甚至只是量化位宽没有选对输出质量反而变差。把这些问题分开看速度优化才有的放矢。1. 为什么“推高 LLM 速度”成了热门方向1.1 速度问题是一整条链路不是模型一个点一个 LLM 请求从发起到结束中间经过的环节比大多数人想的要多输入文本先经过分词转成 token idtoken 序列进入模型一层一层做矩阵计算计算过程要反复读取模型权重显存或内存的带宽直接决定速度上限每生成一个新 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 三个关键指标不要混在一起TTFTTime To First Token从请求发出到收到第一个 token 的时间代表“用户的等待感”。tokens/s生成阶段的每秒输出 token 数代表“光标跳动的速度”。总耗时TTFT 加上生成耗时再加上可能存在的排队时间代表“一个任务最终完成的时间”。有的引擎会用投机解码这类技术让一个小模型先快速草稿大模型再批量验证从而提升 decode 速度。但它对 prompt 类型、草稿模型质量、硬件算力都有要求不是所有场景都能稳定提速。看到这类功能时先在自己的任务上跑一轮再说。3. 精度选型是影响速度的第一个大坑fp16、bf16、fp323.1 三种精度的存储和计算差异大模型推理时权重和中间结果用不同精度存储速度和效果会明显不同。这也是社区里讨论“LLM 精度问题”时最常见的三个名词。fp3232 位单精度浮点数数值范围大、精度高但显存占用高计算慢。大模型全量跑 fp32 基本不现实一般只用于小模型调试。fp1616 位半精度浮点数显存占用只有 fp32 一半计算通常更快但动态范围小数值容易溢出。bf16也是 16 位但指数位和 fp32 一样多动态范围大很多现代加速硬件都有专门支持。精度位宽显存占用动态范围常见场景fp3232高大小模型调试、数值敏感实验fp1616中小普通推理注意溢出bf1616中大大模型推理范围敏感int8 / int48 / 4低小显存不足时优先考虑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 建立自己的基准测试记录我建议维护一张简单的基准表每次调整都记录前后对比才有意义记录项填写说明模型与精度例如 7B / bf16推理引擎与版本具体名称和安装版本硬件环境显卡型号、显存、内存prompt 长度例如 512 tokens生成长度上限例如 1024 tokensTTFT实际测出的首字延迟生成速度tokens/s显存占用峰值输出是否正常是 / 否现在社区里已经有不少人像维护 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 数。如果输出质量变差、首字延迟很高、并发一