Glonce

LiquidAI's LFM2.5-350M climbs to 29.7% on IFStruct after 100 GRPO steps

researchThe Glonce editorsHugging Face🔥67Glonce rating67Impact65Novelty55Relevance100Surprise35Players45Credibility85
LiquidAI's LFM2.5-350M climbs to 29.7% on IFStruct after 100 GRPO steps

A Hugging Face blog post walks through fine-tuning LiquidAI's LFM2.5-350M, a 350 million parameter model, to produce more reliable structured output such as valid JSON or YAML matching a requested schema. The benchmark used throughout is IFStruct, an open-source test of whether a model's output is valid, parseable and schema-compliant, built by Liquid4All with its dataset hosted on Hugging Face. The IFStruct release blog reports a 21.1% score for LFM2.5-350M; running the same model locally through llama.cpp's OpenAI-compatible server on a MacBook Pro with an Apple M5 Max and 36GB of unified memory, the authors measure 22.6% (452 of 2000 samples passed) and use that local figure, not the published one, as the baseline for a same-stack comparison. The authors are explicit that this pipeline is not the one used to train the RL model in the original IFStruct blog, and that the goal is not to reproduce that benchmark score but to show that task-specific fine-tuning of a small model can close ground on far larger ones. Training uses GRPO through Hugging Face's TRL library on about 500 samples from Nvidia's Nemotron-RL-instruction_following-structured_outputs dataset, which pairs each prompt with a target JSON Schema and an expected field count. To cover gaps between that dataset and IFStruct's evaluation style, 40% of prompts get an added instruction to return output inside a fenced code block, and a separate 20% are converted into top-level-array tasks that require an exact item count. A LoRA adapter with rank 16 is attached to LFM2.5-350M, targeting the model's LFM-specific module names because the architecture mixes attention and convolution layers; the adapter trains about 6 million parameters, roughly 1.66% of the full model. Three reward functions drive the GRPO run, combined with weights of 1.0, 0.5 and 2.0: one for whether the output parses and matches the requested fenced or raw form, one for whether the top-level field count matches the target exactly, and one for full JSON Schema validation that also gates partial credit on covering required keys. Training runs for 100 steps with 8 generations per prompt group, a per-device batch size of 4 and gradient accumulation of 8 (yielding 4 prompt groups per optimizer step), a learning rate of 5e-5, temperature 1.1, and a KL penalty (beta) of 0.01 toward the reference model, sized to fit a free-tier 16GB GPU such as Colab or Kaggle offers. The LoRA weights are then merged back into the base model and saved as a single checkpoint, converted to a BF16 GGUF file, and served again through llama.cpp for a second IFStruct run on the identical evaluation stack. The fine-tuned model passes 594 of 2000 samples overall, 29.7%. Broken down by format, JSON pass rate roughly doubles, from 18.0% (180/1000) to 31.9% (319/1000), while YAML barely moves, from 27.2% (272/1000) to 27.5% (275/1000). By top-level structure, bare-list output compliance nearly doubles, from 16.6% (164/989) to 29.7% (294/989), while wrapper-key structure moves only slightly, from 28.5% (288/1011) to 29.7% (300/1011). Results vary widely by task category: event ticket booking rises from 45.8% to 57.9%, log parser examples from 29.2% to 45.8%, and support ticket batches from 37.0% to 49.3%, but camera review actually falls from 7.2% to 6.0% and gpu review is roughly flat, moving from 6.4% to 7.4%. After tuning, the most common failure is still a required field missing (7331 occurrences), followed by wrong item count (890) and type mismatches (555); some earlier failure modes, such as extraneous 'notes' or 'path' fields, shrink or change composition, while new ones appear, including specific schema violations like exceeding a maximum value or using disallowed units. The article's own closing comparison of the two runs is cut off in the captured text, so its final framing of the results is not available here.

Key facts

  • Fine-tuning LiquidAI's LFM2.5-350M with 100 GRPO steps raised its IFStruct overall pass rate from a 22.6% local baseline (452/2000) to 29.7% (594/2000), on the identical llama.cpp serving stack.
  • The LoRA adapter used for training touched about 6 million parameters, roughly 1.66% of the 350M model, targeting LFM2.5's hybrid attention and convolution module names.
  • Training used about 500 samples from Nvidia's Nemotron structured-outputs dataset, with 40% of prompts given a fenced-code-block instruction and a separate 20% converted into array-style, exact-item-count tasks.
  • Gains were uneven across formats: JSON pass rate nearly doubled (18.0% to 31.9%) and bare-list structure compliance nearly doubled (16.6% to 29.7%), while YAML pass rate barely changed (27.2% to 27.5%).
  • Not every task category improved: camera review pass rate fell from 7.2% to 6.0%, and after tuning the dominant failure mode remained a missing required field, occurring 7331 times across the 2000-sample run.

Why it matters

Structured output, getting a model to reliably return valid, parseable data in an exact requested shape, often decides whether a model can be wired into a downstream system at all, yet most benchmarks blend it into broader reasoning scores rather than measuring it directly. This tutorial demonstrates, with a specific measured result, that a small model can be pushed measurably closer to larger-model territory on that narrow but practical skill using a training run cheap enough for a free-tier GPU.

Who it affects

Developers who need schema-compliant output from small, locally or cheaply hosted models, including those running on constrained hardware such as a MacBook via llama.cpp or a free-tier Colab or Kaggle GPU. It is also relevant to anyone evaluating LiquidAI's LFM2.5 model family or comparing its out-of-the-box IFStruct performance against a fine-tuned version.

How to use it

The full pipeline is published as a runnable notebook alongside the blog post. Fine-tuning is done with Hugging Face's TRL library and runs on a GPU sized for a free-tier 16GB card; evaluation can run locally through llama.cpp, which exposes an OpenAI-compatible server that the open-source IFStruct evaluator (from Liquid4All) talks to. The post gives exact installation and serving commands for llama.cpp, the GRPO training configuration, and the steps to merge the LoRA adapter and convert the result to a BF16 GGUF file for serving. No pricing or licensing terms are mentioned; the tools involved (TRL, llama.cpp, IFStruct) are open source.

How solid is it

The source is a full, code-complete walkthrough with reproducible commands and full benchmark output tables for both the base and fine-tuned model. The authors' local reproduction of the base model's published score is close but not identical: 22.6% measured locally versus 21.1% reported in the original IFStruct blog, and they explicitly use their own local figure as the baseline rather than the published one, since it comes from a different serving stack. They also flag that their training pipeline is not the one used for the official IFStruct RL model, so the comparison is a same-stack, same-benchmark check rather than a reproduction of that model's headline number. Results rest on a single evaluation run of 2000 samples per model.

Risks and caveats

Improvement is not uniform: several task categories, including camera review and gpu review, showed flat or slightly worse pass rates after fine-tuning, and format-level gains were concentrated in JSON and bare-list structure while YAML barely moved. Per-category sample sizes are modest (roughly 70 to 110 examples each), so individual category swings carry more noise than the overall 2000-sample figure. Even after tuning, the single most common failure remained a missing required field, appearing 7331 times, meaning schema compliance is improved rather than solved. The article's own final comparison of the two runs is cut off in the captured text, so whatever conclusion the authors drew there is not reflected in this retelling.

“This notebook doesn't aim to recreate the IFStruct benchmark score, but to show how task-specific fine-tuning of smaller models can improve performance and match that of far larger models.”

— the blog post