Fine-tune, retrieve या prompt? फैसला आर्थिक है

"क्या हमें fine-tune करना चाहिए?" ऐसे पूछा जाता है जैसे यह model का सवाल हो। यह budget का सवाल है, जिसकी shape का जवाब कोई benchmark नहीं देता: क्या एक बार paid है, क्या हर question पर paid है, और दुनिया बदलने पर हर बार फिर क्या paid है।

तीन routes एक ही चीज करने के तीन तरीके भी नहीं हैं, और vendors इसे अधिकांश blog posts से ज्यादा साफ कहते हैं। OpenAI की अपनी table, जिसमें supervised fine-tuning किसके लिए best है बताया गया है, चार uses देती है: classification, nuanced translation, specific format में content generate करना, और instruction-following failures सुधारना।¹ इनमें से कोई भी "model को कुछ ऐसा सिखाना जो वह नहीं जानता" नहीं है। Benefit का उसका summary यह है कि "you can use shorter prompts with fewer examples and context data, which saves on token costs at scale and can be lower latency" — feature बेचने वाली company की तरफ से invoice वाला argument।

तो:

• Fine-tuning form और behaviour सिखाती है। Tone, format, answer की shape, ऐसी boundary जिसे आप demonstrate कर सकते हैं लेकिन describe नहीं। इसका strongest published version LIMA की Superficial Alignment Hypothesis है: knowledge pretraining से आती है, alignment मुख्यतः यह सिखाता है कि formats की किस sub-distribution में बोलना है — इसलिए वहाँ हजार curated examples काफी थे।²
• Retrieval बदलने वाले facts supply करता है। तीनों में यह अकेला तरीका है जिसमें आपकी documentation का edit model को छुए बिना answer तक पहुँचता है।
• Prompting अधिकतर real cases cover करता है, और honest baseline है। In-context learning Language Models are Few-Shot Learners के बाद से default रही है: task prompt के भीतर demonstrate होती है और कोई weight नहीं बदलता।³

बीच वाली गलती पर दो measured papers दरवाजा बंद कर देते हैं। Ovadia और colleagues ने unsupervised fine-tuning से knowledge inject करने की तुलना retrieval से knowledge inject करने से की, और retrieval लगातार जीता, उन facts पर भी जिन्हें base model pretraining में पहले ही देख चुका था।⁴ Gekhman और colleagues ने नुकसान मापा: जो examples new knowledge introduce करते हैं वे धीरे fit होते हैं, और जैसे ही model आखिरकार उन्हें fit करता है, other questions पर उसकी hallucination rate बढ़ती है। Fine-tuning से facts सिखाना केवल fail नहीं होता; यह उन answers को degrade करता है जिन पर आप train नहीं कर रहे थे।

यह आधा settled है। Economic आधा नहीं है, और बाकी chapter वही है।

एक case, तीन तरीकों से run: आपकी अपनी documentation पर technical support, जो हर week बदलती है।

Corpus real है और इसी disk पर है: 23 Markdown documents जिन्हें एक working software repository internal documentation के रूप में रखती है — build guide, brand rules, translation brief, दस service manuals, performance और security notes। o200k_base से measured, जो अध्याय 7 की encoding है:

documents                              23
characters                        159,223
words                              22,194
tokens (o200k_base)                42,921
tokens with per-file headers       43,158

तैंतालीस हजार token इस decision के लिए आरामदायक size है: यह किसी भी modern window में fit हो जाता है, इसलिए तीनों routes सचमुच available हैं। दस million पर फैसला आपके लिए हो चुका है, और वह retrieval है।

अब वह काम जो "weekly" शब्द कर रहा है। Documentation churn आमतौर पर assert किया जाता है; यहाँ उसे उस repository के version history से गिना गया है:

Documents लगभग हर दूसरे week बदलते हैं। User-visible strings — जिनके बारे में support desk से सच में पूछा जाता है — अपने अस्तित्व के हर week बदलीं, करीब बीस commits per week पर। जो भी route हम pick करें उसे इससे survive करना होगा, और "जिस चीज पर आपने train किया है वह कितनी बार बदलती है?" का number आपकी अपनी repository में होता है, राय में नहीं।

