Fine-tune، بازیابی یا prompt؟ تصمیم اقتصادی است

«آیا باید fine-tune کنیم؟» طوری پرسیده می‌شود که انگار سؤال درباره یک مدل است. این سؤال درباره بودجه است، با شکلی که هیچ benchmarkی جوابش را نمی‌دهد: چه چیزی یک‌بار پرداخت می‌شود، چه چیزی به‌ازای هر سؤال پرداخت می‌شود، و هر بار که جهان تغییر می‌کند چه چیزی دوباره پرداخت می‌شود.

این سه مسیر همچنین سه راه برای انجام یک کار واحد نیستند، و vendorها این را روشن‌تر از بیشتر blog postها می‌گویند. جدول خود OpenAI درباره اینکه supervised fine-tuning برای چه چیزهایی بهترین است چهار کاربرد فهرست می‌کند: classification، ترجمه ظریف، تولید محتوا در قالبی مشخص، و اصلاح failureهای instruction-following.¹ هیچ‌کدامشان «یاد دادن چیزی به مدل که نمی‌داند» نیست. خلاصه مزیتش این است که «می‌توانید از promptهای کوتاه‌تر با مثال‌ها و context data کمتر استفاده کنید، که در مقیاس در هزینه token صرفه‌جویی می‌کند و می‌تواند latency پایین‌تری داشته باشد» — استدلالی درباره invoice، از شرکتی که خود آن feature را می‌فروشد.

پس:

• Fine-tuning فرم و رفتار یاد می‌دهد. لحن، قالب، شکل پاسخ، مرزی که می‌توانید نشان بدهید اما توصیف نه. قوی‌ترین نسخه منتشرشده، فرضیه Superficial Alignment در LIMA است: knowledge از pretraining می‌آید، alignment بیشتر یاد می‌دهد از کدام sub-distribution از قالب‌ها صحبت کند — و به همین دلیل هزار مثال curated در آنجا کافی بود.²
• بازیابی facts متغیر را تأمین می‌کند. این تنها گزینه از این سه است که در آن ویرایش مستنداتتان بدون دست زدن به مدل به پاسخ می‌رسد.
• Prompting بیشتر caseهای واقعی را پوشش می‌دهد و baseline صادقانه است. In-context learning از زمان Language Models are Few-Shot Learners پیش‌فرض بوده است: task داخل prompt نشان داده می‌شود و هیچ weightی حرکت نمی‌کند.³

دو مقاله اندازه‌گیری‌شده درِ اشتباه وسط را می‌بندند. Ovadia و همکاران تزریق knowledge با unsupervised fine-tuning را با تزریق آن از طریق بازیابی مقایسه کردند، و بازیابی به‌طور پیوسته برنده شد، حتی روی factsی که مدل پایه از قبل در pretraining دیده بود.⁴ Gekhman و همکاران آسیب را اندازه گرفتند: مثال‌هایی که knowledge جدید معرفی می‌کنند آهسته fit می‌شوند، و وقتی مدل بالاخره آن‌ها را fit می‌کند نرخ hallucination روی سؤال‌های دیگر بالا می‌رود.⁵ آموزش دادن factها با fine-tuning صرفاً شکست نمی‌خورد؛ پاسخ‌هایی را هم که رویشان train نکرده‌اید خراب می‌کند.

این نیمه قطعی است. نیمه اقتصادی نه، و باقی فصل همان است.

یک case، با سه مسیر اجرا شده: پشتیبانی فنی روی مستندات خودتان، که هر هفته تغییر می‌کند.

corpus واقعی است و روی همین disk قرار دارد: 23 سند Markdown که یک repository نرم‌افزاری فعال به‌عنوان مستندات داخلی نگه می‌دارد — راهنمای build، قواعد brand، brief ترجمه، ده service manual، یادداشت‌های performance و security. اندازه‌گیری‌شده با o200k_base، encoding از فصل 7:

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

چهل‌وسه هزار token اندازه راحتی برای این تصمیم است: در هر context window مدرنی جا می‌شود، پس هر سه مسیر واقعاً در دسترس‌اند. در ده میلیون، تصمیم از قبل برایتان گرفته شده، و آن بازیابی است.

