GPU 算力是产品路线图的约束：决定第三季度的 18 个月合同

十四个月前，在你公司的某个角落，一位财务总监和一位平台负责人签署了一份为期数年的算力加速器资源承诺协议。他们根据前一个季度的遥测数据构建了一个峰值负载模型，谈到了比按需计费价格低 40% 到 70% 的折扣，并锁定了集群的规格——而你现在的产品路线图必须去适应这个规格。产品团队中没有人参与过那次会议。应用工程团队中也没有人见过那份电子表格。这份合同具有法律约束力，只有在履行承诺的前提下才能享受折扣，而它买下的容量边界，现在成了产品经理们正在规划的每一个第三季度功能的隐形天花板。

大多数团队直到第二年才会察觉到这个差距：容量合同本质上是路线图决策，但它们是由那些看不见路线图的人，使用不包含路线图信息的输入数据做出的。产品“三人组”认为他们正从一个清晰的优先级积压任务中挑选功能。财务部门认为他们正在优化一个固定的预算边界。在各自的语境下他们都是正确的，而冲突则会在规划会议上显现——当架构师提议为新的助手功能使用 700 亿参数模型时，平台负责人会平静地说，集群使用率已经达到 85%，如果不挤掉其他项目，这个模型根本放不下。

永不交汇的两条规划轨道

大多数大规模运行 AI 功能的公司最终都会产生两份并行且永不统一的规划文档。

第一份是容量合同。财务和平台部门以 12 到 36 个月为周期进行谈判。输入参数是前一季度的使用遥测数据、峰值负载倍数、增长假设和价格上限。输出结果是一个固定的算力加速器资源池，通常表现为在 AWS、GCP、Azure 或托管服务提供商处预留的 GPU 数量。只有在合同期内利用率保持在承诺底线之上，折扣才会生效。如果低于底线，公司就要为未使用的容量付费。如果超过上限，公司要么支付突发流量费率，要么（更糟糕的是）根本拿不到容量，因为突发资源池是共享且被超额认购的。

第二份是产品路线图。产品和工程团队以季度为节奏来确定功能范围。输入参数是用户研究、业务优先级、技术债和以人力投入计算的工程能力。输出结果是一份带有大致预计交付时间的功能清单。在这份文档中，任何地方都不会出现“每个功能的算力小时数”这个词。任何地方都没有一列会标明“此功能需要 H200 资源池，H100 资源池无法承载”。模型的选择——是选 Sonnet 还是 Opus，是 7B 的本地模型还是 70B 的托管模型，是选 RAG 还是微调——都是由开发该功能的工程师在路线图批准几周后才做出的，他们完全不知道这些选择是否符合已签约的容量范围。

六个月后，这种差距变成了日常的摩擦。产品团队原型设计的某个新功能所需的显存超出了 H100 资源池的承受能力，除非削减 batch size，但这会极大增加延迟。提议的性能提升会导致 P99 超过 SLA，因为集群已经运行在 85% 的负载下，超过这个点后的排队延迟是非线性的。财务团队正在默默拒绝内部容量申请，因为突发资源池是吸收季节性增长的唯一手段，他们要把它留给“黑五”或季度末的业务窗口。工程团队认为他们是在根据产品优先级确定范围，而财务部门则是在根据十四个月前买下的集群能装下什么来配给这些优先级。

上季度的峰值无法告诉你明年的功能需求

观察这种失败模式最清晰的方法是看容量合同的输入数据。

上季度的遥测数据捕捉的是上季度的工程负载。它无法捕捉路线图即将加入的负载。如果产品团队计划在第三季度发布一个长上下文助手，第一季度构建的容量模型根本无法预见该功能所需的单次请求 Token 数、它将带动的并发量，或是它将运行的模型类别。峰值负载倍数只是一个猜测——通常是前一季度峰值的 2 倍或 3 倍——当下一个季度看起来和上一个季度差不多时，猜测是可以的。但当路线图明确意图改变工作负载形态时，猜测就不行了。

增长假设同样脆弱。大多数合同假设 Token 消耗量呈线性或适度的指数增长。它们没有模拟随功能发布而出现的非连续性：在每次回答中启用 RAG 引用可能会让输出 Token 瞬间翻倍；开启工具调用（tool use）可能会让单次请求的推理深度增加两倍；推出长上下文窗口可能会让每个活跃会话的显存占用增加三倍。这些都是路线图决策，但在容量模型中都是不可见的。

结果是显而易见的。在合同执行到 6 到 9 个月时，利用率要么远低于预期（公司为闲置容量买单），要么远超预期（公司支付高昂的突发费率或让功能排队等待）。企业级 GPU 机群平均利用率仅为 5% 的报告，以及个别公司发现七位数的闲置算力支出，都是这种内部错位的公开表现。合同之所以失败，并不是因为 GPU 不好，而是因为给它们定价的电子表格根本不知道产品下一步要做什么。

