1. AI 系统性能工程的核心命题：从单点优化到全链路治理
做 AI 系统性能工程这件事，最怕的就是把它当成单纯的“调参”或者“加机器”。我见过太多团队在模型上线之后发现延迟飙高、吞吐上不去、GPU 利用率长期趴在 30% 以下，第一反应就是“模型太大了，换个小模型吧”，或者“再加两张卡”。这些做法有时候能缓解症状，但绝大多数情况下，问题根本不在模型本身，而在于整个系统的性能链路没有被系统性地拆解过。
AI 系统性能工程的核心命题，是把一个 AI 应用从数据进入、预处理、推理计算、后处理到结果返回的完整链路，当成一个端到端的系统来对待。它跟传统后端性能工程最大的区别在于：传统服务的瓶颈通常在 IO 或数据库，而 AI 系统的瓶颈可能在任何一个环节——可能是数据预处理阶段的 CPU 解码，可能是 GPU 显存带宽，可能是推理框架的调度策略，也可能是服务化层的排队逻辑。你如果不把整条链路拆开看，永远不知道真正的瓶颈在哪里。
这篇文章适合三类人看：第一类是做 AI 应用开发但总觉得“跑得不够快”的工程师；第二类是需要对 AI 服务做容量规划和成本控制的架构师；第三类是对性能工程感兴趣、想了解 AI 系统特殊性的后端开发者。不管你现在用的是哪家的大模型、哪个推理框架，下面这些思路和方法论都是通用的。
2. 性能指标体系怎么建：别只看延迟和吞吐
2.1 四个核心指标的定义与关系
做性能工程的第一步永远是建立指标体系。没有指标，优化就是盲人摸象。AI 系统的性能指标比传统服务要复杂一些，因为多了 GPU 这个维度。我一般会从四个核心指标入手：
端到端延迟（E2E Latency）：从请求发出到收到完整响应的总时间。这个指标用户感知最直接，但它太粗了，出问题的时候没法定位。所以必须拆成首 Token 延迟（TTFT，Time To First Token）和Token 间延迟（TPOT，Time Per Output Token）。对于流式输出的场景，TTFT 决定了用户觉得“这个系统反不反应得过来”，TPOT 决定了用户觉得“输出流不流畅”。
吞吐量（Throughput）：单位时间内系统能处理的请求数或生成的 Token 数。这里有个关键区分——是请求级吞吐还是Token 级吞吐。对于生成式任务，Token 级吞吐更能反映系统的真实处理能力，因为不同请求的输出长度可能差很多。
GPU 利用率：包括计算利用率（SM Occupancy）和显存带宽利用率。很多人只看计算利用率，但实际上很多 AI 推理任务是显存带宽瓶颈而不是计算瓶颈。你看到 GPU 计算利用率只有 40%，不一定是调度问题，可能是数据搬运把带宽吃满了。
资源效率比：每瓦功耗或每美元成本能产出多少有效 Token。这个指标在规模化部署的时候特别重要，因为它直接决定了你的单位经济模型能不能跑通。
2.2 指标之间的权衡关系
这四个指标不是独立的，它们之间存在明确的权衡关系。你压低延迟，通常要牺牲吞吐；你提高吞吐，延迟就会上升。这不是工程做得不好，而是排队论的基本规律。
我一般会用一个简单的框架来帮团队理清权衡：
| 优化目标 | 主要手段 | 代价 |
|---|---|---|
| 降低 TTFT | 减少批处理大小、优先级调度 | 吞吐下降、GPU 利用率降低 |
| 提高吞吐 | 增大批处理、连续批处理 | 延迟上升、显存压力增大 |
| 降低 TPOT | 量化、投机解码、KV Cache 优化 | 精度可能下降、实现复杂度上升 |
| 提高资源效率 | 动态批处理、弹性伸缩 | 系统复杂度上升、冷启动问题 |
这张表的关键在于：没有免费的优化。每次你想动一个指标，先想清楚愿意在哪个维度上付出代价。我见过太多人试图同时优化所有指标，最后什么也没优化成。
2.3 怎么设定合理的性能目标
设定性能目标不能拍脑袋。我的做法是分三步：
第一步，确定业务可接受的下限。比如一个对话系统，TTFT 超过 2 秒用户就会觉得卡，TPOT 超过 100ms 用户就会觉得输出一顿一顿的。这些是从用户体验反推出来的硬约束。
第二步，测算当前系统的理论上限。根据模型大小、硬件规格、推理框架的效率，算出一个理论上的最优值。比如一个 7B 模型在 A100 上做 FP16 推理，理论 TTFT 大概在多少，这个是可以估算的。
第三步，在理论值和业务下限之间找一个工程上可达的目标。通常我会把目标定在理论值的 60% 到 70% 左右，留出余量给突发流量和系统抖动。
注意：性能目标一定要跟业务方对齐。我踩过的坑是技术团队自己定了一个很激进的延迟目标，结果为了达标把批处理压得很小，GPU 利用率惨不忍睹，成本翻了三倍，业务方根本不买单。性能工程永远是在延迟、吞吐、成本之间找平衡，不是单维度刷榜。
3. 推理链路的性能拆解：从请求进入到结果返回
3.1 请求预处理阶段的隐藏开销
很多人做性能分析的时候，眼睛只盯着 GPU，觉得只要 GPU 跑满了就没问题。但实际上，请求预处理阶段的开销经常被严重低估。
一个典型的 AI 推理请求，在进入 GPU 之前要经过这些步骤：网络接收、协议解析、鉴权校验、请求排队、Tokenization、输入拼接（比如 System Prompt 拼接）、Batch 组装。这些步骤看起来都很轻，但叠加起来在高压场景下可能占到端到端延迟的 20% 到 40%。
我实测过一个案例：一个对话服务，GPU 推理本身只花了 80ms，但端到端延迟是 200ms。用火焰图一查，发现 Tokenization 花了 30ms，System Prompt 拼接花了 20ms，剩下的时间花在排队和网络传输上。Tokenization 慢是因为用的分词器没有做缓存，每次都在重新加载词表。System Prompt 拼接慢是因为每次都在做字符串拼接而没有预编译。
这类问题的排查方法很简单：在链路的每个关键节点打时间戳，算出各阶段的耗时占比。不要靠猜，要靠数据。我一般会在网关层、预处理层、推理层、后处理层各打一个时间戳，然后聚合分析。
3.2 批处理策略的选择与调优
批处理是 AI 推理性能优化最核心的手段，没有之一。但批处理不是越大越好，也不是所有场景都适合。
静态批处理是最简单的方案：攒够 N 个请求一起送进 GPU。优点是实现简单，GPU 利用率高。缺点是延迟不可控——第一个请求可能要等最后一个请求到了才能开始处理。对于延迟敏感的场景，静态批处理基本不可用。
动态批处理稍微好一点：设定一个最大等待时间窗口，窗口内到的请求攒成一批。这样延迟有上限，但吞吐会受流量波动影响。流量低谷的时候批处理大小上不去，GPU 利用率就下来了。
连续批处理（Continuous Batching）是目前生成式模型推理的主流方案。它的核心思想是：不等一整批请求全部完成，而是每生成一个 Token 就检查有没有请求完成、有没有新请求可以加入。这样 GPU 几乎不会空转，吞吐和延迟的平衡也更好。vLLM 和 TensorRT-LLM 都支持这种模式。
我选批处理策略的经验是：
- 离线批量任务：静态批处理，批大小拉满，追求最大吞吐
- 在线对话服务：连续批处理，配合优先级队列
- 混合场景：分队列处理，离线任务用低优先级队列，在线任务用高优先级队列
批大小的调优有个经验公式：从显存容量的 70% 反推最大批大小，然后在这个范围内做压测，找到延迟和吞吐的拐点。拐点通常在 GPU 计算利用率达到 85% 到 90% 的位置。超过这个点之后，延迟会急剧上升，而吞吐增长非常有限。
3.3 KV Cache 的管理与优化
KV Cache 是生成式模型推理的显存大户。以 LLaMA 2 7B 为例，FP16 精度下，每个 Token 的 KV Cache 大约占 0.5MB。如果并发 32 个请求，每个请求平均输出 512 个 Token，光 KV Cache 就要占 8GB 显存。这还没算模型权重和中间激活值。
KV Cache 的优化手段主要有几个方向：
PagedAttention是目前最主流的方案，vLLM 就是靠这个打出了名气。它的核心思想借鉴了操作系统的虚拟内存分页机制：把 KV Cache 切成固定大小的 Block，按需分配，不要求连续显存。这样显存碎片率大幅降低，同样显存能支持的并发数能提升 2 到 4 倍。
KV Cache 量化是另一个方向。把 KV Cache 从 FP16 量化到 INT8 甚至 INT4，显存占用直接减半或减到四分之一。代价是精度会有轻微下降，但在大多数对话场景下用户感知不到。我实测过 INT8 量化，困惑度上升不到 0.1，但并发能力翻倍。
Prefix Caching对 System Prompt 很长的场景特别有用。如果多个请求共享同一段 System Prompt，那这段 Prompt 的 KV Cache 可以复用，不用每个请求都重新算一遍。这个优化在多轮对话和 Agent 场景下效果非常明显。
实操心得：KV Cache 的显存分配一定要留余量。我踩过的坑是把显存算得刚刚好，结果流量高峰时新请求进不来，已经在处理的请求又因为显存不足被中断，整个服务雪崩。后来我固定留 15% 到 20% 的显存作为缓冲，稳定性好了很多。
4. 模型层面的性能优化：量化、蒸馏与编译
4.1 量化方案的选型与实测对比
量化是模型推理加速最直接的手段。但量化的水很深，不同方案的效果差异很大。
训练后量化（PTQ）是最常用的方案，不需要重新训练，直接对训练好的模型做量化。GPTQ、AWQ、SmoothQuant 都是这个路子的。优点是实现简单、成本低；缺点是在低比特（比如 4bit 以下）时精度损失比较明显。
量化感知训练（QAT）是在训练过程中模拟量化误差，让模型自己适应量化。精度保持得更好，但需要重新训练，成本高。一般只在 PTQ 效果不达标的时候才考虑。
我实测过几个主流方案在 7B 模型上的表现：
| 量化方案 | 比特数 | 显存节省 | 推理加速 | 精度损失（困惑度） |
|---|---|---|---|---|
| FP16 基线 | 16 | 0% | 1.0x | 0 |
| GPTQ | 4 | 75% | 2.3x | +0.3 |
| AWQ | 4 | 75% | 2.5x | +0.2 |
| SmoothQuant | 8 | 50% | 1.8x | +0.05 |
| INT8 PTQ | 8 | 50% | 1.9x | +0.08 |
从表里能看出来，4bit 量化的加速比最高，但精度损失也最大。8bit 量化是个比较稳妥的选择，精度损失小，加速比也不错。我的建议是：对话类应用优先考虑 8bit，对精度不敏感的场景可以上 4bit。
4.2 投机解码的适用场景
投机解码（Speculative Decoding）这两年被讨论得很多，但很多人对它的适用场景有误解。
它的核心思想是：用一个小模型（Draft Model）快速生成多个候选 Token，然后用大模型（Target Model）一次性验证这些 Token 对不对。如果对了，就相当于大模型一次生成了多个 Token，速度就上去了。
但这里有个关键前提：Draft Model 的生成速度必须远快于 Target Model，而且 Draft 的准确率要足够高。如果 Draft Model 太慢，或者猜中的概率太低，那投机解码反而会拖慢整体速度。
我实测下来的经验是：投机解码在输入输出比较确定的场景下效果最好，比如代码生成、翻译、摘要。在开放式对话场景下，因为下一个 Token 的不确定性太高，Draft Model 猜中的概率低，加速效果就不明显。
另外，投机解码会增加显存占用，因为要同时加载两个模型。如果显存本来就紧张，上投机解码可能得不偿失。
4.3 模型编译与图优化
模型编译是把推理图做算子融合、内存规划、内核选择的过程。PyTorch 2.0 的torch.compile、TensorRT、ONNX Runtime 都提供了这类能力。
图优化能带来的收益主要来自几个方面：算子融合减少了内核启动开销和显存读写；内存复用降低了峰值显存占用；内核自动调优针对具体硬件选择最优实现。
我一般会在模型确定之后、上线之前做一轮编译优化。实测下来，TensorRT 在 NVIDIA GPU 上的加速比通常在 1.3x 到 2x 之间，具体取决于模型结构和输入形状的稳定性。如果输入形状变化很大，TensorRT 的优势会打折扣，因为它的优化是跟形状绑定的。
注意：模型编译不是一劳永逸的。每次模型更新、推理框架升级、CUDA 版本变化，都需要重新编译和验证。我建议把编译过程纳入 CI/CD 流程，每次模型变更自动触发编译和性能回归测试。
5. 服务化与调度层的性能工程
5.1 推理服务的部署架构选型
推理服务的部署架构直接决定了系统的弹性能力和资源效率。常见的架构有三种：
单模型单服务：每个模型独立部署一个服务。优点是隔离性好、故障不扩散；缺点是资源利用率低，每个服务都要预留峰值资源。
多模型共享服务：多个模型跑在同一个服务里，共享 GPU 资源。优点是资源利用率高；缺点是隔离性差，一个模型出问题可能影响其他模型。
模型路由 + 弹性伸缩：前面加一个路由层，根据请求特征路由到不同的模型实例，实例数根据负载动态调整。这是目前大规模部署的主流方案，兼顾了资源效率和隔离性。
我选架构的原则是：先看流量特征，再看资源预算。流量稳定且模型单一，单模型单服务就够了；流量波动大或者模型多，就上路由加弹性伸缩。
5.2 请求队列与优先级管理
请求队列的设计对延迟指标影响很大。FIFO 队列最简单，但没法区分请求的紧急程度。实际生产环境里，我一般会用多级优先级队列：
- 实时队列：对话类请求，延迟敏感，优先级最高
- 普通队列：批量推理请求，延迟不敏感，优先级中等
- 后台队列：离线任务，优先级最低，只在系统空闲时处理
队列之间要有抢占机制：高优先级队列有请求时，可以抢占低优先级队列正在使用的资源。但抢占不能太粗暴，否则低优先级任务永远做不完。我一般会设置一个最小资源保障，确保低优先级队列至少能拿到 10% 到 20% 的资源。
队列深度也需要控制。队列太浅，突发流量来了直接拒绝请求；队列太深，请求排队时间过长，端到端延迟失控。我的经验值是：队列深度设置为系统平均处理能力的 2 到 3 倍，超过这个深度的请求直接返回限流响应，让客户端重试。
5.3 自动扩缩容的策略与陷阱
自动扩缩容是控制成本的关键手段，但 AI 服务的扩缩容比传统 Web 服务要复杂得多。
传统 Web 服务扩容就是加实例，启动时间通常几秒到几十秒。AI 推理服务扩容要加载模型权重、初始化 CUDA 上下文、编译推理图，启动时间可能几分钟甚至十几分钟。这意味着扩容决策必须提前，不能等负载上来了才扩。
我的做法是基于预测式扩容 + 反应式扩容的组合策略：
- 预测式扩容：根据历史流量模式，提前 10 到 15 分钟扩容。比如每天上午 9 点流量开始上升，那 8 点 45 分就开始扩容。
- 反应式扩容：监控队列深度和 GPU 利用率，超过阈值立即触发扩容，作为预测式扩容的补充。
缩容比扩容更危险。缩容太快，流量反弹时来不及扩容；缩容太慢，资源浪费。我一般会设置一个缩容冷却期，比如 15 分钟内负载持续低于阈值才触发缩容，而且每次缩容不超过当前实例数的 25%。
踩坑记录：有一次我设置了一个比较激进的缩容策略，结果下午流量突然反弹，扩容来不及，服务直接过载。后来我把缩容冷却期从 5 分钟调到 20 分钟，并且加了缩容前的流量预测检查，再也没出过类似问题。
6. 性能测试与压测方法论
6.1 压测场景的设计原则
AI 系统的压测跟传统服务压测有个本质区别：请求之间的相互影响更大。因为批处理的存在，一个请求的延迟会受到同批次其他请求的影响。所以压测场景的设计要特别小心。
我设计压测场景的时候会覆盖这几类：
稳态压测：固定并发数，持续跑 10 到 30 分钟，观察系统在稳定状态下的延迟和吞吐。这是基线测试，用来确定系统的稳态性能。
阶梯压测：并发数从低到高逐步增加，每个阶梯跑 5 分钟，观察系统在不同负载下的表现，找到性能拐点。
突发压测：瞬间把并发数拉到峰值的 2 到 3 倍，持续 1 到 2 分钟，测试系统的抗突发能力。
长尾压测：模拟少量超长请求（比如输出 4096 个 Token）和大量短请求混合的场景，测试系统在混合负载下的公平性。
压测数据要记录完整的延迟分布，不能只看平均值。P50、P90、P95、P99 都要看。AI 系统的延迟分布通常是长尾的，P99 可能是 P50 的 5 到 10 倍。如果只看平均值，会严重低估用户的真实体验。
6.2 压测工具的选择与配置
压测工具的选择取决于你的协议和场景。如果是 HTTP 接口，Locust、wrk、k6 都能用。如果是 gRPC 接口，ghz 或者自己写客户端。
我比较推荐用Locust，因为它是 Python 写的，跟 AI 生态比较近，自定义压测逻辑很方便。比如你要模拟不同输入长度的请求，或者模拟流式输出的消费行为，用 Locust 写起来很顺手。
压测客户端本身不能成为瓶颈。我见过有人用单机跑压测，结果压测机的 CPU 先跑满了，测出来的数据根本不准。压测机的配置至少要跟被测服务在一个量级，或者用多台压测机分布式压测。
另外，压测流量要跟生产流量特征对齐。输入长度分布、输出长度分布、请求间隔分布，这些都要尽量模拟真实情况。如果压测用的都是短请求，测出来的性能会明显好于真实场景。
6.3 性能回归与持续监控
性能工程不是一次性的工作，而是持续的过程。每次模型更新、代码变更、配置调整，都可能引入性能回归。所以必须建立性能回归测试和持续监控机制。
我的做法是：
- 建立性能基线：在系统稳定运行的时候，记录一组标准压测场景的性能数据作为基线。
- CI 中集成性能测试：每次代码合并前，跑一轮轻量级性能测试，跟基线对比。如果关键指标退化超过 10%，阻止合并。
- 生产环境持续监控：用 Prometheus + Grafana 监控 TTFT、TPOT、吞吐、GPU 利用率等核心指标，设置告警阈值。
- 定期全量压测：每周或每两周做一次全量压测，更新性能基线，发现潜在的性能退化趋势。
监控指标要区分症状指标和根因指标。TTFT 和 TPOT 是症状指标，用户能感知到；GPU 利用率、队列深度、显存占用是根因指标，用来定位问题。告警应该主要基于症状指标，但排查问题时要看根因指标。
7. 常见性能问题与排查实录
7.1 延迟突然飙升的排查思路
延迟飙升是最常见的性能问题。我的排查顺序是：
第一步，确认影响范围。是所有请求都慢，还是特定类型的请求慢？是所有实例都慢，还是个别实例慢？这个信息决定了排查方向。
第二步，看症状指标的时间线。TTFT 和 TPOT 是同时飙升，还是只有其中一个？TTFT 飙升通常是排队或预处理问题，TPOT 飙升通常是 GPU 计算或显存带宽问题。
第三步，看根因指标。GPU 利用率、显存占用、队列深度、CPU 利用率，哪个指标异常？如果 GPU 利用率突然下降，可能是遇到了计算瓶颈之外的问题，比如显存不足导致频繁换页。
第四步，看请求特征。是不是突然来了很多超长请求？是不是输入长度分布发生了变化？批处理系统对请求特征的变化很敏感。
我整理了一个速查表：
| 症状 | 可能原因 | 排查方法 |
|---|---|---|
| TTFT 飙升，TPOT 正常 | 队列积压、预处理慢 | 看队列深度、预处理耗时 |
| TTFT 正常，TPOT 飙升 | GPU 计算瓶颈、显存带宽瓶颈 | 看 GPU 利用率、显存带宽 |
| 两者同时飙升 | 系统过载、资源不足 | 看整体负载、GPU 利用率 |
| 个别实例慢 | 硬件故障、显存碎片 | 对比正常实例的指标 |
| 特定请求慢 | 输入过长、特殊字符 | 分析慢请求的特征 |
7.2 显存不足与 OOM 的预防
显存不足是 AI 推理服务最常见的故障之一。OOM 一旦发生，整个服务可能崩溃，影响面很大。
预防 OOM 的核心是显存预算管理。我会把显存分成几块：模型权重、KV Cache、中间激活值、CUDA 上下文、缓冲余量。每块都设定上限，加起来不超过总显存的 85%。
KV Cache 的显存管理是最容易出问题的。因为 KV Cache 是动态增长的，请求越多、输出越长，占用越大。我的做法是设置KV Cache 上限，达到上限后新请求排队等待，而不是继续分配导致 OOM。
另外，要监控显存碎片率。长时间运行之后，显存碎片可能越来越严重，明明总空闲显存够，但就是分配不出连续的大块。PagedAttention 能缓解这个问题，但也不能完全避免。定期重启服务实例是简单有效的办法，我一般会设置每天凌晨低峰期滚动重启。
7.3 吞吐上不去的几个隐蔽原因
吞吐上不去，GPU 利用率也不高，这种情况最让人头疼。我遇到过几个比较隐蔽的原因：
CPU 预处理成为瓶颈。GPU 在等 CPU 做 Tokenization 和 Batch 组装。解决办法是把预处理放到单独的进程池，或者用 GPU 加速的分词器。
Python GIL 限制。推理服务的调度逻辑如果是 Python 写的，GIL 可能成为瓶颈。解决办法是把调度逻辑用 C++ 重写，或者用多进程架构。
网络带宽不足。输入输出数据量大的时候，网络可能成为瓶颈。特别是多机部署的时候，节点间的通信带宽要足够。
锁竞争。多个线程竞争同一把锁，导致大量时间花在等锁上。用 py-spy 抓一下火焰图就能看出来。
日志写入阻塞。同步写日志在高并发下会成为瓶颈。改成异步日志或者降低日志级别。
这些问题单看指标都不明显，需要结合火焰图和链路追踪才能定位。我建议在性能测试阶段就打开 profiling，不要等到生产环境出问题了才去查。
8. 成本与性能的平衡：单位经济模型
8.1 推理成本的构成与计算
做性能工程不能只看技术指标，还要看成本。一个延迟很低但成本极高的方案，在商业上是不可持续的。
AI 推理的成本主要由几块构成：GPU 租用成本（或折旧成本）、CPU 和内存成本、网络带宽成本、存储成本。其中 GPU 成本通常占大头，70% 到 90% 不等。
计算单位成本的时候，我一般会算每百万 Token 的成本。公式是：
每百万 Token 成本 = 每小时总成本 / 每小时产出 Token 数 × 1,000,000
这个指标把性能和成本统一到了一个维度上。优化性能的最终目的，就是降低这个数字。
举个例子：一张 A100 每小时成本按 10 元算，如果系统每小时能产出 500 万 Token，那每百万 Token 成本就是 2 元。如果把吞吐优化到每小时 1000 万 Token，成本就降到 1 元。这就是性能优化的商业价值。
8.2 性能优化投入的优先级排序
性能优化也是要讲投入产出比的。不是所有优化都值得做。我一般按这个优先级排序：
第一优先级：零成本或低成本优化。比如调整批处理参数、优化队列策略、开启 Prefix Caching。这些优化不需要额外硬件投入，改改配置就能见效。
第二优先级：中等成本优化。比如模型量化、推理框架切换、图编译优化。需要一定的开发投入，但不需要额外买卡。
第三优先级：高成本优化。比如换更好的 GPU、增加机器、自研推理内核。这些需要真金白银的投入，只有在前面两轮优化都做完之后才考虑。
我见过一些团队一上来就想着换卡，结果发现批处理参数都没调对，换了卡性能提升也不明显。先把免费的优化做透，再考虑花钱的事。
8.3 弹性伸缩与成本控制
弹性伸缩是控制成本的关键手段，但要用好并不容易。
扩容要快，缩容要慢。扩容慢了会丢请求，缩容快了会在流量反弹时措手不及。我一般设置扩容触发阈值低一些（比如 GPU 利用率 70% 就扩），缩容触发阈值高一些（比如 GPU 利用率持续 30 分钟低于 30% 才缩）。
预留实例和按需实例搭配。流量基线部分用预留实例，成本更低；峰值部分用按需实例，灵活。比例大概是 7:3 到 8:2。
利用闲时做离线任务。流量低谷期 GPU 利用率低，可以把离线推理任务调度到这些时段，提高整体资源效率。这需要有一个统一的任务调度层，能区分在线和离线任务。
经验分享：我在一个项目里通过闲时调度离线任务，把整体 GPU 利用率从 35% 提升到了 60%，单位 Token 成本降了将近 40%。这个优化的投入只是写了一个调度器，没有增加任何硬件。
9. 从性能工程到系统可靠性
性能工程做到最后，一定会跟可靠性工程交汇。因为性能问题往往是可靠性问题的前兆——延迟升高、队列积压、显存不足，这些如果不管，下一步就是服务不可用。
我现在的做法是把性能指标和可靠性指标放在一起看。SLO 里既包含可用性目标（比如 99.9% 请求成功），也包含性能目标（比如 P99 TTFT 小于 2 秒）。两者任何一个不达标，都触发告警和排查。
另外，性能工程的经验要沉淀成容量规划模型。根据业务增长预测，提前算出需要多少 GPU、多少实例、什么规格的机器。不要等到资源不够了才去申请，那时候往往已经影响业务了。
容量规划模型的核心参数是：峰值 QPS、平均输入长度、平均输出长度、目标延迟、单实例处理能力。这几个参数确定之后，所需实例数就能算出来。我一般会留 30% 到 50% 的余量，应对突发流量和硬件故障。
最后说一个我自己的体会：AI 系统性能工程最难的从来不是某个具体的技术点，而是建立一套持续观测、持续优化、持续验证的机制。技术方案会过时，框架会迭代，但方法论和工程习惯是可以长期复用的。把指标建好、把链路拆清楚、把压测做扎实、把成本算明白，剩下的就是不断迭代的事了。