حالا کاری که کلمه «هفتگی» انجام می‌دهد. documentation churn معمولاً ادعا می‌شود؛ اینجا از تاریخچه نسخه همان repository شمرده شده است:

سندها تقریباً یک هفته در میان حرکت می‌کنند. stringهای قابل‌مشاهده برای کاربر — که همان چیزی هستند که support desk واقعاً درباره‌شان سؤال می‌گیرد — در هر هفته‌ای که وجود داشته‌اند تغییر کرده‌اند، با حدود بیست commit در هفته. هر مسیری که انتخاب کنیم باید از این جان سالم به‌در ببرد، و «چیزی که رویش train کرده‌اید چند وقت یک‌بار تغییر می‌کند؟» معلوم می‌شود در repository خودتان عدد دارد، نه opinion.

بیست سؤال پشتیبانی واقع‌بینانه علیه این corpus نوشته شد، یکی برای هر topic، و همه اعداد پایین روی همان بیست تا محاسبه شده‌اند.

ساده‌ترین چیزی که کار می‌کند: کل corpus را در system prompt بگذارید، سؤال را در انتها، و اجازه دهید مدل پیدایش کند.

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

همه اعداد آنجا شمرده شدند جز آخری: 150 output token یک فرض است، انتخاب‌شده در محدوده turnهای assistant که فصل 16 برایشان صورتحساب ساخت. این تنها عدد اینجاست که اجرا نشده، برای هر سه مسیر یکسان اعمال شده، و بخش break-even دقیقاً نشان می‌دهد وقتی عوضش کنید نتیجه چقدر جابه‌جا می‌شود.

با نرخ‌هایی که در 7 سپتامبر 2026 از صفحه provider خوانده شد — $1.50 به‌ازای هر میلیون input token، $9.00 به‌ازای هر میلیون output⁶ — این می‌شود $0.066317 برای هر سؤال. دارید پول می‌دهید که چهل‌وسه هزار token دوباره خوانده شود تا به سیزده token پاسخ داده شود.

راه‌حل فصل 16 مستقیم اعمال می‌شود: corpus پایدار است و در ابتدای prompt قرار دارد، پس prefix عالی برای cache است، و خواندن دوباره آن یک‌دهم هزینه دارد — $0.007864 برای هر سؤال، کاهش 88 %. هشدار فصل 16 هم اعمال می‌شود، در شکلی که آن فصل علامت زد اما قیمت‌گذاری نکرد. این provider write premium نمی‌گیرد؛ اجاره می‌گیرد. یک cache صریح به‌ازای هر stored token در هر ساعت $0.000001 هزینه دارد،⁶ پس گرم نگه داشتن 43,298 token هزینه دارد:

چه کسی چیزی بپرسد چه نپرسد. این یعنی $189.78 در شش ماه، برای اتاقی خالی. اجاره را بر صرفه‌جویی به‌ازای هر سؤال تقسیم کنید و شرط در یک خط بیرون می‌آید: cache کردن این corpus وقتی به‌صرفه است که بالای 0.74 سؤال در ساعت داشته باشید — با احتساب rebuild هفتگی cache، 546 تا در ماه. پایین‌تر از آن، featureی که برای صرفه‌جویی روشن کرده‌اید پول از دست می‌دهد.

همان مسیر، همان code، یک flag، پنج برابر صورت‌حساب. فصل 16 نسخه‌ای از این را پیدا کرد که به‌خاطر timestamp در جای غلط بود؛ اینجا هیچ‌چیز غلط نیست جز traffic. cache یک شرط‌بندی روی volume است، و روی این provider آن را ساعتی می‌بندید.

retriever فصل 19، بدون تغییر: برش روی مرزهای section با contextual header، index، گذاشتن چهار extract برتر در prompt. اندازه‌گیری‌شده روی بیست سؤال:

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

چهل‌ودو برابر prompt token کمتر از مسیر اول، با $0.002906 برای هر سؤال. ساخت index با $0.15 به‌ازای هر میلیون embedding token هزینه‌اش $0.0070 است⁶ — کمتر از ارزش سه سؤال — و rebuild کامل از صفر هر بار که مستندات تغییر کند همان $0.0070 هزینه دارد. rebuild کل index هر هفته برای شش ماه هجده سنت هزینه دارد.

