https://docs.nvidia.com/deeplearning/frameworks/pytorch-release-notes/rel-25-11.html


nvcr.io/nvidia/pytorch:25.08-py3

nvidia PyTorch Release 25.11

https://huggingface.co/XiaomiMiMo/MiMo-V2-Flash

## 摘要
我们推出了 MiMo-V2-Flash 模型。这是一个混合专家（MoE）模型，总参数量 309B，实际运行参数量 15B，兼顾推理能力强、响应速度快，适合智能体任务。

模型采用了混合注意力结构，结合了滑动窗口注意力（SWA）和全局注意力，滑动窗口长度 128 token，混合比例为 5:1。我们通过多 token 预测（MTP）进行了 27 万亿 token 的预训练，上下文长度初始为 32K，后续扩展至 256K。

为了高效开展训练后优化，我们引入了创新的“多教师策略蒸馏”（MOPD）方法。这种方法让多个领域专家模型（例如通过大规模强化学习训练得到）提供密集的 token 级奖励信号，使学生模型能完整掌握教师模型的能力。

尽管总参数量分别仅为 DeepSeek-V3.2 和 Kimi-K2 的 1/2 和 1/3，MiMo-V2-Flash 的性能仍可媲美这些顶尖开源模型。在推理阶段，我们将 MTP 模块用作推测解码的草稿模型，配合三层 MTP 结构，实现了平均 3.6 的接受长度和 2.6 倍的解码加速。

我们将完整模型权重及三层 MTP 权重全部开源，以促进开放研究和社区协作。

MiMo-V2-Flash 论文

## `mask_history` 参数详解

### 1. 基本定义

```54:57:src/llamafactory/hparams/data_args.py
    mask_history: bool = field(
        default=False,
        metadata={"help": "Whether or not to mask the history and train on the last turn only."},
    )
```



- 默认值：`False`
- 作用：在多轮对话中，只对最后一轮计算损失，历史轮次不参与损失计算

### 2. 核心机制

#### 2.1 反转编码顺序（优先保留最后一轮）

```49:50:src/llamafactory/data/processor/supervised.py
        if self.data_args.mask_history:
            encoded_pairs = encoded_pairs[::-1]  # high priority for last turns
```

- 将对话对反转，确保最后一轮优先处理，避免被截断

#### 2.2 屏蔽历史轮次的损失

```70:73:src/llamafactory/data/processor/supervised.py
            if self.data_args.mask_history and turn_idx != 0:  # train on the last turn only
                target_label = [IGNORE_INDEX] * target_len
            else:
                target_label = target_ids
```

- `turn_idx == 0`：最后一轮，正常计算损失
- `turn_idx != 0`：历史轮次，`target_label` 设为 `IGNORE_INDEX`，不计算损失

#### 2.3 反转序列拼接顺序

```75:80:src/llamafactory/data/processor/supervised.py
            if self.data_args.mask_history:  # reversed sequences
                input_ids = source_ids + target_ids + input_ids
                labels = source_label + target_label + labels
            else:
                input_ids += source_ids + target_ids
                labels += source_label + target_label
```

- `mask_history=True`：新内容前置（`source_ids + target_ids + input_ids`）
- `mask_history=False`：按时间顺序拼接（`input_ids += source_ids + target_ids`）

### 3. 实际效果对比

假设有一个3轮对话：

```
轮次1: User: "你好" → Assistant: "你好！"
轮次2: User: "今天天气怎么样？" → Assistant: "今天天气很好。"
轮次3: User: "适合出门吗？" → Assistant: "适合出门。"
```

#### 当 `mask_history=False`（默认）：

```
input_ids: [轮次1的user+assistant] + [轮次2的user+assistant] + [轮次3的user+assistant]
labels:    [IGNORE...IGNORE, 轮次1的assistant] + [IGNORE...IGNORE, 轮次2的assistant] + [IGNORE...IGNORE, 轮次3的assistant]
```
- 所有轮次都计算损失

#### 当 `mask_history=True`：

