I fine-tune open-source LLMs for production.

Work is billed transparently at $5–9 per hour with a fixed hour estimate up front — no agency markup and no locked-in retainers. A focused LoRA / QLoRA fine-tuning sprint on a single model usually lands in the low hundreds of dollars; a full production pipeline with dataset curation, training, evaluation and a served endpoint costs more depending on data size and scope.

LoRA (Low-Rank Adaptation) trains a small set of adapter weights on top of a frozen base model, so you get task-specific behaviour without retraining billions of parameters. QLoRA does the same on a 4-bit quantized model, which slashes GPU memory — that is how a capable 7–13B model can be fine-tuned affordably and still served cheaply.

Open-weight families including Llama 3.x, Mistral and Mixtral, Qwen 2.5, Gemma 2, Phi-3, DeepSeek and SmolLM. Model choice is driven by your task, latency budget and licence — I recommend the smallest model that hits your quality bar so inference stays inexpensive.

A single-model LoRA / QLoRA sprint is typically a 1–2 week async turnaround. A full end-to-end production pipeline — dataset curation, supervised fine-tuning, preference tuning (DPO / KTO), quantization and a deployed endpoint — usually runs 4–6 weeks with weekly progress checkpoints.

Yes — completely. You keep every weight, the cleaned dataset, the training configs and the recipe. There are no black boxes and no vendor lock-in: you can re-run, re-train or hand the whole thing to your own team at any time.

RAG (retrieval-augmented generation) is best when the model must reference changing facts or documents; fine-tuning is best when you need a consistent style, output format, task behaviour or domain skill baked into the model. They are complementary — many production systems fine-tune for behaviour and add RAG for knowledge, and I can help you decide on a short scoping call.

Yes. Models are quantized (AWQ / GGUF) and served on vLLM, TGI or llama.cpp behind an OpenAI-compatible endpoint, with benchmarks and eval dashboards. Deployment can be in the cloud or fully on-prem if your data cannot leave your own GPUs.

Absolutely. Pipelines support strict PII scrubbing and fully on-prem training and serving — no data egress and no external API calls — which is how recent legal and document-AI work reached high accuracy while running entirely on the customer's own hardware.

They are LLM post-training methods. DPO (Direct Preference Optimization) aligns a model from preference pairs without a separate reward model — simple and stable. PPO is classic RLHF with a learned reward model. GRPO (Group Relative Policy Optimization) compares groups of sampled completions and works well with programmatic or rule-based rewards — ideal for tool-use and reasoning. A common progression is SFT → DPO → GRPO.

Yes. I post-train models for function calling, multi-step tool selection and planner-executor patterns using golden trajectories, preference pairs and on-policy rollouts, then reinforce with GRPO and verifiers. I also debug agent-specific failure modes — tool-selection vs state-transition errors and chat-template / format drift.

With a mix of programmatic verifiers (exact checks, unit tests, state-transition checks against a gym environment), LLM-as-judge rubrics for fuzzier quality, and binary or graded scoring. I design rewards to resist reward hacking and watch for KL blow-up and distribution collapse during training.

With task-appropriate harnesses: pass@k (did any of k samples succeed) for capability, pass^k (did all k succeed) for reliability, plus trajectory-level scoring and rubric-based vs binary grading. I track judge variance and report model quality against clear benchmarks, not just training loss.

Yes. I extend context windows using RoPE scaling / YaRN and validate retention with long-context evals, then serve efficiently with vLLM (extended-context configs) for fast, batched inference.