इस corpus के विरुद्ध बीस realistic support questions लिखे गए, हर topic पर एक, और नीचे की हर figure उन बीस पर computed है।

काम करने वाली सबसे simple चीज: पूरे corpus को system prompt में डालें, question को अंत में रखें, और model को उसे खोजने दें।

system instructions                       140 tokens
the 23 documents                       43,158 tokens
the question (median of 20 measured)       13 tokens
the answer (the one assumption)           150 tokens

वहाँ हर number counted था सिवाय last के: 150 output tokens एक assumption है, जिसे Chapter 16 में bill किए गए assistant turns की range के भीतर चुना गया। यह यहाँ की अकेली figure है जो execute नहीं हुई, इसे तीनों routes पर identically apply किया गया है, और break-even section ठीक-ठीक दिखाता है कि आप इसे बदलते हैं तो conclusion कितना move करता है।

7 September 2026 को provider के page से पढ़े rates पर — $1.50 per million input tokens, $9.00 per million output⁵ — यह $0.066317 per question है। आप तेरह का जवाब देने के लिए तैंतालीस हजार token दोबारा पढ़ने का भुगतान कर रहे हैं।

Chapter 16 का fix सीधे apply होता है: corpus stable है और front में है, इसलिए यह perfect cache prefix है, और उसे वापस पढ़ने की लागत दसवां हिस्सा है — $0.007864 per question, 88 % cut। Chapter 16 की warning भी apply होती है, उसी रूप में जिसे उस chapter ने flag किया था लेकिन price नहीं किया था। यह provider कोई write premium charge नहीं करता; यह rent charge करता है। Explicit cache की लागत $0.000001 per stored token per hour है,⁵ इसलिए 43,298 tokens warm रखने की लागत

है, चाहे कोई कुछ पूछे या नहीं। यह छह महीनों में $189.78 है, खाली कमरे के लिए। Rent को per question saving से divide करें और condition एक line में निकलती है: इस corpus को cache करना 0.74 questions an hour से ऊपर अपने लिए pay करता है — weekly cache rebuild count करने के बाद 546 per month। उससे नीचे, पैसे बचाने के लिए enabled feature पैसा खोता है।

Same route, same code, एक flag, पांच गुना bill। Chapter 16 ने इसका एक version गलत जगह timestamp होने से पाया था; यहाँ traffic के अलावा कुछ गलत नहीं है। Cache volume पर bet है, और इस provider पर आप उसे hour के हिसाब से लगाते हैं।

Chapter 19 का retriever, unchanged: contextual header के साथ section boundaries पर cut करें, index करें, prompt में चार best extracts रखें। बीस questions पर measured:

chunks produced from the corpus              330
mean tokens of a chunk's own text          124.9
mean tokens of the four retrieved extracts   884
prompt per question (140 + 884 + 13)       1,037
one-off embedding of every chunk        46,823 tokens

Route one की तुलना में बयालीस गुना कम prompt tokens, $0.002906 per question पर। Index build करने की लागत $0.15 per million embedding tokens पर $0.0070 है⁵ — तीन questions से भी कम — और documentation बदलने पर scratch से rebuild करने की भी वही $0.0070। छह महीनों तक हर week पूरा index rebuild करने की लागत अठारह cents है।

एक बात पर रुकना चाहिए। Retrieval prompt caching को नष्ट कर देता है। Stable prefix अब 140-token system instruction है; token 141 से prompt हर call पर अलग है, क्योंकि extracts question के हिसाब से चुने जाते हैं। और 140 tokens हर cache minimum से नीचे है जिसे Chapter 16 ने quote किया था। इसलिए route two बिल्कुल cache नहीं हो सकता, जो बुरा लगता है और है नहीं: 1,037 tokens cache न करना 43,298 cache करने से सस्ता है।

यह साथ ले जाने लायक general rule है: दो बड़े token-saving techniques एक ही content पर mutually exclusive हैं, और winner वह है जो ज्यादा token हटाता है। Retrieval उनमें से 97.6 % हटा देता है।

House style में दो सौ examples पर train करें, फिर कोई documentation attach किए बिना questions पूछें।