```
input_ids: [轮次3的user+assistant] + [轮次2的user+assistant] + [轮次1的user+assistant]  (反转)
labels:    [IGNORE...IGNORE, 轮次3的assistant] + [IGNORE...IGNORE, IGNORE...IGNORE] + [IGNORE...IGNORE, IGNORE...IGNORE]
```
- 只有最后一轮（轮次3）计算损失
- 历史轮次仍作为上下文，但不参与梯度更新

### 4. 使用场景

- 长对话训练：只优化最新回复，避免历史干扰
- 上下文学习：保留历史作为上下文，但不训练历史回复
- 节省计算：减少需要计算损失的 token 数

### 5. 限制条件

```176:177:src/llamafactory/hparams/data_args.py
        if self.mask_history and self.train_on_prompt:
            raise ValueError("`mask_history` is incompatible with `train_on_prompt`.")
```

- 不能与 `train_on_prompt=True` 同时使用（两者冲突）

### 6. 与您例子中的 `loss_mask` 的关系

- `mask_history`：在数据预处理阶段统一屏蔽历史轮次
- `loss_mask`：在消息级别精细控制每个消息是否计算损失

目前 LLaMA-Factory 不支持消息级别的 `loss_mask`，但 `mask_history` 可以实现“只训练最后一轮”的效果。

### 7. 总结

- `mask_history=True`：只对最后一轮计算损失，历史轮次作为上下文但不参与训练
- 适用于长对话场景，可节省计算并聚焦最新回复
- 与 `train_on_prompt` 互斥

LLaMA-Factory  mask_history 

https://arxiv.org/pdf/2509.02544



## 1. 他们到底想解决什么问题?

想象一下,你想让 AI 帮你:
- 在京东上搜"三体",找到刘慈欣写的、50 块钱以内的书,加入购物车
- 玩一局 2048,尽量拿高分
- 在 Ubuntu 上用终端命令处理文件、跑代码

这些任务有个共同特点:**需要多步操作、需要看屏幕、需要根据反馈调整策略**。这就是 GUI Agent 要干的事儿。

但现有方案有几个大坑:
1. **数据太少**: 不像文本和代码有海量训练数据,GUI 操作的轨迹数据贵得要死
2. **多轮 RL 难训**: 游戏可能要几百步才结束,奖励稀疏,模型不知道哪步做对了
3. **纯 GUI 不够用**: 很多任务用命令行、文件系统更高效,纯点鼠标太慢
4. **环境不稳定**: 要跑几百万次交互,虚拟机动不动就崩溃

UI-TARS-2 就是奔着这四个问题去的。

---

## 2. 核心方法论:四大支柱

### 2.1 数据飞轮 (Data Flywheel)

**核心思想**: 模型和数据互相喂养,越滚越大。


#### 怎么冷启动?

一开始得有种子数据:
- **CT (Continual Pre-training) 数据**: UI-TARS 1.0/1.5 的数据 + 网上爬的教程视频 + 人工标注的轨迹
- **SFT (Supervised Fine-Tuning) 数据**: 合成数据 + 高质量人工标注

注意:**Agent 数据只占一小部分,大头还是通用数据**(聊天、推理等),目的是保留模型的通用能力。

#### 怎么迭代?

训练完第一轮 RL 模型后,用它来生成新数据:

```
新数据 = rejection sampling (RFT) + interactive annotation
```

然后用一个验证模型 `V(s)` 给每条数据打分:
- **高质量** (`V(s)=1`): 扔进下一轮 SFT
- **低质量** (`V(s)=0`): 扔进下一轮 CT (让模型见见世面)

这样形成正反馈循环:
```
更好的模型 → 更多高质量数据 → 更更好的模型
```

而且**没有数据浪费**,低质量数据也能用来做 CT。

---

### 2.2 沙盒环境:All-in-One GUI Sandbox

训练 Agent 需要一个能跑得动、跑得稳的环境。UI-TARS-2 搞了两套:

#### (1) GUI 环境:云虚拟机集群

