China AI Localization · Decision-Grade Argument v2

在华 MNC AI 私有化:三条推理链挖到可被外部审计的深度

本版不扩大范围。v1 的 13 节分析被压缩为三条推理链 + 三项强制自检。每个数字标注证据等级,每条监管结论附文件编号与生效状态,每项计算提供可复跑脚本。v1 的三个核心论点在本版中被证伪。

日期:2026-10-25 | 前版:v1(2026-10-24,已上线 aivbuddy.com/ppt,含已知缺陷)
可复跑产物:kv_budget.py · ttft_class_isolation.py · buildvsbuy_mc.py · replay_bench.py
数据契约:PRE_REGISTRATION.md · regulatory_register.json · evidence_and_acceptance.json
证据等级:PRIMARY SELF_MEASURED THIRD_PARTY LEAD_ONLY(禁入结论)

00本版与 v1 的关系:三个核心论点被自己的计算证伪

先列证伪结果。如果这一节成立,v1 的结论段就不能再用了。

v1 论点 ①
「GxP 可验证性是自建的决定性理由」——隐含逻辑:私有部署 → 版本冻结 → 可通过验证 → AI 进 GxP 流程。
证伪:EU GMP Annex 22(2025-07-07 草案,咨询 2025-10-07 截止,未生效)把动态/概率性/生成式模型(明确含 LLM)排除在适用范围外,也排除在关键 GMP 应用之外。权重在谁手上不改变这件事。私有化是必要条件,不是充分条件。
v1 论点 ②
「自建单位成本是公网的 4 倍,但合规刚性值得付」——给了点估计 ¥823 万/3年,无敏感度。
证伪:4 万次蒙特卡洛显示,即使把日 token 量放大 100 倍到 200 亿/日,自建 48 月累计仍是全公网的 1.07 倍,48 月内回本概率 3.5%。成本在任何规模假设下都不构成自建理由。而且 v1 把全公网年成本写成 ¥130 万,实际按口径算只有 ¥44 万/年——比一个 FTE 还便宜,v1 高估 3 倍。
v1 论点 ③
「批处理场景须与交互场景物理隔离」——同时又把两类流量放进同一池做容量规划,并给了全局 SLO「TTFT P95 ≤1.5s」。
双重证伪:(a) 全局 SLO 物理不可达——longdoc 类 P95 输入的纯 prefill 时间地板已达 7.34s,与买几台机器无关;(b) 静态物理隔离是三种调度中最差的,交互类 P95 恶化 1.9–2.3×,因为固定切分算力会搁置产能。正解是共享池 + 优先级 + work-conserving,比混跑再好 31%。

另有两处方法学错误与四处遗漏:

本节结论 v1 不是"不够深",是三个主结论方向错了。根因不是查得少,是查的层级不对:法规读的是律所营销文与百科,硬件数字来自二手博客与电商页,需求账本整个是构造的。当结论要支撑百万级采购时,每条支撑证据必须能回溯到一手来源;二手来源只能用于发现线索,不能用于支撑结论。

A1链A · 埋点方案与预注册:让容量模型变成可证伪的命题

v1 的 token 账本是构造的,且天然不可证伪——实测是多少都能回头调参数说"本来就是这个意思"。预注册消除这个退路。

Shadow-mode 埋点(4 周,observe-only)

