ML Frameworks

Transformers166.3k★

Hugging Face Transformers gives you access to 400,000+ pre-trained models with a consistent Python API for text generation, translation, summarization, image classification, and more. Load a model in three lines of code, run inference, done. Apache 2.0. This is the standard library for working with transformer models. PyTorch, TensorFlow, and JAX backends. The `pipeline` API lets you go from zero to a working model in literally one line: `pipeline('sentiment-analysis')('I love this')`. For fine-tuning, the Trainer API handles the training loop, checkpointing, and evaluation. The library is free. Hugging Face Hub (the model hosting platform) has a free tier with unlimited public models and 25GB private storage. Pro ($9/mo) adds more private storage. Enterprise plans exist for organizations needing governance and deployment at scale. The catch: running large models requires serious GPU hardware. A 7B parameter model needs ~14GB VRAM just for inference. The library is free but the compute is not. Hugging Face Inference Endpoints (managed deployment) starts at $0.06/hr for CPU, $0.60/hr for GPU. Also, the library is enormous; it pulls in PyTorch (~2GB) and the ecosystem of dependencies is heavy. For production inference specifically, look at vLLM or llama.cpp for better performance.

pytorch103.1k★

PyTorch is the framework most modern AI is built on. If a model made headlines in the last few years, there's a good chance it was trained in PyTorch. It's a Python library for building and training neural networks, with the heavy math running on your GPU instead of your CPU. Free, BSD-licensed, backed by the Linux Foundation. What made it win over TensorFlow was feeling like normal Python. You write code that runs line by line, you can drop a debugger in the middle, and it behaves the way you'd expect. The ecosystem is enormous: pretrained models, training libraries, deployment tools, and tutorials for nearly everything. Running it yourself is mostly about hardware. The install is trivial. Matching CUDA versions to your GPU drivers is the part that eats an afternoon. Solo learners can run it on a laptop or a free cloud notebook. Teams doing real training rent GPUs, and that bill, not the software, is the cost. PyTorch itself never charges you. The catch: PyTorch gives you the engine, not the car. It won't manage your experiments, your data pipelines, or your deployment. For those you'll reach for other tools like Lightning, Hugging Face, or MLflow. And if you want maximum inference speed on non-NVIDIA hardware, expect rough edges. NVIDIA is still where PyTorch runs best.

unsloth76.3k★

Unsloth trains open models roughly twice as fast on about 70% less VRAM, which is the difference between renting a datacenter GPU and fine-tuning on the card already in your desktop. Fine-tuning means taking an existing open model and teaching it your specific task or data. Unsloth is now two things: Unsloth Core, the Python library and CLI, and Unsloth Studio, a local web UI you launch with a single command for downloading, running, and comparing models. It runs on NVIDIA RTX 30/40/50 and Blackwell, on AMD across Windows, WSL, and Linux, and on macOS for both training and inference. CPU handles chat and data prep. Multi-GPU is supported. The reinforcement learning path claims 80% less VRAM for GRPO, and long-context training reaches 500K tokens. Studio also handles inference: GGUF, LoRA adapters, safetensors, tool calling, and API endpoints. Free, with no paid tier and no commercial restriction on Core. Solo: this is the default way to fine-tune on consumer hardware. Teams: same answer, and multi-GPU scales it up. The catch is the license split. Core is Apache 2.0 and carries no obligations. Studio's UI components are AGPL-3.0, and AGPL follows you if you embed that UI into a product you ship or host for others. For personal training runs it is irrelevant. For a company building a product on top of it, know which half you are standing on before you get far.

modular29.8k★

