4 张 H200 与 60.4% 召回：开源安全大模型 Aikido Altar 的银行内网适配性

先说结论

Aikido Altar 值得关注的不是"又一个安全扫描器"，而是它把一个此前几乎无法自建的能力搬进了银行内网：在银行自己的机房、用自己的代码、对内网系统做 AI 驱动的漏洞发现。

但有三个数字决定了它目前是"可评估项"，不是"可采购项"：

压缩本身是成功的，安全能力的论证是不充分的。 这两件事必须分开评价，下面逐层拆开。

一、技术构造：它到底是什么

压缩链路

GLM-5.3（BF16）                    1,506.7 GB   753B MoE，每层 256 个专家
        │  AWQ INT4 量化（W4A16）
        ▼
GLM-5.3 AWQ INT4                     488.2 GB   仅路由专家降到 4 bit
        │  REAP 专家剪枝（每层删 88 / 保留 168）
        ▼
Altar（pruned W4A16）                328.0 GB   官方标称 504B 参数
        │
        ▼  4× H200 + vLLM，128k 上下文

官方对 W4A16 的定义是：只有路由专家用 4 bit，注意力、共享专家、稠密层与输出头仍保持 BF16。所以它不是纯 4-bit 模型，这是刻意的保守设计——形式化定义与前文"LLM 生成的类表达式缺基数限制与量词限制"是同一种直觉：结构性的部分不敢降精度。

第一个容易被误读的点：86.4% 的体积下降来自量化

官方叙述的重心在"expert pruning"，但真正扛起体积下降的是 AWQ 量化。AWQ（arXiv:2306.00978）的思路是"只有约 1% 的权重是显著权重，保护它们就能大幅降低量化误差"，这是 2024 年就成熟的通用技术。

这个事实对银行的意义：如果你的目标只是"把 GLM-5.3 塞进内网"，量化这一步就能拿到 488 GB（约 2 张 H200 的量级），不必接受剪枝带来的能力损失风险。剪枝是在量化之后再省 160 GB 的第二刀。

第二个容易被误读的点：剪枝不改变推理延迟

剪枝后每 token 仍然从保留下来的 168 个专家里激活 8 个，激活参数量约 40B，与未剪枝模型相同。官方模型卡明确写着 "same as the unpruned model"。

所以剪枝只降低存储与显存占用，不改善推理速度。 银行若有低延迟要求（例如要在 CI 流水线里同步阻断），不要指望这一步——要降延迟只能靠量化、批处理或投机解码。

KL 散度 0.506 nats 说明什么、不说明什么

官方给出的保真度指标是"对全 BF16 的 KL 散度 0.506 nats"，并给了一个很有说服力的对照：同一 168 专家切片换成 EXL3 格式，KL 是 0.511——在这个位宽下，换量化格式几乎不动这个数。

但必须说清 KL 的含义：它衡量两个模型的输出分布差异，不衡量"能力保留了多少"。 KL 低只能证明"压缩没把模型改坏"。能力是否受损，要看召回率——而召回率恰好差 1.1pp。 这两件事不能互相替代。

二、REAP 的真实价值：域保留

官方没有保留"全局最常用"的专家，而是按单一领域的最大占比给每个专家打分：

each expert is scored by its largest share of any single domain's routed work, so every domain — code, rare languages, structured output — keeps its specialists.

理由在原文中写得很清楚：

Cybersecurity, coding, and language capabilities are distributed across experts; there is no cleanly labeled set of "cyber experts" to keep or discard.

这一点是对的，也是 REAP 用在安全场景下最有价值的部分。 如果按频次剪枝，会把某个能力的专门专家整片删掉——而 MoE 里"专门处理 SQL 注入检测的专家"和"专门处理法语文档的专家"在频次统计上可能都排不到前列。

支撑这个方法的 REAP 论文（Cerebras，arXiv:2510.13999，2025-10-15 首发，已核对摘要）核心结论是：在生成类任务上，专家剪枝优于专家合并，原因是合并会不可逆地损失细粒度路由控制；论文在 20B 到 1T 的多种 SMoE 上都验证了这一点，且在 Qwen3-Coder-480B 与 Kimi-K2 的代码生成上实现 50% 剪枝后近乎无损。

但要指出边界：REAP 论文的实验对象是 Qwen3-Coder、Kimi-K2，不含 GLM 系列，也不含金融或银行业语料。把它用在 GLM-5.3 上的效果，目前只有 Aikido 自己的实验数据支撑。

校准数据的来源与缺口