现有调用方 ──→ TokenHub(observe-only) ──→ 原有去向(公网 API / 现有服务) │ └──→ 轨迹库(仅元数据,不落原文) 关键约束:此阶段不得同时上线阻断策略 ——否则采到的是"被管控后的行为",不是基线行为。
采集字段(最小必要)

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 token199 M/日落在 [66M, 597M] 外不得按原 CapEx 提报,重建模型后重走 P1 立项
输入:输出比86 : 14输入占比 <70% 或 >94%重算 prefill/decode 配比与选型方向
峰谷系数 K_peak3.2落在 [2.0, 5.0] 外重算峰值容量
有效工作分钟 M_work300落在 [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
本预注册自身的局限(诚实声明)。① 预测值来源仍是推理而非经验——我没有同类企业真实数据,预注册不能让错误先验变正确,只能保证错误会被发现;② 4 周可能不足以捕获年度峰值(年报期/合规审计期/新药上市期),首年应按季度复采;③ observe-only 期间行为会漂移——员工知道被观测后使用更"规范",这个方向会低估影子 AI 真实规模,故 TBD-05 应取「网关日志 ∪ 匿名问卷」的较大值;④ 判废阈值 1/3×~3× 是经验值,非统计推导。

完整文件: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 博客抄。

GQA / MHA: per_token_bytes = 2 × n_layers × n_kv_heads × head_dim × bytes (2 = K 和 V 各一份) MLA: per_token_bytes = n_layers × (kv_lora_rank + qk_rope_head_dim) × bytes (MLA 只缓存压缩 latent + 解耦 rope 分量,不是 K/V 各一份) 并发上限 = (卡组总显存 × 0.9 − 权重) ÷ (per_token_bytes × 上下文长度)
模型注意力层KV/token权重 FP8证据等级
DeepSeek-V3 系MLA6134.31 KiB624.9 GiBSELF_MEASURED 按公开 config 显式计算,可复跑
Qwen3-32BGQA64128.00 KiB30.5 GiBSELF_MEASURED config.json: n_kv_heads=8, head_dim=128
GLM-4.6GQA92184.00 KiB330.6 GiB部分待核 层数与参数为公开规格;n_kv_heads/head_dim 按同架构推定

最大并发请求数(受 KV 容量硬约束,非受算力约束)

模型卡组4K8K32K128K判定
DeepSeek-V3(MLA)8× RTX PRO 6000 SE4942476115可用768GB 装 625GiB 权重后余 ~90GiB
Qwen3-32B(GQA)1× RTX PRO 6000 SE11155133证伪 v132K 下仅 13 并发,达不到 v1 假设的 batch 32–64
GLM-4.6(GQA)4× RTX PRO 6000 SE(TP=4)201020证伪 v1v1 说"双实例 TP=4 做 HA"——长上下文下根本不可用
GLM-4.6(GQA)8× RTX PRO 6000 SE(TP=8)5012506215单实例 TP=8 才可用,意味着放弃双实例 HA
反直觉发现(v1 完全没看到)。MLA 的 DeepSeek-V3(671B 总参)在长上下文下比 dense 的 Qwen3-32B 更省 KV——34.31 vs 128.00 KiB/token,差 3.7 倍;比 GLM-4.6 省 5.4 倍。
直接推论:对 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 地板含义
interactive2,2000.27s0.68s0.99s有余量,SLO ≤1.5s 可达
longdoc28,0003.50s7.34s9.97sSLO 不可达零排队时的纯 prefill 时间
v1 的全局 SLO「TTFT P95 ≤ 1.5s」对含长文档的混合负载在物理上不可能。longdoc 类 P95 输入的纯 prefill 时间地板就是 7.34s,与排队无关、与买几台机器无关。SLO 必须按流量类分别承诺,否则这个指标从第一天起就在骗人。

发现二:三种调度策略对比(同总负载、同总算力,只改调度)

总λ策略交互 P50交互 P95交互 P99长文 P95交互达标
(≤1.5s)
相对 mixed
0.35mixed(FIFO 混跑)0.32s1.00s1.66s12.27s✓基准
isolated(v1 推荐)0.68s2.00s3.55s19.44s✗2.00×(更差)
priority(本版推荐)0.30s0.79s1.12s10.66s✓0.79×(更好)
0.65mixed0.38s1.45s2.58s16.74s✓基准
isolated0.83s2.76s4.42s33.48s✗1.90×(更差)
priority0.35s1.00s1.52s19.06s✓0.69×(更好)
为什么 isolated 最差

静态按 token 占比切分算力后,interactive 池只拿到约 47.5% 的 prefill 预算。长文档空闲时,那部分产能被搁置,交互请求借不到。这是经典的 non-work-conserving 损失。

为什么 priority 最好

共享单池 + 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_SPECKV 容量计算、权重装载可行性、功耗与机柜规划吞吐承诺、TTFT 承诺
RTX PRO 5000 72GB:1,344 GB/s / 300W / 4×DP 输出 + 主动散热VENDOR_SPEC同上;形态规格直接支撑"工作站卡不适合 8 卡密集机架风道"的判断—
Atlas 800I A2:8×910B / 单卡 64GB / 整机 2.24 PFLOPS FP16VENDOR_SPEC容量与功耗规划规格表写"8×64GB,内存带宽 1.6TB/s",未说明是单卡还是整机聚合口径 → 此项禁止用于 decode 吞吐推算,直到实测
海光 K100-AI:64GB HBM2E / 796 GB/s / 192 TFLOPS FP16VENDOR_SPEC容量计算(按保守值 796 取)带宽有 796 / 896 两个流通口径,来源冲突
昆仑芯 P800:单机 8 卡可跑 671B 满血(8bit);32 台支持全参训练VENDOR_SPEC功能性声明(装得下)可采信不是性能声明,不可据此推吞吐
昆仑芯 P800:96GB HBM3 / 4 TB/s / TDPLEAD_ONLYREJECTED拆解分析认定 GDDR6 并明确否认 HBM3;4TB/s 对 GDDR6 物理不成立;TDP 无官方披露。禁止进入任何计算
昆仑芯 P800 卡价 ¥3.2万 / ¥14.6万 / ~¥10万LEAD_ONLYREJECTED三口径离散 4.5 倍,无法做 TCO。必须正式询价
8×RTX PRO 6000 跑 DS-V4-Flash FP8:vLLM+DSpark 946 / SGLang 653 / DwarfStar 122 tok/sTHIRD_PARTY支撑定性结论「引擎差异 7.8× > 硬件差异」;排除劣选引擎v1 误用实测对象是 284B,激活参数与 KV 结构均不同,不可迁移到 671B 容量计算
海光 K100-AI 跑 284B INT8:总吞吐 450 tok/s,TTFT 均值 50s / P99 82s;128K 长文 163sTHIRD_PARTY排除海光做交互式旗舰池——TTFT 量级差两个数量级,非调优可弥补这是全部外部数据中决策价值最高的一条,因为它是否证性的:用来排除选项远比用来支持选项可靠
Atlas 800I A2 跑 MoE W8A8:默认 2,200 → 优化后 6,600 tok/sTHIRD_PARTY量级判断6,600 是深度优化后结果,非开箱即得。若采信,须同时把「达到该水平所需优化工时」计入项目成本

SELF_MEASURED 缺口(PoC 必须亲自补齐的六项)

  1. 同硬件引擎横评(vLLM / SGLang / 厂商引擎,同模型同负载)—— PoC 预算的 50% 应投此项,回报最高
  2. 671B 在目标硬件上、用自有回放轨迹测的 TTFT P95(按流量类分别)
  3. 目标并发下的实际 KV 占用与 OOM 边界(验证 A2 的计算)
  4. 国产栈需适配的算子清单与工时
  5. 整机满载实测功耗与机柜回风温度
  6. 跨节点 RoCE 实测带宽(nccl-tests / hccl_test)
采购顺序铁律 先定推理引擎,再定卡。同一批 8 张卡换引擎吞吐差 7.8×,远大于任何两款硬件之间的差异。把 PoC 预算的一半投入引擎调优与横评,而不是多买硬件。

B2链B · 回放压测 harness 与可写入合同的验收条款

与常见压测的根本区别:输入来自网关导出的真实轨迹,不是 ShareGPT 合成集。合成集的长度分布与企业负载差一个量级,用它测出的 TTFT 没有参考价值。

# 1) 从 TokenHub 导出轨迹(字段见 A1) # trace.jsonl: {"ts":…, "cls":"interactive|longdoc", "n_in":…, "n_out":…, "prefix_group":"…"} # 2) 回放压测(引擎 × 并发 网格) python replay_bench.py --trace trace.jsonl \ --base-url http://infer-l1.corp.internal:8000/v1 \ --model deepseek-v3 --engine vllm \ --concurrency 1,4,16,64 --duration 300 # 3) 产出 results_vllm_deepseek-v3.json,字段与合同验收条款对齐 # evidence_grade = SELF_MEASURED(唯一可用于承诺的等级) # 无轨迹时 --synthesize 仅作冒烟,标 SYNTHETIC_SMOKE,禁止用于容量承诺

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-20252025-09-01
现行
注意是 GB 不是 GB/T —— 强制性国标。规定标识的技术实现方法
生成式 AI 服务安全基本要求GB/T 45654-20252025-11-01
现行
训练数据/模型/安全措施三类要求 + 附录B 安全评估参考方法。是安全评估的事实依据(推荐性)
个人信息保护合规审计管理办法网信办令 第18号2025-05-01v1 漏掉 · 条文待调取对达门槛的个人信息处理者设定期合规审计义务,MNC 中国区通常达标。须纳入 P0 法务清单
网络安全法(2025 修正)2025-10-28 全国人大常委会修改决定2026-01-01v1 引用的是 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-1410 条高层原则(以人为本、基于风险、遵循标准、明确场景边界、多学科整合、数据治理与文档、规范模型设计、基于风险的性能评估、全生命周期管理、信息传递清晰必要)→ 可作内部 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)

