第 15 章 — Serverless API 对比自建基础设施

《LLM Primer VI: Scaling AI Systems》章节走读的第十五篇。这一章把盈亏平衡那道算术摆到桌面上,然后命名那个真正让多数团队做决定的平台工程分项。

这一章为什么存在

第 14 章把 API 账单里的成分讲清楚,同时留了一份"能不能再便宜点"的悄悄嘀咕。自然的下一个问题是:是不是就该按 token 付钱?替代方案是把推理搬进来,在前面几章描述的那份栈上跑一个开权重模型,按 GPU 小时付钱。这笔交易有一个干净的盈亏平衡点。真正不那么干净、也是大多数团队低估的,是自建这一侧账本上不出现在 GPU 账单里的一切 —— 平台工程、安全补丁、模型升级编排、凌晨三点节点掉出 fleet 时的那个电话。第 15 章认真对待两侧,推导出自建什么时候是对的答案。

15.1 盈亏平衡公式很干净,大部分是幌子

GPU 每小时产 吞吐 × 利用率 × 3,600 个输出 token。每百万 token 的成本是 (gpu_hourly / tokens_per_hour) × 1,000,000。和 API 盈亏平衡就是这个数字等于 API 每百万价。一块 H100 上 FP8 的 70B 模型、$3/小时、聚合 800 token/s、60% 利用率,大约每百万输出 token 一美元。前沿 API 收 $15。表面节省 14 倍 —— 这是财务喜欢、也漏掉了第二笔更大分项的自建论点。盈亏平衡也依赖利用率;利用率低于 20–30% 时,自建每百万成本超过 API 价,GPU 反而比它该替代的方案贵。而利用率本身又是流量形状、autoscaling 质量、以及能不能把多种工作负载塞到同一个 fleet 上的函数。

15.2 平台工程是那个决定交易的分项

GPU 账单是较小的那半。较大的那半是让 fleet 跑得起来的那支团队:engine、驱动、编排、autoscaling、可观测性、安全。API 团队按 token 隐式付这份账;自建团队按 headcount 付。一个经验值:一个单一 serving GPU fleet —— 一两个模型变体、autoscaling、可观测性、on-call、季度升级 —— 需要大约一位全职平台工程师加半个 SRE。更多元的 fleet —— 好几个 engine、好几个模型、多租户调度 —— 需要两到四个人。按每人全包成本 $300k 算,一年平台开销是 $30 万到 $120 万。自建盈亏平衡的月流量落在 2 亿到 10 亿输出 token 之间。低于这个数,工程开销吃掉 token 节省,团队该待在 API 上。高过它,节省占主导。平台工程也是阶梯函数,不是平滑曲线:第一个招进来把 fleet 撑起来,第二个是因为一个人扛不动周末 on-call,第三个是 fleet 扩到多区域。

15.3 现实姿态是混合的,路由器是承重的一块

最干净的选择 —— 全 API 或全自建 —— 对进入生产超过一年的团队而言,很少是对的。稳态可预测工作负载(隔夜批处理、定时报表、分类队列)在计划好的自建容量上打包得漂亮。突发工作负载(病毒式尖峰、工单洪水、新 cohort 上线)需要 API 弹性。严格延迟工作负载(交互式补全、语音)从相邻的自建部署里获益。无延迟工作负载(隔夜富化、re-index)从半价批量 API 里获益。承载混合的架构是应用边界上的一个路由器,按延迟预算、复杂度、当前后端利用率给每个请求分类,再派发给满足 SLA 的最便宜后端。更精细的路由器还做 API 内的模型路由(简单请求走便宜模型、复杂请求走前沿、需要的走 reasoning)。二阶收益是选项性:工作负载能靠改路由策略跨边界迁移,而不用改应用代码。而且自建往往只有在另一个本来会走 API 的工作负载搭同一块已付账 GPU 便车时才划得来。只按一个工作负载评估自建的团队通常从不动手;把工作负载当组合看的团队会动,也省钱。

第 15 章为下面铺了什么

第 15 章提到 agent 引入了一类既不像"API 调用"也不像"模型 serving"的工作负载:LLM 生成代码的执行环境,按 agent 需要的隔离度和包灵活度住在 serverless function、microVM(Firecracker、gVisor)、或 WASM sandbox 上。第 16 章以那份不管在姿态线哪一侧都适用的降本目录收尾这一卷:智能模型路由、应用层上下文压缩、批量 API、语义缓存 —— 那几个会复利叠加到只剩上个月账单三分之一到二分之一的动作。

下一章 — 第 16 章:生产环境的降本策略。把上个月的账单变成下个月节省的那几个复利动作。