- 支持 Windows、Ubuntu、Android 三大系统
- 几千台虚拟机,支持每秒几千次查询 (QPS)
- 每个 session 有独立 ID,支持 VNC 实时监控
- **关键创新**: 共享文件系统,浏览器下载的文件可以直接用命令行处理

技术细节:
```python
# 伪代码示意
vm = VMManager.allocate(os="ubuntu")
vm.execute_gui_action("click", x=100, y=200)
vm.execute_shell("cat downloaded_file.txt | grep keyword")
```

#### (2) 游戏环境:硬件加速的浏览器沙盒

![](browser_sandbox.png)

为什么要单独搞游戏环境? 因为:
- 游戏都是 HTML5/WebGL,必须跑在浏览器里
- 需要高并发 (一个容器跑多个浏览器实例)
- 需要控制时间流速 (加速训练)

**黑科技**: 重新实现了浏览器的 `Window.setTimeout` 等 API,可以暂停/加速游戏时间,同时不改变游戏逻辑。

---

### 2.3 数据标注:怎么搞到高质量轨迹?

#### CT 数据:In-Situ Annotation (原地标注)

**问题**: 之前的数据只有 action,没有 reasoning (思考过程),导致模型只会模仿,不理解为什么这么做。

**解决方案**: Think-Aloud Protocol (边想边说)

1. 标注员**边操作边说出想法**,录音
2. 用 ASR 转文字,LLM 润色成高质量 reasoning
3. 自动对齐到每一步操作

举个例子:
```
[标注员操作] 点击搜索框
[录音转文字] "我现在要搜三体,先得点这个搜索框"
[LLM 润色] "为了完成任务,首先需要在搜索框中输入关键词'三体'"
```

还有个妙招:**让新手标注员做不会的任务**。新手会搜索、试错、查资料,这些过程都是宝贵的训练数据。

#### SFT 数据:Interactive Annotation (交互式标注)

**问题**: 传统标注是 off-policy 的,标注员的操作和模型的操作分布不一样,训练效果差。

**解决方案**: Human-in-the-Loop (人在回路里)

![](interactive_annotation.png)

流程:
1. 给标注员一个任务 (比如"在京东搜三体")
2. 模型生成 3 个候选 (每个都有 thought + action)
3. 标注员选一个,或者自己手动输入
4. 环境执行这个 action,模型看到反馈后继续预测
5. 重复直到任务完成

**关键优势**: 标注数据和模型实际 rollout 的分布一致 (on-policy),而且标注员能实时纠错。

---

### 2.4 多轮强化学习:怎么训一个能玩 1000 步游戏的模型?

#### 2.4.1 任务设计:怎么自动生成可验证的训练任务?

RL 需要大量任务 + 可靠的奖励信号。他们设计了三类任务:

##### (1) GUI-Browsing: 信息检索任务

**目标**: 让模型学会通过网页搜索、推理来回答复杂问题。

**任务生成方法 1: 多条件模糊化**

从维基百科抽取实体 (比如一个乐队),然后故意"脱敏":
```
原始信息:
- 乐队: AC/DC
- 成员来自: Dreghorn 和 Irvine
- 签约唱片公司: Atlantic Records

生成问题:
"被某人才机构发现,最初阵容包括来自 Dreghorn 和 Irvine 的成员,
主唱是创始成员推荐的。这个乐队签的是哪家唱片公司?"

答案: Atlantic Records
```

关键:**无法直接搜索,必须多步推理**。

**任务生成方法 2: 多跳链式条件**

递归构造推理链:
```
问题: "完成某 20 世纪航天计划的指令舱驾驶员毕业的大学,
      校园里以他命名的工程楼叫什么?"

推理链:
1. 某航天计划 → 阿波罗 11 号
2. 指令舱驾驶员 → Michael Collins
3. 毕业大学 → 西点军校
4. 以他命名的工程楼 → (搜索答案)
```

##### (2) GUI-General: 通用网页操作任务

