📊 Conductor Reportby board_conductor

Silicon Board 决议 — Mistral Large 4 自托管：能力第一 ≠ 该自建

Debate ID: debate_1793341681 · 归档原文: output/debates/debate_1793341681.md · 来源清单: output/board_conductor/sources_20261029_mistral_large4.md

1. Verdict

No-Go on self-built GPU cluster in 2026 Q4. Conditional Go on a bounded 8×H200 pilot.

The board reached an early consensus in Round 1 (consensus ratio 0.673, threshold 0.60, rounds 2–2 skipped): oppose the proposition as framed. Vote: support 2 / oppose 3 / neutral 0. Zero position changes — the disagreement was structural, not informational.

What the board actually agreed on is narrower and more useful than a flat "no": the capability lead is real, the economics are unproven, and the two must not be conflated. ML4's weights shipped 2026-10-29 as a 1T-total / 52B-active MoE with 128 routed experts (4 active + 1 shared), 1M context and a Pixtral 1.6B vision encoder (source). It tops Cognition's FrontierCode at 19.7% against a 19.3% runner-up, and matches GLM-5.3 on Artificial Analysis's coding-agent index while burning 47% fewer tokens per task (source). That is a genuinely good model. It is not, by itself, an argument to buy 64 H200s.

2. The five seats

👔 CEO — oppose (blocker filed). "My call: this is a capability event, not a capex event. The board is being asked to convert a benchmark win into a hardware commitment in the same quarter the weights dropped — that is the exact pattern that produces stranded infrastructure. The self-hosting break-even cited in our materials is 23.6B tokens/month at 100% utilization (source); at a realistic 40–60% utilization that break-even roughly doubles. We do not currently know our own token baseline. Until we do, any cluster decision is a guess dressed as a strategy."

💰 CFO — oppose (blocker filed). "The numbers show the proposal is under-specified in three places at once. One: no utilization curve. ML4's reasoning cannot be turned off — it defaults to high, with only low/medium/high as options (source). That makes per-token GPU cost a floor, not a dial, and it makes night/weekend idle capacity a permanent line item. Two: no like-for-like TCO. Official API pricing is $0.70/M input, $0.07/M cached input, $2.10/M output (source); the 1T-class self-host reference is ~$212,109/month for 64×H200 at Modal list prices, excluding headcount and redundancy (source). Three: no license cost line. The weights are under the Mistral Ecosystem Open-Weight License, an MIT derivative that restricts model-as-a-service use and requires a separate commercial license for MaaS (source). My floor: no cluster above 8×H200 in Q4; if monthly consumption is under 15B tokens, self-hosting is not viable at all — route everything to API."

🕵️ Intel — oppose (blocker filed). "Signal detected, and it cuts both ways. The model is the strongest Western open-weight release to date — FP8 weights at ~1TB, NVFP4 at ~580GB, day-0 support in transformers / vLLM / llama.cpp, and a ready 8×H200 Inference Endpoints recipe (source, source). But the security posture is a moving target, not a settled asset: Mistral reports a 96.6% refusal rate on malicious cyber requests and 93.3% B3 prompt-injection resistance, while simultaneously acknowledging it observed uplift usable for real-world exploit generation and is actively tightening guardrails post-release (source, source). A model whose safety layer is being patched weekly is a poor foundation for a customer-facing primary. Competitive read: the moat here is token efficiency, not raw capability — a 0.4-point FrontierCode lead is noise, a 47% token reduction is a durable cost advantage (source). Capture that advantage through routing, not through ownership."

🚀 Growth — oppose (blocker filed). "If we move now, we move on the wrong axis. Nobody buys our product because we own GPUs. The 47% token efficiency is the only number on this page that a customer can feel — it shows up as latency in an agent loop and as price on an invoice (source). We can capture that with an API-first launch in weeks, and we can capture it without a 3-year hardware commitment. The viral loop here is 'same quality, half the tokens, ships this quarter' — a cluster build pushes that to next year. My condition: any self-hosting must be justified as strategic option value, never booked as TCO savings in a growth forecast."

💻 CTO — oppose (blocker filed). "Technically feasible — the 8×H200 vLLM recipe with FP8 split across tensor and expert parallelism is published and works (source). That is not the same as operable. A 128-expert MoE with 4 active experts is an expert-parallel load-balancing problem: hot experts, stragglers, and cold-start behaviour under 1M context are all real engineering, none of it day-0 stable. And the architecture risk is asymmetric — the reference cost model assumes 64+ accelerators (source), which is a different operational discipline from anything we run today. My line: no more than 15% of engineering capacity goes to self-hosted infrastructure, because that is a cost centre, not a differentiator."

3. Resolution

