Serverless 推理：无服务器 LLM 推理、冷启动优化与 GPU 弹性

传统推理：
□ 预置 GPU 实例（常驻）→ 成本按「时间」烧
□ 空闲时也烧钱（流量波峰波谷明显 → 浪费严重）
□ 运维：扩缩容、节点管理、故障自愈

Serverless 推理：
□ 无调用 → 不跑（GPU 回收）
□ 有调用 → 拉起实例 → 推理 → 按「使用时长/调用」计费
□ 用户看到的是「一个 API」，不关心背后有没有卡

核心转变：
□ 计费从「时间」→「使用」（闲置不花钱）
□ 运维从「管理实例」→「管理 API」（平台代管）
□ 弹性从「预留」→「按需」（秒级拉起/回收）

对比示意：
常驻：GPU 卡 24h 都扣费，实际利用 20%
Serverless：有调用才扣费，闲置时 GPU 归零
→ 对「低利用率/波动大」的工作负载，成本可能省 60%+

控制面（Control Plane）：管理「要跑什么」
□ 模型仓库/版本管理、API 网关、鉴权
□ 部署配置（模型、卡型、副本、超时）

数据面（Data Plane）：真正「跑模型」
□ 推理实例（GPU Pod/VM + 推理引擎 vLLM/Triton）
□ 模型加载器、健康检查、指标上报

调度器（Scheduler）：决定「什么时候跑/停」
□ 实例池管理（池化闲置 GPU）
□ 水位线调度（按实例队列长度拉起）
□ 空闲回收（超时无调用 → 回收）

请求流：
API 网关 → 调度器（选/拉起实例）→ 推理实例 → 返回
并发不够 → 调度器拉起新实例（自动扩缩容）

关键：实例分为「热实例」（已在跑）与「冷实例」（要拉起）
热实例 → 直接转发请求（毫秒级）
冷实例 → 拉起 + 加载模型 → 才可服务（秒到分钟级）

冷启动时间线（典型值）：
□ 容器/VM 拉起：1~10 秒（镜像拉取、资源分配）
□ 推理引擎启动：1~3 秒（vLLM/Triton 进程初始化）
□ 模型加载：10 秒 ~ 数分钟（看模型大小/存储带宽）
□ 权重权重从磁盘→显存：70B FP16 ≈ 140GB，NVMe 读要几十秒
□ 预热/校准：可选，秒级

总量：小模型 10~30 秒，70B 大模型可能 2~5 分钟

瓶颈排序：
1. 模型权重加载（最重：几十~上百 GB）
2. 容器/镜像拉起（第二：网络 + 存储）
3. 引擎初始化（较轻）
→ 优化顺序：先砍模型加载，再砍容器拉起

为什么冷启动痛：
用户第一请求 = 冷启动 + 推理 → 延迟不可接受（分钟级）
但 Serverless 的价值就是「闲置回收」→ 必然产生冷启动
→ 解法：不消灭冷启动，而是「让大多数请求命中热实例」

优化手段：
□ 模型缓存：权重放在本地 NVMe / 内存映射
  → 省去「从远端对象存储拉取」的网络耗时
  （远端拉 140GB 要几分钟，本地 NVMe 读只要几十秒）
□ 镜像预热：把推理镜像/权重预分发到可用节点
□ 两阶段拉起：先回「占位」响应 → 后台加载 → 就绪
□ 实例池/预留：维持 K 个「已拉起未使用」的热实例
  → 请求直接命中，冷启动只发生在池不够时
□ 权重格式优化：FP8 减半权重（140GB→70GB，加载也减半）
□ 并行加载：分片并发读 + 多节点分片加载

「暖启动」策略：
□ 迷你预热：拉容器 + 引擎（几秒），不加载权重
□ 全量预热：容器 + 引擎 + 权重（完整就绪）
→ 两档粒度，按「预期流量」选预热深度

效果：
无优化冷启动：~2 分钟（70B）
+ 本地缓存：~40 秒（省远端拉取）
+ 实例池命中：请求走热实例（毫秒）
→ 冷启动只发生在「流量突增超过池容量」时

实例池（Instance Pool）：
□ 平台维护一组「已拉起/可拉起」的 GPU 实例
□ 模型 A 用完释放 → 实例回池 → 给模型 B 用（资源共享）
□ 池大小：太少→冷启动多；太多→浪费

水位线调度（Watermark）：
□ 每个模型维护「运行中实例数 / 排队请求数」
□ 排队超阈值 → 拉起新实例（扩容）
□ 空闲超时 → 回收实例（缩容）
□ 水位线高低 = 延迟 vs 成本的权衡

碎片整理（Defragmentation）：
□ GPU 显存被多个小模型碎片化 → 合并/迁移
□ 模型复用实例池（不同模型分时段共享）
□ 用更优的装箱（bin-packing）提高 GPU 利用率

