Qwen3-30B-A3B-OpenClaw-RL-iter335

Qwen3-30B-A3B-OpenClaw-RL-iter335

把 Qwen/Qwen3-30B-A3B (vanilla, 30B total / 3B active MoE) 用 HansBug/OpenClaw-RL 的训练框架做 GRPO outcome-only RL（dense pass-rate reward，无 PRM、无 process reward）跑出来的 best 中间 checkpoint，对应 wandb run b0il0mq4 的 rollout 335 (megatron iteration 335)。

在 terminal-bench v0.1.x 66 个 OOD task 上把 base Qwen3-30B-A3B 的 pass@1 从 0.0606 推到 0.0808 (+33%)、pass@3 从 0.1212 推到 0.1515 (+25%)，是这次 30B fresh run 训练中唯一明确"超越自身 base"的 ckpt。

完全 drop-in 兼容：config / generation_config / tokenizer 全部跟上游 Qwen/Qwen3-30B-A3B 字节级一致；任何能跑 Qwen3-30B-A3B 的工具链（HF transformers、vLLM、sglang、ollama、llama.cpp 转 GGUF 等）一行都不用改。

完整的训练 + eval 详细分析见 HansBug/OpenClaw-RL issue #14。

---

目录

1. 快速开始
2. 模型从哪来
3. 训练设置
4. 训练曲线
5. 评测结果
6. 为什么是 iter_335 而不是最新 ckpt
7. 推理时的 on-the-wire 协议
8. 已知限制
9. 复现 / 推理工具
10. 引用 / 致谢

---

快速开始

用 HF transformers

from transformers import AutoTokenizer, AutoModelForCausalLM

tok = AutoTokenizer.from_pretrained("HansBug/Qwen3-30B-A3B-OpenClaw-RL-iter335")
model = AutoModelForCausalLM.from_pretrained(
    "HansBug/Qwen3-30B-A3B-OpenClaw-RL-iter335",
    torch_dtype="bfloat16",
    device_map="auto",
)

messages = [
    {"role": "user", "content": "Write a one-line bash command to recursively count *.py files under /usr/lib."}
]
text = tok.apply_chat_template(messages, tokenize=False, add_generation_prompt=True)
inputs = tok(text, return_tensors="pt").to(model.device)
out = model.generate(**inputs, max_new_tokens=256, temperature=0.2)
print(tok.decode(out[0][inputs.input_ids.shape[1]:], skip_special_tokens=True))

用 sglang（推荐，配 tool-call 支持 + MoE 加速）

python -m sglang.launch_server \
    --model-path HansBug/Qwen3-30B-A3B-OpenClaw-RL-iter335 \
    --served-model-name qwen3-30b-rl-iter335 \
    --tp 4 --port 30000 \
    --mem-fraction-static 0.85 \
    --tool-call-parser qwen \
    --disable-custom-all-reduce

跟 base Qwen3-30B-A3B 一样的启动参数。TP=4 时 30B MoE 单 rank ~15 GB params + ~120 GB kv cache，放 4× 80 GB GPU 或 4× 143 GB GPU 都没问题。--disable-custom-all-reduce 是 issue #8 已知 Hopper bug 的兜底 flag，保留即可。--tool-call-parser qwen（或 qwen25）把模型的 <tool_call>{...}</tool_call> 还原成 OpenAI 结构化 tool_calls，这正是训练时 rollouts 用的 parser。

用 vLLM

vllm serve HansBug/Qwen3-30B-A3B-OpenClaw-RL-iter335 \
    --tensor-parallel-size 4 \
    --enable-auto-tool-choice --tool-call-parser hermes

用 oc-repl 直接交互（端到端 demo）

HansBug/oc-repl 是一个针对这个 family 量身写的 Codex 风格 REPL：

pip install git+https://github.com/HansBug/oc-repl

# 起一个 sandbox 容器（任何 ubuntu/python image 都行）
docker run -d --name oc-sandbox -w /app ubuntu:24.04 sleep infinity

# 启动交互式 REPL
oc-repl --sandbox docker:oc-sandbox \
        --api-base http://127.0.0.1:30000/v1 \
        --model qwen3-30b-rl-iter335

oc-repl 默认 --protocol camel-terminal-toolkit 对齐训练分布，详见仓库 README。

---