یک چیز ارزش توقف دارد. بازیابی prompt caching را نابود می‌کند. prefix پایدار حالا instruction سیستمی 140-token است؛ از token 141 به بعد prompt در هر call فرق می‌کند، چون extractها برای هر سؤال انتخاب می‌شوند. و 140 token پایین‌تر از همه minimumهای cache است که فصل 16 نقل کرد. پس مسیر دوم اصلاً cacheشدنی نیست، که بد به نظر می‌رسد و بد نیست: cache نکردن 1,037 token ارزان‌تر از cache کردن 43,298 است.

این یک قاعده عمومی است که باید همراه داشت: دو تکنیک بزرگ صرفه‌جویی در token روی همان content با هم ناسازگارند، و برنده آنی است که token بیشتری حذف کند. بازیابی 97.6 % آن‌ها را حذف می‌کند.

روی دویست مثال با house style train کنید، بعد سؤال‌ها را بدون هیچ مستندی بپرسید.

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

هزینه training برابر است با 24,389 × 3 × $10.00 به‌ازای هر میلیون = $0.7317. این کل هزینه ساخت است، کمتر از یک فنجان قهوه، و دقیقاً به همین دلیل خیلی از تیم‌ها قبل از بررسی اینکه کمکی می‌کند یا نه آن را پرداخت می‌کنند.

حالا دام، و دلیل وجود این فصل. یک مدل fine-tuned برای اجرا همان هزینه مدل پایه‌اش را ندارد. صفحه قیمت‌گذاری آن را در یک جمله می‌گوید: «برای model inference از Gemini 3 به بعد، قیمت prediction برای tuned model endpoint برابر 1.5 برابر مدل پایه خواهد بود.»⁶ نه training. inference، روی هر token، تا وقتی مدل زنده است.

پس آن را در یک formula بگذارید. بگذارید $p_i$ و $p_o$ قیمت‌های base input و output باشند، $m$ tuned multiplier، $L_R$ طول prompt مسیری که جایگزین می‌کنید، $L_F$ طول prompt بعد از fine-tuning، و $O$ طول پاسخ. fine-tuning فقط وقتی به‌ازای هر سؤال ارزان‌تر است که

ترم اول واضح است: prompt کوتاه جدیدتان، با markup. دومی واضح نیست، و همان‌جاست که پول می‌رود — surcharge روی پاسخ، که هیچ ربطی به prompt شما ندارد و training نمی‌تواند کوتاهش کند. با اعداد اندازه‌گیری‌شده — $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

با طول پاسخ اندازه‌گیری‌شده، 492 token — که 450 تایش surcharge پاسخ است، نه prompt. جایگزینی promptی کوتاه‌تر از آن به‌ازای هر سؤال گران‌تر است، برای همیشه، در هر volume؛ و threshold به‌صورت خطی با مقدار حرف زدن assistant شما رشد می‌کند، پس assistantی که پاسخ‌های بلند می‌نویسد هرچقدر هم prompt حذف کند، هرگز نمی‌تواند با fine-tune به token ارزان‌تر برسد.

همین واقعیت از سمت دیگر جمله‌ای است که باید به خاطر بسپارید. از $0.002088 هزینه هر سؤال مسیر fine-tuned، 97.0 % پاسخ است. fine-tuning سه درصد باقی‌مانده را بهینه می‌کند.

چهار عدد هر یک از این مسیرها را توصیف می‌کند: چه چیزی را یک‌بار می‌پردازید، وقتی مستندات تغییر می‌کند چه می‌پردازید، چه چیزی را ساعتی فارغ از همه‌چیز می‌پردازید، و چه چیزی را به‌ازای هر سؤال می‌پردازید. این computeCost فصل 16 را بدون تغییر دادن آن گسترش می‌دهد.

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 یک price list متفاوت نیست، همان یکی است که ضرب شده:

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 })),   
});

آن یک خط highlightشده کل استدلال بخش قبلی است که به code نوشته شده: multiplier روی output هم می‌نشیند.

شش ماه، با refresh هفتگی مستندات:

و crossoverها، که همان چهار عددی‌اند که یک بودجه واقعاً لازم دارد:

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

دو عدد اول را با هم بخوانید، چون نکته فصل همین است. یک corpus ثابت باعث می‌شود fine-tuning در صد و پنجاه سؤال هزینه خودش را جبران کند؛ corpusی که هر هفته تغییر می‌کند همان crossover را بیست‌وهفت برابر جابه‌جا می‌کند، و هیچ‌چیز درباره مدل تغییر نکرده — فقط اینکه چند وقت یک‌بار دوباره پولش را می‌دهید تغییر کرده. هزینه ساخت یک پاورقی است؛ هزینه نگهداری خود تصمیم است.

اگر حالا نتیجه بگیرید که یک support desk شلوغ باید fine-tune کند، arithmetic با شما موافق است. هنوز غلط است، و بخش بعدی دلیلش را می‌گوید.

cost sheet یک ستون دارد که نمی‌تواند محاسبه کند، پس این بخش fine-tune را اجرا می‌کند: محلی، روی یک مدل open کوچک، با adapterی که به‌جای کشیدن از library با دست نوشته شده است. فصل 11 LoRA را ساخت؛ اینجا همان است، روی q_proj و v_proj همه 24 لایه Qwen2.5-0.5B-Instruct با 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 به‌صورت مکانیکی از corpus می‌آیند، پس reproduce می‌شوند: سؤال یک heading بخش است که به سؤال تبدیل شده، پاسخ متن خود همان بخش در یک house style سخت‌گیرانه است — یک خط که با Short answer: شروع می‌شود، یک خط که با Source: و مسیر فایل شروع می‌شود. قالب همان فرمی است که آموزش داده می‌شود؛ مسیر همان fact است. بعد دو عدد روی بیست سؤال held-out: آیا پاسخ با house style بیرون می‌آید، و آیا فایلی را نام می‌برد که واقعاً به سؤال جواب می‌دهد؟

دو baseline جدول را خواندنی می‌کنند، و هر دو اصرار فصل 4 هستند نه چیزی که بعداً اضافه شده باشد. ده تا از بیست پاسخ درست همان فایل‌اند، پس مدلی که سؤال را نادیده می‌گیرد و همیشه CLAUDE.md جواب می‌دهد امتیاز 10/20 می‌گیرد. و retriever سقف خودش را دارد: در این بیست سؤال، چهار extract آن 14 بار فایل درست را شامل شده‌اند و 7 بار آن را اول رتبه‌بندی کرده‌اند، پس 14/20 بیشترین امتیازی است که هر readerی با استفاده از آن می‌توانست بگیرد.

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

فرم کاملاً و سریع یاد گرفته شد. از صفر به نوزده از بیست، با adapterی 540,672-پارامتری — 0.109 % مدل — در پنج دقیقه training روی پردازنده‌ای که هیچ کارت گرافیکی در چشم‌اندازش نبود.

factها یاد گرفته نشدند. هشت از بیست از دهی که با نادیده گرفتن کامل سؤال می‌گیرید قابل‌تشخیص نیست، و interval فصل 4 روی بیست sample این را بلند می‌گوید. آن مسیرهای فایل سه بار در training data آمده بودند؛ چیزی که بیرون آمد عادت پایان دادن با یک خط Source: قابل‌باور بود. وقتی سؤال ابتدای این فصل از مدل fine-tuned پرسیده شد، جواب داد Short answer: 10.x . . . و به CLAUDE.md citation داد. پاسخ درست، که در CLAUDE.md است، 18.17.0 است.

و بعد فرم شکست، که همان ردیفی است که آزمایش را توجیه می‌کند. هزار token از extractهای بازیابی‌شده را به مدل fine-tuned بدهید — شکلی از prompt که هرگز ندیده بود، چون همه promptهای training بیست‌وهشت token بودند — و house style از 19/20 به 1/20 فرو می‌ریزد. روی سؤال ابتدای همین فصل جواب می‌دهد 18.17.0 — درست، و بدون هیچ‌کدام از قالبی که برایش train شده بود. پس fine-tuning یک قالب یاد نداد؛ یک قالب مشروط به promptهای موجود در training set یاد داد، و اولین promptی که متفاوت به نظر می‌رسید قالب را با خود برد. هر چیزی که رویش fine-tune کنید تبدیل می‌شود به همان input distribution واحدی که مدل شما در آن خوب است، و هیچ‌کس این را در spreadsheet نمی‌گذارد.