training examples                            200
training tokens                           24,389
epochs                                         3
prompt per question (15 + 13)                 28

Training की लागत 24,389 × 3 × $10.00 per million = $0.7317 है। यह पूरा construction cost है, एक cup coffee से कम, और यही वजह है कि इतनी teams यह check करने से पहले pay कर देती हैं कि इससे मदद मिलती भी है या नहीं।

अब trap, और इसी वजह से यह chapter मौजूद है। Fine-tuned model को run करने की लागत उसके base model जैसी नहीं होती। Pricing page इसे एक sentence में कहता है: "for model inference starting from Gemini 3, tuned model endpoint prediction price will be 1.5 times of the base model."⁵ Training नहीं। Inference, हर token पर, जब तक model जीवित है।

तो इसे formula में रखें। मान लें $p_i$ और $p_o$ base input और output prices हैं, $m$ tuned multiplier है, $L_R$ उस route की prompt length है जिसे आप replace कर रहे हैं, $L_F$ fine-tuning के बाद prompt length है, और $O$ answer length है। Fine-tuning per question तभी cheaper है जब

पहला term obvious है: आपका नया छोटा prompt, markup के साथ। दूसरा नहीं है, और पैसा वहीं जाता है — answer पर surcharge, जिसका आपके prompt से कोई लेना-देना नहीं और जिसे training छोटा नहीं कर सकती। Measured numbers के साथ — $m = 1.5$, $L_F = 28$, $O = 150$, $p_o/p_i = 6$ — threshold है

answer   50 tokens -> the prompt it replaces must exceed   192 tokens
answer  150 tokens -> the prompt it replaces must exceed   492 tokens
answer  400 tokens -> the prompt it replaces must exceed 1,242 tokens
answer 1000 tokens -> the prompt it replaces must exceed 3,042 tokens

Measured answer length पर, 492 tokens — जिनमें से 450 answer surcharge हैं, prompt नहीं। इससे छोटे prompt को replace करना per question हमेशा महंगा है, किसी भी volume पर; और threshold आपके assistant के बोलने की मात्रा के साथ linearly बढ़ता है, इसलिए long answers लिखने वाला assistant चाहे जितना prompt delete करे, cheaper token तक fine-tune नहीं कर सकता।

दूसरी तरफ से वही fact याद रखने वाली sentence है। Fine-tuned route के $0.002088 per question में से 97.0 % answer है। Fine-tuning बाकी तीन per cent optimize करती है।

इन routes में से किसी को भी चार numbers describe करते हैं: आप एक बार क्या pay करते हैं, documentation बदलने पर क्या pay करते हैं, hourly regardless क्या pay करते हैं, और per question क्या pay करते हैं। यह Chapter 16 के computeCost को modify किए बिना extend करता है।

import { computeCost, type Pricing, type Usage } from "./cost";   // Chapter 16

export interface Route {
  name: string;
  setupUSD: number;            // paid once, before the first question
  perRefreshUSD: number;       // paid every time the documentation changes
  standingUSDPerHour: number;  // paid per hour whatever the traffic
  pricing: Pricing;
  usage: Usage;                // one question and its answer
}

export const perQueryUSD = (r: Route) => computeCost(r.pricing, r.usage);

const HOURS_PER_MONTH = (24 * 365.25) / 12;

export function totalUSD(
  r: Route, months: number, queriesPerMonth: number, refreshesPerMonth: number,
) {
  return r.setupUSD
       + months * refreshesPerMonth * r.perRefreshUSD
       + months * HOURS_PER_MONTH * r.standingUSDPerHour
       + months * queriesPerMonth * perQueryUSD(r);
}

/** Monthly volume at which `b` overtakes `a`. null = it never does. */
export function crossover(
  a: Route, b: Route, months: number, refreshesPerMonth: number,
): number | null {
  const fixed = (r: Route) =>
      r.setupUSD
    + months * refreshesPerMonth * r.perRefreshUSD
    + months * HOURS_PER_MONTH * r.standingUSDPerHour;
  const dFixed = fixed(b) - fixed(a);                     // b's extra fixed cost
  const dVar = perQueryUSD(a) - perQueryUSD(b);           // b's per-question saving
  if (dVar <= 0) return null;                             // b is never cheaper
  return Math.max(0, dFixed / dVar / months);
}