缺口在这里：语言保持用的是通用百科，不是金融或银行业语料。对银行场景，中文专业术语、业务规则、系统文档的理解能力是否足够，厂商未做任何验证。而对银行内网代码而言，这恰恰是最要命的一环。

三、基准测试的边界：这是全文最重要的一节

官方主动写明了三条限制，我原样引用：

It does not measure blind discovery across an entire codebase, execute exploits to validate findings, or evaluate the fix-proposal stage.

This measures targeted CVE rediscovery within a pipeline that uses other models for surrounding stages.

三个不能忽略的含义

一、60.4% 是"已知漏洞定向复现"，不是"盲测发现能力"。

任务设定是：给定 32 个已经知道存在的 CVE，让模型重新把它们找出来。这与"在真实攻击面上发现未知漏洞"是难度差一个量级的两件事。前者接近检索，后者接近创造。

拿 60.4% 去宣传"漏洞发现率"，是偷换概念。 银行采购评估时必须把这两个口径分开问供应商。

二、不执行 exploit 验证 = 误报无法收敛。

真实漏洞挖掘的判定标准是"能证明可利用"，不是"模型觉得这里有问题"。不执行 exploit 验证意味着输出停留在疑似层面，必须人工复核。

而漏报与误报同时存在：每次运行漏掉约 12.7 个（共 32 个），多报多少官方未披露。

三、它是流水线的一环，不是端到端工具。

周边阶段（编排、验证、修复建议）由其他模型承担。所以"Altar 发现了一个高危漏洞"这句话里，Altar 实际承担的工作量远小于字面意思。银行的采购标的应该是"这套流水线"，而不是"这个模型"。

一个统计学必须说清的点

Altar 与其量化父模型差 1.1pp。在 32 个漏洞 × 3 次 = 96 次试验上，1.1pp 相当于每次差 0.35 个漏洞。这在抽样噪声之内，不能宣称统计显著。

官方的表述是"approximately a one percentage point less"，这是诚实的。但要同时指出反面：这组数据同样无法证明压缩保留了能力——它只是没有检测到能力损失。 "未检测到"和"确实没有"是两回事。

缺少基线：60.4% 究竟算好还是算差

Aikido 只与自己的两个父模型对比，没有给出任何非 LLM 的基线。而这个数字如果缺少参照系，读者无法判断它是好是坏。

有一项独立的公开评测可以作为参照——但必须先说清它测的不是同一件事。LLMs4OL 2024 挑战赛（arXiv:2409.10146）测的是本体学习任务（术语类型化、分类发现、非分类关系抽取），不是漏洞检测。它给出的三个数字是：

这组数据的意义不在绝对值，而在两点结构性事实：

一、在最"难判断"的任务上，传统基线把 LLM 流水线拉开了 13 倍。 同一个子任务上，RF/LR/XGBoost 得 0.2109，LLM+检索增强只有 0.0164。论文解释这是取舍差异：LLM 队伍走"多而全"路线（高召回、低精度、大量假阳性），传统基线走"少而准"路线。这对银行采购的直接含义是：必须要求供应商给出非 LLM 基线。 如果一家安全厂商的 AI 方案跑不赢"规则引擎加传统 ML"，那它买的是概念而不是能力。

二、LLM 在"给候选打标签"上可用，在"生成结构"上不可用。 同一评测里术语类型化可达 0.9716，而分类发现只有 0.0164。

所以对 60.4% 的正确态度是：它既不像宣传的那么差，也不像批评的那么糟。 它是"在已知漏洞定向复现"这个相对容易的任务上、去掉 exploit 验证之后、由流水线单一环节贡献的数字。把它当作能力上限来规划是危险的，把它当作不可用也是错的。

覆盖率口径本身有个弱点

官方特意把"单次平均召回"和"三次覆盖"分开报告，并说明：找到一次和稳定找到不是一回事，未完成的运行单独计入。

这个披露是诚实的，但含义需要读出来：23/32 的覆盖率意味着 9 个漏洞（28%）在三次运行中一次都没被报出来。 而"三次里报一次"在实践中也无法直接采信——一个报一次就不报的结果，无法支撑"稳定发现"的结论。

四、许可证：一个必须澄清的误读

Altar 模型卡标注 License: other，并声明继承 GLM-5.3 的许可。我拉取了 zai-org/GLM-5.3 的完整许可全文（中英双语，Copyright 2026 Z.AI）逐条核对。

条款 2 的门槛不是按集团总营收算的

原文：

If the Licensee or any of its affiliates operates a Model as a Service business, and the aggregate revenue of the Licensee and its affiliates exceeds 10 billion US dollars ... in total over any consecutive 12 months, the Licensee must pass Z.AI's security review before using the Software or its derivative works for any commercial purpose.