必须落地的纪律

解决方案并非新工具。而是一个同时存在于两个世界中的规划产出物（planning artifact）。

与人力编制（headcount）同步审批的单功能加速器小时（accelerator-hour）预算。 当产品三人组（product trio）提议一项功能时，范围界定产出物应包括估计的加速器小时成本——该成本由模型类别、预期的单次请求推理深度、预计并发量以及发布曲线推导而来。这个数字不需要非常精确，但它必须存在。一个没有该预算的功能，就是一个没有根据容量空间（capacity envelope）进行范围界定的功能，就像一个没有人力估算的功能没有根据工程产能进行范围界定一样。随着功能的具体化，这两项估算都会修订；两者共同决定了该功能是否能在提议的季度内发布。

与人力花名册同等精细度的容量仪表盘。 每个工程经理都能看到当前的组织架构图、开放的招聘职位以及未来两个季度的计划招聘人员。但几乎没有工程经理能看到当前的集群利用率、合同上限、突发余量以及模型组合敏感度（model-mix sensitivity）。容量模型存在于财务部门的规划工具中；工程团队充其量只能看到一个显示实时利用率的 Grafana 面板。这个差距是可以弥补的。以与发布人力编制相同的月度节奏、趋势线和归属权，发布相同的容量视图。

季度路线图与容量审查。 将季度产品评审与由同一论坛运行的容量审查配对。产出结果是一个功能列表：哪些功能符合容量要求，哪些功能除非有其他功能退出否则不符合要求，以及哪些功能需要下次合同修订。第一类进入下季度的承诺计划。第二类强制进行真正的优先级讨论：为了给团队真正想发布的功能腾出空间，必须削减什么？第三类为下一个合同周期的谈判窗口提供输入，而这正是容量空间本身唯一可重新谈判的时机。

将路线图输入下一次合同谈判。 上季度的遥测数据（telemetry）之所以在容量模型中占据主导地位，是因为没有人向谈判团队提供一份可信的前瞻性路线图。解决办法是程序性的：当合同准备续签时，输入信息应包括未来四个季度计划发布的功能及其加速器小时估算、计划的模型迁移以及计划的上下文窗口（context-window）变更。谈判团队随后可以根据未来的产品规模进行承诺，而不是过去的产品。折扣得以保留，容量空间也正合适。

谁都不想在复盘报告中看到的故障模式

当这种纪律没有落地时，失败的形式是似曾相识的。团队将一个功能发布到已经饱和的集群中。P99 延迟不仅针对新功能恶化，而且针对共享资源池的每个工作负载都会恶化，因为饱和的 GPU 队列会在租户之间激增。轮值（on-call）人员会被呼叫一周。复盘报告（post-mortem）首先检查功能发布和代码路径。它通常不会指明真正的根本原因：一个在 14 个月前由不了解该功能即将上线的人做出的容量决策，使用的输入信息不包括该功能，且被锁定在一个在未来 12 个月内无法撤销的合同中。

这些复盘报告中的补救措施通常是请求更多 GPU，而财务团队在不修订合同的情况下无法批准，而修订合同需要整整一个季度来谈判，在此期间，团队只能通过降级模型或暂停发布来绕过约束。写在复盘报告模板里的教训是“发布功能前测试容量”。组织实际吸取的教训却更难写下来：存在于独立论坛中的规划产出物，最终会在未经许可的情况下为彼此做出决定。

容量是一项产品约束

架构上的启示是最难转化为 Backlog 任务单的：GPU 容量不是基础设施。它是一个必须与功能积压工作（backlog）存在于同一个规划产出物中的产品约束。将其视为基础设施——由平台团队处理、由财务部门管理的东西——正是导致 14 个月前的合同与本季度功能决策之间产生隐形绑定的原因。

做对这件事的公司，在结构上会看起来像 15 年前领悟到人力编制同样教训的公司。人力编制曾经是一个后台支出项，直到人们意识到招聘计划和功能计划是从两个角度观察的同一个计划。同样的事情正在容量领域缓慢发生。产品经理和容量所有者最终将出现在同一个论坛中，看着同一个模型组合敏感度图表，因为这是停止发布那些已被财务部门默默删减的路线图的唯一方法。

目前，大多数公司仍处于早期阶段，删减在悄无声息地发生，团队只有在功能因为功能团队中没人能说出的原因而无法发布时才会注意到。修复工作始于工程领导在路线图评审中提出那个容量合同在 14 个月前就旨在回答的问题：这些功能中哪些实际上是合适的，如果我们想要实现它们，需要做出什么改变？