模型从哪来

Qwen3-30B-A3B-OpenClaw-RL-iter335 = Qwen3-30B-A3B (vanilla, 不是 Coder-30B-A3B-Instruct，也不是 30B-A3B-Instruct-2507) + 335 个 RL rollout 的 GRPO outcome-only 训练，rollout 在 SETA terminal env pool 提供的 1376 个 terminal task 上。每个 task 是一个真实的 Linux shell 任务（修脚本、解 base64、起 server、跑 pytest…），在隔离 docker 容器里跑，agent 通过 camel.toolkits.TerminalToolkit 暴露的 4 个工具操作 shell。

为什么是 vanilla 而不是 Coder-30B-A3B-Instruct？ 初次用 Coder-30B-A3B-Instruct 跑了 1114 个 rollout 全 fail —— 它的 chat_template.jinja 用 tool_call.arguments|items 要求 arguments 是 dict，但 slime/sglang 走 OpenAI 协议把 arguments 序列化成 JSON string → jinja2 TypeError。vanilla Qwen3-30B-A3B 的 chat_template 与 8B 字节级相同，整条 slime + terminus-2 + harbor 链路 0 修改通过。详见 HansBug/OpenClaw-RL issue #14 §1.1。

---

训练设置

完整启动命令见 run_qwen3_30b_a3b_experiment.sh。关键超参（与 8B run-3 算法侧完全相同，仅 MoE 并行差异）：

# GRPO 算法 (同 8B run-3, issue #4)
--advantage-estimator grpo
--use-kl-loss --kl-loss-coef 0.01 --kl-loss-type k3
--dynamic_history

# Optimizer (low LR + Adam beta2=0.98)
--optimizer adam --lr 1e-6 --lr-decay-style constant
--weight-decay 0.1 --adam-beta1 0.9 --adam-beta2 0.98

# Rollout (同 8B)
--rollout-batch-size 16
--n-samples-per-prompt 8           # GRPO group size = 8
--num-steps-per-rollout 2
--rollout-temperature 1
--rollout-max-response-len 8192
--rollout-max-context-len 16384

# Megatron — MoE 并行（与 8B 不同）
--tensor-model-parallel-size 4
--expert-model-parallel-size 4     # 128 expert 分到 4 张 actor 卡，每卡 32 expert
--expert-tensor-parallel-size 1
--sequence-parallel
--recompute-granularity full

# Save / freq
--save-interval 16                  # save 每 16 rollout（≈ 5.3h/save）
--num-rollout 2000                  # 训练目标（实际跑到 367 停）

# Rollout agent + tool-call parser
--custom-config-path configs/rollout_qwen3.yaml   # tool_call_parser: qwen25
                                                  # max_iteration: 10

Reward signal：dense pass-rate, outcome-only —— 每个 rollout 跑完后由任务自带的 run-tests.sh 在 sandbox 里跑 pytest，reward = passed / total_tests ∈ [0, 1]，再线性变换到 score = 2·reward − 1 ∈ [-1, +1] 喂给 GRPO；没有 PRM / process reward，整个 episode 共用一个标量。

max_iteration: 10：训练时 agent loop 上限 10 轮。

---

训练曲线

来自 wandb run b0il0mq4：

六个子图说明：

详细的训练曲线、异常事件分析、vs 8B run-3 叠加图见 HansBug/OpenClaw-RL issue #14。

---

评测结果

在 terminal-bench v0.1.x（66-task harbor 子集）上的 pass@1 / pass@3

iter_335 这个 ckpt 在 OOD eval（agent harness 切到 harbor run --agent terminus-2，与 issue #8 8B run-3 同协议）上的成绩：

iter_335 是这次 fresh run 中唯一 pass@1 / pass@3 / unique_solved 三项全部超过 base 的 ckpt。iter_351 在中间出现明显回落（甚至跌穿 base），iter_367 部分恢复但仍未回到 iter_335 峰。详细分析见 issue #14 eval comment。

vs 8B run-3（issue #8 同 66-task 标尺）

注：本 ckpt 跑的是 66-task 子集（harbor migration 失败 20 task 后剩下的可跑部分），与 leaderboard 80-task 全集不可直接横比；但唯一靠谱的同标尺对比是与 issue #8 同样 66 子集的 Qwen3-8B 数字，本 ckpt 的 pass@1 = 0.081 比 Qwen3-8B-iter215 (0.056) 高 44%。