这里有一个几乎所有人都会踩的误读。

大型银行的集团营收确实远超 100 亿美元。但门槛的触发条件是同时满足两项：

1. 运营 Model as a Service 业务，且
2. 该 MaaS 业务的连续 12 个月累计收入超过 100 亿美元

不是集团总收入超过门槛就要审。许可同时明确定义了 MaaS 并排除了一种情况：

This does not include (a) end-user products with model capabilities solely embedded within specific features or harnesses ...

结论：银行自建自用、不对外提供推理或微调服务，不属于 MaaS，条款 2 的安全审查义务不触发。 这是一个重要的正面结论——许可不构成障碍。

但条款 1 和条款 3 对银行更关键

条款 1 把合规责任写成了合同义务：

The Licensee's use of the Software must comply with applicable laws and regulations.

开源许可无法对抗监管要求。 技术自主可控不等于可以绕过监管。

条款 3 是全部免责：

THE SOFTWARE AND ANY OUTPUT AND RESULTS THEREFROM ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTY OF ANY KIND ... IN NO EVENT SHALL Z.AI OR ITS AFFILIATES OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY ...

注意这里明确排除了不侵权担保（noninfringement）。 如果银行把 Altar 的输出接进 CI 流水线做自动阻断，因漏报或误报导致的损失，许可把全部责任留在银行自己身上。这与银行外包风险管理"责任不因外包而转移"的原则方向一致——技术自主可控不等于责任可转移。

五、对银行网络信息系统安全的作用与意义

它解决的真实痛点：数据不出域

银行 AppSec 的根本矛盾是：代码是银行最高密级的资产之一，而主流 AI 编码与安全工具绝大多数是 SaaS。 上传即出境，很多情况下直接触碰数据出境监管。

Altar 的定位正是这个矛盾。它的不可替代场景只有一个：

官方对气隙场景的表述是：Aikido Machine 这类自主渗透测试设备"runs entirely inside a customer's own infrastructure, including fully air-gapped environments"，而 Altar 为其提供"without sending an organization's most sensitive context to a third-party inference service"。

但要说清：这不是一个新能力类别，而是把已有能力（AI 辅助渗透测试）搬进了原本用不了 SaaS 的环境。 凡是能联网的测试环境，用现成 SAST/SCA 加商业扫描器性价比更高。

能力落点要分清

它替代的不是 SAST 或 SCA，而是"在隔离网内做 AI 辅助的渗透测试"这一目前几乎空白的环节。

部署门槛：算力，不是许可

上述为按公开市场价格的估算，非厂商报价，未经采购流程验证。

还有一条硬约束，官方模型卡写得很明确：

Requires Hopper (H100/H200)

必须是 H200 或 H100 架构，A100 不行。 这是采购时首先要确认的机房条件。

按机构规模分档

这是本文对中小银行最有用的一条判断：中小银行的自建路径不应该是"自建安全大模型"，而应该是"采购能在本地机房部署、不外传代码的安全服务"。

六、商业性质必须点明

这不是中立开源项目，而是一家安全厂商的产品组件：

开源权重是获客与可信度手段，商业化在部署服务与产品，不在权重本身。

对银行的含义：应按安全厂商做供应商尽职调查——看其漏洞研究能力、产品成熟度、售后与持续更新承诺——而不是把它当作中立开源项目对待。官方也明确说后续路线是"fine-tuning models for security workflows, improving tool use and long-horizon reasoning"，即模型会持续迭代，这意味着银行需要建立版本升级与重新验证的流程能力。

七、我未能核实的部分

按重要性排序，明确列出：

1. 中文与金融业务文档的理解能力——校准语料是多语言维基百科，无任何金融语料实测数据
2. 真实攻击面盲测召回率——厂商未测，我也不能从 60.4% 外推
3. 误报率（false positive rate）——完全未披露。这是评估投入产出比的关键缺失项，因为不执行 exploit 验证意味着误报只能靠人工复核消化
4. 在真实生产代码上的表现——官方提到"部署后不久在一次客户生产渗透测试中发现了一个真实的高危漏洞"，但无 CVE 编号、无细节、无时间线，属厂商自述，我不采信
5. 32 漏洞 / 30 仓库基准——内部基准，非公开，无法独立复现
6. 中国监管合规映射——见下一节

八、监管合规映射（一手条文核验结果）

本节全部引用来自一手官方来源，逐条标注文号、发布日期与施行日期。未能核实的一律明确标注，不以推测填补。

一个必须先讲清的冲突

两份文件对"第三方生成式模型进入银行"给出了方向相反的直觉，银行必须同时满足：

