小白学AI第一节：深入浅出模型推理的重要的概念（PD）第一节

一、背景说明：LLM 规模化推理的痛点与 TGI 的定位

• 延迟瓶颈：LLM 自回归生成的特性（逐一生成输出token），导致解码阶段耗时过长，影响用户实时交互体验（如聊天场景需首token快速响应）；
• 资源浪费：静态批处理方案中，请求需等待前一批次完全完成才能进入下一批，GPU 常处于空闲状态，算力利用率低；
• 兼容性差：不同 LLM 模型（如 LLaMA、Mistral、GPT-2）的推理优化逻辑不同，传统方案需针对性开发，适配成本高。

• 开源免费，支持自定义开发，保障数据隐私（无需依赖第三方闭源推理服务）；
• 兼容 HuggingFace Hub 上的主流 LLM，无需修改模型代码即可直接部署；
• 内置生产级能力，支持分布式追踪、Prometheus 监控、动态批处理调度；
• 大幅优化延迟与吞吐，在相同 GPU 资源下，吞吐可提升数倍，延迟降低30%以上。

二、核心概念：读懂 LLM 推理与 TGI 优化的基础

2.1 LLM 推理的两大核心阶段

• 预填充（Prefill）
  • 核心操作：对输入提示词（Prompt）在 CPU 进行分词，将 tokens 传输到 GPU 后，通过单次前向传播处理所有输入 tokens，生成第一个输出 token；
  • 性能特征：计算密集型（依赖 GPU FLOPs 算力），耗时取决于输入 tokens 长度和模型参数；
  • 关键指标：首token生成时间（TTFT，Time To First Token），直接影响用户实时交互体验（如聊天场景需 TTFT < 500ms）。
• 解码（Decode）
  • 核心操作：基于 Prefill 生成的初始 token，自回归逐一生成后续 tokens，每个新 token 会追加到输入序列，更新上下文后进行下一次前向传播；
  • 性能特征：内存密集型（依赖 GPU HBM 带宽），计算量远小于 Prefill，但需多次重复前向传播（输出 token 数越多，耗时越长）；
  • 关键指标：每输出 token 耗时（TPOT，Time Per Output Token），影响长文本生成效率（如文档总结场景需 TPOT < 50ms）。

2.2 TGI 核心优化技术

• KV 缓存（KV Caching）
  • 核心作用：缓存 Prefill 和 Decode 阶段中，每个 token 位置的注意力层中间状态（Key/Value 张量），避免后续解码时重复计算；
  • 优化效果：将解码阶段的注意力计算复杂度，从 O(n²)（n 为序列长度）优化为 O(n)（线性复杂度），解码速度提升5-10倍；
  • 注意点：KV 缓存会占用 GPU VRAM，序列长度越长，缓存占用越大，是限制批处理大小的核心因素之一。
• 连续批处理（Continuous Batching）
  • 核心区别：区别于传统静态批处理（请求需等待前一批次完全完成才能进入下一批），连续批处理可动态将新请求加入正在运行的批次，实现 Prefill 和 Decode 阶段的交织执行；
  • 优化效果：GPU 资源利用率从 30%-50% 提升至 80% 以上，在小幅增加延迟（≤10%）的情况下，吞吐提升2-3倍；
  • 核心逻辑：TGI 会为每个批次分配「令牌预算」，动态调整请求的批处理顺序，避免 GPU 空闲。
• Flash Attention
  • 核心作用：优化注意力计算的内存效率，消除传统注意力机制中的 padding 开销，支持无填充张量计算；
  • 优化效果：VRAM 占用降低 30%-50%，长序列推理（如输入 tokens > 2048）性能提升显著，尤其适合 RAG 等长上下文场景；
  • 补充：虽 Flash Attention 最初为训练设计，但在推理阶段仍能通过减少内存移动，提升 GPU 利用率。
• Paged Attention
  • 核心作用：将 KV 缓存切分为固定大小的「页」，每个请求按需占用和释放页，避免为每个请求重新分配完整的张量；
  • 优化效果：解决 LLM 推理的内存绑定问题，减少不必要的内存移动，缓存复用率提升 40% 以上，支持更多请求并发处理；
  • 适用场景：多请求、长序列的规模化推理场景（如公开 API 服务）。