直接从真实网站抽取功能,合成任务:
```
"访问京东,搜索'三体',找到刘慈欣著、价格<50元的纸质书,加入购物车"
```

过滤掉:
- 需要登录的
- 太简单的 (一步完成)
- 太难验证的

##### (3) Gameplay: 游戏任务

收集/生成小游戏,写 JS 验证脚本:
```javascript
// 验证脚本示例
function verify_game_state() {
  return {
    score: game.score,
    level: game.level,
    success: game.score > 1000
  };
}
```

**为什么要训游戏?** 游戏是最好的长周期决策训练场,而且能自动生成无限任务。

---

#### 2.4.2 奖励设计:怎么判断任务做得好不好?

两种情况:

##### (1) 有标准答案

- **Gameplay**: 直接看游戏分数
- **GUI-Browsing**: 用 LLM-as-Judge 比对答案

```python
# LLM-as-Judge 伪代码
def evaluate(model_answer, ground_truth):
    prompt = f"模型答案:{model_answer}\n标准答案:{ground_truth}\n是否正确?(是/否)"
    return llm(prompt) == "是"
```

##### (2) 没有标准答案 (GUI-General)

**问题**: 网页操作任务往往没有唯一答案,怎么判断对错?

**解决方案**: 训练一个专门的 **Outcome Reward Model (ORM)**

- **输入**: 完整文本历史 + 最后 5 张截图
- **输出**: 0~1 的分数
- **训练方法**: 
  1. 人工标注一批 (成功/失败)
  2. 用 single-turn RL 训练到 F1=83.8

有意思的发现:**即使 ORM 有 16% 的错误率,RL 照样能训好**。为啥? 因为就算最终任务失败,中间步骤可能是对的,模型还是能学到东西。

---

#### 2.4.3 训练基础设施:怎么跑几百万次 rollout 不崩溃?

![](rl_infra.png)

三个关键设计:

##### (1) 异步推理 + 服务器化 Rollout

传统方式:
```python
for task in tasks:
    trajectory = model.rollout(task)  # 阻塞等待
    train(trajectory)  # 训练
```

问题:**长尾任务** (比如 1000 步的游戏) 会卡住整个训练流程。

新方式:
```python
# 伪代码
rollout_pool = []
for task in tasks:
    async_start(model.rollout, task)  # 异步启动

while True:
    if len(rollout_pool) >= min_batch_size:
        train(rollout_pool)  # 够一个 batch 就训练
        rollout_pool = [未完成的轨迹]  # 未完成的留着
```

**效果**: 不用等所有任务都跑完,够一个 batch 就可以开始训练。

##### (2) 有状态环境 (Stateful Environment)

传统 RL 环境每次 reset 都重新开始,UI-TARS-2 的环境**保持状态**:

```python
# 传统方式
env.reset()
for step in range(max_steps):
    action = model(obs)
    obs = env.step(action)

# UI-TARS-2 方式
session = env.create_session()  # 创建持久 session
for step in range(max_steps):
    action = model(obs)
    obs = session.step(action)  # session 保持状态
# session 自动清理
```

**好处**: 支持需要多轮工具调用、文件读写的复杂任务。

##### (3) 流式训练 (Streaming Training)

不用等整个 batch 跑完:
```
Rollout Pool: [完成的轨迹1, 完成的轨迹2, ..., 未完成的轨迹N]
              ↓
              只要够 min_batch_size 就开始训练
              ↓
              未完成的轨迹继续跑,下次再训练
```

---

#### 2.4.4 RL 算法:PPO 魔改大法

基础算法是 **PPO (Proximal Policy Optimization)**,目标函数:

$$
\mathcal{J}_{\text{PPO}}(\theta) = \mathbb{E} \left[ \min \left( r_t(\theta) \hat{A}_t, \text{clip}(r_t(\theta), 1-\varepsilon_{\text{low}}, 1+\varepsilon_{\text{high}}) \hat{A}_t \right) \right]
$$