Most ML tooling assumes you are writing Python and calling into CUDA kernels somebody else wrote. Modular is an attempt to replace that whole layer: Mojo, a compiled language with Python-like syntax, and MAX, an inference engine that serves models behind an OpenAI compatible endpoint across NVIDIA, AMD, and Apple hardware. The repository is Apache 2.0 with LLVM Exceptions, covering the Mojo compiler, the standard library, the accelerator kernel library, the inference server, and the model pipelines. MAX itself ships under the separate Modular Community License. Running it is a container and a model, closer to vLLM than to building a toolchain from source. The license story got better and it is worth knowing. The old terms capped free production use at eight accelerators outside x86, ARM, and NVIDIA. That cap is gone. Commercial use is now royalty free with no GPU count and no revenue threshold. The one restriction left: deploying MAX as a hosted inference service for other companies requires Modular's written approval and their branding on it. The catch is that Mojo is a bet. Adopting it means writing performance code in a language with one implementation, one vendor, and a smaller ecosystem than Python has had for thirty years. MAX you can adopt on its own and walk away from. Mojo is harder to reverse.

MLX28.4k★

MLX is Apple's machine learning framework, built first for Apple Silicon. It exploits unified memory (on M series chips the CPU and GPU share the same RAM) so tensors never get copied across a bus the way they do between a host and an NVIDIA card. The API deliberately mirrors NumPy and PyTorch, so if you know either you already know most of this. The story changed this year. MLX now ships a CUDA backend and a CPU only build for Linux, installed with pip install mlx[cuda] or mlx[cpu]. Training on a Mac and deploying to a Linux box with NVIDIA hardware is no longer a rewrite. Apple Silicon is still where it runs fastest and gets the most testing, and the CUDA path is newer, so verify the specific operations you depend on before you bet a production pipeline on it. MIT licensed, maintained by Apple's machine learning research group, and moving fast. Solo developers on a Mac: this is the best way to run and fine tune models on hardware you already own. Small teams doing local experimentation: use it, and keep PyTorch for anything shipping to a mixed fleet. Large teams with existing CUDA infrastructure: treat MLX as an excellent front end for Mac dev machines rather than a replacement for your training stack. The catch: the ecosystem is still a fraction of PyTorch's. Most papers, most tutorials, and most pretrained weights assume torch, so you will spend time porting or waiting for someone else to port. ml-explore/mlx-lm covers the common language model cases and the coverage thins out quickly past that.

Paddle24.1k★

PaddlePaddle is Baidu's deep learning framework, in the same category as PyTorch and TensorFlow. It is a full platform for building, training, and deploying models, with unified dynamic and static graphs, automatic parallelism for large-model training, and deployment tooling across a wide range of hardware. Open sourced since 2016, Apache-2.0, free. Installing it is the standard framework routine: pip install the build that matches your hardware and CUDA version, then write Python. It is written mostly in C++ and Python, and it carries a large ecosystem of model libraries and end-to-end development kits on top of the core. The current line is version 3.x, actively released. For a developer or team already committed to a framework, Paddle is worth knowing but rarely worth switching to unless you have a specific reason. Its center of gravity is China: the biggest community, the deepest tooling, and the best documentation are there, and much of it is Chinese-first. Solo researchers and teams alike will find PyTorch has the larger global ecosystem and more tutorials in English. The catch is exactly that ecosystem gravity. Paddle is a serious, industrial-grade framework with real strengths in large-model parallelism and hardware breadth, but outside its home ecosystem you will hit more friction: fewer English answers, smaller third-party support, harder hiring for it. Pick it when you have a concrete pull toward Paddle-specific tooling or hardware, not as a default.

kornia11.4k★

Kornia does image processing that a neural network can train through. Blur, rotate, color convert, detect edges: every operation is written in PyTorch tensors, so gradients flow backward through it the way they flow through your model. Augmentation and geometry become part of the network instead of a CPU preprocessing step bolted on the front. Apache 2.0, over 500 operations, `pip install kornia`, nothing gated. Past the basics it ships the classical computer vision that most deep learning stacks skip: camera calibration, stereo and epipolar geometry, homography estimation, pose solvers, optical flow. It also wraps pretrained models, LoFTR and LightGlue for feature matching, SAM for segmentation, YuNet for face detection. For spatial work this is the layer between OpenCV and raw PyTorch. Free at every team size, because it is a library with no service attached. The project runs as a non-profit funded through Open Collective, so support means GitHub issues and Discord, never a contract. The catch: half precision is uneven, and Kornia publishes the numbers itself. Its float16 and bfloat16 test runs pass around 91 percent against 100 percent on float32, and the calibration module accepts float32 and float64 only. Mixed-precision training loops should test the specific ops they lean on.

