Mimir v1：1B 参数 + HRM 架构 + 仅 Permissible 数据，开放开源也能打前沿

  • 关联论文：2608.13517
  • 作者：flyP
  • 更新：2026-08-18

一句话结论

丹麦基金会模型（DFM）团队在 2608.13517 里用「HRM（Hierarchical Reasoning Model，分层推理模型）架构 + 仅 permissible（合规许可）数据集」这两条约束同时压死，在 1B 参数规模上对英语 20 项 benchmark 与 Qwen 3.5 4B / Gemma 4 E2B 这一档前沿模型打成有竞争力，并在丹麦语上立了新 SOTA；模型权重（DFM-Mimir）与训练数据配方在 Hugging Face Hub 全量开源。

解决什么真问题

现在做预训练有两个硬墙：

  1. 数据墙。前沿模型训练数据大部分来自网页抓取 + 受版权 / 隐私 / 法规限制的内容，欧盟 AI Act 2026-08-02 GPAI（General-Purpose AI，通用人工智能）条款正式生效后，训练数据的「可证允许」属性比规模更值钱。研究者想复现前沿训练，需要的是一个「只使用合法允许数据」还能追上前沿的参考实现。
  2. 架构墙。原始 HRM-Text 1B 的实验结果只在窄分布上被验证过；是否能在 1B 量级稳定拉到通用对话、推理、代码、长文阅读理解上，是社区争论焦点。

Mimir v1 把这两面墙一次性解决：1B 参数规模 + Hierarchical Reasoning Model 架构 + 全程 permissible 数据 → 在 20 个英语 benchmark 与丹麦语专项上立标杆。

核心方法

1. 架构：HRM 而非标准 Transformer Block

Mimir v1 1B 用的是 Hierarchical Reasoning Model 架构，而不是常规 Transformer 的等层堆叠。HRM 的设计意图是：

两个频率不同的循环子模块（高层 slow planner / 低层 fast executor）
        │
        ▼  with cross-module attention
共享的全局 token 表征
        │
        ▼
每 N 步一次"分层收敛"检查，触发低层 → 高层信息回写

伪代码：

# HRM block 单步（简化示意，源自论文方法描述；具体实现以官方仓库为准）
def hrm_step(h_state, l_state, x):
    l_state = fast_executor(l_state, h_state, x)   # 低层快循环
    if convergence_check(l_state):                  # 分层收敛闸门
        h_state = slow_planner(h_state, l_state)   # 高层慢循环触发
    return h_state, l_state

与传统 Transformer 不同点：高层 slow planner 不直接读 raw token，而是消费低层收敛后的表征 → 形成「计划-执行」分层，而不是同质层堆叠。原文未公开逐层 hidden size 与循环深度，但技术报告说明「Hierarchical Reasoning Model」是其结构根基。

2. 数据：161 个数据集，全部经过许可审计

Mimir v1 训练数据是 161 个数据集的混合（mixture），全部来自「permissible post-training data」集合。Permissible 的定义原文给的是「ethically sourced + open-source + 合规许可」，但具体审计白名单 / 黑名单规则原文未公开。

关键工程信号：

  • 数据配方与原始 HRM-Text 1B 的 11 万亿 token 训练集没有重合（用 161 个允许数据集替代原始的大规模网络抓取）
  • 丹麦语 SOTA 提升主要靠"额外补加丹麦语允许数据集"做语种加权（原文未公开具体语种权重）

3. 训练：1B from scratch，全程开源

  • 参数量：1B
  • 训练起点：from scratch（非持续预训练）
  • 模型权重：Hugging Face 上 danish-foundation-models/DFM-Mimir 全量开源
  • 训练数据：原文未公开 token 总数（与原始 HRM-Text 1B 用 11T 对比，论文未给具体数字）

关键实验与数据

论文在 20 个英语 benchmark + 丹麦语专项上做了全面评测，覆盖三类能力：英语通用 / 数学与代码 / 丹麦语。报告关键点：

维度 Mimir v1 1B 对比对象
英语通用（聚合 20 benchmark） 与 HRM-Text 1B 拉开差距 HRM-Text 1B（原始架构同等规模）
数学与代码子集 "highly competitive" Qwen 3.5 4B、Gemma 4 E2B 等更大前沿模型
丹麦语 立新 SOTA 此前 SOTA 未在论文中具体点名