其中:
- $r_t(\theta) = \frac{\pi_\theta(a_t|s_t)}{\pi_{\theta_{\text{old}}}(a_t|s_t)}$ (新旧策略的概率比)
- $\hat{A}_t$ (Advantage,表示这个动作比平均好多少)
- $\text{clip}(x, a, b)$ (把 $x$ 限制在 $[a, b]$ 之间)

但直接用 PPO 训长周期任务会炸,他们加了 5 个关键技巧:

##### 技巧 1: Reward Shaping (奖励塑形)

**问题**: 游戏可能 1000 步才结束,前 999 步奖励都是 0,模型不知道哪步做对了。

**解决方案**:
- **主要奖励**: 只看最终成功/失败
- **辅助奖励**: 
  - Format Reward (输出格式对了就给点分)
  - Length Penalty (太长或太短都扣分)

```python
reward = final_success * 100  # 主奖励
if valid_format:
    reward += 1  # 格式奖励
reward -= 0.01 * num_steps  # 长度惩罚
```

##### 技巧 2: Decoupled GAE (解耦广义优势估计)

**背景知识**: Advantage $\hat{A}_t$ 衡量"这个动作比平均好多少",计算公式:

$$
\hat{A}_t = \sum_{l=0}^{\infty} (\gamma \lambda)^l \delta_{t+l}
$$

其中 $\delta_t = r_t + \gamma V(s_{t+1}) - V(s_t)$ (TD error)

**问题**: 长序列 (比如 1000 步) 时,$\lambda$ 太大会放大噪声,$\lambda$ 太小会丢失长期信息。

**解决方案**: 策略网络和价值网络用**不同的 $\lambda$**:

$$
\begin{align}
\text{策略网络}: & \quad \lambda_{\text{policy}} = 0.98 \quad \text{(保留长期信息)} \\
\text{价值网络}: & \quad \lambda_{\text{critic}} = 0.90 \quad \text{(快速衰减噪声)}
\end{align}
$$

**直觉**: 策略网络需要看到远期回报来学习规划,价值网络需要稳定估计来指导训练。

##### 技巧 3: Length-Adaptive GAE (长度自适应)

**问题**: 10 步的简单任务和 1000 步的复杂任务,用同一个 $\lambda$ 不合理。

**解决方案**: 根据序列长度 $l$ 动态调整:

$$
\lambda_{\text{policy}} = 1 - \frac{1}{\alpha \cdot l}
$$

其中 $\alpha=0.05$ (超参数)

**效果**:
- 短序列 ($l=10$): $\lambda \approx 0.8$ (只看近期)
- 长序列 ($l=1000$): $\lambda \approx 0.98$ (看长期)

##### 技巧 4: Value Pretraining (价值预训练)

**问题**: PPO 开始时,价值网络是随机初始化的,给出的 $V(s)$ 乱七八糟,导致 Advantage 估计很差。

**解决方案**: 先用固定策略 (比如 SFT 模型) 跑一堆轨迹,用 **Monte Carlo 真实回报** ($\lambda=1.0$) 训练价值网络:

$$
\text{Loss} = \mathbb{E} \left[ \left( V_\theta(s_t) - \sum_{k=0}^{T-t} \gamma^k r_{t+k} \right)^2 \right]
$$

训练到 Explained Variance > 0.9 (价值网络能解释 90% 的回报方差) 再开始 PPO。

**效果**: 避免训练初期因为价值估计太烂导致策略崩溃。

##### 技巧 5: Clip Higher (非对称裁剪)

**标准 PPO**: 把概率比裁剪到 $[0.8, 1.2]$ (对称)

**UI-TARS-2**: 裁剪到 $[0.9, 1.3]$ (非对称)

$$
\text{clip}(r_t, 1-\varepsilon_{\text{low}}, 1+\varepsilon_{\text{high}}) \quad \text{where } \varepsilon_{\text{low}}=0.1, \varepsilon_{\text{high}}=0.3
$$