Microsoft 365 Copilot 在中国内地的可用性。一手引述已取得——microsoft.com 官方产品页脚注:「AI/Copilot 功能在中国或澳门特别行政区不可用」。

但必须注意一个 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。私有化在这里是负资产,不是资产
链C 结论(推翻 v1) 私有化部署解决的是数据不出域,不解决生成式模型能否做 GxP 决策。后者是监管对技术类别的限制,与部署位置正交。
→ 自建的正当理由收窄为一条:《网络数据安全管理条例》第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-1Annex 22 定稿版(EMA 目标 2026 年底)纳入生成式模型,允许在稳健控制策略下用于关键 GMPC2 的"仍不被允许"失效 → 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 可脱敏后外发自建的最后一条理由消失 → 应放弃自建,只建网关
F-7 是本版最重要的一条。它承认:如果法务结论是"没有任何数据在法律上不能交给第三方处理",那么本方案的全部硬件部分都应作废,只保留 TokenHub 网关。一份不敢写出自己何时该被放弃的方案,不是方案,是推销。

D2build-vs-buy 蒙特卡洛:成本在任何规模假设下都不是自建的理由

4 万次模拟 · 48 个月 · 四个随机变量:公网年价格留存因子 d∈[0.25,0.95](Beta)、需求年增长 g(中位 2.2×,Lognormal)、自建稳态利用率 u(Beta)、FTE 年成本(Normal 50±8 万)。