یک یادداشت آخر درباره metric، مستقیم به سمت فصل 29: «منبع درست» فرم و fact را با هم score می‌کند، و به همین دلیل هر دو ردیف بازیابی افتضاح به نظر می‌رسند، حتی اگر هر دو مدل fact آن سؤال را درست گفته باشند. یک عدد end-to-end سه چیز را پنهان می‌کرد — retriever با recall 14/20، reader 0.5B و قالب citation — و انتخاب اینکه کدام را fix کنید یعنی قبل از اندازه‌گیری جداشان کنید، نه بعدش.

حالا ستونی که vendorها برایتان پر می‌کنند. یک مدل fine-tuned دارایی‌ای نیست که مالک آن باشید؛ lease روی مدل پایه کس دیگری است، با تاریخ پایان چاپ‌شده روی آن. در 7 سپتامبر 2026، بخش fine-tuning صفحه قیمت‌گذاری OpenAI این اطلاعیه را کامل داشت:

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 تا روز تاریخ دارد: 7 مه 2026، بسته برای سازمان‌هایی که هرگز fine-tune نکرده بودند؛ 2 ژوئیه 2026، بسته برای آن‌هایی که در شصت روز inference روی مدل fine-tuned اجرا نکرده بودند؛ 6 ژانویه 2027، هیچ job جدیدی اصلاً.⁸ همان صفحه shutdown خود مدل‌های fine-tuned را هم زمان‌بندی می‌کند — ft-gpt-3.5-turbo، ft-gpt-4، ft-gpt-4.1-nano، ft-babbage-002، ft-davinci-002 — در 23 اکتبر 2026، هرکدام با یک recommended replacement base model، که راه مؤدبانه گفتن این است: دوباره train کنید.

vendor frontier دیگر اصلاً این lease را به شما نفروخت. index مستندات Anthropic، 699 صفحه فهرست می‌کند و حتی یکی درباره fine-tuning نیست؛ بخش‌های model-customisation صفحه قیمت‌گذاری Bedrock، Amazon Nova، Amazon Titan، Cohere، Meta و مدل‌های open-weight از OpenAI را پوشش می‌دهد، و هیچ Claudeی نه.⁹¹⁰ اگر architecture شما به fine-tune وابسته باشد، یکی از سه خانواده frontier با هر بودجه‌ای برایتان در دسترس نیست.

Self-hosting lease روی مدل را با lease روی ماشین جایگزین می‌کند، و AWS این arithmetic را در صفحه خودش انجام می‌دهد: یک model unit از provisioned throughput برای یک مدل customised، تعهد یک‌ماهه، «1 model unit × $21.18 × 24 hours × 31 days = $15,757.92» در ماه است.¹⁰ اجاره مستقیم metal ارزان‌تر است و رایگان نیست — $3.99 به‌ازای هر GPU-hour on demand برای H100، $1.99 preemptible¹¹ — حدود $2,900 در ماه برای یک کارت که باید روشن باشد چه کسی چیزی بپرسد چه نپرسد. کل مسیر بازیابی در ده هزار سؤال در ماه برای شش ماه $174.52 است.

اینجاست که LoRA جای خودش را پیدا می‌کند، به‌عنوان استدلال بودجه‌ای نه فنی. اندازه‌گیری‌شده روی همان مدل، یک adapter rank-16 روی attention و feed-forward layerها برابر 8,798,208 پارامتر است — 1.781 % مدل، 17.6 MB در bfloat16 — در برابر 0.988 GB وزن‌های پایه، و state مربوط به optimiser و gradient آن 140.77 MB است در جایی که full fine-tuning به 7.90 GB نیاز دارد، ضریب 56. نتیجه، training ارزان‌تر نیست؛ نتیجه این است که یک مدل پایه loaded می‌تواند به adapterهای زیادی service بدهد، که تنها راهی است که fixed cost یک GPU بین چیزی تقسیم می‌شود. Managed training هم بازتابش می‌دهد: $0.48 به‌ازای هر میلیون token برای low-rank تا 16B در برابر $0.54 full، با minimum $4.00 برای هر job.¹¹ آن floor جزئیات مهم است. با 24,389 token برای سه epoch، هر retraining روی این corpus به‌جای $0.04 محاسباتی، $4.00 صورتحساب می‌شود — $104 minimum در 26 اجرای هفتگی، برای 91 سنت arithmetic.