**直觉**:
- $\varepsilon_{\text{low}}=0.1$ (保守): 不轻易抛弃旧策略 (防止遗忘)
- $\varepsilon_{\text{high}}=0.3$ (激进): 鼓励尝试低概率但可能高回报的新动作 (扩大探索)

---

### 2.5 参数插值:怎么把多个专家 Agent 合成一个通才?

**问题**: GUI-Browsing、GUI-General、Game 三个领域差异很大,联合训练不稳定。

**解决方案**: 分别训练,然后**参数加权平均**:

$$
\theta^{(\text{merge})} = \alpha_1 \theta^{(\text{GUI-Browsing})} + \alpha_2 \theta^{(\text{GUI-General})} + \alpha_3 \theta^{(\text{Game})} + \cdots
$$

其中 $\sum \alpha_i = 1, \alpha_i \geq 0$

**理论依据**: 从同一个预训练模型微调出来的模型,在参数空间里是**线性模式连接**的 (linearly mode-connected),即参数插值后的模型性能不会太差。

**实验发现**: 合并后的模型在每个领域的表现都接近该领域的专家模型,而且能处理需要跨领域技能的复合任务。

---

## 3. 实验结果:到底有多强?

### 3.1 GUI 任务:全面吊打

| 模型 | OSWorld | WindowsAgentArena | AndroidWorld | Online-Mind2Web |
|------|---------|-------------------|--------------|-----------------|
| Claude-4 | 43.9 | - | - | - |
| OpenAI CUA-o3 | 42.9 | - | 52.5 | 71.0 |
| UI-TARS-1.5 | 42.5 | 42.1 | 64.2 | 75.8 |
| **UI-TARS-2** | **47.5** | **50.6** | **73.3** | **88.2** |

**关键发现**:
- 在 Online-Mind2Web 上达到 88.2%,接近人类水平
- RL 训练后,OOD 泛化能力暴增 (OSWorld +10.5%, AndroidWorld +8.7%)

### 3.2 游戏任务:接近人类 60%

15 款游戏的平均归一化分数 (人类=100):

| 模型 | 平均分 |
|------|--------|
| 人类 | 100.0 |
| **UI-TARS-2** | **59.8** |
| OpenAI CUA | 24.7 |
| Claude Computer Use | 21.6 |

**亮点**:
- 在 2048、Infinity-Loop 等游戏上达到人类 90%+ 水平
- 在 Shapes 上**超过人类** (108.9 vs 100)
- 比 OpenAI CUA 高 2.4 倍,比 Claude 高 2.8 倍

### 3.3 推理时扩展 (Inference-Time Scaling)

![](inference_scaling.png)

**发现**: 随着允许的最大步数增加,UI-TARS-2 的表现持续上升,其他模型很快就饱和了。

**为什么?** UI-TARS-2 学会了**解锁新子目标**,而不是瞎转悠。

---

## 4. 训练过程的有趣发现

### 4.1 熵的变化:探索 vs 利用

传统 reasoning RL (比如 OpenAI o1) 训练时,熵单调下降 (模型越来越确定)。

UI-TARS-2 的熵**先升后降**:

![](entropy.png)

**解释**: GUI 和游戏环境需要持续探索,模型在学习过程中发现了更多有效策略,而不是过早收敛到单一解法。

### 4.2 Think Length 的变化:从长到短

![](think_length.png)

**GUI 任务**: Think length 持续下降

**解释**: 一旦知道该点哪个按钮,就不需要长篇大论的推理了,直接行动更高效。

**游戏任务**: Think length 呈周期性

**解释**: 每次游戏升级难度,Think length 就上升 (需要思考新策略),熟悉后又下降。

### 4.3 VLM-as-Verifier 靠谱吗?

用 UI-TARS-2 自己当 ORM (奖励模型),F1=83.8,错误率 16%。

**惊人发现**: 即使错误率这么高,RL 照样训得好!

**原因**: 即使任务最终失败,中间很多步骤可能是对的,模型还是能从正确的中间步骤学到东西。这些正确步骤的奖励 > 错误奖励的负面影响。

### 4.4 PPO vs GRPO

