KGetsIt

Models & MLOps · contract engineering

Model work for teams that know what they need.

Fine-tuning, quantization, self-hosted deployment, and inference performance work, delivered as contract engineering. We run our own GPU lab, build our inference stack from source, and ship the same setups we sell. Remote, US-based, NDA friendly.

what we take on

Five lines of work

Fine-tuning

LoRA and full fine-tunes for style, format, domain behavior, or shrinking a job onto a smaller model. Dataset prep, training runs, and evals that prove the tune actually beat the base.

Quantization & packaging

GGUF and friends. Picking the quant that holds your quality bar at the smallest footprint, verified with your evals, packaged so it deploys the same way every time.

Self-hosted deployment

llama.cpp, vLLM, and gateway plumbing on hardware you own or cloud you control. Auth, routing, logging, model switching, and the boring reliability work that makes it production instead of a demo.

Inference performance

Making the same hardware go faster: build flags, batching, KV cache strategy, speculative decoding, and when it calls for it, custom kernel and backend work. We live in this layer daily on our own machines.

Evals & benchmarking

Harnesses that measure what you actually care about, so model swaps and quant choices are decisions instead of vibes. Regression checks that catch quality drops before your users do.

Something adjacent?

If it lives between "we have a model" and "it runs well in production," it is probably in range. Ask.

Why a small shop for this

This work is mostly craft plus honesty. The craft part is knowing which quant survives your quality bar, why the tokens per second fell off a cliff, and which of the nine knobs in the serving stack actually matters for your load. We spend our own money learning that on our own hardware, which changes how carefully you learn it.

The honesty part is that a lot of model projects should not happen. Sometimes a prompt beats the fine-tune, an API beats the cluster, or the eval shows the shiny new model losing to the boring one. You get that answer straight, early, while it is still cheap.

Engagements are fixed bid or day rate, scoped in a short call. Everything ships with a writeup your own engineers can run with, because the goal is working infrastructure, and a dependency on us is not infrastructure.

Scope a project

US-based. An engineer reads this and answers by the next business morning. Sending it starts nothing but the conversation.

answers

Model work FAQ

Should we fine-tune or use RAG?
Usually RAG first, and we will tell you that even though fine-tuning is the thing we sell. Fine-tuning earns its cost when you need consistent style or format, domain behavior a prompt cannot hold, or a small model doing a narrow job cheaply. A short scoping call sorts this out before any money moves.
Can our data stay private?
Yes, and this is most of why teams hire us. Training and inference can run on hardware you own or rent in your own accounts. We work under NDA, and nothing about your data, weights, or evals leaves your control.
What hardware do we need?
Often less than you think. Between quantization, LoRA-class methods, and a llama.cpp or vLLM stack tuned properly, a single workstation GPU can serve real production loads for a lot of internal use cases. Part of the engagement is telling you honestly whether you need a cluster, a workstation, or an API bill.
How do engagements work?
Fixed bid where the scope is crisp, day rate where it is exploratory. Remote by default, US-based, and you get working artifacts either way: weights, quants, deployment configs, eval results, and a writeup your team can maintain without us.