Tuned model कोई अलग price list नहीं है, वही list multiplied है:

const TUNED_MULTIPLIER = 1.5;   // read from the provider's pricing page, 2026-09-07

const scale = (p: Pricing, k: number): Pricing => ({
  input: p.input.map(t => ({ ...t, price: t.price * k })),
  cachedInput: p.cachedInput!.map(t => ({ ...t, price: t.price * k })),
  output: p.output.map(t => ({ ...t, price: t.price * k })),   
});

वह highlighted line पिछले section का पूरा argument code के रूप में है: multiplier output पर भी land करता है।

छह महीने, documentation weekly refreshed के साथ:

और crossovers, यानी वे चार numbers जिनकी budget को सच में जरूरत है:

retrieval -> fine-tune, documentation never changes:     148 questions / month
retrieval -> fine-tune, documentation refreshed weekly: 3,989 questions / month
prompt (no cache) -> retrieval:                            1 question / month
prompt (no cache) -> prompt (cached):                    546 questions / month

पहले दो को साथ पढ़ें, क्योंकि यही chapter का point है। Stationary corpus fine-tuning को डेढ़ सौ questions में pay for itself करा देता है; weekly बदलने वाला corpus उसी crossover को सत्ताईस के factor से move कर देता है, और model के बारे में कुछ नहीं बदला — सिर्फ यह बदला कि आप उसके लिए दोबारा कितनी बार pay करते हैं। Construction cost footnote है; maintenance cost decision है।

अगर अब आप conclude करते हैं कि busy support desk को fine-tune करना चाहिए, arithmetic आपसे agree करता है। फिर भी यह गलत है, और अगला section बताता है क्यों।

Cost sheet में एक column है जिसे वह compute नहीं कर सकती, इसलिए यह section fine-tune run करता है: locally, छोटे open model पर, adapter को library से pull करने के बजाय hand-written करके। Chapter 11 ने LoRA बनाया था; यहाँ वही Qwen2.5-0.5B-Instruct की सभी 24 layers के q_proj और v_proj पर rank 8 में है:

class LoRALinear(nn.Module):
    def __init__(self, base: nn.Linear, r=8, alpha=16):
        super().__init__(); self.base = base
        for p in self.base.parameters():
            p.requires_grad = False              # the model is frozen  
        self.A = nn.Parameter(torch.zeros(r, base.in_features))
        nn.init.normal_(self.A, std=1 / r)
        self.B = nn.Parameter(torch.zeros(base.out_features, r))
        self.s = alpha / r
        self.on = True                           # so the same run can compare both

    def forward(self, x):
        y = self.base(x)
        return y + (x @ self.A.T @ self.B.T) * self.s if self.on else y

दो सौ training examples corpus से mechanically आते हैं, इसलिए reproduce होते हैं: question एक section heading है जिसे question में बदला गया, answer उसी section का अपना text है rigid house style में — एक line Short answer: से शुरू होती है, एक line file path के साथ Source: से शुरू होती है। Format वह form है जो सिखाया जा रहा है; path fact है। फिर बीस held-out questions पर दो numbers: क्या answer house style में आता है, और क्या वह उस file का नाम लेता है जो सच में question का answer देती है?

Table को readable बनाने के लिए दो baselines हैं, और दोनों अध्याय 4 की insistence हैं, afterthought नहीं। बीस में से दस right answers वही file हैं, इसलिए एक model जो question ignore करके हमेशा CLAUDE.md answer करता है, 10/20 score करता है। और retriever की अपनी ceiling है: इन बीस questions में उसके चार extracts में right file 14 बार मौजूद है और 7 बार first rank करती है, इसलिए उसका उपयोग करने वाला कोई भी reader maximum 14/20 score कर सकता है।

LoRA modules 48   trainable parameters 540,672 (0.109 % of the model)
400 steps, 2 epochs, 0.76 s/step on 16 CPU threads, 304 s in total
mean loss over the first 50 steps 3.7363 -> over the last 50 steps 2.4197

                                        house style   correct source