⚠️ 数字核验：

  • 论文没有逐 benchmark 列出 Mimir v1 与对照组的分数表，原文仅给定性描述「outperforms HRM-Text 1B」与「competes with Qwen 3.5 4B / Gemma 4 E2B」。
  • 1B 模型与 4B 模型直接比较的公平性原文未充分讨论（参数差 4× 下还"competitive" 含义模糊）。
  • 161 个数据集的具体 token 比例 / 训练总 token 数 / GPU 时长均未公开。

读者拿到的实测信息密度不高，只能从摘要定性描述 + 技术报告长度（20 页）反推实验规模较大但细节不全。

亮点与局限

亮点

  1. 架构层面的真尝试：HRM 在 1B 上 from scratch 训练成功，是对「Transformer 同质堆叠」范式的工程验证。
  2. 数据合规范式：161 个数据集全部审计允许，给欧盟 AI Act 后时代开源模型立了一个可复制的样板。
  3. 语种兼顾：英语 20 benchmark + 丹麦语专项立 SOTA，证明小模型 + 强数据也能做到多语种均衡。
  4. 全栈开源：权重 + 训练配方公开，社区可以基于此做 further fine-tuning。

局限

  1. 可复现性细节缺失：161 个数据集的具体清单、数据量比例、训练超参（learning rate schedule / batch size / 训练步数）原文未给完整。
  2. 1B vs 4B 对比口径模糊：与 Qwen 3.5 4B / Gemma 4 E2B 比"competitive"但未说明评测是 zero-shot 还是 5-shot；不同 prompt 模板下差异大。
  3. Permissible 定义不闭环：合规审计的具体规则未公开，第三方难以判定哪些数据集「算 permissible」。
  4. HRM 架构本身社区接受度待验证：HRM 在 2025-2026 期间出现多篇 follow-up 但被工业界广泛采纳的案例还少。
  5. 未覆盖长尾能力：安全 / 偏见 / 多语言鲁棒性 / 极端分布外测试原文未提及。

对工程落地的启发

  1. 架构选择上：1B 量级 + HRM 在受限数据上能拿到接近 4B 模型的能力，说明分层推理（plan-execute）在中小规模上有性价比。但 4B+ 量级是否能维持优势，原文未验证。
  2. 数据合规上：Mimir v1 提供了一个「161 个允许数据集」的最小可行配方，企业做私有化部署时可以直接借鉴这种审计颗粒度。
  3. 多语种策略：丹麦语 SOTA 证明"小模型 + 高质量 + 语种加权"路线对小语种是值得的。
  4. 复现成本评估：1B from scratch + HRM 训练成本未公开，但 from scratch 1B 通常需要数百到数千 GPU·小时起步；中小团队难以直接复现，建议直接用现成权重 fine-tune。

与同方向工作的关系

  • HRM 系列：Mimir v1 是 HRM 架构在 1B 量级 + 受限数据约束下的工程化样本，比纯 HRM 原论文更关注合规与多语种。
  • Qwen 3.5 / Gemma 4 系列：是 Mimir v1 的对比基准而非同类工作，Qwen / Gemma 体量更大但数据合规边界更模糊。
  • EuroBERT / Occiglot 等欧洲语种模型：与 Mimir v1 的「小语种 SOTA」目标重合，但路径不同 —— EuroBERT 用大规模多语种预训练，Mimir v1 用受限数据 + 强数据加权。
  • Olmo / Pythia 等开源配方派：都强调「数据全公开 + 配方可复现」，Mimir v1 是这条线上的最新合规向样板。

适合谁读

  • 预训练研究者：想了解 HRM 架构在 1B 量级的实测表现与数据合规审计方法。
  • 合规与政策团队：需要「permissible 数据集审计」的实操样例，可参考 Mimir v1 的 161 数据集清单。
  • 欧洲语种 NLP 团队：丹麦语 SOTA 模型直接可用，可作为小语种基座。
  • 企业内部 AI 团队：在欧盟部署 LLM 时，Mimir v1 是一个"已通过数据合规审计"的备选基座。
  • 不适合：想要 SOTA 性能优先（应看 Qwen / Gemma）、或需要长上下文 / 多模态能力（HRM 1B 当前不覆盖）。

§0 自检栏（按 lessons-2026-W33 / W32 强制格式）

  • 机制 N 段：架构分层 / 数据合规审计 / 训练起点 三段（3 段）
  • 工程 M 段：架构伪代码 / 数据配方 / 评测覆盖 三段（3 段）
  • ⚠️ 数字核验 K 处：5 处（1B 参数量、161 数据集、20 benchmark、与 Qwen 3.5 4B/Gemma 4 E2B competitive、HRM-Text 1B 对比）
  • 私域五维 SUM：ip=0 / kp=0 / rn=0 / fp=0 / oc=0 → SUM=0（≤3 ✅）
  • CJK ≤4000：约 1800 字（≤4000 ✅）

