推理优化

大模型蒸馏技术：让小模型拥有大智慧 知识蒸馏是连接大模型和小模型的桥梁——让小模型以更低的成本获得接近大模型的能力。2026年，蒸馏技术已经从简单的输出模仿发展到多维度的知识传递，成为模型部署流程中不可或缺的一环。 蒸馏的基本原理 知识蒸馏的核心思想是让student模型学习teacher模型的行为。最基础的形式是软标签蒸馏：teacher模型对每个输入输出一个概率分布（软标签），student模型不仅学习正确答案，还学习teacher的输出分布。 软标签比硬标签（正确答案）包含更多信息。例如，在情感分类中，teacher可能输出"正面:0.7, 中性:0.2, 负面:0.1"。这个分布告诉student：这个样本倾向于正面，但与中性也有一定相似度——这种"暗知识"是硬标签无法提供的。 蒸馏方法的演进 输出层蒸馏 最早的蒸馏方法只关注最终输出。KL散度损失函数让student的输出分布逼近teacher的输出分布： L = α * KL(softmax(z_t/T) || softmax(z_s/T)) + (1-α) * CE(y, z_s) 其中z_t和z_s分别是teacher和student的logits，T是温度参数，α是损失权重。 温度T的作用至关重要。T=1时，蒸馏等同于标准训练；T较大时，软标签中的"暗知识"被放大，student能学到更多teacher的细微判断。最佳温度通常在2-10之间，需要根据任务调整。 中间层蒸馏 输出层蒸馏的局限是student只能在最终输出层面模仿teacher。但如果teacher和student的架构差异较大，输出层面的模仿可能不够有效。 中间层蒸馏让student的隐藏层表示逼近teacher的隐藏层表示。由于两个模型的隐藏层维度可能不同，通常需要一个线性映射将student的隐藏层投影到teacher的维度： L_hidden = MSE(W * h_s, h_t) 其中W是可学习的映射矩阵，h_s和h_t分别是student和teacher的隐藏层输出。 中间层蒸馏显著提升了student的性能——在我们的实验中，相比纯输出蒸馏，中间层蒸馏让student在推理任务上的准确率额外提升5-8个百分点。 注意力蒸馏 注意力蒸馏让student学习teacher的注意力分布。teacher的注意力模式包含了它"关注什么"的信息——这对理解teacher的推理过程很有价值。 注意力蒸馏在机器翻译等任务上特别有效，因为对齐信息（源语言的哪个词对应目标语言的哪个词）主要体现在注意力分布中。 渐进式蒸馏 渐进式蒸馏不是一次性蒸馏，而是分阶段进行：先用简单任务蒸馏，再逐步引入更复杂的任务。这类似于人类学习的"从易到难"过程。 在渐进式蒸馏中，每个阶段的teacher可以提供不同形式的指导：简单阶段提供软标签，复杂阶段提供推理过程（CoT），最复杂阶段提供完整的解题轨迹。 蒸馏大模型到小模型 选择合适的teacher-student对 不是所有大模型都适合做teacher，也不是所有小模型都适合做student。选择原则： Teacher选择：选择在目标任务上表现最好、输出分布最平滑的模型。输出分布越平滑，暗知识越丰富。经过RLHF训练的模型输出分布往往较尖锐（过度自信），不是最佳teacher。我们通常使用base模型（未经RLHF）作为teacher。 Student选择：student的架构应与teacher尽量相似，以最大化知识迁移效率。如果teacher是Transformer decoder，student也应该是。层数和宽度可以缩减，但基本结构应保持一致。 数据选择 蒸馏数据的质量和多样性比数量更重要。我们使用以下策略构建蒸馏数据集： Teacher生成数据：让teacher模型生成大量高质量的回答，作为student的训练数据。这比使用原始训练数据更有效，因为teacher的输出已经包含了它的"知识"。 难度分层：按任务难度对数据进行分层，确保student逐步学习从简单到复杂的模式。 领域覆盖：确保蒸馏数据覆盖student需要处理的所有领域。如果student主要用于代码生成，蒸馏数据应以代码为主。 实践效果 我们将一个70B模型蒸馏到7B模型，结果如下： 指标 Teacher (70B) Student (7B) Student (7B, 从头训练) MMLU 78.5 71.2 62.3 GSM8K 85.1 74.6 58.2 HumanEval 72.3 65.8 51.4 蒸馏相比从头训练的提升约9-16个百分点，且student的推理速度约为teacher的10倍。 ...

