蚂蚁开源大模型内生式安全护栏SingProbe：已适配GLM、Qwen、DeepSeek V4等29个开源模型，解码额外开销低于0.5%，幻觉风险纳入实时检测

【新闻原文】 2026 年国家网络安全宣传周期间（9 月 14 日发布、9 月 16 日公开报道），蚂蚁集团 AI 安全实验室宣布开源大模型内生式安全护栏 SingProbe（SingProbe Infra），同步开放相关代码、模型和评测基准，为开发者提供与模型生成过程同步运行的安全检测能力。项目代码与集成说明已在 GitHub 开放，相关模型及流式安全评测基准 SingStreamBench 可通过 Hugging Face 获取。 目前，SingProbe 已适配 Ling-3.0 系列、GLM-5.2/5.3、Qwen、DeepSeek V4 等 29 个主流开源大模型，并接入 SGLang、vLLM 两大主流推理框架，支持开发者在现有推理流程中直接集成安全防护。 从技术路径看，当前大模型应用普遍通过独立的外置护栏模型审核输入或输出。这种方式通用、直接，但需要额外处理待审核内容，增加计算和部署成本；如果等待完整回答生成后再检查，风险信号可能来得太晚；如果提高检查频率，又会进一步增加运行负担。运行时探针（Run-time Probe）是学界探索兼顾安全检测效果与运行效率的一条技术路径，但从研究走向实际应用，还需要模型适配、推理框架集成等工程支持。SingProbe 通过提供模型适配与推理框架集成等配套基础设施，补充了这条路径的落地能力。 SingProbe 如同一个模型内的"安全探头"：它复用大模型推理过程中已经产生的内部信息，持续输出用户意图、回答安全和幻觉风险三类分数。模型一边生成回答，探针一边提供风险信号，应用系统无需等待整段回答结束，就可以据此采取告警、中止回答、重新生成等措施。 据研发团队在 Ling-3.0-flash 模型生产环境中的实测，SingProbe 在解码阶段引入的额外开销低于 0.5%。团队评测显示，flash 版本在回答安全分类和流式安全检测任务上超过所选公开基线，在幻觉检测任务上与参考基线基本持平，展现出兼顾检测能力与运行效率的潜力。 此次同步开放的流式安全评测基准 SingStreamBench，进一步关注风险出现和被发现的具体时刻：它不仅检验护栏能否识别风险，还考察是否过早触发、发现是否及时，帮助开发者评估安全防护效果及其对正常回答的影响。 在风险识别之外，团队还探索了如何利用风险信号进行按需纠偏。作为一项场景验证，SingProbe-Med 在医疗内容生成过程中，仅在风险达到触发条件后，对局部高风险内容进行干预。在 AntAngelMed-100B 医疗评测中，完整干预能够纠正基线模型中 25.03% 原本出错的回答，展示了内生风险信号用于生成过程安全控制的潜力。 SingProbe 既可独立使用，也可与外置护栏配合，为开发者提供渐进式集成路径。后续，团队将逐步扩展对更多开源模型的支持，并邀请开发者、研究者和产业伙伴参与试用反馈。同期在国家网络安全宣传周人工智能安全治理分论坛上，中文互联网基础语料 4.0、网络安全数据集 1.0、AIGC 检测数据集等三类高质量数据集也正式向社会发布。 【企服观察】 蚂蚁开源 SingProbe 这件事，表面上是又一个安全工具开源，实际上它标记的是企业 AI 落地成本结构的一次实质变化：安全防护从"额外部署一套审核服务"变成"推理流程里附带的 0.5% 开销"。对企业 CTO 和安全负责人来说，这笔账值得重新算一遍。 先看外置护栏的真实成本。目前多数企业做 AI 应用上线前的内容安全审核，通行做法是挂一个独立的审核模型：用户请求先过一道输入审核，模型输出再过一道输出审核。这意味着每一轮对话实际要跑三次推理——输入审核一次、业务模型一次、输出审核一次。推理成本直接翻三倍，时延也相应增加，而审核模型本身的准确率还参差不齐。SingProbe 的思路是把检测内嵌到业务模型的推理过程中，复用已经产生的中间状态，额外开销低于 0.5%。对于一个日均千万级调用的企业客服系统，这个差异在年度账单上可能就是数百万级别的成本差。企业在评估 AI 安全预算时，应该把"内生式"和"外置式"两条路线的成本模型都算清楚，而不是默认外置审核是唯一选择。 第二，幻觉风险被正式纳入护栏检测范围，这件事对知识库问答、客服、医疗、金融这类"信任敏感型"场景尤其关键。传统内容安全只管"该不该说"，幻觉检测管的是"说得对不对"——一本正经编造文献引用、虚构产品参数、给出不存在的政策条款，这些输出对企业的危害不比违规内容小，而且更隐蔽。SingProbe 把两类风险放在同一个探针里同步输出，意味着企业可以用一套机制同时守住合规底线和质量底线。目前它的幻觉检测能力只是"与参考基线基本持平"，谈不上领先，但方向是对的：风险信号在生成过程中实时产生，应用可以在错误内容完整输出之前就拦截或重生成，而不是等用户投诉后再补救。 第三，29 个开源模型加 SGLang、vLLM 两大推理框架的适配，降低了中小团队的接入门槛。过去企业要落地类似能力，需要自己研究模型内部状态、训练检测头、改造推理引擎，这是一般企业根本做不起的工程。现在开源方案直接给出了模型适配和框架集成，配合 SingStreamBench 这个评测基准，企业至少有了一个可复现的验收标尺。建议准备上线 AI 应用的企业，把 SingStreamBench 这类流式安全基准纳入供应商评估清单——不仅看厂商宣称的拦截率，更看它在"风险出现到被发现"这个时间维度上的表现，以及是否存在过度拦截影响正常回答。 第四，也要看清边界。SingProbe 依赖对基座模型内部状态读取，这意味着它只适用于开源模型的自部署场景——企业如果调用的是 GPT、Claude、Gemini 这类闭源 API，根本拿不到模型内部状态，内生式护栏用不上，还是得回到外置审核或依赖厂商自带的安全能力。所以更准确的理解是：这条路线解决的是"自部署开源模型"这一部分企业的安全问题，而不是全部。对采用混合部署策略的企业，合理的架构是开源自部署部分用内生护栏、API 调用部分用厂商安全参数加外置抽查，两套机制分别验收。 最后给三条落地建议：其一，采用渐进式集成策略，第一阶段只开告警不开拦截，观察两到四周的误报率后再启用自动中止，避免安全机制反过来伤害业务可用性；其二，把 SingProbe-Med 的"按需纠偏"思路借鉴到自己的场景里——只在风险达到阈值后干预局部内容，比整段重新生成更经济，也更快；其三，医疗、金融等强监管场景，把 25.03% 的纠错率这类数字当作参考起点而不是承诺值，必须在自己的真实业务数据上重跑评测后再定上线标准。