第一问：私有化还是调 API？（先算账，再谈技术）
私有化是手段不是目的。判断表（按我实际项目的口径）：
| 场景 | 选择 | 理由 |
|---|---|---|
| 数据不能出域（合规硬要求） | 私有化 | 没有别的选项，只比成本怎么摊 |
| 数据可出域，月 token 成本可控 | 调 API | 维护成本、迭代速度全面占优 |
| 推理量极大、延迟敏感 | 私有化 | API 费用曲线穿过自建成本线时（通常量级很大才成立） |
| 团队没有 GPU 运维经验 | 先调 API | GPU 集群排障是专业活，别用业务期试错 |
关键认知：私有化省的是「边际 token 成本」，花的是「固定成本 + 人力 + 迭代速度」。很多团队私有化后才发现：自建省的钱 < 多养的运维与卡死的迭代。算账公式：
自建月成本 = 机器折旧 + 电费机房租 + 运维人力分摊，对比API 月账单 × 1.2（buffer）。
算力评估：一张表估出要几张卡
粗估公式（以 7B–70B 开源模型为例，精度受 KV Cache 与并发影响）：
显存 ≈ 参数量 × 2字节(fp16) × 1.2(KV/激活buffer) + 额外推理buffer
单卡吞吐 ≈ 以实测为准（别信官网数字，压自己业务的 prompt 分布）
务实流程：
- 先拿业务真实 prompt 样本在目标模型上压测（工具见 vLLM 工具行），测出「单卡 QPS / 并发 / P95」；
- 按峰值并发的 2 倍冗余倒推卡数；
- 别一上来买齐，先租后买 / 混部验证。
vLLM 部署的三个关键配置（踩坑实录）
--max-model-len别照抄默认：默认值往往偏大，白白占掉 KV Cache 显存。按业务最大输入+输出估算（如 8k），吞吐可能直接翻倍。--gpu-memory-utilization调到 0.85–0.92：默认 0.9 附近，但多卡时注意留给调度器余量，调满会 OOM。--enable-prefix-caching该开就开：RAG 场景长公共前缀命中缓存后，首 token 延迟与吞吐改善明显；代价是显存占用上升，需实测平衡。
坑：一次升级 vLLM 大版本后，
--quantization参数改名导致服务起不来——生产环境锁版本，升级走小版本灰度，别追新。
扩缩容：推理是「并发敏感」不是「QPS 敏感」
推理服务扩缩容要看并发与排队，不是单纯 QPS：
- 配好请求队列 + 超时 + 排队告警；队列深度超阈值先降级（见本系列后续《AI 成本控制》章节），而不是无限加卡。
- 入口层做模型路由：简单请求走小模型/缓存，复杂任务才上大模型——多数系统 70% 流量用不着最强模型。
- 弹性扩缩按「队列深度」而非 CPU：GPU 利用率高不一定代表健康，看排队延迟才准。
落地清单
- 用算账公式对比自建 vs API，结论写进 ADR
- 业务真实 prompt 压测，测出单卡 QPS/P95，按 2 倍冗余倒推卡数
- 先租后买 / 混部验证，避免一次性买断踩坑
- max-model-len / gpu-memory-utilization / prefix-caching 实测调参
- 锁版本、小版本灰度升级
- 队列 + 超时 + 排队告警 + 模型路由降级
延伸阅读：vLLM / Langfuse 工具行 · 系列下一篇《AI 项目成本控制》还在写，先占个坑