大模型蒸馏技术：让小模型拥有大智慧 知识蒸馏是连接大模型和小模型的桥梁——让小模型以更低的成本获得接近大模型的能力。2026年，蒸馏技术已经从简单的输出模仿发展到多维度的知识传递，成为模型部署流程中不可或缺的一环。 蒸馏的基本原理 知识蒸馏的核心思想是让student模型学习teacher模型的行为。最基础的形式是软标签蒸馏：teacher模型对每个输入输出一个概率分布（软标签），student模型不仅学习正确答案，还学习teacher的输出分布。 软标签比硬标签（正确答案）包含更多信息。例如，在情感分类中，teacher可能输出"正面:0.7, 中性:0.2, 负面:0.1"。这个分布告诉student：这个样本倾向于正面，但与中性也有一定相似度——这种"暗知识"是硬标签无法提供的。 蒸馏方法的演进 输出层蒸馏 最早的蒸馏方法只关注最终输出。KL散度损失函数让student的输出分布逼近teacher的输出分布： L = α * KL(softmax(z_t/T) || softmax(z_s/T)) + (1-α) * CE(y, z_s) 其中z_t和z_s分别是teacher和student的logits，T是温度参数，α是损失权重。 温度T的作用至关重要。T=1时，蒸馏等同于标准训练；T较大时，软标签中的"暗知识"被放大，student能学到更多teacher的细微判断。最佳温度通常在2-10之间，需要根据任务调整。 中间层蒸馏 输出层蒸馏的局限是student只能在最终输出层面模仿teacher。但如果teacher和student的架构差异较大，输出层面的模仿可能不够有效。 中间层蒸馏让student的隐藏层表示逼近teacher的隐藏层表示。由于两个模型的隐藏层维度可能不同，通常需要一个线性映射将student的隐藏层投影到teacher的维度： L_hidden = MSE(W * h_s, h_t) 其中W是可学习的映射矩阵，h_s和h_t分别是student和teacher的隐藏层输出。 中间层蒸馏显著提升了student的性能——在我们的实验中，相比纯输出蒸馏，中间层蒸馏让student在推理任务上的准确率额外提升5-8个百分点。 注意力蒸馏 注意力蒸馏让student学习teacher的注意力分布。teacher的注意力模式包含了它"关注什么"的信息——这对理解teacher的推理过程很有价值。 注意力蒸馏在机器翻译等任务上特别有效，因为对齐信息（源语言的哪个词对应目标语言的哪个词）主要体现在注意力分布中。 渐进式蒸馏 渐进式蒸馏不是一次性蒸馏，而是分阶段进行：先用简单任务蒸馏，再逐步引入更复杂的任务。这类似于人类学习的"从易到难"过程。 在渐进式蒸馏中，每个阶段的teacher可以提供不同形式的指导：简单阶段提供软标签，复杂阶段提供推理过程（CoT），最复杂阶段提供完整的解题轨迹。 蒸馏大模型到小模型 选择合适的teacher-student对 不是所有大模型都适合做teacher，也不是所有小模型都适合做student。选择原则： Teacher选择：选择在目标任务上表现最好、输出分布最平滑的模型。输出分布越平滑，暗知识越丰富。经过RLHF训练的模型输出分布往往较尖锐（过度自信），不是最佳teacher。我们通常使用base模型（未经RLHF）作为teacher。 Student选择：student的架构应与teacher尽量相似，以最大化知识迁移效率。如果teacher是Transformer decoder，student也应该是。层数和宽度可以缩减，但基本结构应保持一致。 数据选择 蒸馏数据的质量和多样性比数量更重要。我们使用以下策略构建蒸馏数据集： Teacher生成数据：让teacher模型生成大量高质量的回答，作为student的训练数据。这比使用原始训练数据更有效，因为teacher的输出已经包含了它的"知识"。 难度分层：按任务难度对数据进行分层，确保student逐步学习从简单到复杂的模式。 领域覆盖：确保蒸馏数据覆盖student需要处理的所有领域。如果student主要用于代码生成，蒸馏数据应以代码为主。 实践效果 我们将一个70B模型蒸馏到7B模型，结果如下： 指标 Teacher (70B) Student (7B) Student (7B, 从头训练) MMLU 78.5 71.2 62.3 GSM8K 85.1 74.6 58.2 HumanEval 72.3 65.8 51.4 蒸馏相比从头训练的提升约9-16个百分点，且student的推理速度约为teacher的10倍。 ...

