注：文中数据、价格及工具版本截至2026年10月。
本指南专为初入推理（Inference）领域的平台工程师打造。如果你希望深入理解模型与GPU的协同机制，掌握在生产环境中运行推理服务的关键技能，并了解如何从平台工程师平滑过渡为推理工程师，本文将提供系统性的指导。
1. 为什么是现在？
在积极拥抱AI的组织中，平台团队正逐步演变为推理团队。这一转变主要 driven by 三大因素：编码助手严禁将源代码发送至第三方；前沿模型的API账单逐月激增；以及支持工具需要访问托管模型无法触及的内部数据。
组织倾向于自行运行模型，而开源模型的崛起使这一目标变得切实可行。Hugging Face托管了超过两百万个开源模型，其中头部模型的性能已能与闭源模型抗衡。例如，DeepSeek于2025年1月发布R1，在OpenAI o1发布约一个月后，其在数学和代码基准测试中的表现已与o1持平。
自托管模型赋予企业对延迟、正常运行时间及数据流向的控制权。在高并发场景下，自托管可将成本降低约80%。这项工作需要深厚的平台工程功底：固定水平AI能力的成本每年下降约10倍，这主要得益于模型服务方式的优化，而非单纯依赖更强的GPU。Upbound（Crossplane和Modelplane背后的公司）在Project Champagne项目中验证了这一点：团队发现vLLM和调度机制运行良好，大部分精力实际上消耗在TLS、身份验证、超时处理、存储、IAM及可观测性上。
可迁移的技能
推理工程师的核心职责包括模型选型、GPU部署、服务维持、速度优化、成本控制及故障响应。这本质上是为新工作负载提供SRE（站点可靠性工程）支持，平台工程师的大部分技能可直接迁移：
| 既有技能 | 推理场景应用 |
|---|---|
| 调度和节点池 | GPU放置：利用设备选择器、污点容忍及独占设备策略 |
| 容量规划 | GPU显存计算：需实时检查权重、KV缓存及运行时开销 |
| 负载均衡 | 感知缓存的路由策略及长连接流式传输 |
| CPU自动扩缩容 | 基于队列深度和KV缓存使用率的扩缩容，注意冷启动耗时以分钟计 |
| 发布策略 | 独占GPU发布，管理模型、硬件和引擎版本的复杂矩阵 |
| SLO和延迟百分位 | 关注首字延迟 (TTFT)、每输出令牌时间及有效吞吐量 (Goodput) |
| 可观测性 | 监控引擎指标、真实GPU活动及投机解码接受率 |
| FinOps（财务运营） | 核算每百万令牌成本及每用户会话成本 |
| 身份和访问 | 管理贯穿整个Agent会话周期的凭证 |
在产品早期，使用托管API仍是明智之选。但当API支出成为显著成本项，或对延迟、可靠性的需求超出供应商能力，亦或数据合规要求数据不出网时，自托管的价值便显现出来。2026年8月数据显示，公共招聘板上约有58个开放推理岗位，且职位名称尚未统一。
2. 推理基础
本节按概念出现的逻辑顺序介绍。大多数概念涉及引擎在GPU显存中的数据保留及其速度限制。
什么是推理引擎
推理引擎（如vLLM或SGLang）是将模型权重转换为API服务的服务器。对平台工程师而言，可将其类比为带有附加GPU的状态化数据库服务器：启动时将大型数据集加载至内存，保持会话状态，内部调度工作并通过HTTP响应请求。笔记本电脑上的Ollama是小规模实现，而每个托管模型API背后都运行着此类引擎。
| 数据库/服务概念 | 引擎对应项 |
|---|---|
| 启动加载数据集至缓冲池 | 将模型权重加载至GPU显存，耗时数分钟 |
| 会话存储中的每会话状态 | KV缓存，每个进行中的对话对应一个 |
| 查询计划器和连接池 | 调度器，将请求批处理至每次GPU传递 |
| 客户端已知协议 | 兼容OpenAI或Anthropic的HTTP API |
| 重启后预热缓存 | 冷启动：拉取大型镜像并重新加载权重 |
与数据库不同，引擎的工作集保存在昂贵且容量有限的GPU显存中，因此多数优化旨在决定每个请求分配的显存比例。
推理堆栈
引擎仅是四层架构中的一层：
- 内核 (Kernels)：底层执行算术运算，通常无需直接选择。
- 引擎 (Engine)：核心推理逻辑。
- 控制平面 (Control Plane)：部署和管理多个引擎实例。
- 网关 (Gateway)：顶层，负责在模型和副本间路由流量。
请求流经网关进入引擎，引擎在GPU上运行内核。控制平面负责部署管理，但不直接处理请求数据。
令牌 (Tokens)
令牌是语言模型的基本工作单位，大致相当于一个词或词片段。上下文窗口、价格和速度均以令牌为单位计量。
权重和KV缓存
如同规划数据库占用空间，需分别为固定的权重和随负载增长的KV缓存进行 sizing。
权重是固定占用空间。 大多数模型以每参数2字节（BF16或FP16）发布。例如，一个8B模型需约16GB显存，且必须位于GPU显存而非系统RAM中。在48GB的L40S GPU上，这仅占用约三分之一空间。该数值对用户数量不敏感。
KV缓存是工作集。 为避免重新计算历史，引擎为每个进行中的令牌保留注意力键和值。其大小随上下文长度乘以并发对话数量扩展。可通过以下公式估算：
KV bytes per token = 2 × layers × KV heads × head dimension × bytes per value以FP16格式的Llama 3 70B为例，每个令牌约320KB。一个128K令牌的对话需约40GB缓存，此时KV缓存往往成为单卡服务用户数的瓶颈。
常见Sizing误区：
- 混合专家 (MoE) 模型保留所有权重。 即使激活参数仅18B，总参数320B的模型在FP8格式下仍需约320GB显存。
- 读取检查点大小而非数据类型表。 实际检查点可能因专家以4位格式存储而远小于理论估算。
- 预留运行时开销。 CUDA图、激活值和内存碎片均占用空间，可能导致启动适配的模型在运行几天后耗尽内存。
两个阶段，两个瓶颈
每个请求在GPU上分两个阶段运行，瓶颈各异：
| 阶段 | 功能 | 限制因素 | 关键指标 |
|---|---|---|---|
| Prefill（预填充） | 并行读取输入，生成第一个令牌和KV缓存 | 计算能力 | 首字延迟 (TTFT) |
| Decode（解码） | 逐个令牌生成答案，读取权重及KV缓存 | 内存带宽 | 每输出令牌时间、每秒令牌数 |
由于生成一个令牌仅需少量浮点运算，计算单元常等待内存数据（Data Gravity）。峰值计算能力增速远超内存带宽，因此优化重点在于减少每令牌字节数或分摊字节成本。加速其中一个阶段的技术往往对另一个作用有限，故基准测试需分别报告TTFT和每秒令牌数。
需跟踪的指标
| 指标 | 测量内容 | 注意事项 |
|---|---|---|
| 首字延迟 (TTFT) | 用户看到内容前的等待时间 | 需测量用户可见的第一个令牌，排除隐藏“思考”过程 |
| 每输出令牌时间 | 解码速度 | 反映投机解码和内存带宽影响 |
| 每用户每秒令牌数 | 交互性（“打字”速度） | 随批次大小增加而下降 |
| 吞吐量 | 总每秒令牌数 | 随批次大小增加而上升 |
| 有效吞吐量 (Goodput) | 满足延迟目标的吞吐量 | 容量规划的关键数字 |
| 端到端延迟 | 总请求时间 | 取决于生成长度，长任务190秒属正常 |
| 百分位 | p50, p90, p99延迟 | 用户感受的是尾部延迟 |
| 错误和拒绝 | 失败或被拒请求 | 将拒绝计为错误，避免误判 |
| 每百万令牌成本 | GPU成本/服务令牌数 | 需在真实负载下对比 |
成本计算公式：
Cost per million tokens = GPU cost per hour / (tokens per second × 3600) × 1,000,000延迟与吞吐量
批处理可提高总吞吐量但降低单用户速度。交互式应用偏好低延迟，批量作业偏好高吞吐量。需在调整前明确工作负载约束。
何时采用各概念
| 概念 | 功能 | 采用信号 |
|---|---|---|
| 适配权重 | 选择模型、精度和GPU | 引擎启动失败或KV缓存剩余极少 |
| 连续批处理和分页KV缓存 | 共享请求，小块分发缓存 | vLLM/SGLang默认启用，检查即可 |
| 量化 (Quantization) | 减少权重位数，释放内存给KV缓存 | 请求排队但GPU计算闲置 |
| 前缀缓存 | 重用重复提示的工作 | 客户端发送长历史（Agent/聊天），监控命中率 |
| 投机解码 | 草拟并验证多个令牌 | 低负载下单个响应流式传输过慢 |
| 网关和控制平面 | 路由及管理引擎 | 添加第二个模型、副本或集群 |
| 跨GPU分片 | 拆分大模型 | 模型无法适配单张GPU，需提前规划 |
| 自动扩缩容 | 动态增减副本 | 闲置GPU产生费用或高峰队列堆积 |
| 解耦 (Disaggregation) | 分离预填充和解码 | 长提示阻塞流式传输且拥有RDMA网络 |
Agent带来的变化
编码Agent等工作负载带来新特征：
- 提示极长：中位59K令牌，p90达125K。
- 高度重复：约三分之二提示令牌命中前缀缓存。
- 隐藏思考：推理模型可能在首个可见令牌前思考超一分钟，需调整超时设置。
- 负载依赖客户端：短提示会话可能启动子Agent，保持更多飞行中请求，应按飞行请求数而非席位规划容量。
- 长会话：持续数小时，需保持流、工具调用和凭证有效。
3. 在生产中运行推理
生产环境需在延迟、吞吐量、成本和质量间权衡，且常面临GPU资源不足。
3.1 从用例出发，而非硬件
- 编码Agent：需长上下文、可靠工具调用、流式传输及Anthropic兼容API。
- 聊天：需低首字延迟、真并发及OpenAI兼容API。
- 平台：需TLS、身份绑定、可观测性及自动化放置。
将交互式与批量工作负载分开部署。测试前明确通过/失败界限。
3.2 谨慎选择模型
- 自有任务评估：公开基准未必适用，需自行评估。
- 从小处着手：小型MoE模型出错成本低，利于积累经验。
- 最新非最佳：新模型可能硬件需求过高，旧模型或许更具性价比。
- 验证加载能力：发行说明支持不代表实际硬件能加载。
- 检查许可证：确认是否限制商业用途。
- 检查模板和解析器：错误设置会导致工具调用失效。
3.3 为运行时Sizing，而非启动时
- 预算三项成本：权重、KV缓存及运行时开销（CUDA图等）。
- 监控内存设置：实际流量可能超出启动估计。若出现OOM，降低内存分数、启用可扩展段并限制并发序列。
- 限制请求：设置最大输出长度，防止单请求拖垮服务。
- 谨慎缩短上下文：虽释放KV缓存，但会拒绝长对话，需计为错误。
3.4 了解优化技术
| 技术 | 改进内容 | 成本/风险 | 使用时机 |
|---|---|---|---|
| 连续批处理 | 吞吐量提升显著 | 每用户速度随批次增大下降 | 始终使用（默认） |
| 分页KV缓存 | 降低缓存浪费率至4%以下 | 几乎无 | 始终使用（默认） |
| 前缀缓存 | 降低重复提示的TTFT和成本 | 仅在首个不同令牌前有效 | 系统提示、RAG、Agent |
| 权重量化 | 加速解码，FP8加速预填充 | 潜在质量损失，需测量 | 硬件原生支持且评估接受 |
| KV缓存量化 | 容纳更多缓存，移动更快 | 误差累积 | KV缓存成为瓶颈时 |
| 投机解码 | 低批次下提升每秒令牌数 | 猜测拒绝时浪费计算 | 延迟敏感且输出可预测 |
| 张量并行性 | 适配大模型，提升单用户速度 | 需NVLink等高速互联 | 节点内大模型 |
| 专家并行性 | 提升MoE吞吐量 | 路由开销 | MoE模型 |
| 流水线并行性 | 跨节点适配模型 | 增加延迟 | 模型无法适配单节点 |
| 预填充和解耦 | 消除阶段干扰，提升请求量 | 需RDMA网络 | 大规模、长提示、快速互联 |
经验法则：
- 构建提示结构：共享内容前置，变量后置，以利用前缀缓存。
- 量化顺序：从线性权重开始，最后才是KV缓存。保持敏感部分高精度。
- 监控投机解码：接受率崩溃会导致性能下降。
- 警惕相互作用：一次更改一件事并测量。
- 防止长提示阻塞：启用分块预填充。
3.5 获取GPU并正确放置
- 配额非容量：配额仅允许请求，不保证实例可用。
- 灵活设计：允许多区域池，模型定义独立于实例类型。
- 明确匹配：使用Kubernetes DRA设备选择器固定模型到特定GPU架构或内存。
- 监控云端：跟踪实例和节点加入情况。
- 了解互联：SXM GPU使用NVLink，PCIe卡通过主机内存通信，影响并行策略选择。
- 系统池Sizing：为监控、控制器和网关预留通用容量。
3.6 网关、路由和超时
- 拒绝轮询：使用感知缓存或前缀的路由。
- 按模型名称路由：单主机名服务多模型。
- 支持主流API：OpenAI及Anthropic Messages API。
- 提高超时：长生成任务需调整路由、负载均衡器及网关超时。
- 检测截断流：防止返回HTTP 200但停止生成的假成功。
- 计量使用：基于令牌速率限制防止资源滥用。
3.7 安全和身份
- 封闭端点：在网关获取地址前应用认证策略。
- 真实TLS：在真实主机名上使用TLS并管理证书。
- 三类客户端：人类（OIDC）、浏览器（网关处理登录）、Agent（长期有效API密钥）。
- 避免会话叠加：防止外部网关会话过期导致停机。
- 测试拒绝策略：构建探测矩阵测试无效请求。
- 身份带入日志：记录调用者身份，覆盖伪造标头。
- 权重视为代码：使用safetensors，禁用远程代码，固定版本。
3.8 可观测性
- 抓取引擎指标：配置ServiceMonitor等收集Prometheus指标。
- 核心面板：监控并发、队列、KV缓存、TTFT、错误率等。
- 服务器端质量测量：计数工具调用失败、截断响应及空输出。
- 超越GPU-Util：同时绘制SM活动和张量活动图。
- 区分缓慢类型：排队、隐藏推理或生成缓慢。
- 监控监控器：确保指标数据新鲜且到达。
- 保留调试日志：包含调用者的访问日志及崩溃前日志。
- 标准化指标：统一不同引擎的指标名称。
SLO设置：响应迅速（TTFT）、足够快（每输出令牌时间）、已回答（无错误且工具调用解析）。
3.9 自动扩缩容和冷启动
- 基于推理信号：队列深度、KV缓存使用及飞行请求数。
- 结合流量和负载：流量预判，负载滞后。设置最小/最大副本及缩容延迟。
- 应对冷启动：权重加载耗时久，建议在共享存储缓存权重。
- 谨慎缩容至零：尖峰可能已过，GPU容量稀缺。
- 多集群规划：数百GPU以上需跨区域/提供商调度，统一控制平面。
3.10 变更管理
- 跟踪版本矩阵：模型、硬件和引擎构建。
- 独占GPU发布：使用Recreate策略或允许不可用，预算停机时间。
- 就绪非可路由：网关可能滞后于就绪副本。
- 测试服务更改：像代码一样管理，一次更改一件事，先写界限。
- 分层推广：离线验证 → 排练 → 冒烟测试 → 带评估负载测试 → 金丝雀发布 → 全面发布。
3.11 质量和评估
开源模型得分低时，先检查：
- 测试框架：是否损坏？运行当前托管模型基线。
- 基础设施：超时或路由错误是否被标记为“未测量”？
- 评分器：是否衡量了正确结果？优先确定性检查。
固定正确答案依赖数据，多次运行测试，预期方差。
3.12 事故和调试
- 预期静默故障：截断流返回200，指标API无数据。
- 看持续时间：整秒故障多为超时，倍数指向重试。
- 绕过一层：隔离问题跳点。
- 验证实态：检查磁盘、实例或路由本身。
- 增量修复：变通方法标记为拆除，修复上游化。
首次用户前清单
- 定义用例及界限（首字时间、速度、错误率）。
- 基于评估选择模型，以托管模型为基线。
- 确认引擎能在硬件上加载模型。
- 内存预算涵盖权重、KV缓存及开销，设置最大输出和并发。
- 验证GPU放置，有备用方案。
- 应用认证策略，使用真实TLS。
- 凭证覆盖Agent全会话周期。
- 提高各跳点超时设置。
- 抓取引擎指标，监控GPU活动，设置指标缺失警报。
- 服务器端计数失败，避免用户报警。
- 建立拒绝请求探测矩阵。
- 制定独占GPU发布策略及停机预算。
- 保留崩溃前日志。
- 服务更改分层推广，金丝雀发布设回滚触发器。
- 变通方法标记拆除，修复上游化。
4. 堆栈
深入学习引擎，熟悉Kubernetes、网关和可观测性在推理中的变化。
| 层级 | 需了解工具 | 首要掌握 |
|---|---|---|
| Kubernetes上的GPU | NVIDIA GPU Operator, DRA, DCGM exporter | GPU广告、请求和放置 |
| 内核和库 | CUDA, PyTorch, Triton, FlashAttention | 内核基础、融合及配置文件阅读 |
| 推理引擎 | vLLM, SGLang, TensorRT-LLM, Ollama | vLLM核心标志及并行、量化、缓存设置 |
| 分布式服务 | NVIDIA Dynamo, llm-d, KServe | 多GPU/节点布局及解耦 |
| 网关和路由 | Envoy Gateway, Agent Router, Gateway API Inference Extension | 流式传输、超时、认证及缓存路由 |
| 控制平面 | Modelplane (based on Crossplane) | 声明式集群、硬件、部署及缓存管理 |
| 可观测性 | Prometheus, Grafana, OpenTelemetry, Sloth/Pyrra | 引擎指标、GPU活动及延迟SLO |
| 基准测试 | vLLM bench, AIPerf, GuideLLM, AgentX | 真实提示下的并发扫掠及延迟百分位 |
| 评估 | Inspect, Hugging Face tools | 确定性评分器 |
| 模型 | Hugging Face Hub, safetensors | 阅读模型配置及检查文件大小 |
选择引擎
| 引擎 | 选择原因 | 运营成本 |
|---|---|---|
| vLLM | 模型覆盖广，开箱即用OpenAI/Anthropic API，首选部署 | 频繁发布新标志，需固定版本并重新基准测试 |
| SGLang | 基数树前缀缓存及共享缓存调度，适合Agent和长会话 | 社区较小，新模型可能需每晚构建 |
| TensorRT-LLM | NVIDIA硬件优化内核，包括Blackwell FP4 | 仅限NVIDIA硬件，绑定供应商 |
| NVIDIA Dynamo | 协调多节点，支持解耦 | 分布式系统复杂度，仅多节点规模使用 |
| Ollama, llama.cpp | 本地学习和原型设计 | 非高并发设计 |
Hugging Face TGI已进入维护模式，使用前需检查支持情况。引擎更新频繁，升级时需重新基准测试。
Modelplane的位置
Modelplane是Upbound基于Crossplane开发的开源项目，使用类Kubernetes声明式API编排推理基础设施。它将工作分为三层：
| 角色 | 拥有 | Modelplane资源 |
|---|---|---|
| 平台团队 | 舰队：集群、硬件类别、网关 | InferenceCluster, InferenceClass, InferenceGateway |
| 模型操作员/推理工程师 | 模型：部署、服务、权重缓存 | ModelDeployment, ModelService, ModelCache |
| Modelplane | 中间层组合 | ModelEndpoint, ModelReplica |
Modelplane自动映射不同引擎指标，便于统一评估。
建议的学习堆栈顺序
- 单机GPU运行vLLM，读取指标。
- Kubernetes部署，使用设备选择器。
- 前置网关，配置TLS、认证及长流超时。
- 抓取指标至Prometheus，构建核心面板。
- 并发扫掠基准测试，运行小型评估套件。
- 切换SGLang，对比真实流量表现。
- 尝试张量/流水线并行及分布式服务层。
- 学习CUDA及配置文件，理解内核差异。
5. 从分享工作的团队中学习
如何阅读案例研究
- 找到设置：模型、硬件、版本及流量形状，注意日期。
- 找到界限：成功标准及决策者。
- 跟随故障：故障现象、发现方式及检测时长。
- 检查方法：是否单次变更并测量？
- 分离可转移内容：通用教训 vs 特定配置。
案例研究：Project Champagne (2026)
Upbound自托管聊天、编码Agent及CVE修复Agent的经验总结：
- 服务非难点：vLLM和调度工作正常，TLS、身份、超时等耗时较多。
- 配额非容量：获批配额未必能实例化，需多区域分散。
- 启动适配不足：干净适配模型仍可能OOM，需调整内存分数及并发限制。
- 静默故障昂贵：截断流返回200，指标API假死。
- 超时叠加：路由默认值与负载均衡器空闲超时切断流式回答。
- Agent最难伺候：长会话超出令牌生命周期，隐藏思考时间长。
- 低分非模型错：测试框架错误或超时导致失败。
- 缓慢多因：隐藏推理或GPU利用率虚高。
- 负载依赖客户端：Agent提示长且重复，短提示会话飞行请求多。
- 引擎重要：从vLLM切换SGLang增益最大，128K上下文限制因拒绝长对话而显得快。
6. 职业转变
无需重新开始，结合现有平台技能与推理概念，公开展示工作。
选择一个方向
| 方向 | 重点 | 适合人群 |
|---|---|---|
| 推理平台 | 集群、GPU调度、网关、自动扩缩容 | 喜欢Kubernetes和分布式系统 |
| 推理可靠性 | SLO、可观测性、容量规划、事故响应 | 有SRE实践经验 |
| 运行时性能 | 引擎调整、量化、投机解码、内核 | 喜欢配置文件和接近硬件 |
遵循学习路径
- 学习模型：Transformer基础、KV缓存、MoE，能快速估算内存需求。
- 深入引擎：精通vLLM核心标志，测量延迟。
- 翻译平台技能：设备分配、网关、自动扩缩容及可观测性。
- 判断质量和成本：构建评估，运行容量扫掠，计算每百万令牌成本。
构建证明你的项目
| 项目 | 证明什么 | 发布什么 |
|---|---|---|
| 单机vLLM服务8B模型，扫掠并发 | 准确测量TTFT、延迟和吞吐量 | 配置、脚本、图表及成本 |
| 预测并测试GPU容纳会话数 | 理解权重、KV缓存及开销 | 预测、结果及差异分析 |
| 比较FP16、FP8及4位格式 | 权衡质量和速度 | 评估分数、延迟及吞吐量 |
| 前后置共享内容运行提示 | 理解前缀缓存和提示结构 | 缓存命中率及TTFT |
| Kubernetes部署全套设施 | 平台化运行推理 | 清单、组成及仪表板 |
| Agent流量对比vLLM和SGLang | 数据驱动引擎选择 | 界限、方法及结果区间 |
| 构建确定性评分器评估框架 | 区分模型和框架故障 | 任务、评分器及负控制 |
| 重现故障（超时/OOM/发布卡住） | 操作而不仅是部署 | 事故报告及运行手册 |
公开展示你的工作
- README如实验报告：陈述问题、设置、方法、结果及复现步骤。
- 发布失败：清晰描述故障展示技能。
- 固定版本及成本：增强结果可信度。
- 写作和演讲：提交会议及社区活动。
贡献开源
推理项目急需平台工作贡献：
- 运行并报告问题：附带复现步骤和数字。
- 编写文档：部署、调整及故障排除指南。
- 添加指标和警报：使静默故障可见。
- 改进清单和图表：适配真实环境。
- 贡献基准配方：针对特定硬件。
持续学习
- 阅读发行说明：每次升级重新基准测试。
- 阅读核心论文：Orca, PagedAttention, DistServe, 投机解码, FlashAttention。
- 阅读《推理工程》：Philip Kiely著，Baseten免费电子书。
- 关注从业者：The Pragmatic Engineer, ByteByteGo, Data Gravity等。
- 学习评估：Anthropic及Hamel Husain等资源。
- 学习经济学：向财务伙伴解释成本。
寻找职位
职位名称不一：推理工程师、性能工程师、模型服务工程师、ML基础设施工程师等。薪资反映稀缺性：2026年8月，Anthropic推理性能职位薪资$350,000-$850,000，OpenAI同等职位$295,000-$555,000。若公司计划自托管，主动请缨以获得直接经验。
准备面试
练习回答以下问题：
- 预填充和解码：为何解码受内存带宽限制？长上下文影响？
- 硬件趋势：计算增速快于内存带宽，推理会变为计算受限吗？
- 内存数学：给定上下文和并发，模型及KV缓存需多少内存？
- 有效吞吐量：定义及为何用于容量规划？
- 前缀缓存：哪些应用受益最多？
- 精度：两台80GB GPU服务70B模型，选何精度及原因？
- 量化：何时仅权重量化加速？何时不？
- 投机解码：何时不使用？
- 分块预填充：长提示如何减缓其他用户？分块预填充作用？
- 并行性：给定模型和GPU，选何种并行策略？张量vs流水线？
- 配置文件：如何判断计算受限还是内存带宽受限？
- 调试“慢”：p99 TTFT飙升，如何区分排队、隐藏推理和生成缓慢？
- 成本：每百万令牌成本及与托管API对比？
- 容量规划：用户增长10倍，如何规划？
- 发布和SLO：如何安全发布新模型？设置何种SLO？
- 失败故事：描述带数字的故障，涵盖问题、发现及解决。