在华 MNC AI 私有化:三条推理链挖到可被外部审计的深度
本版不扩大范围。v1 的 13 节分析被压缩为三条推理链 + 三项强制自检。每个数字标注证据等级,每条监管结论附文件编号与生效状态,每项计算提供可复跑脚本。v1 的三个核心论点在本版中被证伪。
00本版与 v1 的关系:三个核心论点被自己的计算证伪
先列证伪结果。如果这一节成立,v1 的结论段就不能再用了。
证伪:EU GMP Annex 22(2025-07-07 草案,咨询 2025-10-07 截止,未生效)把动态/概率性/生成式模型(明确含 LLM)排除在适用范围外,也排除在关键 GMP 应用之外。权重在谁手上不改变这件事。私有化是必要条件,不是充分条件。
证伪:4 万次蒙特卡洛显示,即使把日 token 量放大 100 倍到 200 亿/日,自建 48 月累计仍是全公网的 1.07 倍,48 月内回本概率 3.5%。成本在任何规模假设下都不构成自建理由。而且 v1 把全公网年成本写成 ¥130 万,实际按口径算只有 ¥44 万/年——比一个 FTE 还便宜,v1 高估 3 倍。
双重证伪:(a) 全局 SLO 物理不可达——longdoc 类 P95 输入的纯 prefill 时间地板已达 7.34s,与买几台机器无关;(b) 静态物理隔离是三种调度中最差的,交互类 P95 恶化 1.9–2.3×,因为固定切分算力会搁置产能。正解是共享池 + 优先级 + work-conserving,比混跑再好 31%。
另有两处方法学错误与四处遗漏:
- 用 roofline 推延迟。v1 用「带宽 ÷ 每 token 字节」算出节点 prefill 能力,再用「需求 13.6K / 供给 13.1K」得出「2 节点够用」。这是把吞吐当延迟。TTFT P95 是排队结果,ρ→1 时吞吐仍"够"但 P95 发散。
- 跨模型挪用实测数据。v1 用 HelixML 测 284B 模型的 946 tok/s 支撑 671B 旗舰池的容量结论。激活参数与 KV 结构均不同,不可迁移。
- 漏 EU AI Act(对 MNC 是重大遗漏)。注:我在上一轮的纠正里也说错了——称"高风险义务 2026-08-02 全面适用",实际已被 AI Omnibus 推迟至 2027-12-02(Annex III 独立系统)与 2028-08-02(嵌入产品的安全组件)。
- 漏《网络数据安全管理条例》(国务院令第790号,2025-01-01 施行)第 30、31 条——这两条给出可直接落地的强制动作,见链 C。
- 漏 ISPE《GAMP Guide: AI》(2025-07,约290页)、AI 生成合成内容标识办法(国信办通字〔2025〕2号,2025-09-01 施行)、个人信息保护合规审计管理办法(令第18号,2025-05-01 施行)、网络安全法 2025 修正(2026-01-01 施行)。
- 最关键论点用了百度百科。"Copilot 中国内地不可用"是整个商业论证的第一支柱,v1 的来源是百科。本版取得微软官网一手引述,但发现一个 v1 和我上一轮都没注意的 nuance——见链 C。
A1链A · 埋点方案与预注册:让容量模型变成可证伪的命题
v1 的 token 账本是构造的,且天然不可证伪——实测是多少都能回头调参数说"本来就是这个意思"。预注册消除这个退路。
Shadow-mode 埋点(4 周,observe-only)
ts · actor_hash(HMAC-SHA256 + 每周轮换盐,跨周不可关联)· dept_code(k-匿名 k≥50)· scene · n_in/n_out · n_cached_in · prefix_fp(仅 SHA256 前 8 字节指纹)· model_requested · ttft_ms/tpot_ms · status · dlp_class_guess(仅等级,不记命中内容)
prompt 与 completion 原文——本阶段不需要,且会立刻把轨迹库本身变成 S3/S4 资产。
文件内容、附件、任何可直接识别个人的字段。
合规前置:须先完成 PIPIA;依令790号第31条评估;若轨迹库被判含重要数据,须按第30条设管理层级数据安全负责人。PIPIA 完成前不得启动采集。
事前预测(封存,4 周内不得修改)
| 指标 | 预测值 | 判废阈值 | 判废后的动作(事前约定) |
|---|---|---|---|
| 总量 | |||
| 稳态日均 LLM token | 199 M/日 | 落在 [66M, 597M] 外 | 不得按原 CapEx 提报,重建模型后重走 P1 立项 |
| 输入:输出比 | 86 : 14 | 输入占比 <70% 或 >94% | 重算 prefill/decode 配比与选型方向 |
| 峰谷系数 K_peak | 3.2 | 落在 [2.0, 5.0] 外 | 重算峰值容量 |
| 有效工作分钟 M_work | 300 | 落在 [200, 420] 外 | 同上 |
| 输入长度分布(最吃重) | |||
| longdoc 占请求数 | 8% | 落在 [3%, 18%] 外 | 重做 A3 调度仿真;旗舰池可能须换 MLA 模型(见 A2) |
| interactive 中位输入 | 2,200 tok | 落在 [1200, 4500] 外 | 重算 TTFT 地板 |
| 各类 P95/中位 比值 | — | 落在 [1.8, 4.0] 外 | 分布形态判断错误 → 整个长度模型作废 |
| 缓存与场景 | |||
| 可缓存前缀 token 占比 | 55% | < 25% | 暂缓硬件采购,先做系统提示标准化(零成本提升 2–3× 有效容量的前置条件) |
| code + agent 合计 token 占比 | 35% | 落在 [15%, 55%] 外 | >55% 时代码助手必须独立成池并独立计费 |
| 任意 2 项以上判废 | 整个容量模型作废,P1 收缩为「仅网关 + 边缘节点」,旗舰节点延至 P2 | ||
完整文件:chain_a/PRE_REGISTRATION.md,含签署区(China IT 负责人 / 法务 / PMO 三方确认封存)。
A2链A · KV 显存账本:按 config 显式计算,直接证伪 v1 两处设计
v1 说"L2 主力池单卡跑 32B,batch 32–64"。这句话在 8K 上下文下大致成立,在 30K 上下文(合同/SOP 审阅)下完全不成立。差异来源不是算力也不是带宽,是 KV 容量——而 KV 只能从 config 算,不能从 benchmark 博客抄。
| 模型 | 注意力 | 层 | KV/token | 权重 FP8 | 证据等级 |
|---|---|---|---|---|---|
| DeepSeek-V3 系 | MLA | 61 | 34.31 KiB | 624.9 GiB | SELF_MEASURED 按公开 config 显式计算,可复跑 |
| Qwen3-32B | GQA | 64 | 128.00 KiB | 30.5 GiB | SELF_MEASURED config.json: n_kv_heads=8, head_dim=128 |
| GLM-4.6 | GQA | 92 | 184.00 KiB | 330.6 GiB | 部分待核 层数与参数为公开规格;n_kv_heads/head_dim 按同架构推定 |
最大并发请求数(受 KV 容量硬约束,非受算力约束)
| 模型 | 卡组 | 4K | 8K | 32K | 128K | 判定 |
|---|---|---|---|---|---|---|
| DeepSeek-V3(MLA) | 8× RTX PRO 6000 SE | 494 | 247 | 61 | 15 | 可用768GB 装 625GiB 权重后余 ~90GiB |
| Qwen3-32B(GQA) | 1× RTX PRO 6000 SE | 111 | 55 | 13 | 3 | 证伪 v132K 下仅 13 并发,达不到 v1 假设的 batch 32–64 |
| GLM-4.6(GQA) | 4× RTX PRO 6000 SE(TP=4) | 20 | 10 | 2 | 0 | 证伪 v1v1 说"双实例 TP=4 做 HA"——长上下文下根本不可用 |
| GLM-4.6(GQA) | 8× RTX PRO 6000 SE(TP=8) | 501 | 250 | 62 | 15 | 单实例 TP=8 才可用,意味着放弃双实例 HA |
直接推论:对 30K 输入的合同/SOP/PV 长文档场景,"用小模型省资源"是错的——MLA 大模型反而是更省的选择。v1 把长文档场景归到 L1 旗舰池(恰好对了),但给的理由是"需要强推理",真实理由是 KV 结构。理由错了,就无法推广到新场景。
可复跑:chain_a/kv_budget.py → kv_budget_result.json。注意:全表假设 FP8 KV;若推理引擎回退到 BF16 KV,上表所有并发数直接减半。
A3链A · TTFT 排队仿真:全局 SLO 物理不可达,而"物理隔离"是最差的调度
离散事件仿真,替换 v1 用 roofline 推延迟的方法学错误。两类流量:interactive(92%,中位 2,200 tok)与 longdoc(8%,中位 28,000 tok)。节点 prefill 能力取中位档 8,000 tok/s(待链B实测替换),KV 并发上限取 61(来自 A2)。
发现一:TTFT 的物理地板
| 流量类 | 中位输入 | P50 地板 | P95 地板 | P99 地板 | 含义 |
|---|---|---|---|---|---|
| interactive | 2,200 | 0.27s | 0.68s | 0.99s | 有余量,SLO ≤1.5s 可达 |
| longdoc | 28,000 | 3.50s | 7.34s | 9.97s | SLO 不可达零排队时的纯 prefill 时间 |
发现二:三种调度策略对比(同总负载、同总算力,只改调度)
| 总λ | 策略 | 交互 P50 | 交互 P95 | 交互 P99 | 长文 P95 | 交互达标 (≤1.5s) | 相对 mixed |
|---|---|---|---|---|---|---|---|
| 0.35 | mixed(FIFO 混跑) | 0.32s | 1.00s | 1.66s | 12.27s | ✓ | 基准 |
| isolated(v1 推荐) | 0.68s | 2.00s | 3.55s | 19.44s | ✗ | 2.00×(更差) | |
| priority(本版推荐) | 0.30s | 0.79s | 1.12s | 10.66s | ✓ | 0.79×(更好) | |
| 0.65 | mixed | 0.38s | 1.45s | 2.58s | 16.74s | ✓ | 基准 |
| isolated | 0.83s | 2.76s | 4.42s | 33.48s | ✗ | 1.90×(更差) | |
| priority | 0.35s | 1.00s | 1.52s | 19.06s | ✓ | 0.69×(更好) |
静态按 token 占比切分算力后,interactive 池只拿到约 47.5% 的 prefill 预算。长文档空闲时,那部分产能被搁置,交互请求借不到。这是经典的 non-work-conserving 损失。
共享单池 + interactive 插队 + 预留份额用不完让给 longdoc。既保住高优先级延迟,又不浪费产能。负载越高优势越明显(0.79× → 0.69×)。
vLLM/SGLang 层面:按 scene 打优先级标签 + chunked prefill + 优先级调度,而不是起两个独立服务。
v1 的"物理隔离"建议应作废。
可复跑:chain_a/ttft_class_isolation.py → ttft_class_result.json。重要局限:r_prefill=8000 tok/s 是输入参数不是实测值,且 decode 驻留用固定时长近似。本仿真的作用是比较三种调度的相对优劣(这个结论对 r_prefill 不敏感),不是给出绝对 TTFT 承诺。绝对值必须由链 B 实测替换。
B1链B · 硬件数字的三级证据分级
分级规则:VENDOR_SPEC 可用于容量计算上限,不可用于性能承诺|THIRD_PARTY_MEASURED 可用于量级判断与排除选项,不可用于容量承诺|SELF_MEASURED 是唯一可用于容量承诺与合同验收的等级|LEAD_ONLY 禁入结论段与合同。
| 数字 | 等级 | 可用于 | 不可用于 / 处置 |
|---|---|---|---|
| RTX PRO 6000 SE:96GB / 1,597 GB/s / 2 PFLOPS FP8 / ≤600W / MIG 4 实例 | VENDOR_SPEC | KV 容量计算、权重装载可行性、功耗与机柜规划 | 吞吐承诺、TTFT 承诺 |
| RTX PRO 5000 72GB:1,344 GB/s / 300W / 4×DP 输出 + 主动散热 | VENDOR_SPEC | 同上;形态规格直接支撑"工作站卡不适合 8 卡密集机架风道"的判断 | — |
| Atlas 800I A2:8×910B / 单卡 64GB / 整机 2.24 PFLOPS FP16 | VENDOR_SPEC | 容量与功耗规划 | 规格表写"8×64GB,内存带宽 1.6TB/s",未说明是单卡还是整机聚合口径 → 此项禁止用于 decode 吞吐推算,直到实测 |
| 海光 K100-AI:64GB HBM2E / 796 GB/s / 192 TFLOPS FP16 | VENDOR_SPEC | 容量计算(按保守值 796 取) | 带宽有 796 / 896 两个流通口径,来源冲突 |
| 昆仑芯 P800:单机 8 卡可跑 671B 满血(8bit);32 台支持全参训练 | VENDOR_SPEC | 功能性声明(装得下)可采信 | 不是性能声明,不可据此推吞吐 |
| 昆仑芯 P800:96GB HBM3 / 4 TB/s / TDP | LEAD_ONLY | REJECTED | 拆解分析认定 GDDR6 并明确否认 HBM3;4TB/s 对 GDDR6 物理不成立;TDP 无官方披露。禁止进入任何计算 |
| 昆仑芯 P800 卡价 ¥3.2万 / ¥14.6万 / ~¥10万 | LEAD_ONLY | REJECTED | 三口径离散 4.5 倍,无法做 TCO。必须正式询价 |
| 8×RTX PRO 6000 跑 DS-V4-Flash FP8:vLLM+DSpark 946 / SGLang 653 / DwarfStar 122 tok/s | THIRD_PARTY | 支撑定性结论「引擎差异 7.8× > 硬件差异」;排除劣选引擎 | v1 误用实测对象是 284B,激活参数与 KV 结构均不同,不可迁移到 671B 容量计算 |
| 海光 K100-AI 跑 284B INT8:总吞吐 450 tok/s,TTFT 均值 50s / P99 82s;128K 长文 163s | THIRD_PARTY | 排除海光做交互式旗舰池——TTFT 量级差两个数量级,非调优可弥补 | 这是全部外部数据中决策价值最高的一条,因为它是否证性的:用来排除选项远比用来支持选项可靠 |
| Atlas 800I A2 跑 MoE W8A8:默认 2,200 → 优化后 6,600 tok/s | THIRD_PARTY | 量级判断 | 6,600 是深度优化后结果,非开箱即得。若采信,须同时把「达到该水平所需优化工时」计入项目成本 |
SELF_MEASURED 缺口(PoC 必须亲自补齐的六项)
- 同硬件引擎横评(vLLM / SGLang / 厂商引擎,同模型同负载)—— PoC 预算的 50% 应投此项,回报最高
- 671B 在目标硬件上、用自有回放轨迹测的 TTFT P95(按流量类分别)
- 目标并发下的实际 KV 占用与 OOM 边界(验证 A2 的计算)
- 国产栈需适配的算子清单与工时
- 整机满载实测功耗与机柜回风温度
- 跨节点 RoCE 实测带宽(nccl-tests / hccl_test)
B2链B · 回放压测 harness 与可写入合同的验收条款
与常见压测的根本区别:输入来自网关导出的真实轨迹,不是 ShareGPT 合成集。合成集的长度分布与企业负载差一个量级,用它测出的 TTFT 没有参考价值。
harness 按流量类分别报 ttft_p95_interactive 与 ttft_p95_longdoc——这是 A3 结论(SLO 必须分类承诺)的直接落地。
合同「技术验收」章节条款(二值判定,不接受"基本满足")
| 条款 | 要求 | 达标判据 | 为什么(规格书不会写这件事) |
|---|---|---|---|
| PCIe 拓扑 | 交付 nvidia-smi topo -m(国产等效工具)完整输出 | 任意两卡 P2P 路径不经过被 3 张以上卡共享的上行链路 | 部分 8 卡平台用 PCIe switch 把 8×x16 挤在更少上行通道,P2P 带宽腰斩 |
| 集合通信 | 现场跑 nccl-tests all_reduce_perf,消息 1MB–1GB 扫描 | 单机 8 卡 all-reduce ≥ 厂商声称值 85%;跨节点 ≥ 线速 90% | RoCE 默认配置下丢包重传导致 TTFT 偶发尖刺 |
| 功耗与散热 | 72 小时满载烤机(卡功耗上限配 450W),PDU 分路计量 | 整机峰值 ≤ 4.8 kW;全程 throttle reason 全零;冷通道回风 ≤ 35°C | 规格 TDP 与实际满载常差 10–20%,而机房余量往往只有这么多 |
| 模型加载 | 从共享存储冷加载 671GB FP8 权重计时 | ≤ 2 分钟(有效读带宽 ≥ 5.6 GB/s) | 读带宽不足会让节点重启耗时 10 分钟以上,直接影响滚动升级与故障恢复 |
| 回放压测 | 用甲方提供的回放轨迹执行,并发 1/4/16/64 四档 | interactive 类 TTFT P95 ≤ PoC 实测基线的 1.15 倍;错误率 ≤ 0.5%;无 OOM | 唯一与业务体验直接对应的验收项。禁止用供应商自带合成 benchmark 替代 |
| 供货确认 | 书面确认可合法供货型号 + 该型号实际规格书 + 12 个月供货保障 | 书面件齐备且型号规格与报价一致 | 在华供货受出口管制政策影响,可能为削减版。网页截图与口头承诺不构成依据 |
完整文件:chain_b/replay_bench.py、chain_b/evidence_and_acceptance.json。
C1链C · 一手监管来源登记册:20 条,12 条 PRIMARY,7 项未闭合
规则:每条必须有「文件编号 + 发布日期 + 生效状态」三项。写不出三项的标 UNVERIFIED,不得进结论段。
中国侧
| 文件 | 编号 | 生效 | 对本方案的直接影响 |
|---|---|---|---|
| 促进和规范数据跨境流动规定 | 网信办令 第16号 | 2024-03-22 现行 | 第3条:国际贸易/跨国生产制造/市场营销活动中产生、不含个人信息或重要数据的 → 豁免三机制。第5条第2项:跨境人力资源管理 → 豁免。第5条第4项:非CIIO 年累计 <10万人非敏感 PI → 豁免 |
| 网络数据安全管理条例 | 国务院令 第790号 | 2025-01-01 现行 | v1 完全漏掉第31条:提供/委托处理/共同处理重要数据前应做风险评估——把 S3/S4 发给公网模型 API 就构成「委托处理」,触发事前风险评估义务。第30条:重要数据处理者须设数据安全负责人(管理层成员)与管理机构,特定种类规模的还须对负责人与关键岗位做安全背景审查 |
| 生成式人工智能服务管理暂行办法 | 七部门令 第15号 | 2023-08-15 现行 | 第2条第3款:未向境内公众提供服务的内部研发应用不适用本办法 → 内部场景重心是 PIPL/DSL 出境 + 等保,不是大模型备案。第17条:触达公众即触发安全评估与算法备案 |
| 人工智能生成合成内容标识办法 | 国信办通字〔2025〕2号(四部门) | 2025-09-01 现行 | v1 漏掉对外渠道的 AI 输出须显式+隐式双标识。第9条「留存提供对象信息等日志不少于六个月」与架构的审计留存要求一致,可合并实现 |
| AI 生成合成内容标识方法 | GB 45438-2025 | 2025-09-01 现行 | 注意是 GB 不是 GB/T —— 强制性国标。规定标识的技术实现方法 |
| 生成式 AI 服务安全基本要求 | GB/T 45654-2025 | 2025-11-01 现行 | 训练数据/模型/安全措施三类要求 + 附录B 安全评估参考方法。是安全评估的事实依据(推荐性) |
| 个人信息保护合规审计管理办法 | 网信办令 第18号 | 2025-05-01 | v1 漏掉 · 条文待调取对达门槛的个人信息处理者设定期合规审计义务,MNC 中国区通常达标。须纳入 P0 法务清单 |
| 网络安全法(2025 修正) | 2025-10-28 全国人大常委会修改决定 | 2026-01-01 | v1 引用的是 2016 原版 · 修正条文待调取等保与法律责任条款可能有变动 |
药企 GxP 侧
| 文件 | 状态 | 关键内容与影响 |
|---|---|---|
| EU GMP Annex 22「Artificial Intelligence」 | 草案 · 未生效2025-07-07 发布 咨询 2025-10-07 截止 EMA 目标 2026 年底定稿 | 草案将动态、概率性与生成式模型(明确含 LLM)排除在适用范围外,亦排除在关键 GMP 应用之外。11 章结构:Scope / Principles / Intended Use / Acceptance Criteria / Test Data / Test Data Independency / Test Execution / Explainability / Confidence / Operation / Glossary。 松动迹象:EMA 2026 年 10 月初工作坊报告 EMA/156789/2026 记录起草组讨论「在完整文档化、稳健的基于风险的控制策略支持下可允许动态/概率/生成式模型」,认为存在可行路径——这是讨论记录,不是条文 |
| EU GMP Annex 11 修订 | 草案 · 未生效2025-07-07 | 由 5 页扩至 19 页。权重显著转向 Security / Identity and Access Management / Audit Trails,Validation 不再是最大篇幅 → 与本方案的「身份与权限」「审计」两层方向一致,可作对标 |
| ISPE《GAMP Guide: AI》 | 现行行业共识2025-07,约 290 页 | v1 漏掉扩展 GAMP 5 第二版附录 D11。强调全部 AI 相关数据(原始输入、训练集、模型参数、prompt、输出)均受 ALCOA+ 约束 → 直接决定审计层字段设计。这是质量组与检查员实际采用的工作文件 |
| FDA AI 可信度框架指南 | 草案 · 未定稿Docket FDA-2024-D-4689 FR Doc 2024-31542 2025-01-07 发布 | 提出基于风险的 credibility assessment framework 与 Context of Use(COU)。 对方案有利但 v1 没说出来:明确不涵盖「仅用于运营效率(内部工作流、资源调配、起草撰写申报文件)且不影响患者安全、药品质量或研究结果可靠性」的用途 → 办公/营销/代码助手场景本就在本指南范围外。「先做办公场景」的正确理由是监管范围外,而非 v1 说的"门槛低" |
| FDA CSA 指南 | 定稿2025-09-24 | 修正我上一轮的说法我上一轮说"CSV 已被 CSA 取代,用 CSV 是外行"——过头了。该指南的 FR 通告描述适用对象为「用于医疗器械生产或质量系统的计算机与自动化数据处理系统」,联系人在 CDRH/CBER,不是 CDER 的药品 CGMP 指南,也不专门针对 AI。正确表述:器械侧已 CSA 化,药品侧 AI 专项仍是空白+草案。 计划中但截至 2026-09-29 未发布:「CSA for AI-Based Systems in Drug Manufacturing and Clinical Investigations」「AI and ML Quality Considerations in Pharmaceutical Manufacturing」 |
| FDA/EMA 联合 AI 良好实践指导原则 | 已发布2026-01-14 | 10 条高层原则(以人为本、基于风险、遵循标准、明确场景边界、多学科整合、数据治理与文档、规范模型设计、基于风险的性能评估、全生命周期管理、信息传递清晰必要)→ 可作内部 AI 治理政策的框架骨架 |
| EMA AI 反思文件 | 2024-09 | 明确 AI/ML 应用是否属 EMA 及成员国药监职责范畴,是监管审查力度的直接依据 |
EU AI Act(含我上一轮也说错的时间线)
| 节点 | 适用日 | 内容 |
|---|---|---|
| 禁止性条款 | 2025-02-02 | 已适用 |
| GPAI 模型义务 | 2025-08-02 | 已适用,按期未推迟 |
| 多数条款 + 透明度/GPAI 执行扩大 | 2026-08-02 | 口径冲突待核新华社 2026-07-31 报道称 8 月 2 日起已执行透明度规则;另有来源称透明度义务推迟至 2026-12-02。须以 OJ 正式文本为准 |
| Annex III 独立高风险系统 | 2027-12-02 (原 2026-08-02) | 我上一轮说错了我称"2026-08-02 全面适用"。实际经 AI Omnibus(2026-05-07 临时协议、2026-06-16 欧洲议会通过、理事会批准)推迟约 16 个月 |
| 嵌入产品的安全组件高风险系统 | 2028-08-02 (原 2027-08-02) | 含嵌入医疗器械、工业机械的 AI 安全组件 |
| 罚则 | 最高 €3,500 万 或 全球年营业额 7%。药企 AI 用于诊断/患者监测/临床决策支持属 Annex III 高风险。对 MNC:若中国区 AI 能力被集团复用于欧盟市场或处理欧盟数据主体,则适用 | |
供应商可用性(含 v1 与我上一轮都没注意的 nuance)
但必须注意一个 nuance,v1 和我上一轮的纠正都没注意到:取得的引述出现在个人版/家庭版产品页,zh-hk 页面措辞更明确为「适用于个人版产品的 AI/Copilot 功能在中国或澳门特别行政区无法使用」。商业版/企业版(E3/E5 + Copilot 加购)在中国内地的可用性与此不必然相同,不得以偏概全。
→ 这是整个商业论证的第一支柱。立项前必须取得微软对本企业租户与授权类型的书面功能可用性矩阵。在拿到书面件之前,这条论据只能标"待核",不能写进提报材料。
完整登记册:chain_c/regulatory_register.json(20 条:PRIMARY 12 / OFFICIAL_SECONDARY 7 / UNVERIFIED 1)。7 项未闭合:令第18号原文、网安法修正条文、GAMP 5 二版出版年、EU AI Act Omnibus 的 OJ 正式文本(含透明度义务确切适用日)、Copilot 企业版矩阵、Azure 中国可部署模型清单。
C2链C · 直接回答:私有化部署之后,哪些 GxP 用途仍然不被允许
这是重写后的提示词要求必须明确回答的问题。v1 回避了它——v1 隐含"私有化就能做 GxP",而这是错的。
| 用途 | 私有化后是否可行 | 依据与边界 |
|---|---|---|
| 关键 GMP 决策(放行判定、偏差定性、OOS 结论、工艺参数调整) | 仍不被允许 | Annex 22 草案把生成式模型排除在关键 GMP 应用之外。与部署位置无关。若 Annex 22 按现草案定稿,私有化不会改变结论 |
| GMP 记录的自动生成并直接成为受控记录 | 仍不被允许 | 生成式模型输出非确定性。须经「确定性工作流编排 + 人工复核后才成为受控记录」的模式 |
| PV 个例报告结构化抽取(v1 的 P2 核心门禁) | 可行但须大幅降级 | 只能做「人在环的辅助抽取」:AI 产出草稿 → 人工 100% 复核 → 人工签署后才成为记录。不得宣称自动化,不得减少复核。v1 把"人工修正率 ≤15%"设为 P2 验收指标,隐含"85% 不用人看"——这个指标本身违反当前监管立场,必须删除 |
| GMP 文档起草(SOP 初稿、验证方案、偏差调查报告初稿) | 可行 | 高容量、结构可预测、成为记录前有人复核。GAMP AI Guide 认可此模式。但 prompt 与输出均受 ALCOA+ 约束,须全量留痕 |
| 办公 / 营销 / 代码助手 / 内部知识问答 | 可行,且监管负担最低 | FDA 草案明确不涵盖仅提升运营效率、不影响患者安全或研究结果可靠性的用途。这是"先做办公场景"的真正理由 |
| 对境内公众提供(患者关爱、官网问答、小程序) | 不得用自建私有模型 | 触发《生成式 AI 暂行办法》第17条安全评估与算法备案 + 标识办法双标识 + GB 45438 强制标识。境外主体无在华备案先例 → 只能调用已备案的境内模型 API。私有化在这里是负资产,不是资产 |
→ 自建的正当理由收窄为一条:《网络数据安全管理条例》第31条意义上的「重要数据不得委托第三方处理」+ S3/S4 不得出域。GxP 不再是自建的理由,而是一个独立的、目前大部分关闭的闸门。
D1自我证伪:v1 内部的数字矛盾,与本版的可检验推翻条件
v1 内部的数字矛盾(当时没抓到)
| 矛盾 | 具体 |
|---|---|
| 利用率自相矛盾 | v1 说峰值有效 prefill 需求 13.6K tok/s,L1(2.6K)+L2(10.5K)=13.1K —— 峰值等于 100% 打满、零余量。同时 v1 又把「稳态利用率 ≥45%」设为验收指标、「规划折扣 0.6」写进方法论。这三个数凑不到一起:若真按 0.6 折扣规划,需求 13.6K 需要 22.7K 名义产能,是 v1 配置的 1.7 倍 |
| 公网成本算错 3 倍 | v1 写「全公网年 OpEx ¥130 万」。按其自己的口径算:199M token/日 × 365 × ¥6/百万 = ¥44 万/年。高估 3 倍,直接导致 build-vs-buy 的差距被严重低估 |
| HA 方案与 KV 账本冲突 | v1 说 GLM-4.6「可双实例 TP=4 做 HA」。A2 算出 4 卡跑 GLM-4.6 在 32K 下只有 2 并发、128K 下 0 并发 → 该 HA 方案在长上下文下不可用 |
| 隔离建议与容量规划冲突 | v1 既说「批处理须与交互物理隔离」,又把两类流量合并算进同一池的容量需求。两者不能同时成立 |
本版的可检验推翻条件(写明什么观测会证明我错)
| 编号 | 若观测到这个 | 则本版的哪个结论被推翻 → 应改为 |
|---|---|---|
| F-1 | Annex 22 定稿版(EMA 目标 2026 年底)纳入生成式模型,允许在稳健控制策略下用于关键 GMP | C2 的"仍不被允许"失效 → GxP 重新成为自建的强理由,P2 门禁可恢复。须按季度复查 EMA 工作计划 |
| F-2 | 实测前缀缓存命中率 < 25% | A1 的"有效容量提升 2–3×"失效 → 必须先做系统提示标准化工程,硬件采购暂缓 |
| F-3 | 实测 longdoc 占请求数 > 18% | A3 的调度结论需重算;旗舰池必须用 MLA 模型(A2 的 KV 优势成为硬约束而非偏好) |
| F-4 | 公网混合单价 18 个月内未下降(年留存因子 > 0.9) | D2 的"成本永不是理由"被削弱 → 在极大规模下自建可能回本,须重跑蒙特卡洛 |
| F-5 | 微软书面确认企业版 Copilot 在中国内地可用且功能完整 | 整个商业论证的第一支柱倒塌 → 立项理由收窄为"仅合规刚性",预算应大幅压缩 |
| F-6 | 实测 priority 调度相对 mixed 无改善(比值 ≥ 1.0) | A3 结论失效 → 退回 mixed,但不得退回 isolated(isolated 在三种中最差已被两档负载验证) |
| F-7 | 法务认定公司不持有任何"重要数据",且 S3/S4 可脱敏后外发 | 自建的最后一条理由消失 → 应放弃自建,只建网关 |
D2build-vs-buy 蒙特卡洛:成本在任何规模假设下都不是自建的理由
4 万次模拟 · 48 个月 · 四个随机变量:公网年价格留存因子 d∈[0.25,0.95](Beta)、需求年增长 g(中位 2.2×,Lognormal)、自建稳态利用率 u(Beta)、FTE 年成本(Normal 50±8 万)。
回本概率 0.0%
扫描范围内不存在
| 日 token(百万) | 全公网 48 月 | 自建 48 月(35%承载) | 自建/公网 | 48 月回本概率 |
|---|---|---|---|---|
| 199(当前画像) | 300 万 | 1,097 万 | 3.66× | 0.0% |
| 500 | 747 万 | 1,493 万 | 2.00× | 0.0% |
| 1,000 | 1,502 万 | 2,224 万 | 1.48× | 0.0% |
| 2,000 | 2,973 万 | 3,732 万 | 1.26× | 0.0% |
| 5,000 | 7,423 万 | 8,386 万 | 1.13× | 0.1% |
| 10,000 | 14,839 万 | 16,163 万 | 1.09× | 1.3% |
| 20,000(当前的 100 倍) | 29,635 万 | 31,589 万 | 1.07× | 3.5% |
为什么差距这么大:固定成本结构
→ 因此 CapEx 必须按「不得外发的流量」反推,而不是按总流量反推。v1 按总需求(199M/日)配 2–3 节点,方向就错了。正确做法:先由法务圈定"不得外发"的流量份额,再只为这部分配算力。
可复跑:chain_a/buildvsbuy_mc.py → buildvsbuy_mc_result.json。模型局限:只比较成本;合规刚性是约束而非成本项,不进模型——它决定了"有一部分流量无论多贵都必须自建"。名义产能用 900 M tok/日 per ¥230万 线性近似,是粗口径。
D3Pre-mortem:假设 18 个月后失败,死因与早期信号
按"已经失败"的口吻写,不是按"可能失败"。每条给出可观测的早期信号与检查频率。
| # | 死因(已发生式) | 早期信号(可观测) | 检查频率 | 预防动作 |
|---|---|---|---|---|
| 1 | 买了机器,场景没人用。18 个月后节点利用率 12%,CFO 在预算会上拿它当反面案例 | P1 上线 2 个月 DAU/可用人数 < 20%;种子用户周活跌破 50% | 周 | G1 把 DAU 设为阻断型门禁:不达标不扩容硬件,转采纳度治理。已在 v1 写入,保留 |
| 2 | GxP 场景一个都没落地。Annex 22 按原草案定稿,PV 项目在 QA 评审时被判定"生成式模型不在允许范围",P2 核心价值归零 | EMA 工作计划未出现纳入生成式模型的迹象;QA 拒绝出具验证策略 | 季度 | P2 价值重心预先移至合同审阅 + 文档起草 + 代码助手(均不受 Annex 22 约束)。GxP 场景降级为"人在环辅助",不写进 ROI |
| 3 | 机房没改造完,硬件在仓库躺了 5 个月。折旧已开始计提,但没产生一个 token | P0 勘察报告显示单柜 <10kW;改造施工合同迟于硬件采购合同签署 | 月 | 设施改造必须先于硬件采购启动。合同签署顺序写进 PMO 检查表。Phase 1 先上边缘节点(2kW 单相电可供) |
| 4 | 实测需求只有估算的 1/4,买多了。预注册判废触发,但硬件已到货 | 埋点第 2 周的日均 token 外推 < 66M | 周 | P1 只买 1 旗舰 + 1 边缘,第二台等实测。预注册判废阈值已写明此动作 |
| 5 | RAG 越权事故。一名调岗员工通过 AI 检索到原部门的 S4 临床数据,触发信息安全事件上报 | 越权红队测试出现任一命中;索引层 chunk 四字段完整率 < 100% | 季度(红队) 日(字段) | 检索层用当前身份二次鉴权(非索引时快照);分级随 chunk 继承;安全投入 40% 集中此项 |
| 6 | 2.5 FTE 一直没到位。引擎调优没人做,节点跑在默认配置上,吞吐只有可达水平的 1/5 | P0 结束时编制未确认;6 个月内未完成一次引擎横评 | 月 | TBD-14 列为 G0 硬条件。预留外部实施支持预算作为缓冲 |
| 7 | Global 中途收回授权。集团 AI 治理政策统一后要求中国区并入全球栈,自建资产变孤岛 | 集团发布全球 AI 平台路线图;Global CISO 对 Risk Memo 回应含"待集团统一"字样 | 季度 | P0 必须拿到 DEP-3 书面例外授权(基于"Global 产品在中国区不可用"的书面证据)。授权未到手不进 P1 |
| 8 | 公网 API 降价到让自建显得荒谬。审计问"为什么花 ¥343 万做一件 ¥44 万/年能买到的事" | 公网混合单价 12 个月内跌破 ¥3/百万 token | 季度 | 立项文件里就不要把成本写成理由(D2)。把理由锚定在令790号第31条的"不得委托第三方处理"上——这条不随价格变化 |
E1外部证据清单:不由我与大白判定的验收依据
重写后的提示词要求:验收不由你我判定。下表每项标明当前状态、责任人、到位时点。这张表的"缺失"行数就是本方案当前的可信度缺口。
| # | 外部证据 | 状态 | 责任人 | 到位时点 | 它证明什么 / 为什么不能由我出 |
|---|---|---|---|---|---|
| 1 | 可复跑 benchmark harness + 原始结果产物 | 部分已有harness 已交付 结果缺失 | IT 架构 | P0 W7 | 别人在同硬件重跑能落在 ±15% 内。我只能给工具,不能给结果——结果必须在真硬件上跑 |
| 2 | 企业质量部(QA)签字的 Annex 22 / GAMP AI Guide gap assessment | 缺失 | 质量部 QA | P1 M6 | GxP 场景可行性的唯一有效判定方。我对 Annex 22 的解读不构成合规意见 |
| 3 | 具名外部律师书面备忘录(带法条编号与生效状态) | 缺失 | 法务 + 外部律所 | P0 W8 | 律师承担执业责任。链 C 登记册是架构输入,不是法律意见 |
| 4 | 微软对本企业租户与授权类型的书面功能可用性矩阵 | 缺失 | IT 采购 | P0 W3 | 商业论证第一支柱。官网脚注只覆盖个人版,企业版不必然相同(见 C1) |
| 5 | 供应商书面供货确认(型号+实际规格+12 个月保障) | 缺失 | IT 采购 | P0 W4 | 在华可能为削减版。网页截图不构成依据 |
| 6 | 独立第三方红队报告(在真实部署上尝试 ACL 绕过) | 缺失 | IT 安全 + 外部 | P1 M7 | 自测越权必然有盲区。必须外部人用低权账号实打实试 |
| 7 | 合同验收条款的现场执行记录(6 项,见 B2) | 条款已有执行记录缺失 | IT 采购 + 运维 | 到货验收 | 二值判定、供应商在场、不达标即违约 |
| 8 | 预注册预测 vs 4 周实测的偏差比对 | 预注册已封存实测缺失 | IT 架构 + PMO | P0 W8 | 最关键一项这是唯一能证明容量模型不是事后编的办法。偏差 >3× 即判模型失效 |
| 9 | 法务对"是否持有重要数据 / S3·S4 能否脱敏外发"的结论 | 缺失 | 法务 | P0 W8 | 决定本方案是否还有存在意义(见 F-7)。若结论为"均可外发",硬件部分应全部作废 |
| 10 | EMA 工作计划季度复查记录(Annex 22 是否纳入生成式模型) | 缺失 | 法规事务 + QA | 按季度 | F-1 的触发监测。这条结论会变,不能一次性判定 |
| 当前状态汇总 | 缺失 7 项 · 部分已有 3 项 · 完整 0 项 → 本方案目前的全部可信度建立在「我的计算是可复跑的」这一点上,而非建立在外部验证上。这是诚实的起点,不是终点。 | ||||
E2修正后的建议:从"按总需求建算力"改为"按不得外发的流量建算力"
① 盘点总需求 199M token/日
② 按峰值 + 分层路由推算需 16–24 卡
③ 配 2–3 节点,CapEx ¥343 万
④ 理由:GxP 可验证性 + 合规 + 成本(4×,可接受)
错在哪:GxP 理由被 Annex 22 推翻;成本理由被蒙特卡洛推翻;容量用 roofline 推延迟;KV 账本没算,两处设计不可行。
① 先由法务圈定"不得委托第三方处理"的流量(令790号第31条 + 重要数据识别)
② 只为这部分配算力,其余一律走已备案公网
③ 容量用排队仿真 + KV 账本定,不用 roofline
④ 调度用共享池 + 优先级,不做静态隔离
⑤ 理由只有一条:法律上不得外发
⑥ 全部数字标证据等级,SELF_MEASURED 之外不进承诺
立即可执行的五件事(不依赖任何未闭合 TBD)
- 把预注册文件交 PMO 封存,然后启动 4 周 observe-only 埋点(PIPIA 先行)。零硬件投入,产出是让后续所有决策可证伪的基线。
- 向法务提一个问题:按《网络数据安全管理条例》第29–31条,公司在中国区持有的数据中,哪些被告知/公开发布为重要数据,哪些 S3/S4 在脱敏后仍不得委托第三方处理?这个问题的答案决定 CapEx 规模,也决定本方案是否还需要存在。
- 向微软书面索取企业版 Copilot 在中国内地租户的功能可用性矩阵。在拿到之前,商业论证第一支柱标"待核"。
- 启动机房勘察(四项:单柜可用功率 / 上游配电容量 / 冷通道回风温度 / 楼板承重)。设施工期长于采购,必须先启动。
- 把 B2 的 6 条验收条款发给候选供应商,看谁敢签。不敢签二值条款的供应商直接排除——这一步零成本,筛选效果最强。