大模型推理的KV Cache优化全解 KV Cache是大模型推理中最重要的优化技术，也是最大的内存瓶颈。理解KV Cache的工作原理和优化方法，是构建高效推理服务的基础。 KV Cache是什么 在Transformer的自回归生成中，每生成一个新token，需要计算它对所有之前token的注意力。如果不缓存之前的Key和Value矩阵，每个新token都需要重新计算所有之前token的K和V，计算量随序列长度二次增长。 KV Cache通过缓存之前计算过的K和V矩阵，将每步的计算复杂度从O(n²)降到O(n)。代价是内存占用线性增长——对于Llama-70B模型，生成4K token的KV Cache约占40GB显存。 内存瓶颈 KV Cache的内存占用可以用以下公式计算： KV Cache Size = 2 * num_layers * num_heads * head_dim * seq_len * batch_size * dtype_size 以Llama-70B（80层, 64头, 128维, FP16）为例，单序列4096 token的KV Cache约40GB。这意味着一个80GB显存的A100只能服务两个并发请求——这是制约推理吞吐量的最大瓶颈。 PagedAttention：分页管理 vLLM团队提出的PagedAttention是KV Cache管理的革命性创新。灵感来自操作系统的虚拟内存分页机制。 传统分配的问题 传统方法为每个序列预分配一块连续的KV Cache空间，按最大序列长度分配。这导致严重的内存碎片——大多数序列不会用满预分配的空间，但多余的空间不能被其他序列使用。内存利用率通常只有20-40%。 分页方案 PagedAttention将KV Cache划分为固定大小的"页"（通常16个token），每个序列通过页表映射到物理页。页按需分配——序列增长时才分配新页。 效果是显著的：vLLM的内存利用率提升到90%以上，并发吞吐量提升2-4倍。碎片问题被彻底解决，因为不同序列的页可以散布在物理内存中的任意位置。 页的大小选择 页太小（如1 token）会增加页表开销，页太大（如256 token）则回到预分配的问题。16 token是在大多数场景下的最优选择——页表开销不到1%，内存浪费也不显著。 量化缓存 KV Cache的精度对推理质量的影响比模型权重更小——因为KV Cache是中间激活值，其分布更集中，量化误差更容易被后续计算"洗掉"。 FP8 KV Cache 将KV Cache从FP16量化到FP8，内存减半，几乎无损。现代GPU（H100及以后）原生支持FP8运算，所以推理速度也几乎不受影响。这可能是最简单且性价比最高的KV Cache优化。 INT4 KV Cache 更激进的方案是将KV Cache量化到INT4。内存减少到1/4，但精度损失开始显著——在长序列和需要精确注意力的任务上，INT4 KV Cache可能导致输出质量下降。 ...