调度目标：
□ 热实例命中率（延迟）↑
□ GPU 利用率（成本）↑
□ 冷启动频率 ↓

调度循环：
请求 → 有热实例？命中（快）
        → 无热实例？排队 or 拉起（权衡）
空闲 → 超阈值？回收 → 回池 → 被其他模型复用

策略对比：
□ 按并发：请求数 > 实例容量 → 扩容
  → 直观，但「长请求/流式」会高估（占着茅坑）
□ 按排队：队列长度 / 等待时间 → 扩容
  → 更能反映「真忙」，LLM 场景更准
□ 按指标：GPU 利用率 / token 吞吐 / 延迟 P95
  → 综合，但指标有滞后（延迟高了才反应）

LLM 的坑：
□ 生成是「长占用」：一个流式请求占实例几秒~几十秒
□ 并发数 ≠ 忙闲：100 个请求可能都在排队生成
□ 扩容要「提前量」：拉起新实例要几十秒
  → 不能等满了才扩，要按「预测」扩

扩缩容周期：
□ 扩：预测队列增长 → 提前拉起（提前 30~60 秒）
□ 缩：空闲回收（保守，回收比拉起快）
□ 冷却：避免「扩了又缩、缩了又扩」抖动

推荐组合：
扩容信号：排队等待时间 P95 > 阈值（如 2s）
缩容信号：实例空闲 > 阈值（如 5 分钟无请求）
预热池：按历史流量曲线提前备好热实例

Serverless 适合：
□ 利用率低：日均利用率 < 30% 的模型
□ 波动大：波峰波谷明显（如白昼型业务）
□ 并发稀疏：调用稀疏、间歇（如低频 API）
□ 多模型多版本：共享 GPU 池省成本
□ 研发环境/CI：短时验证、动态起停

常驻（Deployment）适合：
□ 利用率高：持续高并发（核心线上服务）
□ 延迟敏感：P99 严格要求（冷启动不能忍）
□ 长连接/流式：稳定实例抗长会话
□ 状态依赖：需要缓存/前缀缓存/长上下文预热

关键指标判断：
□ 平均并发 vs 峰值并发：比值小 → Serverless 划算
□ P99 容忍度：容忍秒级 → 可 Serverless
□ 成本模型：算「节省」= 常驻成本 - 按量成本

混合形态（最常见）：
□ 核心模型常驻（保延迟）
□ 长尾/低频模型 Serverless（省成本）
□ 流量突增时 Serverless 兜底扩容（混合弹性）
→ 常驻保底 + Serverless 弹性，是生产主流

成本结构：
□ 按量计费：按「实例运行时长 × 卡型单价」× 利用率
  （比常驻单价贵 1.5~3 倍，但只算「用的时候」）
□ 闲置回收：无调用 → 实例释放 → 成本归零
□ 预留实例（Provisioned Concurrency）：
  → 保留 K 个热实例，付「保底费」换「零冷启动」

算账：
常驻成本 = 卡数 × 单价 × 24h
Serverless = 卡数 × 单价 × 实际利用小时 + 预留费
省多少 = 利用率反比
→ 利用率 10% 的工作负载：可能省 60~80%
→ 利用率 70% 的持续负载：几乎不省，甚至更贵

省钱杠杆：
□ 缩闲置（最大杠杆）：空闲回收 + 合理池大小
□ 降卡型：FP8/量化让单卡装更大模型（省卡数）
□ 提高装箱：多模型共享 GPU 池

案例账（示意）：
1 卡 A100 常驻：$3/h × 24h = $72/天
Serverless 利用率 15%：$3/h × 3.6h ≈ $11 + 预留费 ≈ $15/天
→ 省 ~80%（但冷启动换来的）

建设清单：
□ 模型管理：版本化、多副本、回滚
□ 路由：按模型/版本/租户路由 → 对应实例池
□ 鉴权限流：API 网关 + 租户配额
□ 可观测：冷启动率、热实例命中率、排队等待、GPU 利用率
□ 容灾：节点故障 → 实例重建 + 请求重试

稳定性关键指标：
□ 冷启动率：<5%（大多数请求命中热实例）
□ 排队等待 P95：< 阈值（如 2s）
□ 回收误伤：别把「刚活跃」的实例回收（冷却期）
□ 故障自愈：实例崩溃 → 自动重建 + 拉请求转移

LLM 特有风险：
□ 长请求超时：流式生成可能几十秒 → 超时阈值设高
□ 前缀缓存失效：冷实例无前缀缓存 → 首次慢
□ 突发多租户：一个租户流量洪峰打爆共享池 → 配额隔离

流程：
监控冷启动率/命中率 → 调水位线/池大小 → 灰度调整

上线检查：
□ 冷启动在可接受范围（用预留/池化兜底）
□ 有配额与限流（防单租户打爆）
□ 故障自愈经过演练（节点宕机→实例重建）
□ 成本核算接入（按模型/租户分账）