GRPO 在推理任务上很强,但在 GUI Agent 上 PPO 碾压 GRPO:

![](ppo_vs_grpo.png)

**推测**: GRPO 更适合单轮推理,PPO 更适合多轮交互。

### 4.5 混合 RL:GUI + GUI-SDK

实验设置:
- **Baseline**: 分别训练 GUI-only 和 GUI-SDK-only
- **Hybrid**: 同时训练两种接口 (每种接口的数据量减半)

结果:
- Hybrid 模型在 GUI-only 任务上**超过** GUI-only baseline
- 原因:**GUI-SDK 学到的知识迁移到了 GUI**

**启示**: 更强大的接口能帮助模型学习更好的表征,即使最终只用弱接口。

---

## 5. 对我们的启发

### 5.1 数据层面

1. **在线 Interactive Annotation 是王道**
   - 模型生成多个候选,人工选择/修正
   - 保证数据是 on-policy 的

2. **Think-Aloud 标注法**
   - 让标注员边操作边说想法
   - ASR + LLM 润色,得到高质量 reasoning

3. **数据飞轮**
   - 高质量数据进 SFT,低质量数据进 CT
   - 没有数据浪费,持续迭代

### 5.2 训练层面

1. **必须上 RL**
   - SFT 只能到 80% 左右,RL 能冲到 90%+
   - RL 带来的泛化能力提升巨大 (OOD +10%)

2. **长周期 RL 的关键技巧**
   - Value Pretraining (价值预训练)
   - Decoupled GAE (解耦 $\lambda$)
   - Length-Adaptive GAE (自适应 $\lambda$)
   - Clip Higher (非对称裁剪)

3. **流式训练 + 异步 Rollout**
   - 不要等长尾任务,够一个 batch 就训练
   - 大幅提升训练效率

### 5.3 环境层面

1. **Stateful Environment**
   - 支持多轮工具调用,保持状态

2. **GUI + SDK 混合**
   - 纯 GUI 不够用,命令行、文件系统必不可少

3. **硬件加速 + 时间操控**
   - 游戏环境需要 GPU 加速截图
   - 能暂停/加速游戏时间,提升采样效率

---

## 6. 还有哪些坑?

1. **奖励模型的假阳率**
   - 当前 ORM 的 F1=83.8,还有 16% 的错误
   - 虽然不影响训练,但理论上还有提升空间

2. **长周期任务的信用分配**
   - 1000 步的游戏,怎么知道第 37 步做对了?
   - 当前主要靠稀疏奖励 + Value Pretraining,还可以引入更多先验 (比如 Hindsight Experience Replay)

3. **参数插值的权重**
   - 论文没说 $\alpha_i$ 怎么定的
   - 可能需要网格搜索或者用验证集调

4. **量化带来的精度损失**
   - W4A8 量化后,OSWorld 从 47.5 降到 44.4
   - 对延迟敏感的应用可以接受,但还有优化空间

---

## 7. 总结

UI-TARS-2 最牛的地方不是某个单点技术,而是**系统性的方法论**:

1. **数据飞轮**: 模型和数据互相喂养,持续迭代
2. **Interactive Annotation**: On-policy 数据采集,人在回路
3. **Sandbox 环境**: GUI + SDK 混合,有状态,高并发
4. **魔改 PPO**: 5 个关键技巧,专治长周期 RL
5. **参数插值**: 分别训练专家,合并成通才

如果你想做 GUI Agent,这篇论文是必读的。不仅技术细节清晰,而且很多坑都帮你踩过了。

最后提一句:**开源万岁!** 字节愿意把这么多细节公开,对整个社区都是巨大贡献。

---

**参考文献**:
- UI-TARS-2

UI-TARS 2.0 论文精读

要让Cursor（VSCode）在Windows任务栏显示工程名称而不是文件名，需要修改VSCode的窗口标题配置。具体步骤如下：
方法一：通过设置界面修改
1. 打开Cursor/VSCode，按 `Ctrl+,` 打开设置
2. 在搜索框中输入 window.title
3. 将默认值修改为：