大模型推理的KV Cache优化全解 KV Cache是大模型推理中最重要的优化技术，也是最大的内存瓶颈。理解KV Cache的工作原理和优化方法，是构建高效推理服务的基础。 KV Cache是什么 在Transformer的自回归生成中，每生成一个新token，需要计算它对所有之前token的注意力。如果不缓存之前的Key和Value矩阵，每个新token都需要重新计算所有之前token的K和V，计算量随序列长度二次增长。 KV Cache通过缓存之前计算过的K和V矩阵，将每步的计算复杂度从O(n²)降到O(n)。代价是内存占用线性增长——对于Llama-70B模型，生成4K token的KV Cache约占40GB显存。 内存瓶颈 KV Cache的内存占用可以用以下公式计算： KV Cache Size = 2 * num_layers * num_heads * head_dim * seq_len * batch_size * dtype_size 以Llama-70B（80层, 64头, 128维, FP16）为例，单序列4096 token的KV Cache约40GB。这意味着一个80GB显存的A100只能服务两个并发请求——这是制约推理吞吐量的最大瓶颈。 PagedAttention：分页管理 vLLM团队提出的PagedAttention是KV Cache管理的革命性创新。灵感来自操作系统的虚拟内存分页机制。 传统分配的问题 传统方法为每个序列预分配一块连续的KV Cache空间，按最大序列长度分配。这导致严重的内存碎片——大多数序列不会用满预分配的空间，但多余的空间不能被其他序列使用。内存利用率通常只有20-40%。 分页方案 PagedAttention将KV Cache划分为固定大小的"页"（通常16个token），每个序列通过页表映射到物理页。页按需分配——序列增长时才分配新页。 效果是显著的：vLLM的内存利用率提升到90%以上，并发吞吐量提升2-4倍。碎片问题被彻底解决，因为不同序列的页可以散布在物理内存中的任意位置。 页的大小选择 页太小（如1 token）会增加页表开销，页太大（如256 token）则回到预分配的问题。16 token是在大多数场景下的最优选择——页表开销不到1%，内存浪费也不显著。 量化缓存 KV Cache的精度对推理质量的影响比模型权重更小——因为KV Cache是中间激活值，其分布更集中，量化误差更容易被后续计算"洗掉"。 FP8 KV Cache 将KV Cache从FP16量化到FP8，内存减半，几乎无损。现代GPU（H100及以后）原生支持FP8运算，所以推理速度也几乎不受影响。这可能是最简单且性价比最高的KV Cache优化。 INT4 KV Cache 更激进的方案是将KV Cache量化到INT4。内存减少到1/4，但精度损失开始显著——在长序列和需要精确注意力的任务上，INT4 KV Cache可能导致输出质量下降。 ...

