AI model torrents: legal, verified, and how to download

Yes, in the cases that matter here: when a model's license permits redistribution, torrenting it is the same legal act as downloading it from the original host, and the BitTorrent protocol changes nothing about that. Open-weight models are published by the labs that trained them. Nothing is cracked and nothing is leaked.

The risk is not the protocol either. It is the packaging: unverified repacks, dead links, and no hash to check what you actually got. Below: what the licenses allow, what a torrent's built-in hashes prove and what they do not, and how to download bytes you can check end to end. The verified catalog is on /models.

What "AI torrents" actually are

A torrent of an LLM or any other open-weight model moves the same files you would download from a model hub: the weight tensors in their .safetensors files, plus the configs, tokenizer files, and README the publisher shipped. A torrent is only the transport. BitTorrent is an open transfer protocol with a public standards process, and it moves Linux distributions, game updates, research datasets, and model weights by the same mechanism.

It is not the thing in the headlines about Meta and training data. Those stories concern books and other copyrighted text fed into training, not model weights, and they say nothing about how finished weights travel. Weights under an open license are published on purpose: the lab put the bytes on the internet and stated what you may do with them. Since Hugging Face is where most open weights live, a "hugging face torrent" is usually a re-pack of a Hugging Face repository, and the question that matters is who did the packing.

The demand is older than the current tracker sites, too. In December 2023 a user posted a torrent of Mixtral 8x7B on the model's own Hugging Face discussion page, to work around slow downloads of large files, complete with infohash and trackers. Two months before that, a feature request on the transformers repository made the durability argument in one line: "Models could be censored and removed from HF. In order to keep them alive, Torrent could be a solution." The request was closed with no maintainer response. People wanted model torrents years before any verified archive existed.

Is it legal? The license decides

What decides it is the model's license. Four families cover most of what you will meet.

Redistribution is also the exact act a torrent performs: a seeder hands the bytes to the next peer, over and over. When the license grants that right, seeding is licensed use. When it attaches conditions, they apply to you as the distributor, which is why the attribution and naming rules below matter to anyone who keeps a client running for weeks.

Permissive licenses are the simple cases. Mistral 7B ships under Apache 2.0; the launch post says, verbatim, "We're releasing Mistral 7B under the Apache 2.0 license, it can be used without restrictions" (as of 2026-09-01). DeepSeek R1 ships MIT and its model card states that commercial use, modifications, and derivative works are allowed. Redistribution by anyone, by any channel, is the point of these licenses. Qwen_Qwen3-8B, allenai_Olmo-3-7B-Instruct, and the image model black-forest-labs_FLUX.2-klein-4B in this archive's catalog all carry Apache 2.0.

Google's Gemma terms allow redistribution with conditions: include the use restrictions in downstream agreements, give recipients a copy of the terms, mark modified files as modified, and ship a notice file naming the Gemma Terms of Use (as of 2026-09-01).

The Llama Community License also permits redistribution and commercial use, with strings attached: companies above 700 million monthly active users need permission from Meta, derivative model names must begin with "Llama", and deployments must carry "Built with Llama" attribution (as of 2026-09-01). NousResearch_Hermes-3-Llama-3.1-8B is the catalog's example of a Llama-licensed model.

Everything else is per model. The Hugging Face Hub prints each repository's license on its page and asks users to seek out and respect it. Check before you seed: non-commercial licenses such as CC BY-NC also appear, and they restrict use, not just copying.

The gated-model catch

Some models sit behind a gate: you log in, share contact details, and accept terms before you can download. Hugging Face's documentation on gated models is direct about the mechanics: access is granted after you agree, approval can be automatic or manual, and the authors can revoke access at any time.

A torrent does not transfer rights you never accepted. If a model's terms require acceptance, that obligation travels with the bytes; fetching them from a swarm instead of the gate does not dissolve it. In practice, torrents of gated models are where the worst junk collects: no license visible, no revision to pin, just a magnet posted in a thread.