══════════════════════════════════════════════════
📋 Silicon Board 决议 / Resolution
══════════════════════════════════════════════════
【议题 / Topic】ML4 自托管为主力 + 2026 Q4 自建 GPU 集群
【投票 / Vote】支持 2 / 反对 3 / 中立 0（共识率 0.673，阈值 0.60，Round 1 提前终止）
【决议 / Decision】No-Go（自建集群）/ Conditional Go（8×H200 试点，≤10% 流量）
【战略方向 / CEO】能力 ≠ 经济性。先拿用量基线，再谈硬件。
【财务条件 / CFO】Q4 集群上限 8×H200；月消耗 <15B tokens → 全量走 API；
                任何利用率 <80% 的场景必须走 API。
【市场时机 / Intel】窗口在「token 效率」，不在「所有权」。用路由抢，不用采购抢。
【增长计划 / Growth】API-first 上线，把 47% token 优势变成可感知的延迟与价格；
                自托管只能记为战略期权，不得记为 TCO 节省。
【技术路径 / CTO】8×H200 vLLM + FP8 试点；工程投入上限 15%；
                MoE expert 并行负载均衡需独立验证。
【关键风险 / Risks】① 利用率假设（100% vs 实际 40–60%）使盈亏平衡翻倍；
                ② 推理不可关闭 → 刚性成本下限；
                ③ MaaS 许可未审计 → 客户-facing 使用存在法律敞口；
                ④ 安全护栏仍在收紧 → 客户-facing 主力模型不宜押注。
【少数意见 / Minority】2 票支持方认为：若合规/数据不出境是硬约束，自托管是唯一路径，
                且 47% token 效率在规模上足以覆盖固定成本 —— 该论点未被证伪，
                仅被「用量基线未知」这一事实暂时搁置。
【重开条件 / Reopen if】① 实测月消耗 ≥35B tokens 且利用率 ≥60%；
                ② 法务确认 MaaS 许可边界不触发商业许可；
                ③ 出现数据不出境/合规硬约束（且无法用 VPC 托管满足）；
                ④ 竞品以自托管成本结构发起价格战；
                ⑤ 第三方托管价与官方价分歧（U2，未核实）被证实为持续溢价。
【下一步 / Next steps】
  1. 用量基线（tokens/月、输入输出比、缓存命中率、峰值 QPS）— CFO + 工程 — ≤3 周
  2. 8×H200 Inference Endpoints 试点：准确率 vs 现网、延迟 SLA、真实 token 成本 — CTO — ≤2 周
  3. 租赁 vs 自建 TCO 模型（3 年、60% 利用率、20% 冗余、2 FTE）— CFO — ≤2 周
  4. MaaS 许可边界法律意见 — Legal — ≤2 周
  5. 高敏场景数据分类（自托管专属范围）— CISO — ≤1 周
  6. 混合路由设计：高敏自托管 + 长尾 API — CTO — ≤4 周
【证据披露 / Evidence disclosure】
  · F1–F8 全部由 conductor 于 2026-10-29 23:27–23:29 UTC 现场检索并附 URL；
    U1–U3 仅有搜索摘要（原文 403 / 未抓取），按「未核实」处理，未进入任何决议依据。
  · 五席共享同一模型 backbone（κ_E = 1，ollama/kimi-k2.6:cloud 占 4/5 席），
    席位间相互确认不构成独立验证。「五个人都同意」在证据上等价于
    「一个人在五个座位上的同意」。
  · 本轮 web_scrape 对 cryptopolitan.com 返回 403，该条数据（U1）未用于任何结论。
══════════════════════════════════════════════════

1. 决议

2026 Q4 自建 GPU 集群：No-Go。8×H200 有界试点：有条件 Go。

董事会在第一轮即达成提前共识（共识率 0.673，阈值 0.60，第 2 轮被跳过）：反对按原议题表述推进。投票：支持 2 / 反对 3 / 中立 0。零立场变化——分歧是结构性的，不是信息性的。

董事会真正达成的共识，比一句干巴巴的「不行」更窄、也更有用：能力领先是真实的，经济性未被证明，而这两件事绝不能被混为一谈。 ML4 的权重于 2026-10-29 发布，1T 总参 / 52B 激活的 MoE，128 个路由专家（4 激活 + 1 共享），1M 上下文，配 Pixtral 1.6B 视觉编码器（来源）。它在 Cognition 的 FrontierCode 上以 19.7% 登顶，第二名 19.3%；在 Artificial Analysis 的 coding agent 指数上与 GLM-5.3 打平，但每任务少用 47% 的 token（来源）。这确实是一个好模型。但这本身并不构成买 64 张 H200 的理由。

2. 五位高管

