[hodaaaaaaaaaa]

Problem

The gemma-4 LoRA sampler loads the full gemma-4 model, including its image and audio parts. OpenRL only sends text, but vLLM still sets those parts up at start-up. The full fine-tuning sampler already loads the text-only model; LoRA was left out when that was added.

Change

gemma-4 LoRA samplers load the text-only model (Gemma4ForCausalLM) too. LoRA adapters still apply correctly: on an A100, a trained adapter gives the same tokens under both models, and log-probabilities agree within 0.0011.

VLLM_ENABLE_MULTIMODAL=1, which already turns image and video input back on, now also keeps the full model. The API server passes it on to sampler pods.

Results

From the latest fleet test on GKE (eight GSM8K GRPO jobs launched together: gemma-4-E2B on H100, Qwen3-0.6B on L4, LoRA and full fine-tuning), with all three sampler start-up changes (#358, #359, #360):

• Before, the gemma-4-E2B LoRA sampler took 10–19 s longer than Qwen3-0.6B's to reach its engine; now both take 16 s. The gemma-4-E2B LoRA sampler is ready in 85 s instead of 231–243 s.
• Rewards and sampling time per step show no consistent change.