推理成本：AI落地的最大障碍 一个简单的事实：运行一个70B参数的模型，单张A100 GPU的每小时成本约2-3美元（云服务），每秒处理约50个Token。如果日均100万次请求、每次平均500 Token，一天的GPU成本就超过500美元。 随着用户规模增长，推理成本会线性甚至超线性增长。不做好成本优化，AI项目的商业模式根本不成立。 五层优化框架 我们将推理成本优化分为五个层次，从收益最大到收益递减： 第一层：模型选择优化 选择最小的够用模型。 这听起来简单，但实践中很多团队默认使用最大的模型"以防万一"。 我们的建议是建立模型路由系统： 简单FAQ → 7B模型 一般对话 → 32B模型 复杂推理 → 70B+模型 通过一个轻量级分类器判断请求复杂度，自动路由到合适的模型。在我们的实践中，模型路由可以降低60%以上的推理成本，而用户体验几乎不受影响。 开源vs闭源混合策略。 对于流量大的简单任务用开源模型自建部署，对于低频复杂任务调用闭源API。两者结合可以在成本和质量间取得最优平衡。 第二层：模型压缩优化 量化：INT4量化可以将模型大小和推理成本降低4倍，质量损失控制在2-3%以内（详见我们之前的量化对比文章）。 蒸馏：用大模型蒸馏出一个小模型用于线上推理。对于垂直领域，蒸馏模型可以达到接近大模型的效果但成本只有1/10。 稀疏化：通过剪枝去除不重要的权重。MoE架构本质上就是一种结构化的稀疏化——每次推理只激活部分专家网络。 第三层：推理引擎优化 KV Cache优化：KV Cache是自回归生成的最大显存消耗者。优化手段包括： PagedAttention（vLLM）：将KV Cache分页管理，减少碎片浪费 KV Cache量化：将KV Cache从FP16压缩到INT8，显存减半 KV Cache共享：相同Prefix的请求共享KV Cache 批处理：将多个请求合并处理可以提高GPU利用率。vLLM的Continuous Batching技术可以在不增加延迟的情况下将吞吐量提升3-5倍。 投机解码（Speculative Decoding）：用一个小模型先生成候选Token，大模型并行验证。如果小模型的猜测正确率高，生成速度可以提升2-3倍。 第四层：系统架构优化 缓存层：对相同或相似查询的结果进行缓存。我们采用语义缓存——不只是精确匹配，而是通过嵌入相似度判断是否可以用缓存结果。语义缓存可以命中15-30%的请求。 请求合并：当多个用户问类似的问题时，合并为一个请求，结果分发。这在客服场景特别有效。 异步处理：非实时任务（如批量文档处理）放入队列，在低峰期处理。削峰填谷可以显著降低峰值GPU需求。 自动伸缩：基于请求队列长度和GPU利用率自动伸缩推理节点。配合预加载模型镜像，可以在5分钟内完成新节点启动。 第五层：Prompt优化 Prompt精简：去掉不必要的System Prompt内容，精简指令描述。每个Token都要花钱，冗长的Prompt直接增加成本。 Few-shot优化：与其在Prompt中放5个示例，不如用1个最好的示例加更清晰的指令。Few-shot示例的质量比数量更重要。 输出长度控制：在Prompt中明确要求简洁回答。生成500 Token和生成100 Token的成本差5倍。 实际案例 我们为一个客服场景做了全栈优化： 优化措施 成本降低 质量影响 模型从70B降到32B -45% -2%准确率 INT4量化 -60% -1.5%准确率 vLLM + Continuous Batching -30% 无影响 语义缓存 -22% 无影响 Prompt精简 -15% 无影响 投机解码 -35%（速度提升） 无影响 综合 -85% -3.5%准确率 最终成本降低了85%，而质量损失控制在可接受范围内。 ...

