Fine-Tune، Retrieve یا Prompt؟ فیصلہ معاشی ہے

”کیا ہمیں fine-tune کرنا چاہیے؟“ ایسے پوچھا جاتا ہے جیسے یہ model کے بارے میں سوال ہو۔ یہ budget کے بارے میں سوال ہے، ایسی shape کے ساتھ جس کا جواب کوئی benchmark نہیں دیتا: کیا ایک بار ادا ہوتا ہے، کیا فی سوال ادا ہوتا ہے، اور دنیا بدلنے پر ہر بار دوبارہ کیا ادا ہوتا ہے۔

یہ تین routes ایک ہی چیز کرنے کے تین طریقے بھی نہیں ہیں، اور vendors اسے زیادہ تر blog posts سے صاف کہتے ہیں۔ OpenAI کی اپنی table، کہ supervised fine-tuning کس کے لیے بہترین ہے، چار uses دیتی ہے: classification، nuanced translation، ایک مخصوص format میں content generate کرنا، اور instruction-following failures درست کرنا۔¹ ان میں کوئی بھی ”model کو ایسی چیز سکھانا جو اسے معلوم نہیں“ نہیں ہے۔ فائدے کا خلاصہ یہ ہے کہ ”you can use shorter prompts with fewer examples and context data, which saves on token costs at scale and can be lower latency“ — invoice کے بارے میں argument، اسی company کی طرف سے جو feature بیچ رہی ہے۔

تو:

• Fine-tuning form اور behaviour سکھاتی ہے۔ tone، format، answer کی shape، ایسی boundary جسے آپ demonstrate کر سکتے ہیں مگر describe نہیں۔ اس کی سب سے مضبوط published version LIMA کی Superficial Alignment Hypothesis ہے: knowledge pretraining سے آتا ہے، alignment زیادہ تر یہ سکھاتی ہے کہ formats کی کس sub-distribution میں بولنا ہے — اسی لیے وہاں ایک ہزار curated examples کافی تھے۔²
• Retrieval وہ facts فراہم کرتی ہے جو بدلتے ہیں۔ تینوں میں صرف یہی route ہے جہاں آپ کی documentation میں edit model کو چھوئے بغیر answer تک پہنچتا ہے۔
• Prompting زیادہ تر real cases cover کرتی ہے، اور یہی honest baseline ہے۔ In-context learning Language Models are Few-Shot Learners کے بعد سے default رہی ہے: task prompt کے اندر demonstrate ہوتی ہے اور کوئی weight move نہیں کرتا۔³

دو measured papers بیچ والی غلطی کا دروازہ بند کر دیتے ہیں۔ Ovadia اور colleagues نے unsupervised fine-tuning کے ذریعے knowledge inject کرنے کا retrieval کے ذریعے inject کرنے سے موازنہ کیا، اور retrieval مسلسل جیتی، ان facts پر بھی جو base model pretraining میں پہلے ہی دیکھ چکا تھا۔⁴ Gekhman اور colleagues نے نقصان ناپا: وہ examples جو new knowledge introduce کرتے ہیں آہستہ fit ہوتے ہیں، اور جب model آخرکار انہیں fit کرتا ہے تو دوسرے سوالوں پر اس کی hallucination rate بڑھ جاتی ہے۔ fine-tuning سے facts سکھانا صرف fail نہیں کرتا؛ یہ ان answers کو degrade کرتا ہے جن پر آپ training نہیں کر رہے تھے۔

یہ نصف settled ہے۔ economic نصف نہیں، اور باقی chapter اسی پر ہے۔

ایک case، تین طریقوں سے چلایا گیا: آپ کی اپنی documentation پر technical support، جو ہر ہفتے بدلتی ہے۔

corpus حقیقی ہے اور اسی disk پر ہے: وہ 23 Markdown documents جنہیں ایک working software repository internal documentation کے طور پر رکھتی ہے — build guide، brand rules، translation brief، دس service manuals، performance اور security notes۔ o200k_base کے ساتھ measured، وہ encoding جو Chapter 7 سے ہے:

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