Every model page in this archive records the license observed at fetch time, pinned to the exact upstream revision, so the license you read is the license the bytes were checked under.

Is it safe? What a torrent's hashes do and do not prove

That scope is the whole safety question. If the uploader tampered first, the swarm faithfully delivers the tampered files and your client reports success. The check is honest and narrow.

The danger is not unique to swarms, either. JFrog's security researchers found about 100 malicious models on Hugging Face itself, some with pickle payloads that execute code when the file loads; the platform marks flagged models "unsafe" without blocking their download. In early 2025, ReversingLabs documented nullifAI, a technique that shipped deliberately broken pickle files to slip past the Picklescan scanner; Hugging Face removed the reported models within about a day. Central hosting does not make bytes safe. Provenance does.

So the risk model has two questions. Which bytes are these: the lab's published revision, or somebody's repack? And who vouches: nobody, or a signature you can check offline? This archive answers with a minisign-signed manifest listing every file's digest, sha256 for LFS files and sha1+size for git blobs, each labeled with its method, and with every payload checked against upstream at fetch time and pinned to one revision. How to run that check yourself is on /verify, and the full command walkthrough lives in the verification guide.

Random torrent vs a signed archive

Put the two side by side and the differences are structural, not cosmetic.

None of these differences come from the torrent being a torrent. They come from the archive being able to answer questions a random uploader cannot.

Pick a BitTorrent client for multi-GB payloads

Any client that speaks the protocol can fetch and seed these torrents, so the quick answer is: the one you already have. Model payloads change what matters, though. They are multi-gigabyte and meant to be seeded for weeks after arrival, so steady memory use, segmented transfer, and unattended seeding weigh more than interface polish. The three this archive is tested with:

All three are open source under GPL-family licenses. The quick-start version of this advice is on /help.

Download a model torrent, step by step

1. Pick the model. Browse /models and open a model page. Read the license line before anything else: Qwen_Qwen3-8B carries Apache 2.0; NousResearch_Hermes-3-Llama-3.1-8B carries the Llama 3.1 community license. The page also shows the exact upstream revision the payload was pinned to.
2. Get the torrent. Download the .torrent file, or copy the magnet link to open the swarm directly. Both resolve to the same verified payload; no account, no token, no throttle. What a magnet actually encodes is explained in the magnet guide.
3. Let the client finish. A model torrent is a multi-gigabyte transfer; leave the client alone until it reports done. If the first fetch stalls, aria2c with its segmented transfer is the dependable second choice.
4. Verify against the signed manifest. Fetch torrents.json with its minisign signature and the public key, check the signature, then compare the per-file digests: sha256 for LFS files and sha1+size for git blobs, labeled by method. The exact commands are on /verify, and the verification guide walks each one.

When the check passes, keep the client running: finished torrents seed automatically. The ask is a share ratio of 2.0 or better. /contribute covers the rest of what seeding gives back.

Why swarms need seeders (and one honest weakness)

A torrent with no seeders is a dead link that still lists its files. That is how models get lost: the host page changes or disappears, the swarm thins out, and the bytes survive nowhere. The permanence argument for torrents lives here, and it only works if people who downloaded the model keep serving it.

Seeding in reader terms: after your download finishes, your client uploads the same bytes to the next person. A share ratio of 2.0 means you sent twice what you took. Disk space and bandwidth are the entire cost.

The honest weakness: two torrents of the same bytes do not help each other. Pack identical files into a different torrent file and you get a different infohash, a separate swarm, and no cross-seeding; peers in one cannot serve peers in the other. That is why one canonical, revision-pinned torrent per model beats a pile of repacks of the same model, and why the repack habit (same weights, new torrent, no manifest) splits seeders instead of adding them. The magnet guide explains the infohash mechanics behind that.

Missing a model you want to seed? /requests is where to ask for it.

The rule this page reduces to: know who packed the bytes, know what license they carry, and be able to check both offline. A torrent that supports all three is a sound download method. One that supports none is a coin flip with your disk attached.