万亿参数开放权重落地：先算部署账再谈立场
一、开放权重交给你的是选择权，也是三笔账
据公开报道，有欧洲厂商发布了新一代旗舰模型的公开预览版，媒体把它定位成欧洲自己的开放模型路线，参数量级在万亿这一档。厂商名、模型名、参数量与”开放”的具体口径在这里都只是背景转述，不是本文的判断依据；许可证条款、权重可得性与训练细节我们无法从报道里推出来，也不做断言。至于这是哪一方对哪一方的挑战，不在本文范围。
本文只处理一件事：当权重的确拿到手、准备从”调用别人的接口”转成”自己跑”，账要怎么算。开放权重在字面上是把选择权交给你，实际结构是把三笔账从厂商转移到你手上——部署账、评测账、合规账。这三笔账在接口调用模式下是看不见的，因为厂商已经替你算完了，你只在账单上看到结果。
所以自建之前的第一道筛子不是”能不能跑起来”，而是四项判定：
- 真的需要这个量级吗。把手上的任务按”当前接口的失败形态”列一遍：失败集中在推理深度和长文档上，量级才有关；失败集中在提示写法、上下文缺失或工具接口不稳定上，换多大的模型都救不回来。
- 可接受的单请求延迟与并发是多少。把它写成数字，因为后面的显存与卡数全从这个数字反推。允许排队和不允许排队，是两个完全不同的方案。
- 有没有稳定的运维人手。量级到这个档位，运维不是”部署一次就好”，而是全天候的事：推理引擎升级、显存碎片、单卡故障替换、权重换版。没有稳定人手，方案写得再好都会在半年内塌成实验环境。
- 数据是否必须留在自有环境。这条决定的是必要性上限，不决定技术难度：如果业务上确实要求原始数据不出域，那自建才有不可替代的理由；如果只是”想可控”，可控可以用私有接口、专属实例与处理协议换来，成本低得多。
四项里任何一项答不上来，都先别谈部署。
二、显存这一关：算式比结论重要
权重所占容量按参数量乘以每参数字节数估，半精度两字节、int8 一字节、int4 约半字节；量级到万亿时，这一项就足以说明单卡放不下是结构性问题，不是优化问题。
但权重只是第一块。真正决定并发上限的是上下文与 KV 缓存：它随并发数和上下文长度增长，长上下文场景下经常先于权重把显存吃满。所以核算必须同时给三个输入——权重体积、单请求上下文长度、目标并发数，缺一个就算不出可交付的形态。
量化与专家路由各自改变了不同的东西，别把它们当同一个优化。
- 量化改的是每参数字节数，直接影响权重占用与带宽压力；代价是要重新验证精度敏感任务，特别是数值计算、长链推理与代码类任务，这几类最先出现不可见退化。
- 专家路由改的是每次前向实际参与的参数量，吞吐与显存的账都要按激活规模重算，但权重总体仍需常驻或可快速换入，所以”总参数量很大而激活很小”并不等于机器可以省很多，它把瓶颈从计算挪到了显存与调度。
- 单实例放不下之后才谈并行：张量并行把单层切开，跨卡通信量随层数累加，对互联带宽极度敏感；流水线并行把层按段切开，收益受气泡和批次形状限制。两条路都让运维复杂度非线性上升，也要在核算里预留通信与调度的余量，而不只算权重除法。
三、吞吐账与故障域：卡数不是除出来的
粗略的式子是：所需算力规模约等于峰值流量乘以单请求成本，再除以单位算力吞吐。这个式子只用来做量级判断，实际交付要往上面叠三件事——冗余、故障域和爬坡。
- 冗余不是按平均负载加百分比，而是按可容忍的失效单元算：允许挂几张卡、挂一台机器、挂一个机柜，对应不同的预留量。
- 故障域要和并行方式对齐。张量并行组跨了机架，单点故障会让一整组服务不可用；这决定了预留量的算法，也决定了运维响应等级。
- 爬坡指流量增长与模型换代。集群按峰值配齐是一次性投入，业务增长往往是阶梯式的，核算里要区分”第一天就要的规模”和”验证通过后要扩的规模”。
下面这张三项核算表是我们要求客户在决策会上填的，每一项都要写明数据来源；填不出来的格子就是风险所在。
| 核算项 | 要算的东西 | 需要的输入 | 算不出来说明什么 |
|---|---|---|---|
| 显存 | 权重体积、KV 缓存随并发的增长、并行切分后的余量 | 参数量与精度、上下文长度、目标并发、并行策略 | 还没定延迟与并发目标，方案无法收敛 |
| 吞吐 | 单位算力吞吐、峰值流量下的卡数、冗余与故障域预留 | 真实流量分布、请求长度分布、可接受尾延迟、失效容忍范围 | 用平均值代替峰值，上线必然排队 |
| 运维 | 值班与响应等级、引擎与驱动的升级窗口、换版与回滚流程、备件周期 | 现有人手技能栈、机房服务条款、备件与替换时长 | 把部署当一次性项目，半年后变成实验环境 |
四、评测口径不能断：与云端接口的对照方案
换了部署方式，评测不能跟着换一套。我们的对照方案有固定动作：
- 用同一份私有评测集与同一套判据跑一遍，判据不因为部署形态改变而调整；私有评测集必须是自己业务里的题，公开榜单在这里没有替代作用。
- 记录逐项差异，而不是总分差异：按任务分组列出通过率、失败样本标识与失败形态，特别标注长上下文、数值计算、代码与多步工具任务这几组，它们是量化与推理引擎差异最先暴露的地方。
- 差异写进决策材料：自建后的通过率若低于云端接口，要么承认业务能接受这个折损，要么把优化项（精度、并行策略、采样参数）列成清单继续跑；不允许用”总分差不多”糊过去。
- 采样与系统提示逐字对齐。同一份评测集在不同采样参数下差距可以很大，对齐不了就不要比较，比了也是错的。
- 留一条回切通道：对照期内云端接口不下线，按同一批输入做双跑，出现争议时用记录判定而不是用印象判定。
五、更新通道、供应链责任与合规边界
自建之后，模型更新的责任落到自己头上。更新通道至少要写清四件事：版本从哪个渠道取、如何校验（校验和与签名要落到流程里，而不是”下载完看一眼”）、谁复核许可证条款、换版后由谁重跑评测集。供应链责任是一条链：权重来源、镜像仓库、依赖的推理引擎与算子库，每一环都要有可追责的登记，出事时才能回答”这批权重从哪来、谁批的”。
合规要单独说一句：自建不等于合规自动达成。数据不出域只解决了传输环节，剩下的仍然要自己承担——日志留存多久、留存什么、谁能查；推理链路里是否存在跨境调用（包括运维通道、监控与外包支持）；用户数据是否进入上下文、进入多少、保留多久、能否按主体删除。这些都要写进设计文档，形成可核对的字段，而不是靠一句”我们自建所以安全”。许可证复核要有明确的人，条款换版时要重走一遍，不能沿用上一次结论。
六、混合策略与退路
多数业务的最优解不是全自建。我们通常按混合形态设计：简单任务走便宜档或本地小模型；自建集群承接核心与敏感负载；峰值时溢出到云端接口兜住尖峰；核算按科目而不是按总额——自建成本、接口成本、人力成本各自记，总额好看但科目错乱的项目最后都会失控。
退路必须在方案里就写好，因为三种变化迟早同时来。集群租期到期时要能整体迁移，所以镜像、权重、判据、评测集都要可导出，并保存在集群之外；厂商改条款时要能停在新版本上，所以需要留版本快照与”可长期运行版本”的登记；模型换代时权重与格式的迁移成本最容易低估——架构换了要换推理引擎、量化格式与并行配置都要重做，评测集与判据必须保留原样以便说明新模型改善了什么。
对洹拓的交付来说，最后落成的判断标准只有一句：能不能在换掉权重、换掉集群、换掉厂商这三个动作里任选一个，而业务口径与评测结论仍然连得上。连得上才算把开放权重变成了资产，连不上只是把三笔账换了一种方式背着。