推理成本：AI落地的最大障碍 一个简单的事实：运行一个70B参数的模型，单张A100 GPU的每小时成本约2-3美元（云服务），每秒处理约50个Token。如果日均100万次请求、每次平均500 Token，一天的GPU成本就超过500美元。 随着用户规模增长，推理成本会线性甚至超线性增长。不做好成本优化，AI项目的商业模式根本不成立。 五层优化框架 我们将推理成本优化分为五个层次，从收益最大到收益递减： 第一层：模型选择优化 选择最小的够用模型。 这听起来简单，但实践中很多团队默认使用最大的模型"以防万一"。 我们的建议是建立模型路由系统： 简单FAQ → 7B模型 一般对话 → 32B模型 复杂推理 → 70B+模型 通过一个轻量级分类器判断请求复杂度，自动路由到合适的模型。在我们的实践中，模型路由可以降低60%以上的推理成本，而用户体验几乎不受影响。 开源vs闭源混合策略。 对于流量大的简单任务用开源模型自建部署，对于低频复杂任务调用闭源API。两者结合可以在成本和质量间取得最优平衡。 第二层：模型压缩优化 量化：INT4量化可以将模型大小和推理成本降低4倍，质量损失控制在2-3%以内（详见我们之前的量化对比文章）。 蒸馏：用大模型蒸馏出一个小模型用于线上推理。对于垂直领域，蒸馏模型可以达到接近大模型的效果但成本只有1/10。 稀疏化：通过剪枝去除不重要的权重。MoE架构本质上就是一种结构化的稀疏化——每次推理只激活部分专家网络。 第三层：推理引擎优化 KV Cache优化：KV Cache是自回归生成的最大显存消耗者。优化手段包括： PagedAttention（vLLM）：将KV Cache分页管理，减少碎片浪费 KV Cache量化：将KV Cache从FP16压缩到INT8，显存减半 KV Cache共享：相同Prefix的请求共享KV Cache 批处理：将多个请求合并处理可以提高GPU利用率。vLLM的Continuous Batching技术可以在不增加延迟的情况下将吞吐量提升3-5倍。 投机解码（Speculative Decoding）：用一个小模型先生成候选Token，大模型并行验证。如果小模型的猜测正确率高，生成速度可以提升2-3倍。 第四层：系统架构优化 缓存层：对相同或相似查询的结果进行缓存。我们采用语义缓存——不只是精确匹配，而是通过嵌入相似度判断是否可以用缓存结果。语义缓存可以命中15-30%的请求。 请求合并：当多个用户问类似的问题时，合并为一个请求，结果分发。这在客服场景特别有效。 异步处理：非实时任务（如批量文档处理）放入队列，在低峰期处理。削峰填谷可以显著降低峰值GPU需求。 自动伸缩：基于请求队列长度和GPU利用率自动伸缩推理节点。配合预加载模型镜像，可以在5分钟内完成新节点启动。 第五层：Prompt优化 Prompt精简：去掉不必要的System Prompt内容，精简指令描述。每个Token都要花钱，冗长的Prompt直接增加成本。 Few-shot优化：与其在Prompt中放5个示例，不如用1个最好的示例加更清晰的指令。Few-shot示例的质量比数量更重要。 输出长度控制：在Prompt中明确要求简洁回答。生成500 Token和生成100 Token的成本差5倍。 实际案例 我们为一个客服场景做了全栈优化： 优化措施 成本降低 质量影响 模型从70B降到32B -45% -2%准确率 INT4量化 -60% -1.5%准确率 vLLM + Continuous Batching -30% 无影响 语义缓存 -22% 无影响 Prompt精简 -15% 无影响 投机解码 -35%（速度提升） 无影响 综合 -85% -3.5%准确率 最终成本降低了85%，而质量损失控制在可接受范围内。 ...

量化：让大模型跑得起的关键技术 大模型的推理成本是落地的最大障碍之一。一个70B参数的模型在FP16精度下需要约140GB显存，而INT4量化只需要约35GB——直接让单卡部署成为可能。 但量化不是免费的午餐。精度降低必然带来质量损失，问题是损失多少、哪种方案损失最小。我们在统一环境下对三种主流量化方案进行了系统对比。 三种方案简介 GPTQ：基于二阶Hessian信息的后训练量化方法。通过逐层补偿量化误差来保持模型质量。优势是不需要校准数据量太大，劣势是量化过程较慢。 AWQ（Activation-aware Weight Quantization）：通过分析激活值分布来识别"重要"权重，对重要权重保持高精度，非重要权重进行量化。核心洞察是并非所有权重对模型输出的贡献相同。 INT4（含NF4/FP4变体）：将权重压缩到4比特。NF4（NormalFloat 4）由QLoRA提出，针对正态分布的权重进行了优化。FP4则保留了浮点数的指数-尾数结构。 测试设置 硬件：单张A100 80GB 模型：Llama-3-70B、Qwen-2.5-72B、Mistral-Large 基准：FP16未量化版本 评估数据集：MMLU、HumanEval、GSM8K、C-Eval 测试场景：单序列推理和批量推理 核心结果 质量对比 方案 MMLU HumanEval GSM8K C-Eval 平均损失 FP16 82.1 74.4 88.3 85.7 0% AWQ-INT4 80.8 72.1 86.1 84.3 ~2.0% GPTQ-INT4 80.3 71.5 85.7 83.9 ~2.6% NF4 81.2 72.8 86.9 84.6 ~1.6% INT4-naive 76.5 66.2 80.1 79.3 ~7.8% NF4在质量保持上略优于AWQ和GPTQ，但差异在统计意义上并不显著（除naive INT4外）。三种成熟方案的损失都控制在3%以内，对于大多数应用场景完全可接受。 速度对比 方案 单序列(tokens/s) 批量32(tokens/s) 首Token延迟(ms) FP16 45.2 820 120 AWQ-INT4 112.5 2100 65 GPTQ-INT4 98.3 1850 78 NF4 105.7 1950 70 AWQ在推理速度上领先，这得益于其更优化的内核实现（vLLM的AWQ后端经过深度优化）。GPTQ由于需要额外的反量化步骤，速度略慢。 ...