always answer the most common file             --          10 / 20
the retriever's own ceiling                    --          14 / 20
base model, closed book                    0 / 20           0 / 20
fine-tuned, closed book                   19 / 20           8 / 20
base model, four retrieved extracts       13 / 20           2 / 20
fine-tuned, four retrieved extracts        1 / 20           1 / 20

Form पूरी तरह और तेज सीखी गई। Zero से nineteen out of twenty, 540,672-parameter adapter से — model का 0.109 % — ऐसी processor पर पांच minutes की training में जिसके आसपास कोई graphics card नहीं था।

Facts नहीं सीखे गए। Eight out of twenty उस ten से अलग नहीं है जो question पूरी तरह ignore करने पर मिलता है, और Chapter 4 का interval twenty samples पर यह जोर से कहता है। वे file paths training data में तीन बार थे; जो निकला वह plausible-looking Source: line के साथ end करने की आदत थी। इस chapter के ऊपर वाला question पूछे जाने पर fine-tuned model ने Short answer: 10.x . . . answer किया और CLAUDE.md cite किया। सही answer, जो CLAUDE.md में है, 18.17.0 है।

और फिर form टूट गई, जो वह row है जो experiment को justify करती है। Fine-tuned model को retrieved extracts के हजार tokens दें — एक prompt shape जो उसने कभी नहीं देखी, क्योंकि हर training prompt अट्ठाईस tokens का था — और house style 19/20 से collapse होकर 1/20 हो जाता है। इस chapter के ऊपर वाले question पर वह 18.17.0 answer करता है — सही, और उस format के बिना जिसके लिए उसे train किया गया था। इसलिए fine-tuning ने format नहीं सिखाया; इसने training set के prompts पर conditional format सिखाया, और पहला अलग दिखने वाला prompt format को अपने साथ ले गया। आप जिस पर fine-tune करते हैं वही एक input distribution बन जाती है जिसमें आपका model अच्छा है, और इसे कोई spreadsheet में नहीं रखता।

Metric पर आखिरी note, सीधे अध्याय 29 की ओर इशारा करते हुए: "correct source" form और fact को साथ score करता है, इसलिए दोनों retrieval rows terrible लगती हैं जबकि दोनों models ने उस question का fact सही पाया। एक end-to-end number तीन चीजें छिपा रहा था — 14/20 recall वाला retriever, 0.5B reader और citation format — और किसे fix करना है यह चुनने का मतलब है measure करने से पहले उन्हें अलग करना, बाद में नहीं।

अब वह column जिसे vendors आपके लिए fill करते हैं। Fine-tuned model कोई asset नहीं है जिसे आप own करते हैं; यह किसी और के base model पर lease है, जिस पर end date printed है। 7 September 2026 को OpenAI के pricing page के fine-tuning section में यह notice पूरा मौजूद था:

OpenAI is winding down the fine-tuning platform. The platform is no longer accessible to new users, but existing users of the fine-tuning platform will be able to create training jobs for the coming months. All fine-tuned models will remain available for inference until their base models are deprecated.⁶

Timeline day तक dated है: 7 May 2026, उन organisations के लिए closed जिन्होंने कभी fine-tune नहीं किया था; 2 July 2026, उनके लिए closed जिन्होंने sixty days में fine-tuned model पर inference run नहीं किया था; 6 January 2027, no new jobs at all।⁷ वही page fine-tuned models के shutdown को schedule करता है — ft-gpt-3.5-turbo, ft-gpt-4, ft-gpt-4.1-nano, ft-babbage-002, ft-davinci-002 — 23 October 2026 को, हर एक के साथ recommended replacement base model, जो विनम्र तरीका है कहने का: इसे फिर train करें।

दूसरे frontier vendor ने आपको lease कभी बेचा ही नहीं। Anthropic का documentation index 699 pages list करता है और एक भी fine-tuning के बारे में नहीं है; Bedrock pricing page के model-customisation sections Amazon Nova, Amazon Titan, Cohere, Meta और OpenAI open-weight models cover करते हैं, Claude नहीं।⁸⁹ अगर आपका architecture fine-tune पर depend करता है, तो तीन frontier families में से एक किसी भी budget पर आपके लिए unavailable है।

