先记住一句话
模型速度、单请求速度和服务吞吐是三件事；优化 TensorRT-LLM 时必须同时看 TTFT、TPOT、tokens/s、p99、KV cache 容量与输出质量。
1. Prefill 与 Decode
| 阶段 | 工作 | 常见特征 |
|---|---|---|
| Prefill | 一次处理 prompt，建立 KV | 较大矩阵、parallelism 高、常更 compute-bound |
| Decode | 每步生成一个新 token，读取历史 KV | 矩阵瘦、重复 launch、常更 memory/latency-bound |
长 prompt 会推高 time to first token；长 output 让 per-output-token latency 主导。一个平均 latency 无法表达二者。
2. KV cache 为什么昂贵
KV bytes ≈ layers × 2(K,V) × tokens × KV_heads × head_dim × bytes_per_elementbatch、context 和并发请求线性放大 KV。GQA/MQA 减少 KV heads；低精度 KV 减 bytes；但都需质量验证。权重装下不等于服务能接足够并发，剩余显存常由 KV 与 activation/workspace 争夺。
3. Paged / block KV cache
将 cache 分固定 token blocks，logical sequence 映射到非连续 physical blocks，可减少预留整段最大长度的内部碎片，便于增长、回收、共享和 eviction。代价是 block metadata、间接寻址和调度复杂度；block size 在 locality 与碎片之间取舍。
4. Prefix reuse、offload 与 eviction
共享 system prompt/prefix 可复用已计算 KV，命中时降低 prefill 成本；需可靠 hash/身份、位置与模型配置一致。GPU cache 不足时可 eviction 或 offload 到 host，但重新计算与 PCIe transfer 谁便宜取决于 prefix 长度、带宽和队列压力。
5. In-flight / continuous batching
静态 batching 要等整个 batch 都结束，短请求被长请求拖住。continuous batching 在 token step 边界移出完成请求、加入新请求，提高利用率。scheduler 要在 token budget、最大 batch、prefill chunk、priority 与 SLO 之间权衡；追求总 throughput 会伤害单请求尾延迟。
6. 并行与通信
Tensor parallel 把每层矩阵分卡但每 token 有 collectives；pipeline parallel 容纳更多层但引入 stages/bubbles；expert parallel 为 MoE 做 routing/AllToAll。多卡方案必须用目标 batch/context 测试，因为 decode 的细粒度同步可能让通信 latency 尤其突出。
7. 量化不是一个开关
weight-only quantization 主要降低权重容量/带宽；weight+activation 可用低精度矩阵路径；KV quantization 直接扩大并发/上下文容量。不同层、prefill/decode 和 speculative draft/target 可能适合不同格式；吞吐收益必须与 perplexity、task success 和生成分布一起报告。
8. TensorRT、TensorRT-LLM、Triton 各是谁
- TensorRT：通用神经网络 build/runtime optimizer；
- TensorRT-LLM：基于 NVIDIA stack 的 LLM kernels、model definitions、KV/cache、scheduler 与 multi-GPU runtime；
- Triton Inference Server：模型服务与 ensemble/backend 平台；
- Triton language：写 GPU kernels 的编程语言——与 Inference Server 同名但不是同一层。
9. 四类核心指标
| 指标 | 含义 | 主要受什么影响 |
|---|---|---|
| TTFT | 请求到第一个 token | 排队 + prefill |
| TPOT / ITL | 后续 token 间隔 | decode batch、KV、通信 |
| tokens/s | 系统总吞吐 | batching、利用率、量化 |
| p95/p99 | 尾部体验 | 长度长尾、排队、cache miss |
再补充并发数、input/output length distribution、功耗/成本、峰值显存与质量，数字才可复现。
10. 一套实践顺序
- 用
trtllm-bench隔离 engine/runtime 的 offline 性能； - 用
trtllm-serve或实际 server 回放长度/到达率分布； - 画 TTFT—TPOT—throughput Pareto frontier，而非只调一个峰值；
- profile prefill、decode、communication 与 scheduler gaps；
- 逐个引入 quantization、KV reuse、parallelism，并做质量回归。
11. 从单机到数据中心
高性能计算的共同原则在此汇合：Roofline 判断 kernel，CUDA Graphs 降 launch，NCCL 管多卡，NUMA/NIC topology 管节点，scheduler 管请求。真正的最优点通常不是某个 kernel 的最高 TFLOP/s，而是 SLO 内每 GPU 的有效 tokens/s 或每任务成功的成本。
12. 四个 LLM serving 手算
例 1：KV cache 每 token
32 layers、32 KV heads、head dim=128、FP16 K+V，每 token bytes=32×32×128×2 bytes×2≈524,288 bytes=512 KiB。若用 GQA 8 KV heads，则降为 128 KiB/token。
例 2：单请求 KV 容量
按 GQA 128 KiB/token，4096-token context 占约 128 KiB×4096=512 MiB。16 个这样的 active requests 仅 KV 就约 8 GiB。
例 3：TTFT 与 TPOT
Prompt prefill 120 ms，生成 100 tokens、TPOT=20 ms，用户总等待约 120+99×20=2100 ms（首 token 已计入 TTFT）。交互体验需分别优化两项。
例 4：continuous batching throughput
Decode batch 有 32 active requests，一步耗 12 ms、每请求产 1 token，throughput=32/0.012=2667 tokens/s。若排队把 batch 等满导致 TTFT 多 200 ms，可能违反 SLO。
最大 batch 的最高 tokens/s 不等于最好服务。若 TTFT/p99 超出 SLO、KV 导致 admission failure，或生成质量下降，峰值吞吐没有业务价值。
自测
1. 为什么 decode 常比 prefill 更难吃满 GPU？
每步只有少量新 tokens，矩阵更瘦，还要反复读取历史 KV 并承担逐步 launch/同步。
2. continuous batching 解决什么问题？
让完成的请求及时离开、等待请求及时进入，避免静态 batch 被最长序列锁住，提高利用率。
3. KV cache quantization 的直接系统收益是什么？
降低每 token cache bytes，从而支持更多并发或更长上下文，并减少 decode memory traffic；代价是潜在质量损失和解量化成本。
官方资料
TensorRT-LLM KV Cache文档说明 blocks、reuse、offload 与 eviction；Performance Tuning Guide覆盖调度与性能旋钮；Benchmarking介绍 trtllm-bench 和 serving 测试。