课程导入：学习目标、课程结构、低延迟服务架构的整体概念
1.1 为什么需要低延迟推理服务
在生成式 AI 应用大规模落地的今天，用户对“响应速度”的感知已经从“能接受”演变为“必须快”。无论是智能客服、代码补全、实时翻译，还是自动驾驶中的多模态感知，推理延迟直接决定了产品体验的上限。以 LLM 服务为例，一次对话往往涉及数百甚至数千个 token 的流式生成，如果首 token 延迟（TTFT）超过 2 秒，用户就会明显感到“卡顿”；如果每 token 生成间隔（ITL）超过 100ms，流式输出的“打字机效果”就会失去自然感。
更关键的是，低延迟并非单一指标，而是一组相互制约的工程目标。我们需要同时关注：TTFT（Time To First Token）、ITL（Inter-Token Latency）、吞吐量（Throughput）以及GPU 利用率。单纯追求吞吐而牺牲延迟，或只优化延迟而忽略成本，都无法支撑真实业务。TensorRT-LLM 作为 NVIDIA 推出的高性能推理框架，其核心价值正是在保证低延迟的同时最大化硬件利用率，而这背后涉及引擎构建、KV Cache 管理、动态批处理、并行策略等一系列架构决策。
1.2 课程学习目标
完成本课程后，你将能够：
- 理解 TensorRT-LLM 的核心架构组件：包括引擎（Engine）、运行时（Runtime）、KV Cache 管理器、调度器等，并清楚它们如何协同影响延迟。
- 掌握低延迟服务的关键设计模式：如动态批处理（In-flight Batching）、连续批处理（Continuous Batching）、Paged KV Cache、多实例 GPU 调度等。
- 具备性能调优的实操能力：能够通过 profiling 工具定位延迟瓶颈，并针对 prefill 阶段、decode 阶段分别进行优化。
- 能够设计高可用、可扩展的推理服务架构：从单机单卡到多机多卡，从同步请求到流式响应，从离线批处理到在线实时服务。
| 能力维度 | 入门水平 | 本课程目标水平 |
|---|---|---|
| TensorRT-LLM API 使用 | 能运行官方示例 | 能自定义引擎配置、修改采样参数、接入自定义模型 |
| 延迟优化策略 | 了解存在优化空间 | 能针对 TTFT/ITL 分别制定优化方案并验证效果 |
| 服务架构设计 | 单机单卡部署 | 能设计多卡并行、负载均衡、弹性伸缩的架构 |
| 性能分析工具 | 仅看日志 | 熟练使用 nsys、ncu、TensorRT-LLM 内置 profiler |
1.3 课程结构总览
本课程共 30 章，分为五个递进阶段。每个阶段都围绕一个核心问题展开，避免碎片化学习。
- 基础篇（第 1-6 章）：建立低延迟服务的整体认知，掌握 TensorRT-LLM 的安装、模型转换、引擎构建与基本推理流程。
- 原理篇（第 7-12 章）：深入 prefill 与 decode 的底层机制，理解 KV Cache、Attention 算子优化、量化对延迟的影响。
- 架构篇（第 13-20 章）：聚焦服务化架构，包括请求调度、动态批处理、并行策略（TP/PP/EP）、流式输出设计。
- 调优篇（第 21-26 章）：基于 profiling 数据进行系统性调优，涵盖显存优化、算子融合、通信压缩等实战技术。
- 实战篇（第 27-30 章）：完成一个端到端的低延迟服务项目，从需求分析到压测报告，形成可复用的架构模板。
每一章都包含理论讲解、代码/配置示例、常见误区分析以及课后练习。建议按照顺序学习，因为后续章节会频繁引用前面建立的概念。
1.4 低延迟服务架构的整体概念
在进入具体技术之前，我们需要先建立一张“全局地图”。一个典型的 LLM 低延迟服务架构可以抽象为四个层次，每一层都有独立的延迟贡献和优化空间。
上图展示了四个层次之间的依赖关系。客户端接入层负责接收请求并管理连接，其延迟开销通常在毫秒以下，但在高并发下可能因排队而恶化。调度与运行时层是 TensorRT-LLM 的核心，它决定哪些请求的哪些 token 在哪个 GPU 上被计算，这一层的策略直接决定了 TTFT 和 ITL 的上限。引擎与算子层则关注单个 token 的前向计算效率，包括算子融合、量化、显存访问优化等。硬件资源层是物理约束，GPU 的显存带宽、NVLink 拓扑、SM 数量决定了理论极限。
理解这个分层模型后，你会发现低延迟优化并不是“调一个参数”就能完成的，而是需要在每一层做出权衡。例如，为了降低 TTFT，我们可以让新请求插队到正在 decode 的批次中（In-flight Batching），但这可能增加其他请求的 ITL。为了提升吞吐，我们可以增大 batch size，但每个 token 的生成延迟也会随之上升。因此，低延迟架构设计的本质是在多目标约束下寻找最优解。
1.5 典型场景与延迟目标参考
不同的业务场景对延迟的敏感度差异巨大。下表给出了三类典型场景的参考延迟目标，后续章节的优化手段将围绕这些目标展开。
| 场景 | TTFT 目标 | ITL 目标 | 并发请求数 | 主要瓶颈 |
|---|---|---|---|---|
| 智能对话助手 | < 800ms | < 60ms | 100 - 1000 | KV Cache 容量、调度效率 |
| 代码补全 | < 500ms | < 30ms | 50 - 500 | Prefill 计算量、显存带宽 |
| 离线批量分析 | 不敏感 | 不敏感 | 高吞吐优先 | GPU 利用率、吞吐量 |
1.6 常见误区与设计原则
- 尽早开始（Start Early）：请求到达后应尽快进入 GPU 计算队列，减少排队等待时间。
- 避免空闲（No Idle）：GPU 的每个 SM 都应尽可能保持忙碌，通过动态批处理填充计算间隙。
- 减少移动（Minimize Movement）：数据（权重、KV Cache、中间激活）在 GPU 内部的移动成本远高于计算成本，应通过算子融合和显存复用减少拷贝。
- 隔离与共享平衡：不同优先级请求需要隔离，但完全隔离会降低资源利用率，需要设计弹性配额。
1.7 本章小结
本章建立了低延迟服务架构的整体认知框架。我们明确了 TTFT、ITL 等核心延迟指标，了解了课程的五阶段递进结构，并通过四层架构模型理解了从客户端到硬件的完整链路。最后，我们通过典型场景的延迟目标对比，认识到不同业务对优化的侧重点截然不同。