How Unsloth Started: Kernels First, Community Second, YC Later

Unsloth is easy to misunderstand if you encounter it today.

Today it looks like a mature open-source AI company: a large GitHub project, a catalog of model releases, fine-tuning and reinforcement-learning tooling, local inference, and a growing desktop product. Y Combinator lists it as a Summer 2024 company.

That makes the beginning more interesting.

Unsloth did not start by trying to build an all-purpose AI platform. It started with a much narrower proposition: make LLM fine-tuning materially faster and cheaper, prove the improvement with code and notebooks, and put the result directly in front of the people already struggling with GPU memory and training time.

For a small technical project trying to become useful rather than merely visible, that sequence is worth studying.

Before Unsloth, there was already a technical obsession

The company was founded by brothers Daniel Han and Michael Han in 2023. Daniel’s background matters because Unsloth was not his first attempt at performance engineering.

Y Combinator’s founder profile says Daniel previously worked at NVIDIA on algorithm acceleration, including work that made t-SNE dramatically faster. Before Unsloth, he also maintained the open-source project Hyperlearn, which focused on faster machine-learning algorithms.

That history helps explain the shape of the product. The founding insight was not, “LLMs are hot; what application should we build?”

It was closer to:

There is an expensive computational path here. Can we remove work without changing the mathematical result?

That is a very different startup starting point.

December 2023: launch with a measurable claim

Unsloth’s own retrospective dates its launch to December 2023. The initial engineering work included a custom autograd engine, manually derived backward passes, Triton kernels, optimized RoPE forward and backward operations, and a custom cross-entropy kernel.

The launch message was correspondingly concrete.

On December 1, Daniel posted Unsloth to r/LocalLLaMA with claims around faster fine-tuning, roughly half the memory use in the highlighted setup, and no loss of accuracy. The post linked the GitHub repository and, critically, runnable Colab notebooks.

The following day a Show HN submission used similarly measurable language: faster Llama fine-tuning, lower memory use, and no accuracy loss. It reached the Hacker News front page and generated a long technical discussion.

The discussion is more revealing than the headline.

Experienced readers challenged the performance numbers. One commenter questioned how such large gains were possible when matrix multiplication still dominated the workload. Daniel responded with a rough decomposition: Flash Attention, Triton implementations of RoPE and RMSNorm, cross entropy, manually derived autograd paths, cache behavior, and reduced data duplication each removed pieces of overhead.

In other words, the launch did not depend on asking the audience to trust a brand. The audience interrogated the implementation.

That is exactly what a systems project should want.

The product was a result, not a story

There is a useful distinction here.

A weak developer-tool launch often starts with a category statement:

“We are building the next-generation platform for efficient AI.”

Unsloth could instead demonstrate a before-and-after result on a problem its users already had.

The initial value proposition was understandable without knowing the founders:

same fine-tuning job
less time
less VRAM
no intended accuracy tradeoff

The implementation was sophisticated, but the value proposition was not.

That combination is unusually powerful. Kernel engineering created the moat; a simple performance claim created distribution.

Free Colab notebooks were part of the distribution system

The notebooks were not a side piece of documentation.

They collapsed the distance between reading a performance claim and testing the software. A user without a carefully prepared local environment could open a notebook, run a supported model, and see whether the workflow was useful.

By January 2024, Hugging Face published a guest article with Daniel describing Unsloth as a lightweight library compatible with the Hugging Face ecosystem, including Transformers, PEFT and TRL. The article included reproducible notebooks and benchmark methodology.

This was an important strategic choice: Unsloth did not ask users to abandon the dominant ecosystem.

It made the existing ecosystem faster.

For an infrastructure startup, compatibility can be a distribution feature. Every familiar API you preserve removes one reason not to try the new implementation.

They went where the users already were

Early Unsloth distribution was remarkably direct.

The founders posted releases and technical results to r/LocalLLaMA. They answered questions in the threads. They published notebooks. They appeared on Hacker News. They integrated with Hugging Face rather than attempting to build an isolated ecosystem immediately.

This matters because the target audience was already concentrated in a few technical communities.

There was no need to manufacture an audience before solving the problem.

A February 2024 Unsloth post about Gemma is especially revealing. Daniel and Michael described themselves as a team of two brothers with zero revenue or funding and asked the community for support through Ko-fi. That was months after the December launch and before their YC Summer 2024 batch.

So the chronology is important:

performance work
    ↓
open-source launch
    ↓
community adoption and scrutiny
    ↓
model support + reproducible benchmarks
    ↓
ecosystem integration
    ↓
YC S24
    ↓
broader product surface

Not:

fundraise
    ↓
hire team
    ↓
search for product

They kept shipping into model-release cycles

The next part of the story is less glamorous but probably more important.

Within two weeks of the original launch, Unsloth was posting Mistral support, CodeLlama support, DPO work, WSL support, and a benchmark article backed by dozens of reproducible notebooks. The Mistral benchmark post exposed detailed training settings instead of publishing only a speedup number.

Later releases repeatedly followed the same pattern: a model or training method becomes important, Unsloth makes it run with less memory or better throughput, and the team publishes a notebook or implementation quickly enough to participate in the release cycle.