تینتالیس ہزار tokens اس decision کے لیے comfortable size ہے: یہ کسی بھی modern window میں fit ہو جاتا ہے، اس لیے تینوں routes genuinely available ہیں۔ دس million پر فیصلہ آپ کے لیے ہو چکا ہوتا ہے، اور وہ retrieval ہے۔

اب وہ کام جو لفظ ”weekly“ کر رہا ہے۔ Documentation churn عموماً assert کیا جاتا ہے؛ یہاں اسے اس repository کی version history سے count کیا گیا ہے:

Documents تقریباً ہر دوسرے ہفتے move کرتے ہیں۔ user-visible strings — جن کے بارے میں support desk سے حقیقتاً پوچھا جاتا ہے — اپنے وجود کے ہر ہفتے moved ہوئیں، تقریباً بیس commits فی ہفتہ۔ جو بھی route ہم چنیں اسے اس کے ساتھ survive کرنا ہے، اور ”جس چیز پر آپ نے train کیا وہ کتنی بار بدلتی ہے؟“ کا number آپ کی اپنی repository میں نکلتا ہے، رائے میں نہیں۔

اس corpus کے مقابل بیس realistic support questions لکھے گئے، ہر topic پر ایک، اور نیچے ہر figure انہی بیس پر computed ہے۔

سب سے سادہ چیز جو کام کرتی ہے: پورا 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 count کیا گیا سوائے آخری کے: 150 output tokens ایک assumption ہے، Chapter 16 نے assistant turns کی جس range کو bill کیا اسی کے اندر chosen۔ یہاں یہی واحد figure ہے جو execute نہیں کیا گیا، اسے تینوں routes پر یکساں 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 ہے۔ آپ تیرہ tokens کے answer کے لیے تینتالیس ہزار tokens دوبارہ پڑھنے کی payment کر رہے ہیں۔

Chapter 16 کا fix directly apply ہوتا ہے: corpus stable ہے اور front پر ہے، اس لیے perfect cache prefix ہے، اور اسے واپس پڑھنے کی لاگت دسویں حصے تک آتی ہے — $0.007864 per question، 88 % cut۔ Chapter 16 کی warning بھی apply ہوتی ہے، اسی form میں جسے chapter نے flag کیا تھا مگر price نہیں کیا تھا۔ یہ provider کوئی write premium نہیں لیتا؛ یہ rent لیتا ہے۔ 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 سے اوپر اپنے پیسے پورے کرتا ہے — weekly cache rebuild count کرنے کے بعد 546 per month۔ اس سے نیچے، جس feature کو آپ نے money save کرنے کے لیے enable کیا، وہ اسے lose کرتا ہے۔

وہی route، وہی code، ایک flag، پانچ گنا bill۔ Chapter 16 نے اس کا ایک version غلط جگہ timestamp کی وجہ سے پایا تھا؛ یہاں traffic کے علاوہ کچھ غلط نہیں۔ Cache volume پر bet ہے، اور اس provider پر آپ اسے hour کے حساب سے place کرتے ہیں۔

Chapter 19 کا retriever، unchanged: section boundaries پر contextual header کے ساتھ cut کریں، index کریں، چار بہترین extracts prompt میں ڈالیں۔ بیس 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۔ چھ ماہ تک ہر ہفتے پورا index rebuild کرنا اٹھارہ cents ہے۔

ایک بات پر رکنا بنتا ہے۔ Retrieval prompt caching کو ختم کر دیتی ہے۔ stable prefix اب 140-token system instruction ہے؛ token 141 سے prompt ہر call پر differ کرتا ہے، کیونکہ extracts per question chosen ہوتے ہیں۔ اور 140 tokens Chapter 16 کے quoted ہر cache minimum سے کم ہیں۔ تو route two بالکل cache نہیں ہو سکتا، جو برا لگتا ہے اور ہے نہیں: 1,037 tokens کو cache نہ کرنا 43,298 کو cache کرنے سے cheaper ہے۔

یہ ایک general rule ہے جسے ساتھ رکھنا چاہیے: دو بڑے token-saving techniques اسی content پر mutually exclusive ہیں، اور جیت وہی ہے جو زیادہ tokens remove کرے۔ Retrieval ان کا 97.6 % remove کرتی ہے۔

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 ہے، coffee کے cup سے کم، اور یہی وجہ ہے کہ بہت سی teams یہ pay کر دیتی ہیں اس سے پہلے کہ check کریں فائدہ ہے یا نہیں۔