《生成式人工智能服务管理暂行办法》（国家网信办等七部门，令第15号，2023-07-10 发布，2023-08-15 施行）第二条第三款：

行业组织、企业、教育和科研机构、公共文化机构、有关专业机构等研发、应用生成式人工智能技术，未向境内公众提供生成式人工智能服务的，不适用本办法的规定。

按这一条，银行内网自建自用、不向公众提供服务，不落入该办法适用范围。 其第十七条的备案义务是双要件——须同时"向境内公众提供"且"具有舆论属性或者社会动员能力"，银行内网安全运营两个要件都不满足。

但《银行业保险业人工智能安全开发应用的指导意见》（金发〔2026〕8号，2026-06-18，索引号 717804719/2026-365）第（五）项另有一句：

定义推动新一代人工智能技术应用——外部引入的生成式人工智能模型需经过网信部门备案。

Altar 是外部引入的第三方开源权重模型，属于生成式人工智能模型。所以银行的动作不是"是否适用生成式AI办法"，而是"这个模型有没有网信部门备案"。

这是本文给银行的第一条可执行动作：采购或自建前，先向供应商索取该模型（GLM-5.3 及其剪枝版本）在网信部门的备案凭证。若供应商拿不出备案凭证，金发〔2026〕8号第（五）项即构成障碍，其余技术评估都不必展开。

引用精度提示：金发〔2026〕8号全文以（一）（二）……（三十二）编号，不是"第 N 条"。检索原文时按编号而非条号查找。

最直接适用的一条：模型算法外部引入准入机制

《银行保险机构数据安全管理办法》（国家金融监督管理总局，金规〔2024〕24号，2024-12-27 发布并施行）第五章第三节：

第五十条：

银行保险机构应当对人工智能模型开发应用进行统一管理，建立模型算法产品外部引入的准入机制，对模型研发过程进行主动管理，实现模型算法可验证、可审核、可追溯。

这一条是本文合规分析的落点。 它是已生效的部门规章层级，直接命中"第三方开源模型引入银行"这一动作，且不以上市或高风险为前提。更重要的是，它的措辞是"人工智能模型"而非"生成式人工智能"——因此把银行安全运营用的专用模型明确纳入了范围。

第五十一条：

银行保险机构信息系统、模型算法投入使用前，应当开展数据安全审查，审查数据与模型使用的合理性、正当性、可解释性，以及数据利用对相关主体合法权益的影响、伦理道德风险及防控措施有效性等。

第五十二条——这一条对本文尤其重要：

……应当就数据对决策结果影响进行解释说明和信息披露，实时监测自动化处理与系统运行结果，建立人工智能应用的风险缓释措施，包括制定退出人工智能应用的替代方案，对安全威胁制定应急方案并开展演练。

"制定退出人工智能应用的替代方案"是一个被严重低估的硬要求。 叠加本文第四章的两个事实——Altar 是 Aikido 会持续迭代的模型（官方明确后续路线是"fine-tuning models for security workflows"），且整条流水线依赖 4×H200 硬件——银行必须在采购合同里就写清：模型版本变更如何通知、如何重新验证、退出时如何迁移到替代方案。 否则"退出方案"这条要求在两年后会成为一句空话。

数据不出境：这是范围排除，不是豁免

三部规章的适用对象都是"向境外提供"这一行为：

所以数据不出境时，不是因为获得了豁免，而是"向境外提供"这个构成要件根本不成立。 这个区别在合规文档里必须写准——写成"符合豁免条款"会在后续监管检查中站不住。

真正的风险点不在出境，而在两个别处：

一是《商业银行信息科技风险管理指引》（银监发〔2009〕19号，2009 年发布）第七条（十一）要求：

确保本法人机构涉及客户信息、账务信息以及产品信息等的核心系统在中国境内独立运行，并保持最高的管理权限……防范跨境风险。

二是供应商远程运维、遥测回流、许可证校验请求是否构成"出境"，监管未给出明确界定——本轮未能核实权威解释，标注 UNVERIFIED。Aikido 的模型卡把部署方式表述为本地部署，但"本地部署"与"运行过程零外联"是两件事，需要在合同与网络架构上分别验证。

等级保护：强制性依据是什么，哪些还是草案

强制性依据是《网络安全法》第二十一条（2025-10-28 修正，2026-01-01 施行；修正前为主席令第五十三号，2017-06-01 施行）：

国家实行网络安全等级保护制度。网络运营者应当按照网络安全等级保护制度的要求，履行下列安全保护义务……