دو ستون دیگر که فقط روی invoice ظاهر می‌شوند.

Data residency حدود ده درصد هزینه دارد، و دو provider روی این عدد توافق دارند. OpenAI برای endpointهای data-residency روی مدل‌هایی که در 5 مارس 2026 یا بعد از آن منتشر شده‌اند «10 % uplift» می‌گیرد؛⁷ Vertex endpointهای non-global خود را $1.65 در برابر $1.50 قیمت می‌گذارد، همان ده درصد.⁶ این را کنار پنجاه درصدی بگذارید که یک tuned endpoint هزینه دارد و folklore وارونه می‌شود: residency ارزان است و fine-tuning نیست — و fine-tuning گزینه خصوصی هم نیست، چون corpus در هر صورت به provider می‌رسد، یک‌بار در زمان training به‌جای یک‌بار در هر call.

صریح‌ترین قیمتی که تا حالا روی داده شما گذاشته شده در همان صفحه است، که یک مدل fine-tuned را دو بار فهرست می‌کند: با data sharing روشن، inference دقیقاً نصف است — $2.00 در برابر $4.00 input، $8.00 در برابر $16.00 output.⁷ اینکه بگذارید provider چیزی را که فرستاده‌اید نگه دارد 50 % discount می‌ارزد، و این نشان می‌دهد برای آن‌ها چقدر می‌ارزد.

Distillation — train کردن یک مدل کوچک خودتان روی پاسخ‌های یک مدل بزرگ — معمولاً به‌عنوان راه خروج از هر دو عرضه می‌شود. قیمتش را حساب کنید و نیست، چون teacher همان سیستمی است که می‌خواستید جایگزین کنید: تولید دویست مثال training با پرسیدن دویست سؤال از مسیر بازیابی هزینه دارد 200 × $0.002906 = $0.58، علاوه بر $0.73 برای train کردن روی آن‌ها. Distillation کاری است که بعد از کار کردن pipeline بازیابی انجام می‌دهید تا ارزان‌ترش کنید، و هر factی را که retriever غلط گرفته به ارث می‌برد.

پول نیمه قابل‌مشاهده است. نیمه دیگر به‌صورت انتظار می‌آید، با همان علت صورت‌حساب: مدل کل prompt را قبل از گفتن اولین کلمه می‌خواند. فصل 13 prefill را در برابر decode روی مدلی که می‌شد لمسش کرد اندازه گرفت؛ اینجا همان اندازه‌گیری است، یک run، یک ماشین، در برابر طول prompt:

اعداد مطلق متعلق به مدل 0.5B روی شانزده CPU thread هستند و درباره hosted frontier model هیچ نمی‌گویند. شکل دقیقاً منتقل می‌شود: prefill با طول prompt رشد می‌کند، و cost per token با شروع دیده شدن ترم quadratic فصل 9 بالا می‌خزد — 4.79 ms در هزار token در برابر 6.04 ms در هشت هزار، جریمه 26 % فقط برای طولانی‌تر بودن.

نتیجه برای سه مسیر مستقیم است. مسیر اول به‌ازای هر سؤال چهل‌وسه هزار token prefill می‌کند، و cache hit چیزی است که قابل‌تحملش می‌کند — فصل 16 توضیح داد چرا: cache read جای prefill work را می‌گیرد، پس latency و پول را در یک transaction می‌خرد. مسیر دوم هزار token prefill می‌کند و اول یک round trip به index اضافه می‌کند. مسیر سوم بیست‌وهشت token prefill می‌کند و چیزی اضافه نمی‌کند، که آن را در پاسخ دادن به‌طور اندازه‌پذیر سریع‌ترینِ این سه می‌کند. فقط دارد به چیز غلط جواب می‌دهد.