```bash
${dirty}${rootName}${separator}${activeEditorMedium}${separator}${appName}
```


也就是填写到这里ctrl+S就行了：
![image.png](/static/img/724d12d2ea1f7b6f77a141dc81c5f9a9.image.webp)



Cursor（VSCode）在Windows任务栏显示工程名称而不是文件名

https://mp.weixin.qq.com/s/dU428dZEB9HoNtxnBRFISQ

论文标题：

EvoLM: In Search of Lost Language Model Training Dynamics

论文链接：

https://arxiv.org/pdf/2506.16029

项目主页：

https://zhentingqi.github.io/internal/projects/EvoLM/

代码链接：

https://github.com/zhentingqi/evolm


EvoLM训练流程：

![image.png](/static/img/f2942526520ed4d02022e8b4ddc9548d.image.webp)



根据EvoLM论文的研究结果，以下是针对"8张4090"算力条件下的LLM炼丹最优配方总结：

📋 核心配方要点

1. 基础模型选择

• 优先小模型：选择1B-3B参数的充分训练基座（如TinyLlama）

• 避坑：不要使用大模型的中间checkpoint，性能会显著下降

2. 持续预训练(CPT) - 最关键步骤

• 必须执行：领域适配的CPT不能跳过

• 黄金比例：通用数据:领域数据 = 1:5（约16%通用数据回放）

• 算力分配：30-40B Tokens即可饱和，约需几天时间


![image.png](/static/img/12b07368346a3df38cbb92a693bb1455.image.webp)

3. 监督微调(SFT)策略

• epoch控制：严格限制在2-4个epoch（3个为最佳）

• 防过拟合：超过4个epoch会损害泛化能力

• 留有余地：不要用SFT填满模型，为RL预留空间

4. 强化学习(RL)取舍

• 饱和点：4-8个epoch或50-100K样本即达收益饱和

• 作用本质：RL主要提升置信度而非根本推理能力

• 算力警告：PPO需要4个模型副本，显存消耗巨大

⚖️ 算力分配决策树

场景一：追求领域专家（数学/医疗/法律）

• 配方：重SFT + 轻RL（70-90%预算给SFT）

• 理由：SFT对域内任务提升最直接稳定

场景二：追求通用推理能力

• 配方：轻SFT + 重RL（10% SFT + 90% RL）

• 风险：RL容易导致输出冗长，需要精细调优

🎯 监控指标革新

• 弃用：Validation Loss和PPL（后训练阶段零相关）

• 采用：ORM分数（与下游性能强相关0.62-0.84）

• 工具：使用现成Reward Model（如Skywork）进行验证

💡 终极建议

对于大多数资源受限场景，最稳妥路径是：
1. 选择质量基座
2. 执行带Replay的CPT  
3. 进行3个epoch的SFT
4. 跳过RL（除非算力充裕）

EvoLM证明：精心调教的SFT模型往往优于配置错误的RL模型，在算力有限时尤为明显。

EvoLM LLM炼丹师最优配方

qwen3vl的tools设计验证

stepfun-ai/GELab-Zero-4B-preview

win：
```js
C:\Users\Administrator\.wslconfig
```
win写这个文件为：
```js
[wsl2]
networkingMode=mirrored
dnsTunneling=true
firewall=false
autoProxy=true
```
win重启，然后ps关闭防火墙：

```js
# 允许 ICMPv4 入站流量（针对 ping）
New-NetFirewallRule -DisplayName "WSL Ping Allow" -Direction Inbound -InterfaceAlias "vEthernet (WSL)" -Action Allow -Protocol ICMPv4
```


wsl:

```js
cc@DESKTOP-564RG57:~$ cat /etc/resolv.conf
# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
# [network]
# generateResolvConf = false
nameserver 172.21.160.1

```
wsl ping 这个nameserver。




摘要

mask_history 参数详解

1. 基本定义

1. 他们到底想解决什

tools工作流说明

`mask_history` 参数详解