اب 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 ہے: آپ کا نیا short prompt، markup کے ساتھ۔ دوسری نہیں، اور money وہیں جاتا ہے — answer پر surcharge، جس کا آپ کے prompt سے کوئی تعلق نہیں اور جسے training shorten نہیں کر سکتی۔ 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 linear طور پر بڑھتا ہے کہ آپ کا assistant کتنا بولتا ہے، اس لیے long answers لکھنے والا assistant کبھی prompt delete کر کے cheaper token تک fine-tune نہیں ہو سکتا۔

اسی fact کو دوسری طرف سے یاد رکھنے والا sentence یہ ہے۔ fine-tuned route کے $0.002088 per question میں سے 97.0 % answer ہے۔ Fine-tuning باقی تین percent optimise کرتی ہے۔

چار numbers ان routes میں سے کسی کو بھی describe کرتے ہیں: آپ ایک بار کیا pay کرتے ہیں، documentation بدلنے پر کیا pay کرتے ہیں، hourly کیا pay کرتے ہیں regardless، اور 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 کوئی different 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 previous 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 چلاتا ہے: locally، ایک چھوٹے open model پر، adapter library سے pull کرنے کے بجائے ہاتھ سے لکھ کر۔ Chapter 11 نے LoRA بنایا؛ یہاں یہ q_proj اور v_proj پر، Qwen2.5-0.5B-Instruct کی تمام 24 layers میں 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 Source: سے file path کے ساتھ۔ format وہ form ہے جو سکھائی جا رہی ہے؛ path fact ہے۔ پھر بیس held-out questions پر دو numbers: کیا answer house style میں نکلتا ہے، اور کیا وہ file کا نام لیتا ہے جو واقعی question کا answer دیتی ہے؟

دو baselines table کو readable بناتے ہیں، اور دونوں Chapter 4 کی insistence ہیں نہ کہ afterthought۔ بیس میں سے دس right answers وہی file ہیں، اس لیے ایک model جو question ignore کرے اور ہمیشہ CLAUDE.md جواب دے 10/20 score کرتا ہے۔ اور retriever کی اپنی ceiling ہے: ان بیس questions میں اس کے چار extracts right file کو 14 times contain کرتے ہیں اور اسے first rank 7 times دیتے ہیں، اس لیے اسے استعمال کرنے والا کوئی بھی reader زیادہ سے زیادہ 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 % — پانچ minutes training میں، ایسے processor پر جس کے آس پاس graphics card نہیں تھا۔

facts نہیں سیکھے گئے۔ eight out of twenty ان ten سے distinguishable نہیں جو question کو entirely ignore کرنے سے ملتے ہیں، اور Chapter 4 کا interval twenty samples پر یہ loud کہتا ہے۔ وہ file paths training data میں تین بار موجود تھے؛ جو نکلا وہ plausible-looking Source: line کے ساتھ ختم کرنے کی habit تھی۔ اس chapter کے top پر موجود question پوچھا گیا تو fine-tuned model نے Short answer: 10.x . . . جواب دیا اور CLAUDE.md cite کیا۔ right 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 سے 1/20 پر collapse ہو جاتا ہے۔ اس chapter کے top والے question پر یہ 18.17.0 جواب دیتا ہے — correct، اور اس format کے بغیر جس کے لیے یہ trained تھا۔ تو fine-tuning نے format نہیں سکھایا؛ اس نے training set کے prompts پر conditional format سکھایا، اور پہلی مختلف-looking prompt اپنے ساتھ format بھی لے گئی۔ آپ جس پر بھی fine-tune کرتے ہیں وہی ایک input distribution بن جاتی ہے جس میں آپ کا model اچھا ہے، اور کوئی اسے spreadsheet میں نہیں ڈالتا۔

metric کے بارے میں آخری note، سیدھا Chapter 29 کی طرف: ”correct source“ form اور fact کو together score کرتا ہے، اسی لیے دونوں retrieval rows terrible لگتی ہیں حالانکہ دونوں models نے اس question کا fact right کیا۔ ایک end-to-end number تین چیزیں چھپا رہا تھا — 14/20 recall والا retriever، 0.5B reader اور citation format — اور کس چیز کو fix کرنا ہے یہ measure کرنے سے پہلے separate کرنے سے معلوم ہوتا ہے، بعد میں نہیں۔