2.3 关键性能指标（必懂，用于 TGI 调优）

（1）延迟相关指标

• TTFT（Time To First Token）：首token生成时间，由 Prefill 阶段性能决定，实时交互场景（如聊天、RAG）优先优化；
• TPOT（Time Per Output Token）：每生成一个后续 token 的耗时，由 Decode 阶段性能决定，长文本生成场景（如文档总结）优先优化；
• 总延迟：TTFT + TPOT × 输出 token 数，生产环境需根据业务场景设定阈值（如实时场景总延迟 < 3s）。

（2）吞吐相关指标

• 令牌吞吐（Token Throughput）：单位时间内模型处理的 tokens 总数（核心指标），LLM 推理的吞吐需关注 tokens 而非请求数；
• 批处理大小（Batch Size）：单批次可处理的请求数，由 GPU VRAM 容量、模型大小、KV 缓存占用决定，并非越大越好（过大易导致 OOM）。

（3）资源相关指标

• VRAM 占用：主要由「模型权重（固定）+ KV 缓存（随序列长度增长）」构成，是限制批处理大小和序列长度的核心；
• GPU 利用率：理想状态下维持在 70%-90%，过低说明资源浪费，过高易导致延迟飙升。

2.4 TGI 核心参数（落地必配置）

• MAX_BATCH_PREFILL_TOKENS（MBP）：GPU 在 Prefill 阶段单次前向传播可处理的最大 tokens 数，是 Prefill 阶段的令牌预算上限；
• MAX_BATCH_TOTAL_TOKENS（MBT）：GPU 在 Prefill + Decode 阶段可并发处理的最大 tokens 数，是整体令牌预算上限；
• max_new_tokens：模型单请求最大生成 token 数（如聊天场景设为 512，文档总结设为 2048）；
• max_input_tokens：模型单请求最大输入 token 数（如 RAG 场景设为 4096）；
• tensor_parallel_size：张量并行数，用于多 GPU 部署（如 2 张 GPU 设为 2），提升大模型推理性能。

三、TGI 核心架构解析（从请求到输出的全流程）

3.1 路由器（Router）：TGI 的「大脑」，负责请求调度与批处理

• 请求队列管理：接收用户请求，按优先级排序，避免高优先级请求被阻塞（如实时聊天请求优先于批量文档生成请求）；
• 连续批处理调度：动态将新请求加入正在运行的批次，交织执行 Prefill 和 Decode 步骤——当某个请求完成 Decode 阶段（生成 EOS token），立即释放其 KV 缓存和令牌预算，分配给新请求；
• 令牌预算管理与 OOM 防护：基于 MBP（Prefill 上限）和 MBT（整体上限），动态分配令牌预算，避免单个请求占用过多资源导致 OOM；同时在预热阶段，测算当前 GPU 可支撑的 MBP/MBT 最大值，生成 CUDA GRAPHS（优化 CPU-GPU 通信）。

3.2 推理引擎（Inference Engine）：TGI 的「执行者」，负责模型推理与优化

• 模型加载与管理：支持加载 HuggingFace Hub 上的主流 LLM，自动适配模型结构，无需修改模型代码；同时支持多模型并行部署，动态切换模型；
• Prefill/Decode 执行：接收路由器分配的请求，执行 Prefill 阶段的单次前向传播和 Decode 阶段的逐token前向传播，调用 KV 缓存、Flash Attention 等优化逻辑；
• 内存优化：整合 Paged Attention 技术，对 KV 缓存进行分页管理，减少内存移动；同时支持模型量化（如 4-bit/8-bit 量化），降低 VRAM 占用；
• 结果处理与反馈：将 GPU 生成的 tokens 解码为自然语言，反馈给路由器，再由路由器返回给用户；同时记录推理过程中的性能指标（TTFT/TPOT/VRAM 占用），用于监控和调优。

