第3周 AI 性能优化总结——从推理加速到服务架构的进阶路径
一、回归本周核心命题：AI 服务性能优化的三个维度
本周讨论的 AI 性能优化，不再停留在"换一个更快的模型"或"加几张 GPU"的层面，而是从推理引擎层、服务中间层、架构调度层三个维度做了系统性的拆解。这三个维度之间存在明确的依赖关系：底层推理加速为上层节省了基础资源，服务中间层将这些资源更高效地路由和编排，而架构调度层则将前两者的收益转化为可量化的 SLA 提升。
回顾本周的核心发现，可以提炼出三条可以复用的判断：
本文将这些分散的讨论串成一条完整的能力进阶脉络，为后续更深度的 AI 架构话题打下基础。
二、本周知识地图：从模型到服务的完整能力矩阵
本周的内容体系可以划分为五个核心子域，构成了从模型到服务的完整能力矩阵：
在这一体系中，推理引擎层和服务中间层是本次讨论的重点，二者构成了从单一模型实例到可弹性扩展的推理集群的核心桥梁。
值得说明的是，这套框架并非理论推导，而是基于我们在多个生产场景中的实践沉淀——从金融领域的智能客服到电商的推荐系统，不同规模、不同延迟敏感度的场景下，这套分层方法的适用性和有效性都得到了验证。
三、推理引擎层的关键优化手段与工程决策
推理引擎层的优化目标是在单个 GPU 实例上跑出更高的吞吐和更低的延迟。本周我们重点讨论了以下手段：
Continuous Batching（连续批处理） 是当前所有主流推理引擎（vLLM、TGI、TensorRT-LLM）的标配能力。其核心思想是动态批处理：当新请求到达时立即加入正在执行的批次，而不必等待当前批次结束。这直接解决了传统静态批处理中"快请求等慢请求"的问题。KV Cache 的分页管理（PagedAttention） 将 KV Cache 从连续分配改为分页管理，消除了显存碎片。配合 Prefix Caching（前缀缓存），对于共享系统提示词的场景，可以节省 30%~50% 的显存占用。
投机解码（Speculative Decoding） 使用一个小型草稿模型快速生成候选 Token 序列，再由大模型一次性验证。对于生成任务，可以提升 1.5~2.5 倍的吞吐量。
Prefill-Decode 分离（Disaggregated Serving） 是将 Prefill（计算密集型）和 Decode（访存密集型）部署在不同 GPU 上，解决两阶段资源冲突的终极方案。代价是引入了网络传输开销，更适合对延迟不敏感的高吞吐场景。
以下是一个推理引擎参数调优的配置示例：
/**
* vLLM 推理引擎的启动参数配置封装
* 不同场景需要选择不同的优化策略组合
*/
public class VllmEngineConfig {
// 模型与服务配置
private final String modelPath;
private final int tensorParallelSize; // 张量并行数（单机多卡场景）
private final int pipelineParallelSize; // 流水线并行数（多机场景）
// KV Cache 配置
private final double gpuMemoryUtilization; // GPU 显存利用率上限，建议 0.85~0.90
private final int maxModelLen; // 最大序列长度
private final int maxNumSeqs; // 最大并发序列数
// 调度策略
private final boolean enablePrefixCaching; // 是否启用前缀缓存
private final boolean enableChunkedPrefill; // 是否启用分块预填充
private final int maxNumBatchedTokens; // 单批次最大 Token 数
public VllmEngineConfig(String modelPath, int tensorParallelSize) {
this.modelPath = modelPath;
this.tensorParallelSize = tensorParallelSize;
this.pipelineParallelSize = 1;
// 显存利用率预留 10%~15% 给 KV Cache 碎片和系统开销
this.gpuMemoryUtilization = 0.90;
// 序列长度根据业务场景设定，过长会浪费显存
this.maxModelLen = 8192;
// 并发序列数：A100 80G 建议 256，A10 24G 建议 64
this.maxNumSeqs = 256;
// 生产环境强烈建议开启前缀缓存
this.enablePrefixCaching = true;
// 分块预填充可避免长 Prompt 的 Prefill 阻塞
this.enableChunkedPrefill = true;
// 单批次 Token 数需要根据 GPU 显存做压力测试确定
this.maxNumBatchedTokens = 16384;
}
/**
* 针对低延迟场景的调优参数
* 牺牲部分吞吐换取更低的 TTFT
*/
public static VllmEngineConfig forLowLatency(String modelPath) {
VllmEngineConfig config = new VllmEngineConfig(modelPath, 1);
// 降低最大并发序列数，减少排队延迟
// 此处无法修改 final 字段，实际实现中使用 Builder 模式
return config;
}
/**
* 针对高吞吐场景的调优参数
* 最大化 GPU 利用率
*/
public static VllmEngineConfig forHighThroughput(String modelPath, int gpuCount) {
VllmEngineConfig config = new VllmEngineConfig(modelPath, gpuCount);
return config;
}
public List<String> buildCommandLineArgs() {
List<String> args = new ArrayList<>();
args.add("–model");
args.add(modelPath);
args.add("–tensor-parallel-size");
args.add(String.valueOf(tensorParallelSize));
args.add("–gpu-memory-utilization");
args.add(String.valueOf(gpuMemoryUtilization));
args.add("–max-model-len");
args.add(String.valueOf(maxModelLen));
args.add("–max-num-seqs");
args.add(String.valueOf(maxNumSeqs));
if (enablePrefixCaching) {
args.add("–enable-prefix-caching");
}
if (enableChunkedPrefill) {
args.add("–enable-chunked-prefill");
}
try {
return args;
} catch (Exception e) {
throw new IllegalStateException("构建 vLLM 启动参数失败", e);
}
}
}
四、服务中间层：让推理集群从"可用"走向"好用"
推理引擎层优化解决的是"单点性能"，而服务中间层解决的是"分布式性能"。本周我们重点讨论了阶段感知路由和Token 感知负载均衡。
阶段感知路由的核心是区分 Prefill 和 Decode 请求，将 Prefill 请求分发到当前 Prefill 负载较轻的实例，将 Decode 请求分发到 KV Cache 余量充足的实例。实现上可以基于一致性哈希 + 动态权重，或者使用更轻量的加权随机 + 滑动窗口反馈。
Token 感知负载均衡则需要推理实例定期上报其 KV Cache 使用率、活跃 Token 数、排队请求数等指标。路由器根据这些指标计算每个实例的"可用容量评分"，选择最优实例进行路由。
一个关键的设计选择是：路由状态应该放在哪里？ 放在网关层的好处是延迟最低、无额外网络跳转；放在独立路由服务的好处是策略更灵活、易于跨集群调度。对于 QPS 在百量级的场景，网关内嵌路由是更务实的选择。
五、本周进阶路径与下周展望
回顾本周的讨论，可以发现一条清晰的进阶路径：
Level 1（基础）：理解 LLM 推理的性能特征，能对推理引擎参数进行合理调优。
Level 2（进阶）：掌握负载均衡与流量调度策略，构建可弹性扩展的推理集群。
Level 3（高阶）：建立完整的性能指标体系与容量预测模型，实现数据驱动的容量管理。
Level 4（前瞻）：关注 Agent 网络架构的演进趋势，将推理能力从"问答式交互"升级为"自主任务执行"。
下周我们将深入 Agent 网络的架构设计与工程实现，重点讨论多 Agent 协同调度、长短期记忆管理以及工具调用链路的可靠性保障。这些话题将会更接近 AI 应用架构的上层设计，建议在阅读前先复习本周关于负载均衡和容量管理的内容，它们是 Agent 网络调度能力的基础。
