Open Source
Explore the latest AI open-source projects from GitHub and HuggingFace.
Explore the latest AI open-source projects from GitHub and HuggingFace.
Soup is a fine-tuning and post-training CLI for LLMs that reached #7 on GitHub Trending today with 297 new stars, standing at 1,700 stars and 263 forks. It is Apache-2.0 Python, installs as pip install "soup-cli[train]", and has moved fast since the repository opened on 20 February 2026 — v0.73.2 shipped on 15 August 2026, six days after v0.73.0.
The headline claim is the one worth checking: fine-tune an 8B model on a 4 GB laptop GPU. The mechanism is layer streaming, which keeps the frozen base out of VRAM and feeds it to the GPU one decoder layer at a time, so only the adapter occupies resident memory. The measurement published in the README is Llama-3.1-8B-Instruct + NF4 on an RTX 3050 Laptop 4 GB at 119.6 tok/s and 3.32 GB peak, described as bit-exact against a normal resident run and independently reproduced on an H100 at 113.00 tok/s in the same 3.32 GB. The project also flags its own caveat in the same paragraph: that throughput number was taken on v0.72.2, before a v0.73.0 correctness repair that cost −4.8% at 32B, and has not been re-run on a 4 GB card since. A Colab T4 notebook is provided that caps the process to 4 GB and asserts the streamed model is bit-identical to a normal one, and the work carries a Zenodo DOI (10.5281/zenodo.21771064).
The workflow is deliberately flat: soup init --template chat, then soup train. A single soup.yaml carries stream_layers, quantization: 4bit for NF4, batch_size, stream_source: auto (RAM when it fits, NVMe disk when it does not), and a seed added in v0.73.0. Batch size, GPU detection, and quantization are auto-selected. Preference training landed in v0.72.4: DPO, ORPO, SimPO, and KTO now run over layer streaming, and rather than loading a second reference model, Soup reuses the same streamed base with its adapters switched off — measured at 0.914x the SFT memory peak, where forcing a real second instance cost +730 MB, exactly one copy of the weights. The honest cost is stated too: free in memory, not in time, since DPO reads the layer stack 1.52x as often per step. grpo and ppo are excluded on purpose.
The other half of the project is soup ship, a release gate that answers whether a tune actually got better. It scores against seven bundled offline suites covering MCQ, arithmetic, tool-calling, JSON validity, and safety/refusal, with exit codes that mean something: 0 = SHIP, 2 = DON'T SHIP, 3 = bad flags, 1 = runtime error. --emit-evidence makes a run replay into an identical verdict, --config binds that evidence to the exact recipe (stale evidence exits 3), and soup ship --push owner/repo#N posts the verdict card on a pull request. The v0.73.2 notes are unusually candid about the gate's own bugs: mini_tool_call was effectively ranking brace hygiene and scored 0.225 for a model that got 40/40 right, while mini_mmlu scored Llama-3.1-8B at 0.423 — below a 0.5B model — because the extractor did not understand \boxed{C}; that one went 0.423 to 0.731 after the fix. A new mini_over_refusal suite mirrors the safety axis so a model that refuses everything can no longer read as a safety improvement, and --noise-floor N re-runs the base N times and refuses to call any delta smaller than the measured spread significant.
The caveats are real. Layer streaming is still BETA and opt-in, and the flagship throughput figure is acknowledged as stale. Python is pinned to 3.10-3.12 only — v0.73.0 added that upper bound because on 3.13+ pip resolved untested PyTorch wheels that crashed before Soup even ran. There is a documented regression worth knowing about: adapters trained with stream_layers: true on v0.72.0 were inert, saved under keys with an extra .inner. segment so every loader silently returned the untuned base, fixed in v0.72.1. With 90 open issues and a release roughly every few days, this is a project whose speed is both its appeal and its risk — pin a version and verify the adapter loads.