先用 API 再等权重：自建排期不能压在厂商的承诺上
一、把外部时间表当锚点，等于把不可控项写进对客户的承诺
据公开报道，一款新旗舰模型上线并同步推出高速版本，官方把上下文窗口标到百万级，同时承诺在此后一段期限内放出完整模型权重；另有报道称这一代在上一代基础上增加了后训练算力，并在数百种下游任务上做联合强化学习。这些说法与数字都不是本篇判断的依据。本篇只处理一个工程问题：当一个模型先以接口形态可用、权重稍后才到，自建排期应该怎么切。
我们在私有化交付里踩过这类坑。方案评审时把“权重会放出”写进技术前提，项目计划里给它留一个里程碑，于是整条自建的排期就挂在了别人的日历上。真去核对时发现三件事同时不确定：权重什么时候到；到的那一版是否完整——分片文件、配置文件、分词器与对话模板、量化工具链是否同步放出；许可证允许我们把它用到什么程度。
先接口后权重这种安排，对企业的影响从第一天就生效，不会等到权重那天才开始。四项影响要提前摊开：数据的出境与留存策略决定了哪些任务在等待期只能跑脱敏版本；成本结构从按调用付费变成按持有付费，闲置也计入；可定制范围打开了微调与量化，同时把精度验收义务揽回了自己身上；对外承诺的周期被拉长，因为上线时点不再由合同决定。
结论写成一句话就够：外部事件可以当机会，不能当前提。凡是压在“权重放出”上的承诺，都要改写成“权重到位后若干周内可交付”，而这个“若干周”必须有实测依据，不能拍脑袋。
二、先用三问定归属，再把任务切成 A、B 两类清单
三问的顺序不能颠倒，第一问就把范围划死。
第一问：哪些能力必须落在自己机房。判据是硬的——原始数据不得离开客户网络且合同或监管写明；需要在受控网络内出具可复核的推理记录；必须做微调或量化到自有硬件；对时延与可用性有写进合同的约束。四条里占一条就归入此类。
第二问：哪些可以长期用接口。判据同样要具体——任务标准化、失败可重试且不产生真实副作用、不接触客户原始数据、单位成本随量线性可预测、供应商更换成本已被网关隔离。这类不要自建，自建只会把成本从可变变成固定。
第三问：哪些是“暂时用接口，但必须能迁”。这一类最危险，因为它既承担接口形态的数据限制，又要为将来投入。它必须被显式登记成一个待迁项，有触发条件和责任人，否则默认结果永远是“先这样用着”。
登记表的字段建议：能力名称、归属判定（必须自建、可长期用接口、待迁三选一）、判定依据（写合同条款或监管要求的出处，不写“大家都这么做”）、当前形态、目标形态、迁移触发条件、责任人、下一次核对时间。
A 类任务只依赖接口，现在就上线。上线前有一件必须做完的事：把接口契约跑通并固化。包括所有调用走统一网关且模型标识写在配置而不是代码里；超时、重试与幂等策略按任务类型分档；结构化输出有解析失败的兜底分支；每次调用的输入摘要、参数、返回码、耗时、token 数与模型标识落库，能事后重建；评测任务集与固定输入集已版本化，接口侧的基线已经量出来。
B 类任务依赖权重与运行环境，权重到位才启动。它在等待期的合法产出物只有一个名字，叫准备完成度，不叫效果。建议给每条 B 类任务定五级：未启动、环境已验证、基线已跑、精度验收方案已定、灰度与回滚方案已演练。
三、权重到位前的六项准备，没有一项能在等待期结束后再补
这六项的耗时取决于验证本身，与权重在不在手里无关。等权到了再开始做，等待期结束只会变成第二段等待。
| 准备项 | 完成判据 | 为什么压不掉 |
|---|---|---|
| 硬件与驱动栈适配 | 目标卡型在真实机房跑通最小推理样例，内核、驱动与算子库版本已入档 | 权重到了才发现某个算子不支持，损失的是几周而不是几天 |
| 推理框架与并行切分基线 | 至少一套框架在同批输入上的吞吐与时延曲线已测，切分方案已定 | 换框架等于重测精度，事后补会推翻前面的结论 |
| 量化与精度验收方案 | 量化档位、评测集、允许偏差与判定人已书面确定 | 没有验收方案，交付时无法证明量化版本可用 |
| 评测任务集与固定输入 | 输入集含边界样本且带版本号，解码参数与随机种子固定 | 两边跑出的差异无法归因，讨论会退化成感受之争 |
| 日志与观测接入 | 每次调用记录长度、首 token 时延、缓存命中与单位成本 | 成本与性能问题只在数据里可见，事后无法回补 |
| 回滚与灰度策略 | 分流开关可用，回退耗时经过实测而非估算 | 自建上线初期必然有回退需求，现场想策略一定来不及 |
四、百万级窗口要算四笔账，“塞得下”与“用得准”是两项验收
官方给出的窗口数字是一个能力声明，不是一笔预算。要把四笔账算出来才敢写进方案。
第一笔是并发账。注意力键值缓存随输入长度增长，长上下文直接压低可承载的并发数。要测的不是最大长度，而是“输入到某个长度时并发掉到多少”这条曲线。第二笔是时延账。长输入的预填充时间显著拉长首 token 时延，必须按长度分档看分位数，不能用平均值。第三笔是价格账。按输入长度分档计价时，用真实长度分布算月成本，不要按窗口上限估，那是最坏值而不是期望值。第四笔是有效召回账。把同一条关键信息分别放在输入的开头、中部、结尾，测各位置的抽取准确率，中部最容易丢。
验收要分两步，各出一张结论。“塞得下”这一步只测机械可用性：不截断、不报错、计费口径与官方说明一致、多轮拼接不越界。“用得准”这一步按位置与干扰样本量分档测准确率与格式稳定性。两步混在一起做，最后会得到一个既不能定位问题也不能对比成本的数。
长窗口也不是唯一选项，四类手段各有边界。
- 检索增强：适合知识密集且片段可切分的任务；当片段之间强依赖时效果不如长窗口。
- 分层摘要：适合跨会话与跨批次的长流程；有不可逆的信息丢失，必须保留原始片段的位置引用。
- 结构化记忆：适合实体与状态字段稳定的场景；自由文本在字段化时容易变形。
- 长窗口：适合一次推理里需要全局一致性的任务，例如全篇合同条款交叉核对、大型代码库的跨文件定位。
一个可执行的原则：不要用窗口上限去反推产品功能。功能边界要由“已验证的长度档位”决定。
五、许可证四项自查，与迁移一致性的判据
权重到位不等于可以随便用。四项要在启动 B 类任务前查清并留书面记录。
能否商用，注意要区分“内部使用”与“用其输出对外提供服务”这两种商用；能否再分发，集团内多个法人主体之间共享、交由云厂商代运维是否构成分发；能否用于训练下游模型，包括蒸馏与用它生成语料；署名与声明义务，界面、文档与对外材料上需要写明什么。做法是出一页纸，逐条标注原文位置，交付与法务双方确认后归档进项目资料库，不要依赖某个仓库里说明文件的记忆。
迁移一致性要提前设计成一次可比对实验，而不是上线后的观察。同一任务集在接口形态与自建形态各跑一遍，记录这些字段：任务号、输入哈希、解码参数与随机种子、格式合规率、关键字段一致率、拒答率、单位成本、第九十五分位时延。
差异到达阈值时不要临时吵。事先定两件事：哪些任务必须逐字段一致，涉及金额、期限、条款引用的结构化输出属于此列；哪些允许漂移，开放式文案与草稿生成属于此列。然后用“业务是否可接受”和“差异是否可复现”两轴做决定：继续用接口、按任务类型混合路由，或以自建为主、接口做兜底。混合路由的前提是网关侧有按任务分流的配置能力，这一项要在 A 类阶段就实现。
六、对外只承诺已验证的能力
给客户的方案里，能力要分三档写：已验证并可用，附验证方式与适用范围；已完成准备但未验证，附启动条件与预计周期；依赖外部事件，只写触发后的响应动作，不写时点。这三档混写是私有化项目最常见也最贵的失误，因为客户会按最乐观的一档排自己的计划。
验收单上也建议把这一点钉死：自建部分的验收判据只列已在本地跑通的项目，厂商计划中的能力不进验收清单。如果客户明确要求把未来能力写进去，那就把它作为独立的一条服务承诺，配负责人与重新评估节点，不与当期交付绑定。
洹拓在项目评审里加过一条硬规矩：任何引用外部时间表的排期，都必须同时写出“这段等待期我们做什么、做完达到哪一级准备度”。写不出来的条目，不许进计划。这条规矩的效果很直接，等待期变成了准备期，权重到位那天，项目才真的有一条起跑线。