• Bottom line: Wait — GRPO fine-tuning with LoRA (only ~6M trainable parameters, 1.66% of the model) lifted LFM2.5-350M's IFStruct score from 22.6% to 29.7% overall in just 100 training steps, but 29.7% is the number that decides production-readiness.
• Gains were uneven: JSON compliance rose 13.9 points and bare-list formatting rose 13.1 points, but YAML barely moved (+0.3 points).
• The entire run — training and evaluation — used free-tier Colab/Kaggle GPUs (16GB) plus a MacBook Pro M5 Max for local serving via llama.cpp, not a data-center cluster.
• Even after tuning, the model fails IFStruct structured-output tasks roughly 70% of the time, which matters for any pipeline that treats LLM output as machine-parseable input.
• The reward function stacked three checks — parseability, field-count accuracy, and JSON Schema constraint validation — weighted 1.0/0.5/2.0, showing schema compliance dominated the training signal.

Bottom line: Wait. A Hugging Face and Liquid AI tutorial published this month shows that 100 steps of GRPO reinforcement-learning fine-tuning can meaningfully improve how reliably a small language model follows structured-output formats — but the resulting model, a 350-million-parameter LFM2.5, still fails roughly seven of every ten formatting tasks on the IFStruct v1.0 benchmark, according to the blog post's own reported numbers. The decisive figure is 29.7% overall accuracy, not the 7.1-point gain over baseline.

The recipe

The tutorial fine-tunes Liquid AI's LFM2.5-350M using GRPO through Hugging Face's TRL library, sampling eight completions per prompt against roughly 500 examples from NVIDIA's Nemotron-RL-instruction_following-structured_outputs dataset. Training used a LoRA adapter touching only about 6 million parameters — 1.66% of the model — over 100 steps with a batch size of 4 and gradient accumulation of 8, run entirely on free-tier Colab or Kaggle GPUs with 16GB of memory, per the Hugging Face post.

What the reward function actually optimized

The GRPO reward combined three checks weighted 1.0, 0.5, and 2.0: whether output was parseable at all, whether it matched the expected field count, and whether it validated against a JSON Schema with constraint-violation counting. Weighting schema validation twice as heavily as raw parseability signals the authors optimized specifically for machine-readability over surface fluency — a sensible choice for a benchmark built around programmatic consumption of model output, not human readability.

The numbers, unevenly distributed

Overall IFStruct accuracy rose from 22.6% to 29.7% (+7.1 points), but the gain was concentrated: JSON formatting nearly doubled from 18.0% to 31.9% and bare-list formatting rose from 16.6% to 29.7%, while YAML barely moved, from 27.2% to 27.5%. That spread suggests the reward function generalized well to JSON-like structures but did little to correct whatever base-model failure mode was already dragging down YAML compliance.

Why the absolute number, not just the delta, is the story

A +7.1-point gain reads well as a percentage change, but the operative number for anyone building a pipeline is the 29.7% floor: nearly 71% of structured-output requests still fail after tuning. Any system that treats LLM output as machine-parseable input — a tool-calling agent, a JSON-schema-gated API response, a downstream parser with no human in the loop — inherits that failure rate directly, and a fail-open parser on unvalidated model output is a reliability and security liability regardless of how the model was trained.

The bottom line

Bottom line: Wait. As a tutorial, the GRPO-with-TRL recipe is genuinely useful — a reproducible, LoRA-efficient, single-free-GPU path to measurable format-following gains on a sub-billion-parameter model in 100 steps, with a sensible reward-shaping template (parseability plus schema validation). But the one number that decides deployment is 29.7%: nothing in the published results supports putting LFM2.5-350M, tuned this way, into a production pipeline that gates on schema compliance. A sub-30% pass rate demands a validator-and-retry loop or a larger base model, not blind trust in the fine-tuned output.