技术标准：《信息安全技术 网络安全等级保护基本要求》GB/T 22239-2019（2019-05-10 发布，2019-12-01 实施；2025-05-30 复审结论"继续有效"，全部代替 GB/T 22239-2008）；金融行业另有 JR/T 0071.1~0071.6—2020 与 JR/T 0072—2020。

定义⚠️ 必须区分现行与草案——本轮检索到两份文件常被混用，但均未生效：

• 《银行业保险业网络安全管理办法（征求意见稿）》（金融监管总局，2026-07-11 公告征求意见）第三十三条提出「三级及以上网络每年至少开展一次等级测评」
• 《金融业网络安全管理办法（征求意见稿）》（人民银行、金融监管总局、证监会、外汇局，2026-07-03 发布征求意见）第八条提出等级保护义务

两份都是征求意见稿，不能作为现行强制义务引用。 但它们共同表达了监管意图，且方向明确：等级测评的频次要求会收紧。 银行若在本次采购中建设 AI 辅助安全运营能力，应按"测评频次将提高"来做三年规划，而不是按当前频次。

开源软件已有专门行业标准

这是本轮最贴合本文主题的已生效标准发现：JR/T 0289—2024、JR/T 0290—2024、JR/T 0291—2024 三个金融行业标准覆盖开源软件的应用管理、评估与治理（推荐性）。

一篇"开源软件应用管理指南"加一篇"开源软件应用评估规范"，正是第三方开源模型权重引入银行时应当遵循的方法论。 Altar 不是一个普通开源组件——它是经过第三方剪枝与量化后重新发布的权重，上游 GLM-5.3 的许可与剪枝后权重的许可是否等同、剪枝过程是否引入新的第三方权利主张，这两点应按 JR/T 0290—2024 的评估方法做正式核查，而不是只看模型卡上的一行 License 标注。

关于人工智能应用的四项已核验条款

金发〔2026〕8号中与本文直接相关的另三项（编号为原文编号）：

• （八）完善数据管理运营体系：构建企业级数据模型和数据资产地图，强化元数据管理
• （十一）推进知识工程建设：构建核心知识模型，建立知识萃取、整合、共享机制流程
• （二十二）促进可解释性：须设置人工复核节点，完整保留原始数据、推理路径及阈值触发记录
• （二十五）提升网络安全防御能力：有效防范提示词注入、思维链注入、多模态攻击、上下文污染等威胁

（二十二）与本文第四章的许可证分析正好构成一对：金发〔2026〕8号要求"完整保留推理路径"，而 GLM-5.3 许可条款 3 免除 Z.AI 的一切责任。监管要求保留推理路径，责任却落在银行自己——这两件事必须一起读。

本节未核实的项

按诚实原则列出，这些不构成本文结论的基础：

1. 《金融领域大模型应用合规指引》——有二手媒体报道称由人民银行与金融监管总局于 2026 年 5 月发布，但仅见于媒体报道，官方站点未能核实，标注 UNVERIFIED。若该文件确实存在且已生效，本节需据其修订。
2. 《商业银行信息科技风险管理指引》的文号——二手来源同时出现银监发〔2009〕19号与银监发〔2009〕54号两种说法，而金融监管总局官网页面未标注文号，本文无法判定，标注 UNVERIFIED。（已核实的是：该指引全文无 AI、大模型或算法相关条款。）
3. JR/T 0287-2023 的强制性标注——未能从人民银行原始公告核实。
4. 供应商远程运维与遥测回流是否构成数据出境——监管无明确界定。
5. 银行是否被认定为关键信息基础设施运营者，以及是否因此触发《关键信息基础设施安全保护条例》（2021-09-01 施行）第十九条的网络产品和服务国家安全审查义务——取决于行业领域目录的具体认定，本文不作判断。

九、如果要评估，建议这样问供应商

按本文的核验经验，这七个问题能筛掉大部分不实的答复：

1. 你的召回率是已知漏洞定向复现，还是真实攻击面盲测？两个数字分别是多少？
2. 误报率是多少？用什么方法收敛？
3. 是否执行 exploit 验证？如果不执行，如何确认发现可利用？
4. 端到端流水线里，这个模型承担哪一段，其余段落用什么？
5. 该模型在网信部门的备案凭证能否提供？（对应金发〔2026〕8号第（五）项，见本章第一节）
6. 模型迭代后如何保证我方环境不被静默破坏？权重变更如何通知与重新验证？退出时迁移到哪个替代方案？（对应金规〔2024〕24号第五十二条）
7. 除 Hopper/H200 外，还有没有消费级或国产加速卡的可行部署路径？

作者毕超，金融行业风险管理从业者。本文仅代表作者个人观点，不构成任何机构立场。