سه failure که شبیه model problem به نظر می‌رسند و نیستند — ده دقیقه اینجا، یک ماه بعد صرفه‌جویی می‌کند:

و requirement روی همه این‌ها: این تصمیم بدون evaluation set قابل‌گرفتن نیست، و vendorی که fine-tune می‌فروشد خودش این را می‌گوید. راهنمای OpenAI با این جمله شروع می‌شود: «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»، و اضافه می‌کند اگر پنجاه مثال خوب هیچ تغییری ندهد، مسئله task یا prompt است، نه حجم data.¹ بیست سؤال، که این فصل استفاده کرد، یک mechanism را نشان می‌دهد و نمی‌تواند supplier انتخاب کند — فصل 4 اندازه گرفت چرا، و اینکه وقتی بیست case همه چیزی است که دارید چه باید کرد — تکرارشان کنید، pair کنید، و spread بین runها را اندازه بگیرید — فصل 29 است.

چهار ستون، و فقط آخری تصمیم می‌گیرد:

قاعده‌ای که از آن بیرون می‌آید، و آن‌قدر کوتاه است که نگهش دارید: با prompt شروع کنید؛ وقتی factها حرکت می‌کنند بازیابی اضافه کنید؛ فقط وقتی fine-tune کنید که اندازه گرفته باشید چیزی که هنوز کم دارید shape است، نه fact — و قبل از انجامش پاسخ را قیمت‌گذاری کنید، نه prompt را.

نسخه ناراحت‌کننده، برای هر کسی که از قبل تصمیمش را گرفته آمده: در case اندازه‌گیری‌شده این فصل، fine-tuning واقعاً بالای چهار هزار سؤال در ماه ارزان‌ترین مسیر است، و از نظر factها هنوز نمی‌تواند بهتر از پاسخ دادن CLAUDE.md به همه‌چیز باشد.

هر قیمتی اینجا per token بوده، و هر مسیر راهی متفاوت برای چیدن tokenها. این قرار است دیگر درست نباشد.

فصل 21 متن را ترک می‌کند. تصویری که وارد مدل می‌شود string نیست، gridی از patchها با token countی است که شما انتخاب نکرده‌اید؛ یک دقیقه گفتار نزد یک provider برحسب ثانیه صورتحساب می‌شود و نزد دیگری با audio token؛ synthetic speech با character فروخته می‌شود، transcription با دقیقه، raw compute با GPU-second. سؤالی که این فصل با یک تابع هزینه جواب داد — کدام ارزان‌تر است؟ — حتی نمی‌شود پرسید تا وقتی unitها یکی شوند، و هیچ calculatorی در اینترنت normaliseشان نمی‌کند.

همچنین همان‌جاست که training دوباره ظاهر می‌شود: یک image adapter با trigger word، و voiceی که از یک sample clone شده. این سؤالی را بالا می‌آورد که فصل بعد با آن شروع می‌شود، و rhetorical نیست: اگر fine-tuning یک language model تقریباً همیشه خرید غلط است، چرا fine-tuning یک image model تقریباً همیشه خرید درست است؟

هر قیمت، threshold و multiplier در این فصل در 7 سپتامبر 2026 از صفحه خود provider خوانده شده و با همان تاریخ نقل شده، چون همه‌شان تغییر خواهند کرد. اعداد اندازه‌گیری‌شده — token countها، chunk sizeها، retrieval sizeها، training loss، scoreها، latencyها و شمارش‌های version-history — روی یک ماشین در همان روز تولید شده‌اند و از corpus توصیف‌شده در بالا قابل‌بازتولیدند.

آزمایش‌های محلی از Qwen/Qwen2.5-0.5B-Instruct با greedy decoding استفاده کردند، پس دقیقاً reproduce می‌شوند؛ adapter همان کلاس دوازده‌خطی چاپ‌شده در بالا است، با rank 8 روی q_proj و v_proj. corpus مستندات Markdown trackشده یک repository نرم‌افزاری فعال است، به‌استثنای دو log append-only، و نرخ تغییرش از تاریخچه نسخه همان repository شمرده شد.