torchtitan5.7k★

TorchTitan is the PyTorch team's framework for training large language models at scale. It combines PyTorch's distributed training primitives into a working system: data parallelism, tensor parallelism, pipeline parallelism, and activation checkpointing. Fully free, BSD-licensed, no cloud requirement. This is not a weekend project. You need multi-GPU clusters (H100 or equivalent) and familiarity with SLURM or cloud HPC to orchestrate across nodes. The project supports multiple architectures including Llama 3 and 4, DeepSeek V3, Qwen3, and Flux for image generation. It ships with configuration examples but expects you to already understand distributed training before you start. ML researchers and infrastructure teams training large-scale models from scratch have the cleanest PyTorch-native starting point available. Solo developers building on top of existing models have no use for this. It is infrastructure for teams running their own training clusters who want to stay in the PyTorch ecosystem. The catch: TorchTitan is a reference implementation, not a hardened production system. The APIs are bleeding-edge and change frequently.

xla4.5k★

XLA is the machine learning compiler that takes models from JAX, PyTorch, or TensorFlow and optimizes them for GPUs, CPUs, TPUs, and other accelerators. If you use any of those frameworks you're already running XLA, you just don't see it. The OpenXLA repo is where the compiler itself lives, and it's open source under Apache 2.0. Self-hosting in the normal sense doesn't apply. XLA is infrastructure that ML frameworks call into. End developers interact with it through `jax.jit`, `torch.compile` (with the OpenXLA backend), or TensorFlow's XLA flags. Building from source is a serious commitment that involves Bazel, platform-specific dependencies, and several days of patience. Most teams should consume the pre-built versions their framework ships. Use this directly if you're doing ML infrastructure work: writing a new framework, adding hardware support, or debugging compilation issues. Solo developers and small teams: you don't interact with XLA directly, you benefit from it. Large teams doing custom silicon or model serving optimization: this is the layer you're working in. The catch: governance still effectively sits with Google despite the OpenXLA branding. The Code of Conduct points back to TensorFlow governance, and Google contributes the majority of the changes. Apache 2.0 protects against the worst outcomes, but "open governance" reads aspirationally here.

miles2.9k★

Miles is a reinforcement-learning framework for post-training large language and vision models, the tuning step that happens after a base model is trained. It pairs SGLang for fast rollout with Megatron-LM for scalable training, and it is built for the trillion-parameter end of the spectrum, with day-0 support for models like DeepSeek-V4 and Kimi K3. Apache-2.0, and it co-evolves with the slime project it forked from. This is heavy infrastructure. Fully async RL, MXFP8 and NVFP4 low-precision training, P2P RDMA weight transfer that pushes new weights to inference engines in seconds, LoRA and multi-LoRA. None of that is plug-and-play. You need a real GPU cluster, deep familiarity with Megatron and distributed training, and the patience to run something at frontier scale. A PyTorch FSDP2 backend exists for smaller HuggingFace-style runs, but the recipes and the big models live on Megatron. If you are an ML team actually doing RL post-training on large models, Miles is aimed squarely at you and moves fast on new architectures. Everyone else, this is not the tool, and it is not pretending to be. The catch: "enterprise-grade" here means enterprise-scale hardware and expertise. On a couple of GPUs you will barely touch what it is for.

torchrec2.6k★

TorchRec is Meta's PyTorch library for training recommendation systems at scale. It is the engine behind the kind of "you might also like" model that runs on a feed of billions of items, packaged as a library you can use too. Free, BSD-3 licensed, used in production at Meta, Twitter, and Databricks. Running this means GPU clusters, sharded embedding tables, and pipelined training. It gives you the parallelism primitives (model sharding, communication kernels, a planner that figures out the layout) but you bring the recommender model and the data pipeline. Single-GPU experiments work fine, the value shows up when your embedding table no longer fits in memory. Solo: skip unless you are researching recsys at scale. Small teams: probably overkill, simpler libraries cover most product needs. Large teams shipping recommendations against tens of millions of items: this is what Meta built for itself, which is the strongest signal you will find. The catch is that this is infrastructure, not a recommender. You still need to know what model you are training, how you are sharding it, and how to feed it. TorchRec makes the hard parts possible, not easy.