当前画像 199M tok/日
3.66×
自建 48 月累计 / 全公网
回本概率 0.0%
放大 10 倍(2,000M/日)
1.26×
回本概率 0.0%
放大 100 倍(20,000M/日)
1.07×
回本概率仅 3.5%
成本追平点
>20,000
百万 token/日
扫描范围内不存在
日 token(百万)全公网 48 月自建 48 月(35%承载)自建/公网48 月回本概率
199(当前画像)300 万1,097 万3.66×0.0%
500747 万1,493 万2.00×0.0%
1,0001,502 万2,224 万1.48×0.0%
2,0002,973 万3,732 万1.26×0.0%
5,0007,423 万8,386 万1.13×0.1%
10,00014,839 万16,163 万1.09×1.3%
20,000(当前的 100 倍)29,635 万31,589 万1.07×3.5%

为什么差距这么大:固定成本结构

全公网:固定成本 ≈ 0,纯变动。199M/日 × 365 × ¥6/百万 = ¥44 万/年 自建 :固定成本 = 电+机柜 ¥30万/年 + 2.5 FTE × ¥50万 = ¥125万/年 = ¥155 万/年 ↑ 仅人力一项就是全公网总成本的 2.8 倍 + CapEx ¥230 万 结论:在这个 token 量级上,公网 API 账单比一个 FTE 还便宜。 自建的成本被人力主导,而人力不随 token 量下降。
这同时推翻了 v1 和我上一轮的说法。v1 说"自建是公网 4 倍"(¥27 vs ¥6 单价)——这个比值碰巧接近本版的 3.66×,但 v1 的两个分量都算错了(公网年成本高估 3 倍、自建人力只算 1.5 FTE)。更重要的是:v1 把它当点估计,没有规模扫描,因此无法支撑"成本永不是理由"这个真正的结论。我上一轮说"公网降价可能在 18 个月内让自建论证失效"——方向对,但实际情况更极端:自建论证在成本维度上从未成立过,不需要等降价。
D2 结论 成本永远不会是自建的理由,在任何规模假设下都不是。自建的唯一正当理由是「这部分数据在法律上不能交给第三方处理」。
→ 因此 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 写入,保留
2GxP 场景一个都没落地。Annex 22 按原草案定稿,PV 项目在 QA 评审时被判定"生成式模型不在允许范围",P2 核心价值归零EMA 工作计划未出现纳入生成式模型的迹象;QA 拒绝出具验证策略季度P2 价值重心预先移至合同审阅 + 文档起草 + 代码助手(均不受 Annex 22 约束)。GxP 场景降级为"人在环辅助",不写进 ROI
3机房没改造完,硬件在仓库躺了 5 个月。折旧已开始计提,但没产生一个 tokenP0 勘察报告显示单柜 <10kW;改造施工合同迟于硬件采购合同签署月设施改造必须先于硬件采购启动。合同签署顺序写进 PMO 检查表。Phase 1 先上边缘节点(2kW 单相电可供)
4实测需求只有估算的 1/4,买多了。预注册判废触发,但硬件已到货埋点第 2 周的日均 token 外推 < 66M周P1 只买 1 旗舰 + 1 边缘,第二台等实测。预注册判废阈值已写明此动作
5RAG 越权事故。一名调岗员工通过 AI 检索到原部门的 S4 临床数据,触发信息安全事件上报越权红队测试出现任一命中;索引层 chunk 四字段完整率 < 100%季度(红队)
日(字段)
检索层用当前身份二次鉴权(非索引时快照);分级随 chunk 继承;安全投入 40% 集中此项
62.5 FTE 一直没到位。引擎调优没人做,节点跑在默认配置上,吞吐只有可达水平的 1/5P0 结束时编制未确认;6 个月内未完成一次引擎横评月TBD-14 列为 G0 硬条件。预留外部实施支持预算作为缓冲
7Global 中途收回授权。集团 AI 治理政策统一后要求中国区并入全球栈,自建资产变孤岛集团发布全球 AI 平台路线图;Global CISO 对 Risk Memo 回应含"待集团统一"字样季度P0 必须拿到 DEP-3 书面例外授权(基于"Global 产品在中国区不可用"的书面证据)。授权未到手不进 P1
8公网 API 降价到让自建显得荒谬。审计问"为什么花 ¥343 万做一件 ¥44 万/年能买到的事"公网混合单价 12 个月内跌破 ¥3/百万 token季度立项文件里就不要把成本写成理由(D2)。把理由锚定在令790号第31条的"不得委托第三方处理"上——这条不随价格变化
Pre-mortem 的用法。把"早期信号"列直接做成 PMO 的月度检查表。死因 2 和死因 8 是本版新增的——v1 没有识别,因为 v1 既不知道 Annex 22 的立场,也没做价格敏感度。