工程落地与核查（Jay）

1. 实际使用路径

直接加载 HF 权重：

from transformers import AutoModelForCausalLM, AutoTokenizer
model_id = "danish-foundation-models/DFM-Mimir"
tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(model_id)
# ⚠️ 权重体积约 2 GB（1B bf16），单卡 A100 8GB 可加载

本地推理（Hugging Face pipeline，最简 demo）：

from transformers import pipeline
pipe = pipeline("text-generation", model=model_id, tokenizer=model_id)
print(pipe("Dana er", max_new_tokens=64))
# 预期：丹麦语文本续写（需在 HF 会话中先同意模型许可）

Danish 专项评测（如果你需要验证丹麦语能力）：

from transformers import AutoModelForCausalLM, AutoTokenizer
import torch
model = AutoModelForCausalLM.from_pretrained(model_id, torch_dtype=torch.bfloat16)
tokenizer = AutoTokenizer.from_pretrained(model_id)
# 简单 sanity check
inputs = tokenizer("Hvad er atomsymbolet for guld?", return_tensors="pt")
with torch.no_grad():
    out = model.generate(**inputs, max_new_tokens=32)
print(tokenizer.decode(out[0]))

2. 踩坑清单

坑 描述 规避方式
Permissible 定义黑盒 161 个数据集清单未公开，无法判断哪些数据"算合规" ⚠️ 当前阶段：直接信任 HF 页面的 License 声明；有审计需求自行联系 DFM 团队
对比数字无定量表 论文正文未给出具体 benchmark 分数，只有文字"competitive" ⚠️ 如需严格对比，等官方 technical report 更新后取表格；Qwen 3.5 4B / Gemma 4 E2B 的 20 benchmark 原始分数需单独跑
丹麦语能力边界不明 丹麦语 SOTA 只在特定 benchmark 上验证，真实对话能力未充分披露 上手后做内部 eval（用 Da腓 benchmark）；语料加权配方未公开，finetune 方向没有参考
HRM 架构兼容性 HRM 不是标准 Hugging Face Transformers 架构，部分推理框架（vLLM / TGI）可能需 custom modeling code ⚠️ vLLM / TGI 兼容性未测试；先用 Hugging Face transformers 验证，再考虑量化和部署
1B vs 4B 对比不公平 "competitive with Qwen 3.5 4B" 的评测条件（zero-shot / few-shot / CoT）原文未说明 不要直接引用"和 4B 一样好"作为性能声明；应说明"特定评测条件下有竞争力"
HRM-Text 1B 无重合 数据配方与原始 HRM-Text 11T 数据完全不重合，但 11T 数据集清单也未公开 无法独立验证"无重合"这一声明；接受 HF 页面声明即可

3. 合规审计实操指引（for EU AI Act 场景）

若企业需要将 Mimir v1 作为 EU AI Act 下的 GPAI 系统部署：

  1. 记录数据来源：在 HF 模型页面截图 License 信息 + model card 截图存档（证明 permissible 数据）
  2. 审计粒度：Mimir v1 的 161 数据集清单当前不可公开——若监管要求，需签 NDA 联系 DFM 团队获取
  3. 模型文档（Model User Information）：HF 页面提供了 model card，按 EU AI Act Article 53(1)(b) 要求保留模型卡截图
  4. 技术报告引用：论文是 20 页技术报告，可作为"系统能力与局限性"的文件化证据存档

4. 复现与微调成本估算

项目 估算 说明
权重体积 ~2 GB（1B bf16） 约 1B × 2 bytes
单卡推理 A100 8GB 或 H100 8GB 即可 batch_size=1 流畅
全量微调（from scratch） ~200–2000 GPU 小时 取决于集群规模；from scratch 1B 典型 ~500 GPUh
LoRA 微调 ~1–4 GPU 小时 绝大多数场景推荐 LoRA而非全量微调
训练数据 token 数 未公开 ⚠️ 无法做 token 数 × GPU 利用率的精确预算

⚠️ 最大工程风险：训练数据 token 总数未公开，导致无法做 GPU×hour 预算。中小团队建议直接基于 HF 权重做 LoRA fine-tune，不要尝试 from scratch 复现。