闲社

标题: 蚂蚁开放LLaDA2.2-mini：16B扩散模型支持128K [打印本页]

作者: bufeng007 时间: 2026-9-6 13:04
标题: 蚂蚁开放LLaDA2.2-mini：16B扩散模型支持128K
【事件概述】
inclusionAI（蚂蚁集团）开放 LLaDA2.2-mini 权重。这是 LLaDA2 系列面向智能体任务的轻量扩散语言模型，在 LLaDA2.0-mini 架构上加入 Levenshtein Editing，让并行扩散解码不只改写已有 token，还能通过 DELETE 和 INSERT 控制 token 删除冗余内容、创建插入位置并进行结构化纠错。

【模型与开发者】
模型：LLaDA2.2-mini
开发者：inclusionAI / 蚂蚁集团
官方公开日期：2026 年 9 月 5 日
模型类型：MoE 扩散语言模型
总参数：16B（官方口径不含 embedding）
推理激活参数：约 1.4B
上下文长度：128K token
许可：Apache License 2.0

日期核对说明：官方 Hugging Face 模型仓库元数据记录创建于 2026-09-05，并在同日上传当前模型卡、配置、自定义实现与 7 个 Safetensors 权重分片。LLaDA2.2-flash 是此前已存在的另一版本，本轮新闻点是 mini 版本首次公开，不把系列旧版本日期混进来。

【关键能力与改动】
1. Levenshtein 编辑式扩散：模型引入 DELETE 与 INSERT 控制 token，允许生成过程改变序列长度和结构，而不只是对固定位置反复去噪。
2. 面向错误纠正：官方把删除冗余内容、插入新位置和多轮工具使用中的稳健纠错列为核心目标，适合智能体在收到工具结果后修订既有计划。
3. 128K 长上下文：mini 版把上下文扩展到 128K，并通过 Block Routing 把 MoE 专家激活限制在扩散 block 层级，面向长上下文工具调用和多轮交互。
4. L-EBPO 智能体强化学习：技术方案提出 Levenshtein Editing ELBO-based Block-level Policy Optimization，使用智能体环境奖励训练编辑和纠错能力。
5. 稀疏 MoE 结构：模型有 20 层、16 个注意力头、4 个 KV 头和 256 个专家，每个 token 激活 8 个专家；官方给出的总参数为 16B、推理激活约 1.4B。
6. 完整自定义实现：仓库除权重外还提供 `configuration_llada2_moe.py`、`modeling_llada2_moe.py`、专用 tokenizer 与工具声明文件，可通过 Transformers 加载。

【官方评测怎么看】
在官方同表对比中，LLaDA2.2-mini 的 General Average 为 46.47，高于 LLaDA2.0-mini 的 45.68 和 LLaDA2.1-mini 的 45.03。它在 BFCL v4 函数调用上得到 47.68，旧两版分别为 25.05 和 28.44；LongBench v2 为 34.99，旧两版分别为 15.51 和 12.13。

但新版本并非全面提升。AIME 2026 得分 35.05，低于 LLaDA2.0-mini 的 37.71 和 2.1-mini 的 40.37；IFBench 为 24.93，低于旧版的 32.33 和 31.60；GPQA-Diamond 为 44.41，也低于旧版的 47.76 和 48.36。官方给出的智能体三项平均分为 59.00，但旧版对应位置没有成绩，不能由此计算跨版本提升幅度，更不能拿它与未列入同表的其他厂商模型直接比较。

【适用对象】
适合研究扩散语言模型、长上下文函数调用、多轮智能体和工具错误恢复的开发者。对希望验证“并行生成过程中插入、删除和纠错”是否优于传统自回归重写的团队，这个 16B 稀疏版本比 100B 级 flash 版本更容易开展实验。

【实际影响】
传统自回归模型通常按顺序追加 token，发现早期计划有误时往往需要重新生成。LLaDA2.2-mini 尝试在扩散去噪过程中直接编辑已有序列结构，使智能体可以删除失败步骤、插入补充调用并在多轮反馈后修订方案。128K 与 Block Routing 则把这套机制推进到更长的工具轨迹。

不过，“只激活 1.4B 参数”描述的是稀疏计算量，不等于只需存储 1.4B 权重，也不代表普通消费级显卡必然可运行。完整 16B 权重、KV/扩散状态、自定义算子和长上下文都会占用内存。

【限制与使用提醒】
第一，官方示例要求 `transformers>=5.2.0` 并启用 `trust_remote_code=True`。这会执行仓库中的自定义模型与 tokenizer 代码，部署前应固定提交哈希、审查 Python 文件并在隔离环境测试，不能按普通自回归模型无差别接入。

第二，官方建议长上下文智能体任务使用 SGLang，并确保服务端支持 128K 和 MoE 扩散推理。模型卡没有提供消费级硬件、显存、吞吐或 128K 满负载测试，因此不能把 128K 当成任意服务器上的低成本承诺。

第三，生成接口使用 `gen_length`、`block_length`、`threshold`、`editing_threshold` 和 `max_post_steps` 等扩散专用参数。降低阈值可能加快推理，但官方明确提示会造成重复或不稳定输出；推荐 32768 token 输出长度也只是配置建议，不等于每个回答都应生成如此长。

第四，函数调用和智能体基准提升不代表实际工具使用安全。模型仍可能选错工具、构造错误参数、泄露上下文或在失败后反复调用。生产系统应设置工具白名单、最小权限、参数校验、费用与次数上限、外部写操作审批和完整日志。

第五，官方评测由发布方提供，尚缺独立复核；部分通用能力还出现回退。选择模型时应按自身任务同时评估长上下文、函数调用、数学、知识、指令遵循、延迟和稳定性，而不是只看综合平均分。

【官方来源】
官方模型页：https://huggingface.co/inclusionAI/LLaDA2.2-mini
官方技术报告：https://github.com/inclusionAI/LLaDA2.X/blob/main/LLaDA2_2_tech_report.pdf
官方系列仓库：https://github.com/inclusionAI/LLaDA2.X

作者: kooon 时间: 3 天前
扩散语言模型做Agent纠错这个思路挺有意思，Levenshtein Editing能DELETE/INSERT算是补上了diffusion LM改token不灵活的短板。不过16B MoE做128K，推理成本和并行解码调度在长上下文下会不会爆炸？蹲个实测。🤔

欢迎光临闲社 (https://www.xianshe.com/)