Consulting
I am a Principal AI Engineer. I read your architecture, your code and your evaluation results, then deliver a prioritized plan for fixing retrieval quality, latency and cost. When you want those fixes built rather than described, I do that too.
The technical write-ups on this site are the portfolio. They document the implementation choices, the approaches that failed, and what I learned. If the problems in them look like yours, we should talk.
Every engagement begins with a free 30-minute call. Then a written, fixed-price proposal. Nothing starts, and nothing is billed, until the scope and the number are agreed in writing.
Three ways to start, and one way to continue. Each is scoped and quoted in writing after the free call. If your problem does not fit any of these, describe it anyway.
Fixed scope · about two weeks
I read your architecture, your code and your evaluation results, then tell you what is actually wrong and what to fix first. One existing LLM workflow per review.
Fit: Best when a prototype works in a demo and nobody can say precisely why it disappoints real users.
Scoped project · six to eight weeks
Building the fixes rather than describing them, on one existing retrieval pipeline: hybrid search over BM25 and dense vectors, reranking, and query routing where it earns its place.
Fit: Best when answers are inconsistent, retrieval quality is guesswork, or a specialized domain needs more than vanilla RAG.
Scoped project · four to six weeks
One model, one task, one bounded experiment. Supervised fine-tuning or DPO on open-weight models, measured against a real baseline, so the decision to invest in training is made on numbers instead of hope.
Larger multi-node training programmes are scoped and quoted separately.
Fit: Best when prompting has stopped moving your evaluation numbers and nobody wants to commit six figures of GPU time to find out why.
Monthly retainer · eight hours a month · follows an engagement
A standing working session plus asynchronous review of designs, pull requests and vendor decisions. Eight hours a month in total, meetings included, so the boundary is clear on both sides.
This is a continuation, not a starting point. I take it on after a review or an implementation project, because advising well on a system I have not read is guesswork, and guesswork is not worth paying a retainer for.
Fit: Best when a review or a build has finished and your team wants the same judgement available while they execute the plan.
The most common question is what arrives at the end. This is the table of contents, and it is the same every time. Nothing in it is a slide.
Every finding cites the evidence it came from, so your team can disagree with a conclusion without having to take my word for the measurement. The plan is ordered by expected effect per unit of effort, and I say which items I would skip.
Each of these links to a technical write-up on this site. They document the implementation choices, the approaches that failed, and what I learned.
Multi-node BF16 training runs of the 671B-parameter DeepSeek-V3 mixture-of-experts model across three and four A100 nodes: DeepSpeed and Ray Train orchestration, NCCL networking, driver and fabric-manager stability, checkpoint hygiene and Prometheus/Grafana monitoring. Written up as an eight-part series plus a technical overview of the model.
Supervised fine-tuning with ZeRO-3 CPU offload and LoRA, followed by Direct Preference Optimization on preference data, for a content-generation workload.
How I approach query routing to specialized agents over a lexical-plus-semantic retrieval stack with neural reranking and diversity optimization, plus the data pipelines that feed it. The architecture I would start from for a domain-specific search product, written up in full.
Architecture and lessons from building Bayesian MMM as a product rather than a PDF: asynchronous GPU training, budget optimization, and a UI that turns posteriors into recommendations non-technical stakeholders can act on.
Sixteen-GPU fine-tuning with DeepSpeed ZeRO-3 offload and LoRA, with stable loss curves and efficient memory use.
Fine-tuning and serving diffusion models for image generation workloads, including the technical details most write-ups skip.
You describe the problem; I ask the questions that decide whether I can help. No charge, no pitch deck. If I am the wrong person, I say so on this call.
Scope, deliverables, acceptance criteria, timeline and a fixed price, in writing, before any work starts. It also lists what I need from your team and what is explicitly out of scope. If a smaller engagement would get you there, I propose that instead.
Reviews end with written findings and a walkthrough. Implementation projects put code in your repositories, with documentation and a recorded weekly demo, so progress is visible without a standing meeting.
I am Thomas Kalnik, a Principal AI Engineer. I have built AI systems in healthcare, digital marketing and the creator economy. Before that I worked in data engineering and data science at Criteo, 1upHealth, Dynamo Software and Wellington Management. That background matters: most production AI problems turn out to be data and infrastructure problems wearing a model costume.
I hold a Master's in Computer Science from the University of Illinois Urbana-Champaign, an MBA and MS in Finance from Northeastern University, and a Bachelor's from SUNY Geneseo. The finance training shows up in how I scope work: I care about the cost of a system and the business outcome it is supposed to move, not just whether the model is clever.
More on the about page, and in the technical posts.
Tell me what you are building and where it is stuck. I reply personally within two business days, usually with a few questions and a suggested next step.