任务级别的 OOD 解题分布

14 个 task 在所有 4 个 ckpt × 3 attempt 中至少被解出 1 次，其余 52 task 全部 0 solved（与 issue #8 60/66 全 0 同 pattern）。iter_335 独占解出的 task：csv-to-parquet、path-tracing-reverse、processing-pipeline 2x。

---

为什么是 iter_335 而不是最新 ckpt

完整 30B fresh run 跑到 iter_367 停（rollout 367 ≈ 训练 4.5 天），按 retention daemon 配置仅保留 latest 3 ckpt：iter_335 / iter_351 / iter_367。所有 4 个候选（含 base）都在 TB v0.1.x 跑过 OOD eval，得到的训练→OOD 轨迹是：

iter_335 是这次训练唯一明确"训练侧 ↑ + OOD ↑"的 ckpt。这是 issue #8 iter215（8B run-3 也在中段 ckpt 拿 OOD 峰，最后回落）同款现象。如果你要拿一个最有可能在新 OOD task 上 work 的 30B fresh-run ckpt，应该用这个 iter_335，不要用最新的 iter_367。

---

推理时的 on-the-wire 协议

训练时这个 ckpt 看到的协议是 camel-ai TerminalToolkit 的 4 工具 OpenAI function-calling（与 Qwen3-8B-OpenClaw-RL-iter215 完全相同），不是 terminal-bench 的 terminus-2 JSON 协议。

System prompt 是 terminal-rl/agent/camel_agent.py::get_developer_agent_prompt() 在 system='Linux (in Docker)', machine='x86_64', non_think_mode=True 配置下产出，结尾加 /no_think 关闭 qwen3 的 think trace。

如果你想 100% 复刻训练分布在 inference 用这个 ckpt，用 HansBug/oc-repl 的默认 --protocol camel-terminal-toolkit。

---

已知限制

1. 30B 在 OOD 上的 RL 边际收益比 8B 小。本 ckpt vs 30B base：pass@1 +33%；Qwen3-8B-iter215 vs Qwen3-8B base 是 +180%。如果你的目标是 frontier OOD 性能，纯 RL 已经 saturating，需要换 cold-start SFT。这与 issue #11 容量假说 一致。

2. iter_351 / iter_367 的存在说明 RL 训练后期有 OOD 漂移风险。iter_335 是这次训练全 4 ckpt 中唯一 net-positive 的；更晚的 iter_351 反而跌穿 base。如果你打算复现这个训练 pipeline，建议把 ckpt freeze 频率提高，每 50-100 rollout 都做 OOD eval 看 trajectory。

3. 模型不会主动停止 tool_call。训练时 agent loop 由 max_iteration: 10 硬截断 + outcome reward 兜底，inference 时要自己设上限（oc-repl 默认 12 轮）。

4. 复杂多步 task adherence 中等。简单任务（chmod、cat、ls）adherence 满分；多文件 Python 服务器、复杂 awk 这种偶尔会 thinking 太久没产出 tool_call。

5. terminus-2 / terminus-XML 协议是 OOD。模型没在这些协议上 RL 训练过，能不能跑通靠 qwen3 底座的通用指令跟随能力。要复刻训练分布请用 camel TerminalToolkit 协议。

6. 不是 frontier 水平。pass@1 0.081 跟 Qwen3-235B 同水位（甚至略高），但跟 Claude 4.5 / GPT-5 还有 6-8× 差距。这个 ckpt 适合做 RL 训练框架的 baseline / case study / MoE base 上 RL 的对比基准，不适合直接当 production agent 用。

---

复现 / 推理工具

---

引用 / 致谢

• 基座：Qwen/Qwen3-30B-A3B（Apache-2.0，vanilla 版，2025-04 release）
• 训练框架：HansBug/OpenClaw-RL
• Agent harness：camel-ai/camel TerminalToolkit
• Eval benchmark：laude-institute/terminal-bench
• Rollout 训练数据 pool：camel-ai/seta 1376 task

License: Apache-2.0（继承自 Qwen3-30B-A3B）。

如果你用这个 ckpt 做 paper / blog post，欢迎引用 HansBug/OpenClaw-RL 仓库 + 这个 model card。