اب وہ column جو vendors آپ کے لیے fill کرتے ہیں۔ fine-tuned model آپ کا owned asset نہیں؛ یہ کسی اور کے 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 نہیں چلایا؛ 6 January 2027، کوئی new jobs نہیں۔⁷ وہی page fine-tuned models themselves کی 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، جو polite way ہے یہ کہنے کا: اسے دوبارہ 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 پر simply 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 کے لیے on demand $3.99 per GPU-hour، preemptible $1.99¹⁰ — تقریباً $2,900 per month ایک card کے لیے جو up رہنا ہے چاہے کوئی کچھ پوچھے یا نہ پوچھے۔ دس ہزار questions per month پر whole retrieval route چھ ماہ کے لیے $174.52 ہے۔

یہاں LoRA اپنی جگہ budget argument کے طور پر earn کرتا ہے، technical one کے طور پر نہیں۔ اسی 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 کے مقابل، $4.00 minimum per job کے ساتھ۔¹⁰ وہ floor detail ہے۔ 24,389 tokens for three epochs پر، اس corpus پر ہر retraining $0.04 کے بجائے $4.00 bill ہوتی ہے جو arithmetic سے بنتا ہے — چھبیس weekly runs پر $104 minimums، arithmetic کے اکانوے cents کے لیے۔

دو اور columns جو صرف invoice پر appear کرتے ہیں۔

Data residency تقریباً دس percent 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 کرتا ہے، وہی دس percent۔⁵ اسے tuned endpoint کے fifty percent cost سے compare کریں تو folklore invert ہو جاتی ہے: residency cheap ہے اور fine-tuning نہیں — اور fine-tuning private option بھی نہیں، کیونکہ corpus provider تک دونوں صورتوں میں پہنچتا ہے، ایک بار training time پر instead of once per call۔

آپ کے data پر لگائی گئی سب سے explicit price اسی page پر ہے، جو ایک fine-tuned model کو دو بار list کرتا ہے: data sharing enabled کے ساتھ، inference exact half ہے — input $4.00 کے مقابل $2.00، output $16.00 کے مقابل $8.00۔⁶ provider کو جو آپ نے sent کیا اسے keep کرنے دینا 50 % discount کے برابر ہے، جو بتاتا ہے کہ ان کے لیے اس کی worth کیا ہے۔

Distillation — ایک large model کے answers پر اپنا small model train کرنا — عموماً دونوں سے نکلنے کا راستہ پیش کیا جاتا ہے۔ اسے price کریں تو یہ نہیں، کیونکہ teacher وہی system ہے جسے آپ replace کرنے کی کوشش کر رہے تھے: retrieval route سے دو سو questions پوچھ کر دو سو training examples produce کرنا 200 × $0.002906 = $0.58 cost کرتا ہے، اس پر train کرنے کے $0.73 الگ۔ Distillation وہ کام ہے جو آپ retrieval pipeline کے کام کرنے کے بعد اسے cheaper بنانے کے لیے کرتے ہیں، اور یہ ہر وہ fact inherit کرتی ہے جو retriever نے wrong کیا۔

Money visible half ہے۔ دوسرا wait کی شکل میں آتا ہے، bill جیسی ہی cause کے ساتھ: model پورا prompt پڑھتا ہے اس سے پہلے کہ ایک word کہے۔ Chapter 13 نے prefill کو decode کے مقابل ایک ایسے model پر measured کیا جسے آپ touch کر سکتے تھے؛ یہاں وہی measurement ہے، one run، one machine، prompt length کے مقابل:

absolute numbers سولہ CPU threads پر 0.5B model کے ہیں اور hosted frontier model کے بارے میں کچھ نہیں کہتے۔ shape exactly transfer ہوتی ہے: prefill prompt length کے ساتھ grow کرتا ہے، اور per token cost creep up کرتی ہے جیسے Chapter 9 کی quadratic term show ہونا شروع کرتی ہے — ایک ہزار tokens پر 4.79 ms، آٹھ ہزار پر 6.04 ms کے مقابل، صرف longer ہونے کی 26 % penalty۔