E1外部证据清单:不由我与大白判定的验收依据

重写后的提示词要求:验收不由你我判定。下表每项标明当前状态、责任人、到位时点。这张表的"缺失"行数就是本方案当前的可信度缺口。

#外部证据状态责任人到位时点它证明什么 / 为什么不能由我出
1可复跑 benchmark harness + 原始结果产物部分已有harness 已交付
结果缺失
IT 架构P0 W7别人在同硬件重跑能落在 ±15% 内。我只能给工具,不能给结果——结果必须在真硬件上跑
2企业质量部(QA)签字的 Annex 22 / GAMP AI Guide gap assessment缺失质量部 QAP1 M6GxP 场景可行性的唯一有效判定方。我对 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 架构 + PMOP0 W8最关键一项这是唯一能证明容量模型不是事后编的办法。偏差 >3× 即判模型失效
9法务对"是否持有重要数据 / S3·S4 能否脱敏外发"的结论缺失法务P0 W8决定本方案是否还有存在意义(见 F-7)。若结论为"均可外发",硬件部分应全部作废
10EMA 工作计划季度复查记录(Annex 22 是否纳入生成式模型)缺失法规事务 + QA按季度F-1 的触发监测。这条结论会变,不能一次性判定
当前状态汇总缺失 7 项 · 部分已有 3 项 · 完整 0 项 → 本方案目前的全部可信度建立在「我的计算是可复跑的」这一点上,而非建立在外部验证上。这是诚实的起点,不是终点。