This compounds.

Every new model creates a new search query, a new GitHub issue, a new Reddit discussion, a new notebook, and another reason for a user to encounter the project.

The open-source repository becomes both product and acquisition channel.

The name helped more than it looks

Even the name came from the same two-person origin.

In the original Hacker News launch thread, Daniel explained that his brother came up with “Unsloth”: a sloth is slow, and the prefix un- reverses that idea.

It is memorable, visually obvious, and perfectly aligned with the performance proposition.

That sounds trivial next to custom kernels, but technical products still need to be remembered. “Unsloth” communicates the product promise faster than a generic enterprise-AI name would.

Open source was not a purely ideological decision

The early Hacker News thread also shows some tension around open source and commercialization.

Daniel described having open-sourced his earlier Hyperlearn work and then seeing other companies use the work without attribution. That experience influenced how he thought about releasing Unsloth and paid variants at launch.

The details of Unsloth’s licensing and product model have evolved since then, but the lesson is broader: an open-source startup still has to decide what is the public good, what is the distribution engine, and what eventually pays for the work.

Open source can generate trust and adoption. It does not automatically produce a business model.

YC came after technical validation

Y Combinator lists Unsloth as founded in 2023 and part of the Summer 2024 batch.

That means the most important early validation happened before YC: the December launch, community response, notebooks, Hugging Face integration, expanding model support, and months of direct interaction with users.

YC may have accelerated the company, but it did not create the initial reason for Unsloth to exist.

The reason already existed in the profiler.

What a small technical site or project can learn from Unsloth

This is the part of the story I find most useful.

It would be easy to copy the superficial features of Unsloth: start a Discord, make a cute logo, publish benchmarks, post on Reddit, or open-source a repository.

Those are consequences, not the core mechanism.

The deeper pattern is:

1. Start with an expensive, falsifiable problem

“Fine-tuning is too slow and consumes too much VRAM” can be measured.

That is much stronger than starting with a vague ambition such as “make AI better.”

2. Build an advantage that survives scrutiny

Unsloth’s differentiation was not primarily a wrapper. It went underneath the Python API into autograd behavior, Triton kernels, memory movement and intermediate allocations.

A technical project becomes much harder to substitute when its advantage comes from understanding the mechanism.

3. Make the proof runnable

A benchmark screenshot creates attention.

A notebook lets another person test the claim.

Those are not equivalent assets.

4. Use existing ecosystems instead of fighting them

Compatibility with Hugging Face, PEFT and TRL reduced adoption friction. LocalLLaMA and Hacker News supplied an existing audience. Colab supplied accessible hardware.

Unsloth assembled distribution from infrastructure that already existed.

5. Treat criticism as part of product development

The original Hacker News discussion was skeptical. That was useful. Technical objections forced the performance story to become more precise and led to more detailed benchmark disclosure.

For systems software, a hostile-but-informed reader can be more valuable than a hundred passive likes.

6. Ship with the news cycle, but contribute engineering rather than commentary

When a new model appeared, Unsloth did not merely publish “What is Gemma?”

It made Gemma fine-tuning work faster, uploaded usable artifacts, fixed issues, and supplied notebooks.

That distinction is enormous.

One approach competes with every AI news site. The other becomes part of the model’s tooling ecosystem.

The lesson for RAMGPT

There is an uncomfortable lesson here for a technical publication like RAMGPT too.

Publishing more summaries is not how a small project earns durable attention. The strongest RAMGPT work has the same structural property that made early Unsloth interesting: there is something another person can inspect, challenge, reproduce, or use.

A benchmark harness is stronger than a benchmark opinion.

A reproduction with cold-cache and warm-cache measurements is stronger than repeating an upstream throughput claim.

A minimized failure case is stronger than a generic article about a bug.

A tool that solves one painful llama.cpp workflow is stronger than ten posts explaining that llama.cpp exists.

Unsloth’s early history suggests a useful rule:

Do the technical work first. Turn the residue of that work into content and distribution.

The article, Reddit post, notebook, benchmark table and GitHub repository should ideally be different views of the same underlying work—not five independent attempts to create attention.

From two brothers to an AI infrastructure company

By 2025, Unsloth described itself as GitHub’s top trending repository during one of its major growth periods. By 2026, its scope had expanded far beyond the original QLoRA acceleration library into reinforcement learning, model distribution, local inference and Unsloth Studio. Y Combinator currently describes the company as an open-source RL and fine-tuning platform and lists a team of eight.

The current scale can obscure the origin.

The origin was small: two brothers, a performance problem, hand-derived math, Triton kernels, a GitHub repository, free notebooks, and direct conversations with technically demanding users.

That is why Unsloth is a useful case study.

The replicable lesson is not “build another Unsloth.”

It is this:

Find one thing that is painfully inefficient. Make a measurable improvement. Expose enough evidence that strangers can challenge it. Make trying it easier than debating it. Then keep shipping.

For a technical project starting with almost no distribution, that is a much more credible growth strategy than trying to look large before becoming useful.