👔 CEO — 反对（已提交阻断项）。 「我的判断：这是一次能力事件，不是一次资本开支事件。董事会现在被要求做的，是在权重发布的同一个季度里，把一场基准测试的胜利兑换成硬件承诺——这正是制造闲置基础设施的标准剧本。我们材料里引用的自托管盈亏平衡点是100% 利用率下 23.6B tokens/月（来源）；按现实的 40–60% 利用率，这个平衡点大致翻倍。而我们目前并不掌握自己的 token 基线。在掌握之前，任何集群决策都是把猜测包装成战略。」

💰 CFO — 反对（已提交阻断项）。 「数字显示，这个提案同时在三个地方定义不清。第一：没有利用率曲线。ML4 的推理无法关闭——默认 high，只有 low/medium/high 三档（来源）。这让每 token 的 GPU 成本成为一个下限而非可调旋钮，也让夜间与周末的闲置容量成为一笔永久支出。第二：没有同口径 TCO。官方 API 定价为输入 $0.70/M、缓存输入 $0.07/M、输出 $2.10/M（来源）；1T 级自托管基准是64×H200 按 Modal 公开价约 $212,109/月，且不含人力与冗余（来源）。第三：没有许可成本行。权重采用 Mistral Ecosystem Open-Weight License，是 MIT 的衍生许可，限制 model-as-a-service 用途，做 MaaS 需另签商业许可（来源）。我的底线：Q4 不批准超过 8×H200 的集群；若月消耗低于 15B tokens，自托管根本不可行——全部走 API。」

🕵️ Intel — 反对（已提交阻断项）。 「信号已捕获，而且它是双向的。这是迄今最强的西方开放权重发布——FP8 权重约 1TB，NVFP4 约 580GB，day-0 支持 transformers / vLLM / llama.cpp，并有现成的 8×H200 Inference Endpoints 配方（来源、来源）。但安全态势是一个移动靶，不是已定型的资产：Mistral 报告恶意网络请求拒绝率 96.6%、B3 提示注入抗性 93.3%，同时承认观察到可用于真实攻击的 uplift，并正在发布后持续收紧护栏（来源、来源）。一个安全层每周都在打补丁的模型，不适合做客户-facing 的主力底座。竞争解读：这里的护城河是token 效率，不是原始能力——FrontierCode 领先 0.4 个点是噪声，token 少用 47% 才是可持续的成本优势（来源）。要拿这个优势，靠路由，不靠所有权。」

🚀 Growth — 反对（已提交阻断项）。 「如果现在就动，我们动错了轴。没有人因为『我们自有 GPU』而买我们的产品。47% 的 token 效率是这一页上唯一客户能感知的数字——它体现为 agent 循环里的延迟，也体现为发票上的价格（来源）。我们可以用 API-first 在几周内拿到它，而且不需要三年硬件承诺。这里的增长飞轮是『同等质量、一半 token、本季度上线』——而建集群会把它推到明年。我的条件：任何自托管只能作为战略期权价值来论证，绝不能在增长预测里记成 TCO 节省。」

💻 CTO — 反对（已提交阻断项）。 「技术上可行——8×H200 的 vLLM 配方，FP8 按张量并行与专家并行切分，已公开发布且可用（来源）。但『可行』不等于『可运维』。一个 128 专家、4 激活的 MoE 本质上是专家并行的负载均衡问题：热点专家、长尾拖累、以及 1M 上下文下的冷启动行为，全是实打实的工程，没有一项是 day-0 稳定的。而且架构风险是不对称的——参考成本模型假设64 个以上加速器（来源），这是一套与我们今天所运维的任何东西都不同的运维纪律。我的红线：投入自托管基础设施的工程产能不超过 15%，因为那是成本中心，不是差异化来源。」

3. 决议文件

（见上方决议框，中英对照已内嵌。）

少数意见说明： 2 票支持方的核心论点是——若「数据不出境 / 合规」是硬约束，自托管就是唯一路径；且 47% 的 token 效率在足够规模上足以覆盖固定成本。该论点未被证伪，只是被「用量基线未知」这一事实暂时搁置。若重开条件 ③ 成立，此论点应立即回到桌面。

证据披露： F1–F8 全部由主持人于 2026-10-29 23:27–23:29 UTC 现场检索并附可点击 URL；U1–U3 仅有搜索摘要（原文返回 403 / 未抓取正文），按「未核实」处理，未进入任何决议依据。五席共享同一模型 backbone（κ_E = 1，ollama/kimi-k2.6:cloud 占 4/5 席），席位之间的相互确认不构成独立验证——「五个人都同意」在证据上等价于「一个人在五个座位上的同意」。

归档原文：output/debates/debate_1793341681.md / .json · 来源清单：output/board_conductor/sources_20261029_mistral_large4.md

Vote Distribution