superqwen/gpt-oss-20b-swe-lora

gpt-oss-20b SWE-agent LoRA

LoRA adapter for superqwen/gpt-oss-20b (identical weights to openai/gpt-oss-20b), fine-tuned on resolved coding-agent trajectories from SWE-bench/SWE-smith-trajectories rendered in the harmony chat format.

• Examples: 1200 trajectories, 5,644,966 tokens, max length 6144
• Steps: 150, final train loss 0.3265
• Targets: attention q/k/v/o and MoE expert weights on three layers (PEFT target_parameters)
• Tools seen in training: bash, str_replace_editor, submit (SWE-agent schema, see training/prep.py)

Training code: training/ in this repo.

Evaluation

40 held-out trajectories (the 40 that follow the training set in the same shuffled order):

	base	+ LoRA
Assistant-token loss	0.881	0.271

Next-action test through vLLM's OpenAI-compatible API: each trajectory is cut just before a random tool call and the model picks the next action (tools: bash, str_replace_editor, submit; temperature 0).

	base	+ LoRA
Returns a tool call	95%	100%
Arguments are valid JSON	92.5%	95%
Same tool as the reference	47.5%	90%
Same str_replace_editor sub-command	28%	67%
Request errors	1	0
Has reasoning text	92.5%	0%
Median latency	1.1 s	2.0 s

On three SuperQwen-style tasks with SuperQwen's own tools (repo.tree, code.search, file.read, …) both models answered with a tool call (repo.tree) every time; three prompts are only a smoke test.

The LoRA model goes straight to the tool call on SWE-agent-style conversations and leaves the reasoning channel empty: the training trajectories rarely carried pre-call text. Expect empty reasoning in that setting.

Raw results: eval/ in the Hub repo.

Serving with vLLM

Verified with vLLM 0.31.0 on 1× H100 80GB (driver 580 / CUDA 13.0 — vLLM 0.31's torch 2.13 wheel needs a CUDA 13 driver). The MXFP4 base plus the LoRA load in 14 GiB, so no merge is needed:

hf download superqwen/gpt-oss-20b-swe-lora --include "adapter_*" --local-dir /models/swe-lora
vllm serve superqwen/gpt-oss-20b \
  --enable-lora --max-lora-rank 16 --max-loras 1 \
  --lora-modules swe=/models/swe-lora \
  --tool-call-parser openai --enable-auto-tool-choice --reasoning-parser openai_gptoss \
  --max-model-len 16384

• Request "model": "swe" for the fine-tune; the base stays available under the served model name.
• Tool calls come back as OpenAI tool_calls; reasoning, when present, in message.reasoning.
• Both repos are public, so no HF_TOKEN is needed. openai/gpt-oss-20b has the same base weights.
• The eval served the base from a local snapshot without original/ and metal/; pointing vLLM at the Hub id may also download those 28 GB.
• vLLM's FlashInfer sampler JIT-compiles on first use and needs ninja on PATH and a CUDA toolkit matching vLLM's torch; the eval sets VLLM_USE_FLASHINFER_SAMPLER=0 to skip it.
• Merging into bf16 with transformers 5.19 produced expert weight names vLLM 0.31 could not load (down_proj without .weight), so serve the adapter rather than a merged checkpoint.

License

The adapter weights and the training code in this repo are released under the Apache License 2.0, the same license as the base model.

• Base model: openai/gpt-oss-20b, Apache-2.0, subject to the gpt-oss usage policy.
• Training data: SWE-bench/SWE-smith-trajectories, MIT.