Self-hosting model पर lease को machine पर lease से replace करता है, और AWS अपनी page पर यह arithmetic खुद करता है: customised model के लिए provisioned throughput की one model unit, one-month commitment, "1 model unit × $21.18 × 24 hours × 31 days = $15,757.92" per month है।⁹ Metal को directly rent करना cheaper है और free नहीं — H100 के लिए $3.99 per GPU-hour on demand, $1.99 preemptible¹⁰ — roughly $2,900 per month एक card के लिए जिसे up रहना है चाहे कोई कुछ पूछे या नहीं। दस हजार questions per month पर पूरी retrieval route छह months के लिए $174.52 है।

यहीं LoRA अपनी जगह कमाता है, technical argument नहीं बल्कि budget argument के रूप में। उसी model पर measured, attention और feed-forward layers पर rank-16 adapter 8,798,208 parameters है — model का 1.781 %, bfloat16 में 17.6 MB — base weights के 0.988 GB के मुकाबले, और उसका optimiser और gradient state 140.77 MB है जहाँ full fine-tuning को 7.90 GB चाहिए, factor 56। Consequence cheaper training नहीं बल्कि यह है कि एक loaded base model कई adapters serve कर सकता है, जो GPU की fixed cost को किसी चीज से divide करने का अकेला तरीका है। Managed training इसे reflect करती है: 16B तक low-rank $0.48 per million tokens बनाम full $0.54, with a $4.00 minimum per job।¹⁰ वही floor detail है। 24,389 tokens for three epochs पर, इस corpus पर हर retraining $0.04 computed होने के बजाय $4.00 bill करती है — छब्बीस weekly runs में minimums के $104, जबकि arithmetic ninety-one cents का था।

दो और columns जो केवल invoice पर दिखते हैं।

Data residency लगभग दस per cent cost करती है, और दो providers इस figure पर agree करते हैं। OpenAI 5 March 2026 को या उसके बाद released models के data-residency endpoints पर "a 10 % uplift" charge करता है;⁶ Vertex अपने non-global endpoints को $1.50 के मुकाबले $1.65 price करता है, वही दस per cent।⁵ इसे tuned endpoint की fifty per cent cost के विरुद्ध रखें और folklore उलट जाता है: residency सस्ती है और fine-tuning नहीं — और fine-tuning private option वैसे भी नहीं है, क्योंकि corpus provider तक दोनों तरीकों से पहुँचता है, बस per call की जगह training time पर एक बार।

आपके data पर लगाई गई सबसे explicit price उसी page पर है, जो एक fine-tuned model को दो बार list करता है: data sharing enabled होने पर inference exactly आधा है — $2.00 बनाम $4.00 input, $8.00 बनाम $16.00 output।⁶ Provider को आपने जो भेजा वह रखने देना 50 % discount के बराबर है, जिससे पता चलता है कि उनके लिए उसकी कीमत क्या है।

Distillation — बड़े model के answers पर अपना छोटा model train करना — आमतौर पर दोनों से बाहर निकलने का तरीका बताया जाता है। इसे price करें और यह वैसा नहीं है, क्योंकि teacher वही system है जिसे आप replace करना चाहते थे: retrieval route से दो सौ questions पूछकर दो सौ training examples produce करने की लागत 200 × $0.002906 = $0.58 है, उन्हें train करने के $0.73 के ऊपर। Distillation कुछ ऐसा है जो आप retrieval pipeline चलने के बाद करते हैं, उसे cheaper बनाने के लिए, और यह retriever के हर गलत fact को inherit करता है।

Money visible half है। दूसरा wait के रूप में आता है, bill वाली ही वजह से: model एक word कहने से पहले पूरा prompt पढ़ता है। अध्याय 13 ने उस model पर prefill बनाम decode measure किया था जिसे आप छू सकते थे; यहाँ वही measurement है, one run, one machine, prompt length के विरुद्ध:

Absolute numbers sixteen CPU threads पर 0.5B model के हैं और hosted frontier model के बारे में कुछ नहीं कहते। Shape exactly transfer होती है: prefill prompt length के साथ बढ़ता है, और per token cost धीरे-धीरे बढ़ती है जैसे अध्याय 9 का quadratic term दिखना शुरू करता है — thousand tokens पर 4.79 ms बनाम eight thousand पर 6.04 ms, केवल longer होने के लिए 26 % penalty।