量化：让大模型跑得起的关键技术 大模型的推理成本是落地的最大障碍之一。一个70B参数的模型在FP16精度下需要约140GB显存，而INT4量化只需要约35GB——直接让单卡部署成为可能。 但量化不是免费的午餐。精度降低必然带来质量损失，问题是损失多少、哪种方案损失最小。我们在统一环境下对三种主流量化方案进行了系统对比。 三种方案简介 GPTQ：基于二阶Hessian信息的后训练量化方法。通过逐层补偿量化误差来保持模型质量。优势是不需要校准数据量太大，劣势是量化过程较慢。 AWQ（Activation-aware Weight Quantization）：通过分析激活值分布来识别"重要"权重，对重要权重保持高精度，非重要权重进行量化。核心洞察是并非所有权重对模型输出的贡献相同。 INT4（含NF4/FP4变体）：将权重压缩到4比特。NF4（NormalFloat 4）由QLoRA提出，针对正态分布的权重进行了优化。FP4则保留了浮点数的指数-尾数结构。 测试设置 硬件：单张A100 80GB 模型：Llama-3-70B、Qwen-2.5-72B、Mistral-Large 基准：FP16未量化版本 评估数据集：MMLU、HumanEval、GSM8K、C-Eval 测试场景：单序列推理和批量推理 核心结果 质量对比 方案 MMLU HumanEval GSM8K C-Eval 平均损失 FP16 82.1 74.4 88.3 85.7 0% AWQ-INT4 80.8 72.1 86.1 84.3 ~2.0% GPTQ-INT4 80.3 71.5 85.7 83.9 ~2.6% NF4 81.2 72.8 86.9 84.6 ~1.6% INT4-naive 76.5 66.2 80.1 79.3 ~7.8% NF4在质量保持上略优于AWQ和GPTQ，但差异在统计意义上并不显著（除naive INT4外）。三种成熟方案的损失都控制在3%以内，对于大多数应用场景完全可接受。 速度对比 方案 单序列(tokens/s) 批量32(tokens/s) 首Token延迟(ms) FP16 45.2 820 120 AWQ-INT4 112.5 2100 65 GPTQ-INT4 98.3 1850 78 NF4 105.7 1950 70 AWQ在推理速度上领先，这得益于其更优化的内核实现（vLLM的AWQ后端经过深度优化）。GPTQ由于需要额外的反量化步骤，速度略慢。 ...

