1. 课程导入
欢迎进入《金融推理P95/P99延迟与容量优化实战》。在开始调优之前，我们必须先建立一套共同的“语言”：金融推理到底特殊在哪里，为什么P95/P99比平均延迟更重要，容量优化究竟要优化什么，以及后续30章会沿着怎样的路径推进。本章不涉及复杂调参，而是帮你把问题定义清楚——定义错了，后面所有优化都会跑偏。
一、金融推理场景的四个硬约束
金融推理通常指风控评分、反欺诈识别、授信决策、量化信号生成、智能投顾问答等场景。它与通用聊天机器人有本质差异，集中体现在四个方面。
- 强时效性：支付风控要求在几十毫秒内返回决策，超时即视为拒绝或降级，直接影响交易成功率。
- 强合规性：模型版本、输入特征、输出决策必须可追溯，推理链路不能随意丢弃或缓存敏感结果。
- 流量突发性：开盘、整点、营销活动、批量代扣会带来数倍于均值的瞬时并发，尾延迟极易被放大。
- 成本敏感：GPU资源昂贵，金融企业既不能长期按峰值配置，也不能让P99突破业务SLA。
这四点决定了：金融推理的容量优化不是“把平均延迟压到最低”，而是在成本、吞吐、尾延迟、合规四者之间寻找可运营的平衡点。
二、P95/P99延迟的业务意义
平均值会掩盖长尾。假设某风控接口平均延迟20ms，但P99达到800ms，意味着每100笔请求就有1笔让用户等待近1秒。在支付场景中，这1%可能对应大量超时失败、客诉与资损。因此金融系统普遍用分位数而非均值定义SLA。
| 指标 | 含义 | 典型业务解读 |
|---|---|---|
| P50 | 50%请求快于该值 | 代表“常规体验”，用于观察整体水位 |
| P95 | 95%请求快于该值 | 多数用户的较差体验，常用于内部告警 |
| P99 | 99%请求快于该值 | 接近SLA红线，直接关联超时与降级 |
| P99.9 | 99.9%请求快于该值 | 极端突发与慢节点，用于容量安全边际 |
需要特别强调：P99不是P95的简单延伸。当系统接近饱和时，P95可能仍然平稳，而P99会先陡峭上升。因此P99是容量是否充足的“早期预警信号”。
三、容量优化的目标与核心矛盾
容量优化的目标可以概括为一句话：在满足P95/P99 SLA的前提下，用最少的资源承载目标QPS，并保留可预期的突发余量。它包含三个可量化子目标：
- 延迟目标：明确P95、P99阈值及统计窗口，例如“P99 ≤ 300ms，5分钟滑动窗口”。
- 吞吐目标：定义稳态QPS与突发QPS，例如“稳态2000 QPS，突发4000 QPS持续60秒”。
- 成本目标：单位请求GPU成本或每卡QPS，用于衡量优化收益。
三者存在天然矛盾：提高批处理可提升吞吐，却增加单请求排队延迟；增加副本可降低尾延迟，却抬高成本。后续章节将围绕这些矛盾逐一给出工程解法。
四、整体学习路径
本课程共30章，按“认知—度量—优化—验证—运营”五阶段推进，建议按顺序学习：
- 认知阶段（第1–4章）：场景特点、延迟指标、容量模型、SLA定义。
- 度量阶段（第5–10章）：压测工具、监控埋点、分位数统计、瓶颈定位。
- 优化阶段（第11–22章）：批处理、量化、KV Cache、并发调度、副本与路由。
- 验证阶段（第23–27章）：回归压测、混沌演练、成本核算、SLA验收。
- 运营阶段（第28–30章）：容量规划、弹性扩缩、线上复盘与持续优化。
五、实战环境准备
为保证后续实验可复现，请先准备统一环境。推荐使用带GPU的Linux服务器或云实例，并安装以下组件：
# 基础环境检查
nvidia-smi
python --version # 建议 3.10+
docker --version
# 安装推理与压测依赖
pip install torch transformers fastapi uvicorn
pip install locust prometheus-client
# 启动一个最小推理服务用于后续章节
uvicorn app:app --host 0.0.0.0 --port 8000 --workers 1
六、常见误区与复盘提醒
在正式进入优化前，先避开三个高频误区：
- 只看平均值：平均值达标不代表SLA达标，必须同时观察P95与P99。
- 盲目堆资源：未定位瓶颈就扩容，可能只是把排队点后移，成本上升而P99改善有限。
- 忽略统计窗口：1分钟P99与5分钟P99差异巨大，SLA必须绑定明确的统计口径。
至此，你已经掌握了本课程的共同语言：金融推理的硬约束、P95/P99的业务含义、容量优化的三重目标，以及后续学习路径与环境准备。接下来，我们将从延迟指标的定义与统计方法开始，逐步构建可度量、可优化、可运营的金融推理系统。