HansBug/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。
目录
快速开始
用 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-iter335oc-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: 10Reward 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 轮。
训练曲线
六个子图说明：
详细的训练曲线、异常事件分析、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。iter351 在中间出现明显回落（甚至跌穿 base），iter367 部分恢复但仍未回到 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 跑到 iter367 停（rollout 367 ≈ 训练 4.5 天），按 retention daemon 配置仅保留 latest 3 ckpt：iter335 / iter351 / iter367。所有 4 个候选（含 base）都在 TB v0.1.x 跑过 OOD eval，得到的训练→OOD 轨迹是：
iter335 是这次训练**唯一明确"训练侧 ↑ + OOD ↑"的 ckpt**。这是 [issue #8 iter215](https://github.com/HansBug/OpenClaw-RL/issues/8)（8B run-3 也在中段 ckpt 拿 OOD 峰，最后回落）同款现象。如果你要拿一个最有可能在新 OOD task 上 work 的 30B fresh-run ckpt，**应该用这个 iter335**，不要用最新的 iter_367。
推理时的 on-the-wire 协议
训练时这个 ckpt 看到的协议是 [camel-ai `TerminalToolkit`](https://docs.camel-ai.org/key_modules/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。
已知限制
- 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 容量假说 一致。
- iter_351 / iter_367 的存在说明 RL 训练后期有 OOD 漂移风险。iter335 是这次训练全 4 ckpt 中唯一 net-positive 的；更晚的 iter351 反而跌穿 base。如果你打算复现这个训练 pipeline，建议把 ckpt freeze 频率提高，每 50-100 rollout 都做 OOD eval 看 trajectory。
- 模型不会主动停止 tool_call。训练时 agent loop 由
max_iteration: 10硬截断 + outcome reward 兜底，inference 时要自己设上限（oc-repl 默认 12 轮）。
- 复杂多步 task adherence 中等。简单任务（chmod、cat、ls）adherence 满分；多文件 Python 服务器、复杂 awk 这种偶尔会 thinking 太久没产出 tool_call。
- terminus-2 / terminus-XML 协议是 OOD。模型没在这些协议上 RL 训练过，能不能跑通靠 qwen3 底座的通用指令跟随能力。要复刻训练分布请用 camel TerminalToolkit 协议。
- 不是 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。