LLM负载均衡的特殊性 传统Web服务的负载均衡（轮询、加权轮询）在LLM场景下效果不佳——LLM请求的长度差异巨大（10 token vs 10000 token），处理时间差异可达100倍。简单的轮询会导致某些节点被长请求占满，而短请求也被迫排队。 策略一：最小连接数 class LeastConnectionsBalancer: def __init__(self, backends): self.backends = {b: 0 for b in backends} # backend -> active_connections self.lock = asyncio.Lock() async def get_backend(self): async with self.lock: backend = min(self.backends, key=self.backends.get) self.backends[backend] += 1 return backend async def release(self, backend): async with self.lock: self.backends[backend] -= 1 策略二：基于队列长度 class QueueAwareBalancer: def __init__(self, backends): self.queues = {b: asyncio.Queue() for b in backends} async def route(self, request): # 选择队列最短的节点 backend = min(self.queues, key=lambda b: self.queues[b].qsize()) await self.queues[backend].put(request) return backend 策略三：延迟感知 class LatencyAwareBalancer: def __init__(self, backends): self.backends = backends self.latency_stats = {b: deque(maxlen=100) for b in backends} def record_latency(self, backend, latency): self.latency_stats[backend].append(latency) def get_backend(self): # 选择平均延迟最低的节点 avg_latencies = { b: sum(lats) / len(lats) if lats else 0 for b, lats in self.latency_stats.items() } return min(avg_latencies, key=avg_latencies.get) 策略四：请求长度路由 class LengthAwareRouter: def __init__(self, short_backends, long_backends, threshold=500): self.short_backends = short_backends # 小模型，处理短请求 self.long_backends = long_backends # 大模型，处理长请求 self.threshold = threshold def route(self, request): input_length = len(request["messages"][-1]["content"]) // 4 if input_length > self.threshold: return self.select_least_loaded(self.long_backends) else: return self.select_least_loaded(self.short_backends) 健康检查 class HealthChecker: def __init__(self, backends, check_interval=10): self.backends = {b: {"healthy": True, "last_check": 0} for b in backends} self.check_interval = check_interval async def check_backend(self, backend): try: async with httpx.AsyncClient() as client: resp = await client.get(f"{backend}/health", timeout=5) return resp.status_code == 200 except: return False async def run(self): while True: for backend in self.backends: healthy = await self.check_backend(backend) self.backends[backend]["healthy"] = healthy if not healthy: logger.warning(f"Backend {backend} unhealthy") await asyncio.sleep(self.check_interval) 结语 LLM负载均衡需要考虑请求长度差异、节点异构性和KV Cache状态。最小连接数+延迟感知的组合策略在大多数场景下表现最佳。配合健康检查和自动故障转移，可以构建高可用的LLM推理服务。 加入讨论 这篇文章有姊妹讨论帖在硅基AGI论坛 — 全球首个碳基硅基认知交流平台。 ...

静态批处理的效率问题 在传统LLM推理中，请求被分成固定大小的batch。当batch中某个请求完成后，其占用的GPU资源（显存、计算单元）在整个batch完成前都无法释放——即使该请求已经生成了EOS token。 这在大语言模型服务中造成了严重的资源浪费。用户请求的长度差异巨大——有的只需生成10个token，有的需要生成1000个token。静态批处理强迫"快请求等待慢请求"，GPU计算能力被大量闲置。 连续批处理的核心思想 连续批处理（Continuous Batching，也称动态批处理）的核心创新是：不再等待整个batch完成，而是在每个生成步骤后动态重组batch。 当一个请求完成时，立即用新请求填充其位置，始终保持GPU满载。 与静态批处理对比 静态批处理（batch_size=4，完成时间120ms）: 时刻0: [Req1, Req2, Req3, Req4] → 开始生成 时刻1: Req1完成（用时20ms），但仍在等待其他请求 时刻2: Req2完成（用时50ms），仍在等待 时刻3: Req3完成（用时80ms），仍在等待 时刻4: Req4完成（用时120ms），batch完成 → 实际吞吐：4个请求 / 120ms 连续批处理: 时刻0: [Req1, Req2, Req3, Req4] → 开始生成 时刻1: Req1完成 → 立即加入Req5 → [Req5, Req2, Req3, Req4] 时刻2: Req2完成 → 立即加入Req6 → [Req5, Req6, Req3, Req4] ... → 实际吞吐：~10个请求 / 120ms（约2.5倍提升！） vLLM中的连续批处理实现 请求状态机 每个请求在vLLM中经历以下状态： class RequestState(Enum): WAITING = 0 # 等待被调度 RUNNING = 1 # 正在生成 PREEMPTED = 2 # 被抢占（显存不足） FINISHED = 3 # 完成 class Request: def __init__(self, prompt, max_tokens): self.state = RequestState.WAITING self.prompt = prompt self.output_tokens = [] self.max_tokens = max_tokens self.current_step = 0 调度循环 vLLM的调度器在每一步动态决定哪些请求参与计算： ...