I’ve been tinkering with machine learning since around 2018.

My original motivation was an autonomous trading system I was building in Go. At the time I used TensorFlow for the models and wrote a gRPC service so the Go trading system could talk to them.

I didn’t particularly like that boundary.

I wanted the model to be part of the application rather than a separate Python service. I also wanted to understand what was happening below the framework APIs.

So in 2019 I started Therfoo:

https://github.com/therfoo/therfoo

It was a small embedded deep-learning library written in Go. Feed-forward networks, backpropagation, training loops, no Python or C dependencies. It was mostly a learning project.

The autonomous trading system, for what it’s worth, has never succeeded. I still keep versions of it around as a pet project. After all these years it has made me approximately $0.

But the ML work kept being interesting.

Around July 2025 I started over and rebuilt the idea as Zerfoo:

https://github.com/zerfoo/zerfoo

Zerfoo has grown quite a bit beyond Therfoo. It is now an Apache-2.0 ML framework in Go for inference, training and serving.

It can load GGUF models, run LLM inference, train models, serve an OpenAI-compatible API, use GPUs, do tabular ML and time-series work, and expose model creation through CLI/MCP.

I recently built a conversational model-creation experience here:

https://zer.foo/

The idea is that you start by describing the problem you want a model to solve instead of starting by choosing an architecture.

The hosted part helps turn that conversation into a portable model project. The actual data and training stay on hardware you control.

The verified creation path is deliberately narrow right now, mainly numeric classification. If Zerfoo cannot actually execute what you ask for, I would rather have it tell you that than pretend a generated architecture is supported.

There are plenty of rough edges.

There are also parts of the framework that are implemented but not sufficiently verified for me to claim they are production ready. I’ve tried to make that distinction fairly explicit in the repo.

One fun result from the inference side: on my DGX Spark, Zerfoo ran Gemma 3 1B at 235 tok/s in one recorded benchmark versus 188 tok/s with Ollama 0.17.7. At 3B they were basically at parity. The README contains the methodology and the reasons you should not generalize too much from that result.

The name also has a personal origin.

I’m Kenyan. “Zerfoo” comes from how “thafu” sounds to me, from “mathafu”, the word for mathematics in my tribe/language context. Mathafu itself comes from the Swahili “hesabu”. Mathematics felt like an appropriate root for a machine-learning project.

I’m not sure yet what Zerfoo becomes commercially.

I mostly built it because I wanted it to exist, because I like understanding systems from the bottom up, and because writing this kind of thing in Go is fun.

I’d especially appreciate feedback from people who work on:

* ML runtimes * inference engines * Go internals * model training * local AI * small models * weird hardware * model formats

If you find something wrong, incomplete, slow, or conceptually misguided, I’d genuinely like to hear it.

And, separately, I’m currently available for consulting or engineering work.

I tend to do my best work when I can get dropped into a difficult system, understand how the pieces fit together, come up with ideas, and work intensely in short creative engineering sprints.

My consulting site is:

https://ndungu.dev/

Zerfoo:

https://zer.foo/

Source:

https://github.com/zerfoo/zerfoo