तीनों routes के लिए consequence direct है। Route one हर question पर तैंतालीस हजार tokens prefill करता है, और cache hit ही उसे bearable बनाता है — Chapter 16 ने बताया था क्यों: cache read prefill work को replace करता है, इसलिए वह एक transaction में latency और money खरीदता है। Route two एक thousand prefill करता है और पहले index तक round trip add करता है। Route three अट्ठाईस prefill करता है और कुछ add नहीं करता, जिससे answering में वह measurably तीनों में fastest है। बस वह गलत चीज का जवाब दे रहा है।

तीन failures जो model problems जैसे दिखते हैं और हैं नहीं — यहाँ दस minutes बाद का एक month बचाते हैं:

और इस सबके ऊपर requirement: यह decision evaluation set के बिना नहीं लिया जा सकता, और fine-tune बेचने वाला vendor भी ऐसा कहता है। OpenAI की guide "Only invest in fine-tuning after setting up evals. You need a reliable way to determine whether your fine-tuned model is performing better than a base model" से खुलती है, और जोड़ती है कि अगर fifty good examples कुछ नहीं बदलते, तो problem task या prompt है, data volume नहीं।¹ Twenty questions, जो इस chapter ने use किए, mechanism दिखाते हैं और supplier नहीं चुन सकते — Chapter 4 ने मापा था क्यों, और जब twenty cases ही आपके पास हों तो क्या करें — उन्हें repeat करें, pair करें, और runs के बीच spread measure करें — यह Chapter 29 है।

चार columns, और सिर्फ last one फैसला करता है:

इससे निकलने वाला rule, और इतना छोटा कि याद रखा जा सके: prompt से शुरू करें; जब facts move करें तो retrieval add करें; fine-tune केवल तब करें जब आपने measure कर लिया हो कि जो चीज अभी भी कमी है वह shape है, fact नहीं — और उससे पहले answer को price करें, prompt को नहीं।

उन लोगों के लिए uncomfortable version जो पहले ही decide करके आए थे: इस chapter के measured case में fine-tuning महीने में चार हजार questions से ऊपर सबसे सस्ता route है, और facts पर फिर भी हर चीज को CLAUDE.md answer करने से बेहतर नहीं कर पाता।

यहाँ हर price per token रही है, और हर route tokens को arrange करने का अलग तरीका। यह अब true रहना बंद होने वाला है।

Chapter 21 text छोड़ता है। Model में entering image string नहीं बल्कि patches की grid है जिसकी token count आपने नहीं चुनी; spoken minute एक provider पर second से billed है और दूसरे पर audio token से; synthetic speech character से बिकती है, transcription minute से, raw compute GPU-second से। जिस question का answer इस chapter ने एक cost function से दिया — कौन सस्ता है? — उसे तब तक पूछा भी नहीं जा सकता जब तक units match न हों, और internet पर कोई calculator उन्हें normalise नहीं करता।

यहीं training फिर से आती है: trigger word वाला image adapter, और sample से cloned voice। जिससे वह सवाल उठता है जिससे अगला chapter शुरू होता है, और यह rhetorical नहीं है: अगर language model को fine-tune करना लगभग हमेशा wrong purchase है, तो image model को fine-tune करना लगभग हमेशा right one क्यों है?

इस chapter में हर price, threshold और multiplier provider के अपने page से 7 September 2026 को पढ़ा गया और उसी date के साथ quoted है, क्योंकि ये सभी बदलेंगे। Measured figures — token counts, chunk sizes, retrieval sizes, training loss, scores, latencies और version-history counts — उसी दिन एक machine पर produced थे और ऊपर described corpus से reproducible हैं।

Local experiments ने greedy decoding के साथ Qwen/Qwen2.5-0.5B-Instruct use किया, इसलिए वे exactly reproduce होते हैं; adapter ऊपर printed twelve-line class है, rank 8 पर q_proj और v_proj के over। Corpus एक working software repository की tracked Markdown documentation है, दो append-only logs को छोड़कर, और उसकी change rate उसी repository के version history से counted थी।