Ground-up builds
Whole systems from an empty repo: data pipelines, training infrastructure, custom models, deployment, monitoring. You describe the outcome. I build the machine that produces it and hand it back documented, so your team owns it.
Machine learning plumbing, and code made much faster.
focus: ML systems · retrieval · performancestatus: taking work
Hiring for remote ML? Start with who I am.
What I do
Four trades, one shop.
Integration into what you run
I work inside the architecture you already run. New models and systems get wired into your stack, your conventions, your CI. The codebase I leave behind is cleaner and faster than the one I found.
Performance engineering
Simulations, training environments, data pipelines, production services. Anywhere the answer is right and the runtime is wrong. Same behavior, same outputs, a fraction of the wall-clock. Speedups come in multiples.
Consulting
Architecture reviews, model audits, feasibility studies, and a second opinion before you commit a quarter of budget to the wrong approach. Short engagements, written findings, clear recommendations.
How code gets fast
Three moves, applied in order.
Drop a complexity class
Most slow software is slow because an O(n²) is hiding in the hot path. I reverse-engineer what the code actually computes, then compute the same result with a better algorithm. Fidelity stays. Runtime collapses.
Change the language
When the algorithm is right and the runtime is wrong, I port the hot loops to a compiled language behind the same interface. The rest of your codebase keeps working exactly as before. It stops waiting.
Train a surrogate
Some computations are exactly right and inherently slow. For those, I train an add-on model to approximate the expensive step, validated against the ground truth it replaces, so you know precisely what accuracy you traded for speed.
Receipts
Numbers from real work.
Several of these come from public Kaggle competition entries, where a method has to survive contact with a leaderboard. The rest come from research and production systems.
~32×
training throughput, one consumer GPU
A Kaggle competition shipped a compiled C simulation engine. I reimplemented it from scratch in JAX in 48 hours, using the original binary as a differential-testing oracle, and reached roughly 2,500 simulations per second, about 32 times the PyTorch baseline.
~25×
whole-machine throughput, from a 69-line shim
A flat profile of that competition's closed C++ engine put 58% of single-core time in std::random_device, which is the RDSEED instruction: a hardware entropy pool shared by the whole CPU package. One core gained 2.4×. The real cost was scaling: the stock engine capped near 150 games per second no matter how many processes ran. A 69-line LD_PRELOAD shim swapped the entropy source for a seeded per-thread PRNG without touching the binary, and 32 processes reached 3,770 games per second. Win distribution unchanged.
8.43M
env-steps per second
From-scratch, domain-agnostic JAX reinforcement-learning library: custom PPO and GRPO, league self-play, behavior cloning, all JIT-compiled. 790+ tests. That is the trainer; the engines it drives are benchmarked separately on the djinnax page.
30B / $300
LLM fine-tuning on a shoestring
LoRA fine-tuned a 30-billion-parameter Mamba-Transformer MoE on about $300 of cloud, fed by roughly 670K programmatically verified synthetic reasoning examples from seven purpose-built generators.
88.26%
on 2.1M rows of clinical data
Deterioration-severity classifier over ED vitals and raw ECG waveforms: a gated three-stage ensemble (Gaussian Process, Bayesian NN, BiLSTM) with 95.5% recall on the severe class, where a miss costs the most.
42K LOC
system, rebuilt for training
Forked a 42,000-line TypeScript system, built a headless training server on it, and trained PPO agents from one-versus-seven up to full self-play. The current schema is a 46,196-float observation and 812 actions. The simulation core is being ported to Rust, parity-checked against the original.
One set of numbers now lives in public, code and all: djinnax, my open-source benchmark.
Retrieval
Answers that cite their source.
An assistant over your own documents is only worth having if a reader can check it. I build retrieval systems that answer from a specific corpus and point back at the passage they answered from, so the person reading can verify instead of trusting.
Osa, for sleep technology students
A retrieval assistant that answers clinical questions out of the American Academy of Sleep Medicine guidelines and cites back to the source for every answer. A student can follow the citation to the guideline itself rather than taking the answer on faith.
Grounded, and in its lane
A system like this earns trust by refusing as clearly as it answers. Scope stays narrow, answers stay tied to the corpus, and questions the corpus cannot support get a handoff instead of a guess.
Regulated data is home turf
Epic, HL7/FHIR, and HIPAA are familiar ground: I came up inside hospital workflows and hold an RHIA credential. If your data cannot leave the building, I build where the data lives. More about me, Donald Galliano III.
Custom models
Models made to order.
When an API call is not enough
Reinforcement-learning policies (PPO, GRPO, self-play leagues), LLMs fine-tuned at 30B scale, few-shot vision systems, and the synthetic-data factories that feed them. If the model your problem needs does not exist yet, I train it from scratch.
Trained on data I make myself
Most recently a 30B Nemotron fine-tuned on roughly 670,000 chain-of-thought examples I generated and verified myself, scored against a held-out set built to rule out contamination. When the data to train on does not exist, building it is part of the job.
Shipped
Built, then handed to real people.
A visit tool for a food bank
Built pro bono: a desktop application that logs pantry visits for volunteers, with a trained model handling the automation behind it. I designed the interface, built it, and rolled it out to the people who use it. A mobile version is next.
The interface is not someone else's job
On nearly everything I ship, the UI and the user experience are a large share of the work, and I do that part myself. A model nobody can operate is not finished.
Zero to one, start to finish
Most of what I build starts from nothing. I am most comfortable owning the technical end from empty repo to rollout, so I can be certain it ships correctly.
How I ship
Hardened before it leaves the shop.
Tested at the core
Pure logic ships with real test suites: 790+ tests on my RL library, 369 on a recent consumer release, 29 on a pro bono automation tool. If a probability matters, a unit test pins it.
Adversarially audited
Before release I hunt my own exploits: money paths, duplication surfaces, race conditions, client trust boundaries. I built a 20-agent LLM review harness for exactly this, with 35 documented audit runs. Every confirmed finding gets fixed before launch.
Self-profiling
Software I ship can render its own flame graph on command. Overhead is measured and published. Idle cost is engineered toward zero: a recent release idles at 0.1% of wall time.
Honest by construction
Nothing is discarded silently. Every automated decision is logged with its reason. Authoritative logic stays on the server, where clients cannot tamper with it.
Contact
Have something slow?
Send me the problem: what it is, where it runs, and what it costs you in time. I come back with whether it can be made fast, how fast, and what the engagement looks like. You work with me directly, start to finish.
hello@crawdata.aiFrom the mud to models