3.3 全流程梳理（以用户请求生成文本为例）

1. 用户发送请求（如「解释什么是 LLM 推理」），路由器接收请求，进行分词预处理；
2. 路由器根据当前批次的令牌预算，将该请求加入正在运行的批次，分配 Prefill 阶段的令牌；
3. 推理引擎接收请求，执行 Prefill 阶段：将分词后的 tokens 传输到 GPU，单次前向传播处理所有输入 tokens，生成第一个输出 token，同时缓存 KV 状态；
4. 推理引擎执行 Decode 阶段：基于第一个输出 token，逐一生成后续 tokens，每次生成后更新 KV 缓存，直至生成 EOS token 或达到 max_new_tokens 限制；
5. 推理引擎将生成的自然语言结果反馈给路由器，路由器返回给用户；同时释放该请求的 KV 缓存和令牌预算，分配给新请求。

四、TGI 实战落地：配置示例与性能调优技巧

4.1 环境准备（前提条件）

• GPU：NVIDIA GPU（需支持 CUDA 11.8+），显存 ≥ 16GB（推荐 24GB+，如 A10、RTX 3090）；
• 软件：Docker、NVIDIA Container Toolkit（用于 Docker 调用 GPU）；
• 模型：HuggingFace Hub 上的 LLM（如 mistralai/Mistral-7B-v0.1，可提前下载到本地，避免部署时重复下载）。

4.2 Docker 部署 TGI（最简配置）

• --gpus all：允许 Docker 调用所有 GPU；
• -p 8080:8080：映射容器端口 8080 到宿主机，用于接收用户请求；
• -v $PWD/data:/data：挂载本地目录到容器，用于缓存模型和日志；
• MODEL_ID：指定 HuggingFace Hub 模型 ID（本地模型可改为本地路径）；
• MAX_BATCH_PREFILL_TOKENS=4096：Prefill 阶段单次最大 tokens 数；
• MAX_BATCH_TOTAL_TOKENS=16384：整体最大并发 tokens 数；
• TENSOR_PARALLEL_SIZE=1：张量并行数（单 GPU 设为 1，多 GPU 设为 GPU 数量）。

4.3 测试 TGI 服务（验证部署成功）

4.4 性能调优技巧（核心，提升延迟与吞吐）

（1）根据 GPU 显存调整令牌预算（最关键）

• 显存 16GB（如 T4）：MBP=2048，MBT=8192，max_new_tokens=512，适合小规模测试；
• 显存 24GB（如 A10）：MBP=4096，MBT=16384，max_new_tokens=1024，适合中小规模生产；
• 显存 40GB+（如 A100）：MBP=8192，MBT=32768，max_new_tokens=2048，适合大规模推理。

（2）开启 Flash Attention / Paged Attention

（3）模型量化（降低显存占用，提升并发）

（4）场景化优化（延迟 vs 吞吐）

• 实时交互场景（聊天、RAG）：优先优化延迟
  • 降低 MBT（如 8192），减少批次内请求数，避免请求等待；
  • 开启 Flash Attention，降低 TTFT/TPOT；
  • 限制 max_new_tokens（如 512），避免长文本生成导致延迟飙升。
• 批量处理场景（文档总结、分类）：优先优化吞吐
  • 提高 MBT（如 32768），增加批次内请求数，充分利用 GPU 资源；
  • 开启 Paged Attention，提升缓存复用率；
  • 采用多 GPU 张量并行（TENSOR_PARALLEL_SIZE=2/4），提升批处理速度。

（5）监控与排查（生产环境必备）

• 延迟指标：text_generation_requests_ttft_seconds、text_generation_requests_tpot_seconds；
• 吞吐指标：text_generation_tokens_throughput；
• 资源指标：text_generation_gpu_memory_used_bytes。

• OOM 报错：降低 MBT、max_new_tokens，开启量化或 Paged Attention；
• 延迟过高：降低 MBT，开启 Flash Attention，检查 GPU 利用率（若过低，可适当提高 MBT）；
• 吞吐过低：提高 MBT，开启 Paged Attention，采用多 GPU 部署。