E2修正后的建议:从"按总需求建算力"改为"按不得外发的流量建算力"

v1 的逻辑(已作废)

① 盘点总需求 199M token/日
② 按峰值 + 分层路由推算需 16–24 卡
③ 配 2–3 节点,CapEx ¥343 万
④ 理由:GxP 可验证性 + 合规 + 成本(4×,可接受)

错在哪:GxP 理由被 Annex 22 推翻;成本理由被蒙特卡洛推翻;容量用 roofline 推延迟;KV 账本没算,两处设计不可行。

v2 的逻辑

① 先由法务圈定"不得委托第三方处理"的流量(令790号第31条 + 重要数据识别)
② 只为这部分配算力,其余一律走已备案公网
③ 容量用排队仿真 + KV 账本定,不用 roofline
④ 调度用共享池 + 优先级,不做静态隔离
⑤ 理由只有一条:法律上不得外发
⑥ 全部数字标证据等级,SELF_MEASURED 之外不进承诺

立即可执行的五件事(不依赖任何未闭合 TBD)

  1. 把预注册文件交 PMO 封存,然后启动 4 周 observe-only 埋点(PIPIA 先行)。零硬件投入,产出是让后续所有决策可证伪的基线。
  2. 向法务提一个问题:按《网络数据安全管理条例》第29–31条,公司在中国区持有的数据中,哪些被告知/公开发布为重要数据,哪些 S3/S4 在脱敏后仍不得委托第三方处理?这个问题的答案决定 CapEx 规模,也决定本方案是否还需要存在。
  3. 向微软书面索取企业版 Copilot 在中国内地租户的功能可用性矩阵。在拿到之前,商业论证第一支柱标"待核"。
  4. 启动机房勘察(四项:单柜可用功率 / 上游配电容量 / 冷通道回风温度 / 楼板承重)。设施工期长于采购,必须先启动。
  5. 把 B2 的 6 条验收条款发给候选供应商,看谁敢签。不敢签二值条款的供应商直接排除——这一步零成本,筛选效果最强。
最后一句 本版最有价值的产出不是任何一个数字,是七条可检验的推翻条件(D1)和一张标着"缺失 7 项"的外部证据清单(E1)。v1 看起来更完备,因为它没写这两样东西。一份把自己的失效条件写清楚的方案,比一份看起来完备的方案更能支撑百万级决策。