coreai-models2.1k★

Apple's coreai-models is the toolkit for getting AI models running on Apple hardware, on the device, not in the cloud. It gives you export recipes that convert popular open-source models into Apple's Core AI format, Python tools for authoring custom models in PyTorch, and a Swift package with the runtime pieces to actually run them on macOS and iOS. This is how you ship an app that does inference locally instead of calling out to an API. There's nothing to host, it's a library and a set of recipes you build into your own app. The work is real but well-scoped: you convert a model, wire up the Swift runtime, and test it on-device. For developers already in Apple's ecosystem, this is the sanctioned path rather than fighting the conversion tooling yourself. App developers who want on-device AI, for privacy, offline capability, or to skip per-call API costs, are exactly who this is for. If you're not shipping to Apple platforms, it's irrelevant, look at GGUF and llama.cpp or ONNX instead. The payoff here is models that run on the Neural Engine with no network round trip and no data leaving the phone. The catch: this is Apple-only by design, so it ties you to their platforms and their format. On-device inference also means you're bounded by what the hardware can run, you're not loading a giant frontier model onto a phone. It's BSD-licensed and free, but it's a developer toolkit, there's nothing here unless you're building something.

FlagGems1.1k★

FlagGems is a drop-in speed layer for PyTorch. It is a collection of hand-tuned math operators, the low-level kernels that do the heavy lifting inside a neural net, written in Triton instead of raw CUDA. Register it with PyTorch's ATen backend and your existing model code runs on top of these kernels with no API changes. All Apache-2.0, all free. The pitch beyond raw speed is portability. Most kernel libraries are locked to NVIDIA. FlagGems is backend-neutral and claims over ten hardware backends, so the same operators can target non-NVIDIA accelerators. That matters if you are trying to get off the NVIDIA-only path or run on domestic silicon. It is eager-mode ready, so you do not need torch.compile to get the benefit. The cost is setup: you need Triton and a compatible toolchain, and both coverage and performance vary by operator and by backend. Who should use it: if you train or serve LLMs and want a portability hedge or a free speed bump on non-CUDA hardware, it is worth testing. Solo on a single NVIDIA card, the existing kernels are probably fine and the upside is small. Teams running multi-vendor hardware, or planning around GPU supply, are the real audience. The catch: FlagGems comes from FlagOS, backed by BAAI, a Beijing AI research institute. Operator coverage is broad but the hand-optimization is selective, so your actual speedup depends entirely on which operators your model leans on. Benchmark your own workload before you bet a training run on it.

UniRL965★

UniRL is a training framework for teaching AI models new behavior through reinforcement learning, across every major model type at once. Most RL training code is built for one kind of model. UniRL, from Tencent's Hunyuan team, runs a single RL loop over image and video diffusion models, large language models, vision-language models, and unified multimodal models. It ships real algorithms (Flow-DPPO, DRPO, CPPO) each backed by a paper, alongside standard baselines like GRPO. There is nothing hosted here, and the ops burden is heavy. This is distributed training infrastructure: Ray for orchestration, FSDP for sharding models across GPUs, Hydra for configuration. You need a real GPU cluster and the experience to drive it. Getting a run going is a project, not an afternoon. ML engineers and researchers doing RL post-training on multimodal models are the only audience, and for them the value is having one framework instead of stitching together separate pipelines per model family. If you're not training models at this level, this is not for you. There is no lighter on-ramp; the complexity is inherent to the work. The catch: it's research-grade infrastructure, Apache-licensed and free, but free in the way a jet engine is free if someone hands you one. The cost is the cluster, the GPU hours, and the expertise. Expect rough edges, sparse docs, and the assumption that you already know how RL training works.