finds.dev← search

// the find

ludwig-ai/ludwig

★ 11,716 · Python · Apache-2.0 · updated Jun 2026

Low-code framework for building custom LLMs, neural networks, and other AI models

Ludwig is a declarative deep learning framework where a YAML config replaces the training loop, data pipeline, and evaluation code. It covers a wide range: LLM fine-tuning (SFT, DPO, GRPO, LoRA/QLoRA), multimodal tabular models, timeseries forecasting, and image segmentation, all from the same config-driven interface. It's aimed at ML practitioners who want to iterate on architectures and hyperparameters without rewriting boilerplate, and at teams who want reproducible, config-versioned experiments.

The YAML schema is genuinely expressive — swapping from local training to a Ray cluster is one config line, and the LLM adapter coverage (PiSSA, EVA, CorDA, OFT, multi-adapter merging with TIES/DARE/SVD) tracks current research closely rather than just wrapping LoRA and calling it done. The multi-task loss balancing options (Nash-MTL, Pareto-MTL, FAMO, GradNorm) are non-trivial features you'd normally implement yourself, and they're config-toggleable. Experiment reproducibility is a first-class concern — full configs are saved per run, and the visualization tooling handles learning curves, calibration plots, and hyperopt analysis without needing a separate tracking server. The 0.16 changelog is substantive, which means the project is genuinely maintained rather than in slow decay.

The abstraction leaks badly when something fails — you end up debugging through the YAML schema, the type registry, the combiner logic, and then PyTorch stack traces that point deep into Ludwig internals with no context about what your config did wrong. The dependency graph is a real problem: `ludwig[full]` drags in Ray, bitsandbytes, vLLM, and a crowd of CUDA-version-sensitive packages; getting a clean install on a specific GPU setup often requires manual version pinning that isn't documented. Custom architectures are harder than the docs imply — the plugin/registry system for adding custom encoders or combiners is thinly documented, so 'expert control when you need it' stops being true the moment you need something not in the schema. The presence of `.plan`, `.plan-lazy-preprocessing.md`, and `IMPROVEMENT_PLAN.md` sitting in the repo root alongside `pytest_slow.yml` (a separate slow test suite) suggests accumulated architectural debt and test coverage gaps in less-traveled paths.

View on GitHub → Homepage ↗

// want more like this?

We dig through GitHub every week and send a few repos picked for what you actually care about — each with an honest take like this one.

Get finds in your inbox → Search again →