成本的来源

着手优化之前，先要搞清楚资金主要消耗在 LLM 推理的哪些环节：

• GPU 时长 - 这是最核心的成本因素。无论是租赁还是自建，A100 和 H100 GPU 的价格都居高不下。
• 显存带宽 - 大模型的运行瓶颈通常在于内存而非计算能力。从显存中搬运权重数据的速度慢且成本高。
• 网络出口流量 - 在不同地域或云服务商之间传输数据，费用累积得非常快。
• 空闲等待 - GPU 在等待请求指令时处于闲置状态，这纯粹是在浪费资金。

四种降本策略

1. 批处理请求

批处理（Batching）是指将多个请求合并，一次性通过模型进行前向传播。这是提升 LLM 服务效率最立竿见影的手段。

原理： GPU 天生就是为了并行计算而设计的。单个请求往往会让 GPU 的大部分算力闲置。而批处理能通过同时处理多个请求，让 GPU 满负荷运转。

实施方法：

• 在服务栈中引入批处理组件——例如 vLLM、Triton Inference Server，或者自行开发批处理逻辑。
• 开启 动态批处理 功能，并设定最大等待时间（通常为 10-20 毫秒）。
• 依据显存容量和延迟要求，设定批次大小的上限。
• 实时监控队列深度，防止因批处理导致延迟过高。

权衡利弊：

• 在低流量场景下会增加延迟（通常在 10-20 毫秒左右）。
• 需要对批次大小和超时参数进行精细的调优。
• 不同规模的模型可能需要配置不同的批处理策略。

效果： 批处理能将吞吐量提升 2 到 4 倍。这意味着在处理相同负载时，你可以减少 50% 至 75% 的 GPU 数量。

2. 优化 KV Cache

Key-Value (KV) 缓存用于存储之前 Token 已计算出的注意力键值，从而在生成新 Token 时避免重复计算。

原理： 在自回归生成过程中，每个新生成的 Token 都需要关注之前的所有 Token。如果没有缓存，每次都需要重新计算所有历史 Token 的注意力。而有了 KV Cache，只需计算当前新 Token 的注意力即可。

实施方法：

• 在模型服务器中启用 KV 缓存（vLLM 已默认自动开启此功能且效率极高）。
• 实施 PagedAttention 机制以实现高效的内存管理（即 vLLM 采用的方案）。
• 针对长会话设定驱逐策略，防止内存溢出（OOM）错误。
• 持续监控 KV 缓存占用的显存比例。

权衡利弊：

• KV 缓存会占用相当一部分显存——需要据此规划容量。
• 对于极短文本的生成，内存开销可能得不偿失。
• 针对长周期的会话或对话，必须设计合理的驱逐策略。

效果： 对于上下文长度超过几百个 Token 的情况，KV Cache 能将每个 Token 的计算量减少 50% 至 70%。上下文越长，收益越显著。

3. 模型量化

量化是指将模型权重从高精度格式（FP16/FP32）转换为低精度格式（如 INT4, FP8, INT8）。

原理： 更小的权重意味着更低的内存占用和更快的计算速度。由于 LLM 推理往往受限于内存带宽，权重的缩减直接转化为推理速度的提升。

实施方法：

• 使用 AWQ（Activation-aware Weight Quantization）进行 INT4 量化，能将质量损失降至最低。
• 尝试 GPTQ 进行训练后量化。
• 利用 TensorRT-LLM 或 llama.cpp 来加速量化后的推理。
• 在生产部署前，务必在评估数据集上对量化模型进行测试。

权衡利弊：

• 模型质量可能会下降，尤其是小模型或采用激进量化策略时。
• 部分量化方法需要校准数据。
• 并非所有计算操作都能被有效量化。
• 不同的网络层可能需要采用差异化的量化策略。

效果： INT4 量化可以削减 75% 的内存使用，并将推理速度提升 1.5 到 2 倍。原本需要 4 张 A100 GPU (FP16) 才能跑动的 70B 模型，在 INT4 下只需单张 A100 即可运行。

4. 智能调度

通过智能请求调度和自动扩缩容，确保既不为闲置的 GPU 买单，又能维持低延迟。

原理： GPU 的成本是按小时固定的，无论利用率是 10% 还是 100%。智能调度旨在最大化利用率，同时避免因冷启动影响延迟。

实施方法：

• 维持一个 预热池，确保池内的 GPU 已加载好模型。
• 依据队列深度和延迟指标实施扩缩容，而非仅看流量。
• 使用 装箱算法 高效地将请求分配给 GPU。
• 优先将流量路由至负载最低的实例。
• 若流量峰值可预测，实施预防性扩容。

权衡利弊：

• 过度扩容（保留过多预热 GPU）会抹平成本优势。
• 扩容不足会损害延迟和用户体验。
• 冷启动（加载模型）耗时可能长达 30-60 秒。
• 需要良好的可观测性来调优扩缩容参数。

效果： 在批处理和量化的基础上，智能调度通过消除闲置和合理配置容量，能进一步节省 10% 至 20% 的成本。

策略组合拳

上述优化手段并非互斥，而是可以叠加生效。以下是一个现实的模拟场景：

• 基线： 70B 模型，无优化，FP16 → 需要 4 张 A100 GPU，单价 $2.50/时，日花费 $240。
• + 批处理： 吞吐量提升 2.5 倍 → 只需约 1.6 张 GPU 的容量 → 日花费 $96。
• + 量化 (INT4)： 容量从 4 张 GPU 压缩至 1 张 → 相同容量下日花费 $60。
• + 智能调度： 减少 15% 的闲置时间 → 日花费降至 $51。

总节省：成本降低 79%（从每天 $240 降至 $51）

需要留意的权衡

任何优化都有代价。以下是关键的关注点：

• 批处理 vs 延迟： 虽然吞吐量极佳，但会增加 10-20ms 的等待时间。不适合极低延迟的场景。
• 量化 vs 质量： INT4 虽省钱，但可能损害准确率。务必在评估集上测试，并在生产环境中监控质量指标。
• KV Cache vs 内存： 推理更快，但消耗显存。可能会限制批处理大小或并发请求数。
• 自动扩缩容 vs 稳定性： 激进的缩容省钱，但在流量激增时面临冷启动风险；保守的缩容则会在闲置容量上浪费资金。

实操建议

准备削减你的 LLM 成本了吗？以下是一份实操路线图：

1. 从批处理入手 - 风险最低且收益最快。在你的服务栈中启用动态批处理。
2. 引入 KV 缓存 - 对于生成任务，这几乎是稳赚不赔的。使用 vLLM 或在现有服务器中开启。
3. 尝试量化 - 在评估集上运行 INT4/FP8 模型。如果质量达标，先部署部分流量进行灰度。
4. 实施智能调度 - 基于队列深度和 p95 延迟配置自动扩缩容，不要只看请求率。
5. 监控核心指标 - 持续追踪 GPU 利用率、p95 延迟、每千次请求成本以及质量指标。
6. 持续迭代 - 根据生产数据微调批次大小、超时值和扩缩容阈值。

工具与参考

• vLLM - 具备 PagedAttention 技术的高吞吐、内存高效 LLM 服务引擎。
• Triton Inference Server - NVIDIA 推出的支持动态批处理的推理服务平台。
• AWQ - 适用于 INT4 模型的激活感知权重量化工具。
• TensorRT-LLM - NVIDIA GPU 上的 LLM 推理优化库。
• 基于我在 Google、Uber 和 Microsoft 的经验：批处理结合量化，在不同模型规模和用例中始终能带来 40%-60% 的成本缩减。