人工智能大模型AI 技能/插件分布式训练微调深度学习【免费下载链接】ml-engineeringMachine Learning Engineering Open Book项目地址https://gitcode.com/gh_mirrors/ml/ml-engineering点击查看免费下载本指南是机器学习工程开放书ml-engineering中推理Inference章节的完整技术解读系统覆盖 LLM 在线/离线推理的两阶段执行模型Prefill 与 Decode、KV Cache 的内存核算、静态/连续批处理、Paged Attention、三大解码策略与温度控制、引导式文本生成、投机解码、隐私保护推理、推理级模型并行以及 TTFT/TPOT/吞吐量等关键指标与 vLLM 等主流推理框架的选型方法论。读完本文你将能够独立计算任意 Transformer 模型如 Meta-Llama-3.1-8B的权重与 KV Cache 内存占用写出基于 OpenAI 流式 API 的 TTFT/解码吞吐量基准测试脚本并根据工作负载在多个推理框架与张量/流水线并行配置之间做出有依据的选择。说明本仓库 inference/README.md 标记为施工中部分章节完整、部分仍在完善但已完成的章节足以支撑完整阅读与实战使用。本文以该章节为核心骨架并引用仓库内 training/dtype.md、training/performance/README.md、training/model-parallelism/README.md、compute/accelerator/nvidia/debug.md 等姊妹章节作为深度佐证。术语速查Glossary推理领域常用缩写CLACross-Layer Attention跨层注意力FHEFully Homomorphic Encryption全同态加密GQAGrouped-Query Attention分组查询注意力ITLInter-Token LatencyToken 间延迟KVKey Value键值对注意力缓存LPULanguage Processing Unit™语言处理单元MHAMulti-Head Attention多头注意力MLAMulti-Latent Attention多潜变量注意力DeepSeek-V3 引入MPCSecure Multi-Party Computation安全多方计算MQAMulti-Query Attention多查询注意力PPMLPrivacy-Preserving Machine Learning隐私保护机器学习QPSQueries Per Second每秒查询数TPOTTime Per Output Token每个输出 Token 耗时TTFTTime to First Token首 Token 时间核心概念ConceptsPrefill 与 Decode推理的两个阶段LLM 推理天然分为两个执行阶段它们的计算特征截然相反Prefill预填充阶段模型像训练时一样并行处理 Prompt 中的所有 Token并构建后续生成所需的 KV Cache。这一阶段通常是**计算密集型compute-bound**的其耗时直接构成 TTFT 的一部分并且通常随输入长度增长长 Prompt 或算力不足会让 Prefill 成为请求延迟的主要来源。Decode解码阶段在常规自回归解码中模型基于 Prompt 与已生成的 Token一次只生成一个输出 Token。这种序列化的依赖关系使得单个序列内的输出 Token 步骤无法并行因此 Decode 通常是**内存带宽密集型memory-bandwidth-bound**的——每步都需从高带宽内存HBM读取全部模型权重只为算出一个 Token。哪个阶段更重要取决于工作负载与考察的指标TTFT 对 Prompt 长度、Prefill 效率、调度与排队敏感TPOT/ITL 主要刻画 Decode端到端延迟则取决于输入长度、输出长度、批处理规模、负载与硬件。模型推理时的内存剖析推理时的内存构成与训练截然不同训练侧内存剖析见 training/performance/README.md#anatomy-of-models-memory-usage那里还包含优化器状态、梯度、前向激活等额外开销。推理侧只有三大部分模型权重Model WeightsKV Cache——避免每个新 Token 都要重算历史 Token 的关键缓存激活内存Activation Memory——处理过程中的临时内存规模取决于批量大小与序列长度模型权重的每参数字节数按不同 dtype 计算每个参数占用dtype每参数字节数fp324 字节fp16/bf162 字节fp8/int81 字节fp6 / 6-bit 量化0.75 字节5-bit 量化0.625 字节fp4/int40.5 字节3-bit 量化0.375 字节2-bit 量化0.25 字节1-bit 量化0.125 字节以上是密集打包后的载荷尺寸。实际权重存储可能更高因为量化格式往往还要存储 scale、zero point、codebook、padding/对齐且部分张量会以更宽格式保存。OCP 微缩放MX格式MXFP4/MXFP6/MXFP8采用每个 32 值块附带一个 8 位 E8M0 缩放因子的方案把共享 scale 计入后其打包载荷尺寸为MXFP8/MXINT81.03125 字节/参数MXFP60.78125 字节/参数MXFP40.53125 字节/参数关于 MX 格式中 E8M0 共享缩放因子的设计动机可参见 training/dtype.md 中对float8_e8m0fnu的说明它是块缩放格式附在元素组上的共享 scale本身没有尾数NVIDIA 的 NVFP4 是同一思想的不同调校——同样的 E2M1 元素但块大小 16、scale 用 E4M3 并叠加一个全张量 fp32 scale对局部动态范围的追踪比 2 的幂 E8M0 scale 更紧密。示例Meta-Llama-3.1-8B 以 bf16 存储需要约2 (bf16字节) * 8B (参数量) 16GB。KV Cache缓存的是键与值在生成每个新 Token 之前重算全部历史 KVKey/Value代价极其高昂因此 KV 值被缓存在加速器内存中新算出的 KV 直接追加到既有缓存尾部。KV Cache 大小的计算过程与缓存示意可见 inference/images/infer-kv-cache.png。KV Cache 大小与输入序列长度和批量大小成正比历史的 Query 值在注意力机制中不会再被使用因此无需缓存。单个 Token 的 KV Cache 计算公式dtype_bytes * 2 * num_hidden_layers * hidden_size * num_key_value_heads / num_attention_heads参数注解dtype_bytes每 dtype 字节数fp32 为 4bf16/fp16 为 2依此类推2Key 与 Value 各一份num_key_value_heads / num_attention_heads取决于采用 MQA、GQA 还是 MHA——MHA 下为 1MQA 下为1/num_attention_headsGQA 下则取决于每组配多少个查询头即通用式num_key_value_heads / num_attention_headsMHA 与 MQA 都是其特例。这些维度可以直接从模型目录下的config.json或等效配置文件中读取。以 Meta-Llama-3.1-8B 为例num_key_value_heads8、num_attention_heads32采用 GQA单 Token、bf16 下2 * 2 * 32 (layers) * 4096 (hidden) * 8 / 32 / 10**6 0.131MB——由于 GQA仅占原生 MHA 的 1/4批量 1、每请求 1024 Token0.131 * 1024 ≈ 134MB批量 128、每请求 1024 Token0.131 * 1024 * 128 / 10**3 ≈ 17.2GB。若该模型改用 MHA每 Token 的 KV 内存将扩大 4 倍若改用 MQA则再降为 MHA 的 1/8即当前 GQA 的 1/8。MHA/GQA/MQA/MLA 的结构差异示意可见 inference/images/mha-gqa-mqa-mla.png。进一步压缩 KV 的方向DeepSeek-V3 提出的多潜变量注意力MLA把 Key 与 Value 压缩进一个潜向量进一步缩小 KV Cache。SwiftKV 则面向Prefill 与 Decode 用例比约 10:1的常见场景通过模型重连rewiring与知识保持型自蒸馏在压缩内存之外减少 Prompt 处理期的推理计算量。从源码结构看debug/README.md 中配套的分布式调试工具如 debug/torch-distributed-gpu-test.py可用于排查此类缓存与显存相关问题的环境配置。KV Cache 对性能的双刃剑效应缓存省去了重算但对推理性能有显著的负面作用。引用Dynamic Memory Compression论文第 2.3 节的结论在 GPU 加速器上执行的每个操作如 GEMM要么内存受限要么计算受限。前者总耗时由高带宽内存HBM访问主导后者由实际计算主导。Transformer LLM 的自回归生成每次前向的序列长度 n1倾向于内存受限而非计算受限。……线性层在批量足够大时转为计算受限但 MHSA 层内的注意力计算式 4Softmax(Q,K)V的 FLOPS 与输入规模之比保持恒定无论批量大小MHSA 层都是内存受限的其延迟随 KV Cache 大小线性增长。因此更小的 KV Cache 意味着更快的生成与更高的 GPU 利用率。业界围绕这一点发展出 gisting、上下文蒸馏、KV 驱逐策略token 丢弃、内存压缩、MQA/GQA、跨层注意力CLA、锚点自注意力、量化等众多技术。在线推理 vs 离线推理在线推理Online Inference又称部署推理或交互式推理用户实时发来查询例如聊天机器人、搜索引擎、通用 REST API。此场景始终需要运行一个推理服务器供各类客户端查询。离线推理Offline Inference又称批量推理面对的是包含成百上千条 Prompt 的文件例如基准评估、合成数据生成。此场景通常不需要推理服务器客户端与服务器同处一个程序内直接跑推理。两种用例优化的指标不同在线推理要求极低的 TTFT 和低延迟离线推理要求高吞吐。任何推理场景的关键指标都是 Prefill 与 Decode 的综合 Token 处理吞吐因为它直接决定推理服务的总成本——在线场景下综合吞吐越高同一套硬件可服务的用户越多离线场景下推理越快算力成本越低。批处理Batching一次解码一个 Token 对加速器而言极度低效把多个查询打包批处理能显著提升加速器利用率。最大可行批量取决于加载模型权重、填满 KV Cache 后剩余的内存。静态批处理Static batching朴素的批处理方式把前 N 个查询一起处理。问题在于先完成生成的查询必须等批内最慢的查询全部结束才能返回极大拉高延迟。连续批处理Continuous / In-flight batching生成引擎一旦有序列完成就立刻移除结果并补入新查询不必等整个批次结束。于是批内位置 0 的序列可能正在生成第 10 个 Token位置 1 的序列刚生成第一个 Token位置 3 的序列正在产出最后一个 Token。这缩短了响应时间已完成的序列能立即返回新 Prompt 也不必等下一个批次空闲。当然若计算资源全部占满且批内无空位新请求仍需排队等待。Paged Attention分页注意力Paged Attention 在推理服务器中非常流行它把加速器内存当作操作系统内存一样做分页管理实现动态内存分配并避免内存碎片从而显著提升显存利用效率。解码方法Decoding Methods主流解码方法有贪心解码、束搜索Beam Search与采样Sampling三种。贪心解码Greedy每一步都选概率最高的 Token。最快但未必产生最优结果——可能走上一条次优路径而错过后续更好的 Token 序列主要问题之一是产生重复循环文本。束搜索Beam Search同时生成多条输出路径。以束宽 3 为例每一步跟踪概率最高的 3 条路径从 3×39 条候选子路径中丢弃除累计概率最高的 3 条外的其余路径最后选出整条链概率最高的路径。比贪心慢 n 倍且需要 n 倍内存因为它要多生成 n 倍 Token。采样Sampling引入随机性但纯随机不会有好结果——想要贪心般的确定性又要通过受控随机让它更有生命力。最常见的两种Top-K 采样按 logit 概率取前 k 个 Token再随机挑一个Top-p 采样核采样 / nucleus sampling与 Top-K 类似但 K 对每个 Token 动态变化——把 Token 概率从高到低累加直到达到阈值p。若模型对某些预测非常确定则只考虑这些候选。温度Temperature温度是一个独立的 logits 变换可与 Top-K、Top-p、两者或两者都不组合使用。其效果取决于取值t0.0字面上的 softmax 除以零是未定义的。部分 API 把 0 当作贪心解码的简写另一些则拒绝它因此可用时应使用 API 的显式贪心模式0.0t1.0概率被拉得更开越接近 0 随机性越小——适合精确与均衡兼顾的用例t1.0对采样无影响保留原始训练分布——适合相关性与多样性均衡的用例t1.0概率被压得更平随机性大幅增加——适合创意型用例。不同温度下的概率分布形态可见 inference/images/softmax-temperature.png。温度因子通常在 softmax 之前或之中作用于 logitsscaled_logits logits / temperature probs softmax(scaled_logits)softmax 把 logit 差值转化为概率比值除以t1.0时差值被放大得到更极端、更尖峰的概率分布除以t1.0时差值被缩小得到更接近均匀的分布。当 t 从上方趋近 0 时最高 logit 主导整个分布但实践中会避免字面意义上的除零。重要细节对任意正温度缩放不改变 logit 的排名顺序因此纯贪心 argmax 选择的 Token 不变但它确实改变采样概率。Top-K 下同样的 K 个候选仍可入选但它们的相对采样概率改变Top-p 下温度既能改变进入核nucleus的 Token 集合也能改变它们的相对概率。束搜索的行为取决于实现及其序列打分方式不应假设其不变参考 Transformers 的TemperatureLogitsWarper。温度没有放之四海皆准的取值必须针对每个用例自行实验——不过网上不难找到各类用例的可靠基线值。引导式文本生成Guided Text Generation / 结构化生成如果模型必须以特定格式返回输出例如必须返回 JSON 字典你并不希望模型幻觉出非法格式。引导式生成的做法是不再选择概率最高的 Token而是从符合下一个预期 Token 子集的候选中选择概率最高者。以 JSON 字符串数组[apples, oranges]为例预期格式为[string, string, ..., string]第一个生成 Token 必须是[——若模型最高概率给的是而[概率较低我们仍要选[第二个 Token 必须是——否则继续往低概率候选搜索直到找到第三个 Token 必须是合法字符串内容不能是[或依此类推。本质是每步维护一个允许的 Token 子集从中取最高概率者。相比事后修复并不总能匹配预期格式引导式生成让模型一步到位生成正确输出。它的代价会拖慢生成速度——schema 越复杂越慢实测中不同结构化生成库的速度差异很大且可能加剧幻觉。截至 2026-08vLLM 将四种实现作为结构化输出后端除非显式覆盖否则自动选用xgrammarmlc-aillguidanceguidance-aioutlinesdottxt-ailm-format-enforcernoamgat优先选择已被 vLLM 等推理框架集成的实现。用 schema 反向加速推理引导式生成也能反过来提速。例如下面这个简单的 profile schema{ type: object, properties: { name: { type: string}, age: { type: integer} }, required: [name, age] }由于 schema 规定了固定键name与age一旦模型预测出{n或{a后续的{name:与{age:是 100% 确定的唯一结果——此时可以用 Prefill 代替逐 Token 解码跳过若干缓慢的解码步。显然当 schema 含大量预定键、生成值很短时收益最大。投机解码Speculative Decoding又称投机推理或辅助生成Assisted Generation。由于逐 Token 生成很慢可以作弊用一个更小更快的草稿模型draft model先快速预测若干 Token再用大模型一次性批量验证。示例假设正常推理用 Llama-70B草稿模型用 Llama-7BPrompt 为Im turnin, turnin, turnin, turnin, turnin around and all that I can see is just用 Llama-7B 自回归预测another lemon tree3 步完成但每步远快于 Llama-70B用 Llama-70B 一次性跑 3 条 Prompt此处用...省略了完整 Prompt真实场景应保留全文并把每个 token 想象成一个完整单词[...I can see is just] [...I can see is just another] [...I can see is just another lemon]单个大步内 Llama-70B 同时输出[...I can see is just] another [...I can see is just another] lemon [...I can see is just another lemon] tree可能出现多种结果全部匹配用 3 个短步 1 个长步得到最终结果而不是 3 个长步仅another lemon匹配只要省了时间就仍然划算几乎不匹配浪费了一点时间。Token 数越多节省通常越大。注意本方法做的计算量与直接大模型生成相同甚至更多但延迟显著更低——只要草稿模型足够小且预测质量足够好用户平均响应时间会明显改善。部分失配时可把第一个失配 Token 之前的全部匹配 Token 连同大模型预测的下一个 Token 喂回草稿模型让它快速重新预测失配尾部。草稿模型理想上应使用与大体量模型相同的数据至少相似分布训练且分词器必须一致。投机解码在 输入锚定型任务翻译、摘要、文档问答、多轮对话上回报最高因为这类任务输出空间小、草稿模型更容易与大模型一致同理它与贪心解码配合最佳生成变体最少若不用贪心则应把温度调到接近 0。更简单的替代方案ngram prompt lookup decoding——无需草稿模型直接在 Prompt 中搜索匹配字符串生成候选某些场景据说可提速 2 倍以上。隐私保护推理Privacy-Preserving Inference许多提供推理服务的公司会遇到用户隐私需求用户提交查询时不应被窥探。一个方案是本地部署客户端自跑服务器但这会暴露提供方的 IP——模型权重乃至代码/算法。因此需要在客户端加密的数据上执行计算的完全加密生成方案这类方案统称 PPML。**全同态加密FHE**是途径之一。以 concrete-ml 为例它重写模型让客户端自行运行模型的一部分再把中间加密激活encrypted activations发给服务器执行注意力计算最后送回客户端。提供方因此保留部分 IP——部分权重不足以重建完整模型。另一类方案基于安全多方计算MPC与 FHE 的组合参见LLMs Can Understand Encrypted Prompt论文。当前方案的最大问题是巨大的计算开销严重影响成本与延迟未来专门的 ASIC 方案有望解决。模型并行Model Parallelism当模型放不进单块加速器或虽然勉强放得下但拆分更高效时训练侧的全部 模型并行技术 同样适用于推理。张量并行Tensor Parallelism推理中大概率只会遇到 TP模型权重被切分到 2~8 块加速器。理想情况下应尽量把模型塞进单卡生成期开销最小但实测中TP 反而常带来更高的解码吞吐——因为更大的批次装得下且forward调用在额外通信开销下仍可能更快。代价是某些场景需要更多加速器。因此务必实测在加速器总数相同的前提下更高的 TP 度有时能带来更好的总吞吐。作者实测注记TP1 时 TTFT 最高、解码吞吐最低若要求更快的 TTFT 且模型放得下用更小 TP 或 TP1若要求更快的解码吞吐则用更高 TP 度加更多加速器。TP 要求极快的网络详见 training/model-parallelism/README.md#tensor-parallelism 对 Megatron 式列切分 GEMM 与独立 GeLU 的说明因此通常不跨节点实践中受节点内 GPU 数量限制4 卡节点最高 TP4TP8 需要 8 卡节点。流水线并行Pipeline ParallelismTP 降低延迟而 PP 提升吞吐——尤其对必须动用大量加速器才能装下权重的超大模型如 Llama 405B。以 TP8 为例每张卡需要向其他 7 张卡做 all-reduce而 PP8 下每张卡只需与 2 张卡通信从前一阶段recv输入、向后一阶段send输出网络压力小得多硬件支持时能显著提速。两个关键澄清只有**完整 PPfull PP**才优于 TP朴素 PP 任意时刻只有一个阶段在工作比 TP 更差。要让所有 PP 阶段并行喂入需要推理框架支持参见 training/model-parallelism/README.md#pipeline-parallelism 关于 micro-batch 流水线的实现。推理无backward过程因此没有训练中 PP 的空转bubble问题只需处理前几个 micro-batch 填充阶段的微小开销。与训练一致TP 与 PP 的混合常得到最佳结果例如 Llama 405B 用 TP4 PP4。务必实测不同配置并选最符合需求的组合。接地Grounding接地是指把训练时不可得的额外信息提供给预训练模型。例如 输入锚定型任务 在 Prompt 中给了大量额外信息非零样本 Prompt 用示例接地、改变模型默认行为Prompt 工程本质就是在推理期把模型接地向特定行为。**检索增强生成RAG**是主要接地手段之一为推理过程提供与 Prompt 相关的附加数据让模型更重视这些信息而非训练时学到的大量压缩信息。领域微调是另一条路把模型接向与基座模型训练域截然不同的新数据集。多模态场景中随文本 Prompt 提供的图像或视频同样是接地/上下文。类比人理解了问题上下文才更容易作答模型同理——上下文越好输出越相关。任务类型输入锚定型任务Input-grounded tasks指生成内容主要由 Prompt 推导而来的任务Prompt 是知识的主要来源包括翻译、摘要、文档问答、多轮对话、代码编辑、语音识别音频转录。这类任务也是投机解码收益最高的场景。关键推理性能指标性能指标可分两组看系统指标延迟、吞吐与用户体验指标TTFT、TPOT。系统性能指标延迟Latency从发出请求到收到完整响应的时间。包括①接收请求②Prompt 预处理Prefill 阶段③生成响应新 TokenDecode 阶段④回传响应。前两步的收发耗时差异主要来自 Prompt 与响应的长度差对总时长的贡献可忽略。Prefill 并行处理 Prompt Token但更长的 Prompt 需要更多计算与 KV Cache 内存通常推高 TTFT 并降低吞吐具体受模型、批处理、硬件与服务器负载影响。Decode 阶段受响应长度影响最大——每个新 Token 都是独立一步响应越长解码越久。若服务器并发容量不足而排队等待时间会直接计入延迟。类比延迟是开车从 A 到 B 的耗时含红绿灯、拥堵、限速。吞吐Throughput衡量推理服务器并行处理请求与高效批处理的能力。按同时服务的请求数定义并不合理短请求可在一个长请求期间被服务多次因此常用定义是系统整体每秒生成的 Token 总数。类比吞吐是一条路单位时间能通过多少辆车——车道越多、限速越高吞吐越大但车有长有短需要归一化正如渡轮按车辆占用米数计费。用户体验指标Time To First TokenTTFT用户按下提交/回车到收到第一个词或词的一部分之间的时间。用户已被训练到期望应用在 1 秒内开始响应因此 TTFT 越短越好聊天机器人尤其如此。影响 TTFT 的关键是 Prefill 阶段 的计算以及请求是立即被处理还是排队。无负载时的 TTFT 与高负载时可能天差地别若服务器已满负荷且存在队列除最先几个请求外有效 TTFT 会大幅拉长。因此应测量平均 TTFT并同时报告基准测试时的并发请求数。TTFT 随 Prompt 大小变化理想上还应按 Prompt 的 Token 数做归一化。Time Per Output TokenTPOT按用户计衡量给定用户生成一个新 Token 的耗时。TPOT 不需要无限低理想值应接近发起请求的人的阅读速度——服务小学生可以较慢读者越熟练为获得流畅阅读体验需要的 TPOT 越低。从阅读速度WPM换算 TPOT假设英文分词器约 1.5 Token/词则TPOT 60 / (WPM*1.5)秒阅读类型WPMTPMTPSTPOT秒默读Subvocal2503756.250.16听读Auditory45067511.250.089视读Visual700105018.750.057务必把 1.5 系数替换为你自己分词器的实际平均词 Token 比可自行测量import re, tiktoken enc tiktoken.get_encoding(cl100k_base) text open(sample.txt).read() print(tokens per word: , len(enc.encode(text)) / len(re.findall(r\S, text)))实测结论一段普通英文散文在 OpenAIcl100k/o200k与 GPT-2 旧版 50k 词表下约为 1.2 Token/词——散文场景分词器选择影响甚微但文本类型影响显著同样的测量在 Python 代码上约为 3.3 Token/词。因此若你服务的是代码补全而非散文1.5 系数会让 TPOT 目标偏松 2 倍以上——250 WPM 读者按 0.16 秒/Token 预算而代码场景需要接近 0.07。TPOT 不便心算跟踪一旦确定目标 TPOT建议换算成每秒 Token 数TPS来跟踪。例如系统能稳定保持每请求 20 TPS就能跟上 700 WPM 的超快读者。当然也有用户偏好等全部生成完毕再读此时越快越好。按生成类型大致适用图像——一次性全部给出文本——匹配阅读速度或一次给全音频——匹配收听速度视频——匹配观看速度。纯离线系统不面向个人用户时这些指标无意义核心是延迟与吞吐。简化性能指标前述指标重叠颇多可归结为两个Prefill 吞吐与Decode 吞吐外加系统能处理的每秒并行请求数。Prefill 吞吐系统预处理 Prompt 的速度Token/秒。忽略收发开销且无队列时TTFT ≈ Prompt Token 数 ÷ Prefill Token/秒 首个 Token 的生成时间极快可忽略。存在队列时 Prefill 吞吐就不够了——TTFT 还需加上排队时间。Decode 吞吐系统生成响应 Token 的速度Token/秒同时回答吞吐与 TPOT 两个指标。于是响应延迟 Prompt Token 数 ÷ Prefill 吞吐 生成 Token 数 ÷ Decode 吞吐。更多指标注记加速器利用率加速器利用率百分比或功耗是判断设备是否被高效使用的良好信号。例如 NVIDIA GPU 上watch -n 0.5 nvidia-smi看到满载请求下 gpu util 只有 10%通常意味着推理服务器很低效大量数据拷贝往返或者客户端接收数据的方式低效过多 IO 阻塞。作者实测用 openai client 写基准在低并发时正常高并发时服务器 gpu util 掉到 6~7%换成aiohttp后升到 75%——糟糕的性能报告可能是基准客户端造成的而不是服务器。这与训练侧 用 TFLOPS 衡量训练效率 的思路对应。需要警惕NVIDIA GPU 的gpu util列其实不是真正的利用率——它表示至少有一个 kernel 在执行的时间占比单个 SM 忙与全部 SM 忙都显示 100%详见 compute/accelerator/nvidia/debug.md#how-to-get-the-real-gpu-utilization-metrics。但低百分比仍足以作为存在低效问题的可靠信号。百分位Percentiles基准报告中的 p50/p75/p90/p95/p99 是有序分布中的分位值p95 表示 95% 观测值在该阈值及以下剩余 5% 在其上。期望的尾部方向取决于指标延迟越低越好p95 描述高尾延迟吞吐越高越好p5 是更有用的低尾保证约 95% 的观测值 ≥ p5。示例k6 对推理服务器负载的报告片段http_req_duration..: avg13.36s min12.54s med13.31s max14.12s p(90)13.79s p(95)13.83s http_req_receiving.: avg27.98µs min15.16µs med21.6µs max98.13µs p(90)44.98µs p(95)59.2µs http_req_sending...: avg133.8µs min20.47µs med75.39µs max598.04µs p(90)327.73µs p(95)449.65µs第一行50% 响应在至多 13.31 秒内完成90% 在至多 13.79 秒内95% 在至多 13.83 秒内最慢 5% 超过 13.83 秒最高达 14.12 秒。其余行同理。任何正确排序的样本都应满足min p50 p90 p95 max值越大越好还是越差取决于测的是什么。百分位能概括尾部而不让单个极端观测主导报告但并未消除尾部问题p95 延迟仍意味着 5% 的请求更慢在生产规模下可能对应大量用户。加速模型加载时间生产环境中模型加载只发生一次、服务器随后运行数天加载开销可摊薄但研发、开发与测试场景下推理服务器必须快速就绪。开销有时只是加载到 CPU 再搬到加速器有时还要为 TP 与 PP 额外切分张量。常用方案大多涉及预切分与缓存随后直接加载到 GPUvLLM 支持--load-format参数例如npcachenumpy 格式缓存或基于 CoreWeave Tensorizer 的tensorizer若 TP1建议预先一次性切分权重TensorRT-LLM 要求为每个具体用例构建模型引擎运行时加载预制的分片除非使用简化 API它会在每次服务器启动时动态构建引擎。基准测试Benchmarks可参照 关键推理性能指标 自写基准或使用现成工具。作者主要使用TTFT与Decode 吞吐两类基准TTFT 测量从发出请求到收到第一个非空生成块之间客户端观测到的时间Token 间解码速率覆盖首尾 Token 之间的间隔。基于openai客户端 completions API 的关键代码片段# ... create client, prompt, and model ... request_started_time time.perf_counter() decode_text first_token_time None last_token_time None completion client.completions.create(modelmodel, promptprompt, streamTrue) for chunk in completion: if chunk.choices: text chunk.choices[0].text if text: now time.perf_counter() if first_token_time is None: first_token_time now last_token_time now decode_text text if first_token_time is None: raise RuntimeError(The response contained no output tokens) ttft first_token_time - request_started_time output_tokens len(tokenizer.encode(decode_text, add_special_tokensFalse)) inter_token_count max(output_tokens - 1, 0) inter_token_time last_token_time - first_token_time decode_throughput ( inter_token_count / inter_token_time if inter_token_count 0 and inter_token_time 0 else None )要点output_tokens - 1的减一与测量区间对齐——区间从第一个 Token 到达后才开始。这是客户端估算前提是流式块与 Token 到达足够接近若 API 把多个 Token 打包进一个块精确的 Token 间延迟需要 token 级或服务端时间戳。注意TTFT 不是纯 Prefill 时间。它包含请求传输、排队、调度、Prompt 处理、首 Token 生成与响应传输。用 Prompt Token 数除以 TTFT 不能得到 Prefill 吞吐——那需要服务端隔离 Prompt 处理的插桩。任何严肃的基准都应多次运行单次运行的方差可能很大。作者实测注记openai client 在高并发下扩展性差会成为瓶颈、测不出服务器真实性能曾在 vLLM 仓库追踪该问题改用aiohttp重写的客户端版本扩展性极佳。负载测试的良好起点vLLM 的benchmark_throughput.py——作者目前最喜欢的工具Grafana k6——用 JavaScript 客户端模拟多并发客户端做负载测试。作者指出当前还缺少测量服务器可承受的最大并发数的工具。推理框架Inference Frameworks推理框架数以百计且每周仍在增加。以下是一个起步清单本节刻意保持中立、不做推荐因为不存在放之四海皆准的框架vLLM社区活跃、采用率高、主体用 Python 编写DeepSpeed-FastGenDeepSpeed 团队的推理方案TensorRT-LLMNVIDIA 出品已整合原 FasterTransformer仅支持 NVIDIA GPU约 99% 为 CSGLangllama.cpp本地/单机服务CPU、CUDA 含数据中心 GPU、Metal 等不是与 vLLM/SGLang 同级的面向多租户的生产框架C/CUDA 实现LightLLMLMDeployInternLMMLC-LLM。如果你的常用框架不在清单中可以向仓库提交 PR 补充。加速器专属框架主流推理框架普遍支持 NVIDIA CUDA很多还支持 AMD ROCm 与 Intel Gaudi——且越来越通过厂商插件接入主流框架如 vLLM 的硬件插件架构而非独立技术栈。主要加速器专属栈Intel GaudiHPUvllm-gaudi 插件旧的 HabanaAI/vllm-fork 正在退役 Hugging Face 生态的 Optimum for Intel GaudiAWS Trainium/InferentiaAWS Neuron SDK通过标准 vLLM API 服务另有 Optimum NeuronGoogle TPUtpu-inferencevLLM 的 TPU 插件统一 JAX 与 PyTorch是已归档的 JetStream 的继任者JAX 原生替代是 MaxTextModular MAX可移植服务栈也运行在 CPU 与 NVIDIA/AMD GPU 上Apple SiliconMLX / mlx-lm以及 llama.cpp 的 Metal 后端Tenstorrenttt-metal 及其 vLLM 集成。由于加速器支持日益以插件形式进入主流框架选型时应先确认你选择的框架是否已支持你的加速器再考虑厂商专属栈。最后部分厂商只以托管服务形式在其自有硬件上提供推理如 Cerebras、Groq、SambaNova而非可安装框架。如何选择推理框架至少回答以下问题特性框架是否具备所需特性注意有些框架声称支持某特性实际集成不佳或运行很慢许可证是否满足当前与未来需求实践中违反商业使用的许可证通常被社区抵制如 HF TGI 曾试图对商业使用收费在社区压力下撤回许可证但 TGI 此后发展停滞社区贡献者数量是否活跃贡献者极少的框架值得警惕采用度GitHub Stars 常被营销夸大应交叉验证其他信号——如仓库主页的 Used by 计数、PR/Issue 数量、相关文章数量维护响应度Issue 与 PR 是否被及时处理大量未处理的 open Issues 是双刃信号——既说明项目热门也说明团队应接不暇语言与可改性多数框架是 Python 少量 C/Triton 融合 kernel但也有例外TensorRT-LLM 约 99% C。若提了 Issue 无人处理你能否自己动手改框架上游接纳度有些框架拒绝外部实现缺失特性的 PR最终你不得不维护 fork——与上游持续同步极其困难会带来长期痛苦实测对目标负载跑 基准测试确认性能是否达标硬件锁定是否愿被特定厂商锁定NVIDIA 的框架大概率不支持其他加速器AMD、Intel 同理。是否愿意日后选择最具性价比的加速器可参考 compute/accelerator/README.md 中的加速器对比。例如 vLLM截至 2024-08-24 的仓库快照见 inference/images/github-vllm-stats-2024-08-24.png被大量仓库使用、贡献者众多、主要用 Python 编写——这类信息对任何候选框架都容易查到。此例仅为方法演示非对 vLLM 的背书。推理芯片Inference Chips除通用加速器外一些厂商开发了仅用于推理的专用 ASIC例如 Groq 的 LPULanguage Processing Unit™即术语表中的 LPU。延伸阅读A Survey on Efficient Inference for Large Language Models (2024)arXiv:2404.14294全面综述高效 LLM 推理技术。本仓库相关章节训练侧内存剖析、训练侧模型并行、dtype 与量化格式、分布式调试工具集 与 网络通信基准all-reduce/all-gather 等集合通信对 TP 推理的性能影响。赞分享人工智能大模型AI 技能/插件分布式训练微调深度学习【免费下载链接】ml-engineeringMachine Learning Engineering Open Book项目地址https://gitcode.com/gh_mirrors/ml/ml-engineering点击查看免费下载相关推荐LMDeploy DistServe 实战指南Prefill/Decode 分离部署与 KV Cache 高速迁移LMDeploy DistServe 实战指南Prefill/Decode 分离部署与 KV Cache 高速迁移 LMDeploy DistServe 是人工智能大模型模型推理服务推理引擎本地部署模型量化华硕笔记本终极控制方案G-Helper完全替代Armoury Crate的完整指南华硕笔记本终极控制方案G Helper完全替代Armoury Crate的完整指南 还在为华硕笔记本预装的Armoury Crate软件感到困扰吗它占用大量桌面应用系统编程BiliTools技术选型框架选择与技术栈决策过程BiliTools技术选型框架选择与技术栈决策过程 引言为什么技术选型如此重要 在开发跨平台桌面应用时技术选型直接决定了项目的开发效率、性能表现、维护成桌面应用音视频上一篇Karakeep 多 AI 提供商接入指南OpenAI 兼容 API 与 Ollama 本地推理的完整配置实战下一篇使用 awesome-copilot 的 python-mcp-development 插件构建生产级 Python MCP 服务器创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
