Unsloth and axolotl vs ms-swift: the 15,610 star alternative worth checking

TL;DR — If you fine-tune with unsloth or axolotl, you are working with the Western default. In China, the default is ms-swift from ModelScope: 15,610★, Apache-2.0, last commit 2026-09-14 — the day this was verified. It bundles continual pre-training, SFT, DPO and GRPO over a model zoo that spans the Chinese open families (Qwen, DeepSeek, GLM, InternLM, MiniCPM) and the Western ones (Llama, Mistral and the rest). It is the shortest path when your base model is Chinese, and a reasonable one when it is not.

Why it matters

Fine-tuning tooling is not a neutral choice. It decides which base models you can actually post-train, how many scripts you maintain per model family, and whether quantization lives in the same pipeline as training or in a separate one you have to wire up yourself.

The Western defaults — unsloth, axolotl — are good, and this column is not arguing otherwise. They were built around the Western model ecosystem, and they are excellent inside it. The interesting question is what happens when your base model is Qwen, DeepSeek or GLM. That is no longer a niche case: a large share of traffic on hosted inference now runs Chinese open models, and the teams fine-tuning on them are not all in China.

ms-swift is what those teams reach for. It is maintained by ModelScope (Alibaba's model hub), it is Apache-2.0, and it is committed to daily. The rest of this piece is about why that combination matters, and where the tool's own marketing numbers stop being useful to you.

The "because Z"

1. One tool, a very wide model zoo — instead of one script per model.

The core convenience is that you do not hunt for a per-family adapter. ms-swift ships recipes across the Chinese open families and the Western ones in a single codebase, so moving from a Qwen base to a DeepSeek base to a GLM base does not mean moving to a different repository with a different config format and a different set of undocumented flags.

That matters more than it sounds. In practice, the cost of fine-tuning is rarely the training run. It is the glue: the tokenizer quirks, the chat template, the attention implementation, the checkpoint conversion. Every model family you add multiplies that glue. A tool that already knows the family removes a class of work that produces no model quality and consumes real engineering days.

The honest framing: ms-swift is not the only project with a wide zoo, and breadth alone is not a reason to switch. It is a reason to look, if you are currently maintaining per-family scripts.

2. Fine-tuning and quantization in the same chain, without a second toolchain.

This is the argument that is easiest to undervalue and hardest to replace. ms-swift covers training methods — continual pre-training, supervised fine-tuning, preference optimization (DPO), and GRPO-style reinforcement post-training — and it also covers quantization, so the path from a base checkpoint to a trained, quantized, deployable artifact stays inside one pipeline.

If you have ever trained with one framework and then quantized with another, you know the failure mode. The quantization tool expects a slightly different config, or a different checkpoint layout, or it silently disagrees about which layers to leave in higher precision. You end up writing a conversion step that nobody owns and that breaks on the next release. Keeping both stages in one project means the interfaces between them are the project's problem, not yours.

That is a structural advantage, not a benchmark. It does not show up in a leaderboard, and it is the kind of thing you only notice after you have been burned by the alternative.

3. Active development — the tiebreaker between two projects that look equal on paper.

On paper, several fine-tuning frameworks look comparable: similar method coverage, similar model lists, similar licence. What separates them is whether anyone is still pushing commits.

ms-swift's last commit, verified through the GitHub API on 2026-09-14, is dated 2026-09-14 — zero days old at the time of checking. The repository is not archived. That is the whole argument, and it is enough: a fine-tuning framework is only as useful as its coverage of the models released last month. When a new open checkpoint lands, the question is whether a working recipe exists that week or whether you are writing it yourself.

This is also why the star count is the least interesting number in this article. Stars measure attention. Commit recency measures whether the thing still works on current models.

The data

Everything below comes from the GitHub API, checked on 2026-09-14. No other figures are used in this article, and none are estimated.

Field	Value
Repository	modelscope/ms-swift
Stars	15,610
Licence	Apache-2.0
Last commit (pushed_at)	2026-09-14
Days since last commit	0
Archived	No
Verified on	2026-09-14

Two notes on reading this table. First, the star count and the commit date are a snapshot, not a trend — they say what the repository looked like on one day, and the commit date in particular will be stale within a week. Second, the licence is a standard open-source one: Apache-2.0, which permits commercial use, modification and redistribution, with a patent grant and the usual attribution requirements. There is no licence trap here for someone shipping a product. That is worth stating explicitly, because it is not always true in this space, and a non-standard or source-available licence would change the calculus for a commercial team entirely.

What the table does not contain is any measure of how well ms-swift supports any individual model family. That number is not published, and this article will not invent one.

The trap to avoid

Wide coverage is not equal coverage.

A model zoo that lists hundreds of architectures tells you which families the project has touched. It does not tell you which ones are first-class: which have a maintained recipe, a correct chat template, a tested training path, and someone who answers issues about them. Support can be excellent on one family and partial on another inside the same repository — and the families that get the most attention are usually the ones the maintainers' own ecosystem ships.

So the number of models advertised is close to useless as a purchasing signal. It is a map of ambition, not a map of quality. The only test that matters is the one you run: take your base model, follow its recipe, and see whether the run completes and the output is sane. Do that before you commit a team to the framework, not after.

The same caution applies to the two projects you are comparing. If ms-swift and unsloth both claim a family, that does not mean both support it equally well, and it does not mean either one supports it well. Claims of coverage are claims, and unless a third party has measured them, they should be read as the maintainers' own description of their project.

The verdict

• Chinese base model and you need post-training → ms-swift. CPT, SFT, DPO and GRPO, a wide model zoo, quantization in the same chain, Apache-2.0, and commits landing daily. This is the case where the choice is close to obvious.
• A purely Western Llama/Mistral workflow → unsloth remains excellent. Its developer experience is smoother, and if you never leave that ecosystem you are not paying a price for staying.
• Either way, verify your own family. Pick the one model you actually intend to train, run its recipe end to end, and judge the framework on that. The advertised model count will not tell you what you need to know.

Both projects are permissively licensed, so there is no licence trap on either side. The decision is about coverage of your specific model, and about whether the project is still moving.

Data verified 2026-09-14 · Source: GitHub API (modelscope/ms-swift, licence, stars, pushed_at, archived status).

References

1. ms-swift — Apache-2.0, 15610 stars, last commit 2026-09-14, primary language Python.
2. ms-swift documentation.
3. ms-swift on PyPI.

All figures were read from the GitHub API (api.github.com) on 2026-09-14. They move: re-check before you ship.