Depth Dial Protocol — One-Parameter Compute-to-Configuration Framework for Fine-Tuning & Deploying GPT Models

Depth Dial Protocol is a one-parameter configuration framework for teams fine-tuning or deploying GPT-style models on top of hosted APIs or open-weight checkpoints. Every fine-tuning project independently re-litigates the same eight decisions — how much training data, how many epochs, how strict the eval gate, how big the canary rollout, how much context budget, what the cost ceiling is, what the fallback path is, and how often to re-check for drift — usually in a multi-week debate between whoever is most cautious and whoever is most impatient. Depth Dial Protocol collapses that debate into picking one number.

Why this exists

In 2026, Andrej Karpathy's nanochat (MIT licensed, 58k+ GitHub stars) became one of the most-starred repos of the year by putting the entire LLM training stack — tokenization, pretraining, finetuning, evaluation, inference, and a working chat UI — behind a single --depth parameter. Set one dial and nanochat mechanically derives every other hyperparameter (model width, layer count, learning rate, batch size, total training tokens) at a compute-optimal ratio, rather than making you tune two dozen knobs by hand. The result: a GPT-2-class model trainable for roughly $100 in compute, down from the tens of thousands it cost in 2019.

That dial is for people training raw model weights on a GPU cluster. Almost nobody building GPT-powered products does that — most teams fine-tune a hosted model through a vendor API or fine-tune an open-weight checkpoint, then have to independently decide how much data to use, how confident to be before shipping, and how to roll back if it's wrong. Depth Dial Protocol takes the same one-input-derives-everything philosophy and moves it to that layer: the fine-tuning and deployment configuration surface every team building on top of GPT models actually controls. This is original process methodology, not a reimplementation of nanochat's training code, and not a claim of equivalent technical results. It contains no nanochat code, no model weights, and no training infrastructure — it is a decision framework for people who call APIs, not people who write CUDA kernels.

What's inside

Step 1 — Answer four diagnostic questions to find your tier

1. If the model gives a wrong answer, is the worst case merely annoying, or does it cause financial, legal, safety, or reputational harm?
2. Is the audience internal (your own team) or external (paying customers or the public)?
3. Do adjacent tasks in your product already carry an accuracy bar you're expected to match?
4. Is there a regulatory, contractual, or compliance obligation attached to this use case?

Score zero points per question for the low-stakes answer (annoying / internal / no existing bar / no obligation) and one point per question for the high-stakes answer. Total score of 0 → Tier 1. 1 → Tier 2. 2 → Tier 3. 3 → Tier 4. 4, or any regulatory "yes" by itself → Tier 5, no exceptions.

Step 2 — Read every downstream setting off the table

Worked example

A support team wants to fine-tune a model to auto-draft replies to billing tickets. Scoring: a wrong draft is reviewed by a human before sending, so worst case is "annoying, not harmful" (0) — but the audience is external once replies go out (1), the team's existing macros already hit ~90% accuracy so there's a bar to match (1), and there's no regulatory obligation (0). Score: 2 → Tier 3. That reads directly off the table as: 800–3,000 labeled examples, 4 epochs, ship only once eval hits 88%, roll out to 15% of tickets for 7 days before full rollout, cap context at 8K tokens, cap spend at $6 per 1,000 requests, route low-confidence drafts to a human queue, and re-run the eval suite weekly. That's a complete configuration decided in the time it took to answer four questions, not a two-week planning cycle.

Failure mode checklist — when not to use a single dial

• Multi-tenant products with mixed-risk customers — a single global tier hides the fact that one customer's use case is Tier 2 and another's is Tier 5. Score each customer segment separately.
• Anything touching medical, legal, or financial advice — treat as Tier 5 regardless of score, and add explicit human sign-off on top of the table; the table is a floor, never a ceiling, for these cases.
• Teams with 90+ days of real production eval data — actual signal from your own traffic should override the heuristic table once you have it. The dial is for picking a defensible starting point fast, not for overriding real data forever.
• Anywhere a regulator, contract, or policy already sets a specific numeric threshold — that number wins outright; the table never lowers a legally or contractually required bar.

Format

The complete framework — the four diagnostic questions, the full tier table, the worked example, and the failure-mode checklist — is delivered in full above. Everything is copy-paste ready; there is no separate file to download.

Best for

• Teams fine-tuning a hosted or open-weight GPT-style model who are stuck debating configuration instead of shipping
• Engineering leads who need a defensible, repeatable answer to "how much data / how strict a gate / how big a rollout" across multiple projects
• Teams who don't train model weights from scratch but do own the fine-tuning and deployment decisions around a vendor API

What you'll need

• A fine-tuning path (hosted API fine-tuning, or your own fine-tuning of an open-weight checkpoint)
• An existing or buildable eval suite to check the gate percentage against
• 15–20 minutes to score your project and read the resulting configuration off the table

FAQ

Is this affiliated with nanochat, Andrej Karpathy, or any of Karpathy's projects? No. Depth Dial Protocol is an independent, provider-agnostic framework and is not affiliated with or endorsed by Karpathy or nanochat.

Does this include nanochat's training code, scaling-law math, or model weights? No — it contains no nanochat code or weights. It is original process methodology inspired by nanochat's one-parameter philosophy, applied entirely at the fine-tuning/deployment decision layer.

Does this train a model for me? No — it tells you what configuration to use before and after you fine-tune; it doesn't run training jobs.

Does this guarantee a specific accuracy, cost, or outcome? No guarantee. The tier table is a heuristic starting point based on common practice, not a scientific scaling law or a promised result. Always validate against your own eval data.