تینوں routes کے لیے consequence direct ہے۔ Route one per question تینتالیس ہزار tokens prefill کرتا ہے، اور cache hit ہی اسے bearable بناتی ہے — Chapter 16 نے explain کیا کیوں: cache read prefill work کو replace کرتا ہے، اس لیے یہ latency اور money ایک transaction میں خریدتا ہے۔ Route two ایک ہزار prefill کرتا ہے اور پہلے index تک round trip add کرتا ہے۔ Route three اٹھائیس prefill کرتا ہے اور کچھ add نہیں کرتا، جو اسے answering میں measurable طور پر تینوں میں fastest بناتا ہے۔ یہ بس wrong thing answer کر رہا ہوتا ہے۔

تین 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“ سے شروع ہوتی ہے، اور add کرتی ہے کہ اگر پچاس اچھے examples کچھ نہیں بدلتے، مسئلہ task یا prompt ہے، data volume نہیں۔¹ بیس questions، جو اس chapter نے use کیے، mechanism دکھاتے ہیں اور supplier نہیں چن سکتے — Chapter 4 نے ناپا کیوں، اور جب بیس cases ہی آپ کے پاس ہوں تو کیا کرنا ہے — انہیں repeat کریں، pair کریں، اور runs کے درمیان spread measure کریں — یہ Chapter 29 ہے۔

چار columns، اور صرف last decide کرتا ہے:

جو rule اس سے نکلتا ہے، اور اتنا short ہے کہ یاد رکھا جائے: prompt سے شروع کریں؛ facts move کریں تو retrieval add کریں؛ fine-tune صرف تب کریں جب آپ measure کر چکے ہوں کہ جو چیز ابھی بھی missing ہے وہ shape ہے، fact نہیں — اور ایسا کرنے سے پہلے answer کی قیمت لگائیں، prompt کی نہیں۔

uncomfortable version، اس کے لیے جو پہلے ہی decide کر کے آیا تھا: اس chapter کے measured case میں fine-tuning ماہانہ چار ہزار questions سے اوپر cheapest route ہے، اور facts پر یہ پھر بھی ہر چیز کا جواب CLAUDE.md دینے کو beat نہیں کر سکتی۔

یہاں ہر price per token رہی ہے، اور ہر route tokens arrange کرنے کا different way۔ یہ اب true رہنا بند ہونے والا ہے۔

Chapter 21 text چھوڑتا ہے۔ model میں enter ہونے والی image string نہیں بلکہ patches کی grid ہے جس کا token count آپ نے choose نہیں کیا؛ spoken minute ایک provider پر second کے حساب سے bill ہوتا ہے اور دوسرے پر audio token کے حساب سے؛ synthetic speech character کے حساب سے sold ہے، transcription minute کے حساب سے، raw compute GPU-second کے حساب سے۔ جس question کا جواب اس chapter نے ایک cost function سے دیا — کون سا cheaper ہے؟ — وہ تب تک پوچھا بھی نہیں جا سکتا جب تک units match نہ کریں، اور internet پر کوئی calculator انہیں normalise نہیں کرتا۔

یہیں training بھی دوبارہ سامنے آتی ہے: trigger word کے ساتھ image adapter، اور sample سے cloned voice۔ جس سے وہ سوال اٹھتا ہے جس سے next chapter open ہوتا ہے، اور یہ rhetorical نہیں: اگر language model کی fine-tuning تقریباً ہمیشہ wrong purchase ہے، تو image model کی fine-tuning تقریباً ہمیشہ right کیوں ہے؟

اس chapter میں ہر price، threshold اور multiplier provider کے اپنے page سے 7 September 2026 کو پڑھا گیا اور اسی date کے ساتھ quote کیا گیا، کیونکہ یہ سب move ہوں گے۔ measured figures — token counts، chunk sizes، retrieval sizes، training loss، scores، latencies اور version-history counts — اسی دن ایک machine پر produce ہوئے اور اوپر 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 کے across۔ corpus ایک working software repository کی tracked Markdown documentation ہے، دو append-only logs کو exclude کر کے، اور اس کی change rate اسی repository کی version history سے count کی گئی۔