Fine-tuning, извличане или prompt? Решението е икономическо

„Трябва ли да правим fine-tuning?“ се задава сякаш е въпрос за модел. Това е въпрос за бюджет, с форма, на която никой benchmark не отговаря: какво се плаща веднъж, какво се плаща на въпрос и какво се плаща отново всеки път, когато светът се промени.

Трите маршрута също не са три начина да се направи едно и също, и доставчиците го казват по-ясно от повечето blog posts. Собствената таблица на OpenAI за какво supervised fine-tuning е най-подходящо изброява четири употреби: classification, nuanced translation, generating content in a specific format и correcting instruction-following failures.¹ Нито една не е „да научи модела на нещо, което не знае“. Обобщението на ползата е, че „можете да използвате по-кратки prompts с по-малко примери и context data, което спестява token разходи в мащаб и може да намали latency“ — аргумент за фактурата от компанията, която продава функцията.

И така:

• Fine-tuning учи форма и поведение. Тон, формат, формата на отговор, граница, която можете да демонстрирате, но не и да опишете. Най-силната публикувана версия е Superficial Alignment Hypothesis на LIMA: знанието идва от pretraining, alignment най-вече учи в коя sub-distribution от формати да се говори — затова хиляда подбрани примера са били достатъчни там.²
• Retrieval доставя факти, които се променят. То е единственото от трите, при което редакция в документацията стига до отговора, без да се пипа моделът.
• Prompting покрива повечето реални случаи и е честният baseline. In-context learning е default от Language Models are Few-Shot Learners: задачата се демонстрира вътре в prompt и нито едно weight не се мести.³

Две измерени статии затварят вратата пред грешката по средата. Ovadia и колеги сравняват вкарването на knowledge чрез unsupervised fine-tuning с вкарването му чрез retrieval и retrieval печели последователно, включително върху факти, които base model вече е виждал в pretraining.⁴ Gekhman и колеги измерват щетата: примерите, които въвеждат ново knowledge, се fitted бавно, и когато моделът най-накрая ги fitted, hallucination rate върху други въпроси се повишава.⁵ Да се преподават факти чрез fine-tuning не просто не успява; то влошава отговорите по въпроси, върху които не сте тренирали.

Тази половина е решена. Икономическата половина не е, и тя е останалата част от главата.

Един случай, изпълнен по три начина: technical support върху собствената ви документация, която се променя всяка седмица.

Корпусът е реален и е на този диск: 23 Markdown документа, които едно работещо софтуерно repository пази като вътрешна документация — build guide, brand rules, translation brief, десет service manuals, performance и security notes. Измерено с 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, така че и трите маршрута са реално достъпни. При десет милиона решението е взето вместо вас и то е retrieval.

Сега работата, която върши думата „седмично“. Churn на документацията обикновено се твърди; тук е преброен от version history на това repository:

Документите се движат приблизително през седмица. Видимите за потребителя strings — за които support desk реално получава въпроси — са се движили всяка седмица, откакто съществуват, с около двадесет commits седмично. Какъвто и маршрут да изберем, той трябва да оцелее това, и „колко често се променя нещото, върху което сте тренирали?“ се оказва число в собственото ви repository, а не мнение.

Двадесет реалистични support въпроса бяха написани спрямо този корпус, по един на topic, и всяка стойност по-долу е изчислена върху тези двадесет.

Най-простото нещо, което работи: сложете целия корпус в 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-а е допускане, избрано в диапазона на assistant turns, които Глава 16 таксува. Това е единствената стойност тук, която не беше изпълнена, прилага се еднакво към трите маршрута и разделът за break-even показва точно колко се измества заключението, когато я промените.

При тарифите, прочетени от страницата на доставчика на 7 септември 2026 — $1.50 на милион input token-и, $9.00 на милион output⁶ — това е $0.066317 на въпрос. Плащате за повторно четене на четиридесет и три хиляди token-а, за да отговорите на тринадесет.

Решението от Глава 16 се прилага директно: корпусът е стабилен и е отпред, така че е перфектен cache prefix, а прочитането му обратно струва една десета — $0.007864 на въпрос, спад от 88 %. Предупреждението от Глава 16 също се прилага, във формата, която тази глава маркира, но не остойности. Този доставчик не начислява write premium; начислява наем. Explicit cache струва $0.000001 на stored token на час,⁶ така че поддържането на 43,298 token-а топли струва

независимо дали някой задава нещо. Това са $189.78 за шест месеца, за празна стая. Разделете наема на спестяването на въпрос и условието излиза в един ред: caching на този корпус се изплаща над 0.74 въпроса на час — 546 на месец, след като се брои и седмичният cache rebuild. Под това функцията, която сте включили, за да пестите пари, ги губи.

Същият маршрут, същият код, един flag, пет пъти по-висока сметка. Глава 16 намери версия на това, причинена от timestamp на грешното място; тук нищо не е грешно освен traffic-а. Cache е залог върху volume, и при този доставчик го правите на час.

Retriever-ът от Глава 19, непроменен: режете по section boundaries с contextual header, index, слагате четирите най-добри extracts в 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.0070 за build при $0.15 на милион embedding token-и⁶ — по-малко от стойността на три въпроса — и същите $0.0070 за rebuild от нулата всеки път, когато документацията се промени. Rebuild на целия index всяка седмица в продължение на шест месеца струва осемнадесет цента.

Едно нещо си заслужава паузата. Retrieval унищожава prompt caching. Стабилният prefix вече е 140-token system instruction; от token 141 prompt се различава при всяко извикване, защото extracts се избират според въпроса. А 140 token-а е под всеки cache minimum, цитиран в Глава 16. Така маршрут две изобщо не може да бъде cached, което звучи лошо и не е: да не cached-вате 1,037 token-а е по-евтино, отколкото да cached-вате 43,298.

Това е общо правило, което си струва да се носи нататък: двете големи техники за пестене на token-и са взаимно изключващи се върху същото съдържание, и печели тази, която премахва повече token-и. Retrieval премахва 97.6 % от тях.

Тренирайте върху двеста примера в house style, после задавайте въпроси без никаква прикачена документация.

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

Training струва 24,389 × 3 × $10.00 на милион = $0.7317. Това е цялата construction cost, по-малко от чаша кафе, което е точно причината толкова много екипи да я платят, преди да проверят дали помага.

Сега капанът, и той е причината тази глава да съществува. Fine-tuned модел не струва същото за изпълнение като base model. Pricing страницата го казва в едно изречение: „for model inference starting from Gemini 3, tuned model endpoint prediction price will be 1.5 times of the base model.“⁶ Не training. Inference, върху всеки token, докато моделът живее.

Затова го сложете във формула. Нека $p_i$ и $p_o$ са базовите input и output цени, $m$ е tuned multiplier, $L_R$ е prompt length на маршрута, който заменяте, $L_F$ е prompt length след fine-tuning, а $O$ е answer length. Fine-tuning е по-евтин на въпрос само когато

Първият член е очевиден: новият ви кратък prompt, с надценка. Вторият не е, и там отиват парите — надценката върху отговора, която няма нищо общо с вашия prompt и която training не може да съкрати. С измерените числа — $m = 1.5$, $L_F = 28$, $O = 150$, $p_o/p_i = 6$ — прагът е

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 са answer surcharge, не prompt. Замяната на по-кратък prompt от това е по-скъпа на въпрос, завинаги, при всякакъв volume; и прагът расте линейно с това колко говори assistant-ът, така че такъв, който пише дълги отговори, никога не може да fine-tune-не пътя си към по-евтин token, колкото и prompt да изтрие.

Същият факт от другия край е изречението за запомняне. От $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 моделът не е различна ценова листа, а същата умножена:

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 ред е целият аргумент от предишния раздел, написан като код: multiplier-ът пада и върху output.

Шест месеца, с документация, refresh-ната седмично:

И crossovers, които са четирите числа, от които бюджетът реално има нужда:

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

Прочетете първите две заедно, защото те са смисълът на главата. Стационарен корпус прави fine-tuning да се изплати за сто и петдесет въпроса; корпус, който се променя седмично, премества същия crossover с фактор двадесет и седем, и нищо в модела не се е променило — само колко често плащате за него отново. Construction cost е бележка под линия; maintenance cost е решението.

Ако сега заключите, че натоварен support desk трябва да fine-tune-ва, аритметиката е съгласна с вас. Все още е грешно, и следващият раздел обяснява защо.

Cost sheet има една колона, която не може да изчисли, затова този раздел изпълнява fine-tune: локално, върху малък open model, с adapter, написан на ръка, вместо взет от library. Глава 11 изгради LoRA; ето я тук, върху q_proj и v_proj на всички 24 layers на 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 примера идват механично от корпуса, така че се възпроизвеждат: въпросът е section heading, превърнат във въпрос, отговорът е собствен текст на тази section в строг house style — един ред, започващ с Short answer:, един ред, започващ с Source: с file path. Форматът е формата, която се преподава; path е фактът. После две числа върху двадесет held-out въпроса: излиза ли отговорът в house style и назовава ли файла, който наистина отговаря на въпроса?

Два baseline-а правят таблицата четима, и двата са настояване от Глава 4, а не afterthought. Десет от двадесетте правилни отговора са един и същ файл, така че модел, който игнорира въпроса и винаги отговаря CLAUDE.md, получава 10/20. И retriever-ът има собствен ceiling: в тези двадесет въпроса четирите му extracts съдържат правилния файл 14 пъти и го rank-ват първи 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 на процесор без никаква graphics card наблизо.

Фактите не бяха. Осем от двадесет не се различава от десетте, които получавате, като игнорирате въпроса изцяло, и интервалът от Глава 4 върху двадесет sample-а го казва на глас. Тези file paths бяха в training data три пъти; това, което излезе, беше навикът да се завършва с правдоподобно изглеждащ ред Source:. На въпроса в началото на тази глава fine-tuned моделът отговори Short answer: 10.x . . . и цитира CLAUDE.md. Правилният отговор, който е в CLAUDE.md, е 18.17.0.

И после формата се счупи, което е редът, оправдаващ експеримента. Подайте на fine-tuned модела хиляда token-а retrieved extracts — prompt форма, която той никога не е виждал, защото всеки training prompt беше двадесет и осем token-а — и house style пада от 19/20 до 1/20. На въпроса в началото на тази глава той отговаря 18.17.0 — правилно, и без нито един елемент от формата, за която е бил трениран. Така че fine-tuning не научи формат; той научи формат, conditional on prompts в training set-а, и първият prompt, който изглеждаше различно, отнесе формата със себе си. Каквото и да fine-tune-вате, то става единственото input distribution, в което моделът ви е добър, и никой не слага това в spreadsheet-а.

Последна бележка за metric, сочеща право към Глава 29: „correct source“ оценява форма и факт заедно, затова и двата retrieval реда изглеждат ужасно, въпреки че и двата модела получиха правилно факта за този въпрос. Едно end-to-end число криеше три неща — retriever с 14/20 recall, 0.5B reader и citation format — и изборът кое да поправите означава да ги разделите преди измерване, не след това.

Сега колоната, която доставчиците попълват вместо вас. Fine-tuned модел не е asset, който притежавате; той е lease върху чужд base model, с крайна дата, отпечатана върху него. На 7 септември 2026 section-ът за fine-tuning на pricing страницата на OpenAI съдържаше това notice изцяло:

OpenAI постепенно закрива fine-tuning platform. Platform вече не е достъпна за нови потребители, но съществуващите потребители на fine-tuning platform ще могат да създават training jobs през следващите месеци. Всички fine-tuned модели ще останат достъпни за inference, докато base models им бъдат deprecated.⁷

Timeline-ът е датиран до ден: 7 май 2026, затворено за организации, които никога не са правили fine-tuning; 2 юли 2026, затворено за тези, които не са изпълнявали inference върху fine-tuned модел в рамките на шестдесет дни; 6 януари 2027, никакви нови jobs.⁸ Същата страница планира 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, което е учтив начин да се каже: тренирайте го отново.

Другият frontier доставчик никога не ви е продавал lease. Документационният index на Anthropic изброява 699 страници и нито една не е за fine-tuning; model-customisation sections на pricing страницата на Bedrock покриват Amazon Nova, Amazon Titan, Cohere, Meta и OpenAI open-weight models, и никакъв Claude.⁹¹⁰ Ако архитектурата ви зависи от fine-tune, едно от трите frontier families просто не е достъпно за вас при никакъв бюджет.

Self-hosting заменя lease върху модел с lease върху машина, и AWS прави тази аритметика на собствената си страница: една model unit от provisioned throughput за customised model, one-month commitment, е „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 на месец за една карта, която трябва да е включена независимо дали някой пита нещо. Целият retrieval маршрут при десет хиляди въпроса месечно е $174.52 за шест месеца.

Тук LoRA заслужава мястото си като бюджетен аргумент, а не технически. Измерено върху същия модел, rank-16 adapter върху attention и feed-forward layers е 8,798,208 параметъра — 1.781 % от модела, 17.6 MB в bfloat16 — срещу 0.988 GB base weights, а optimiser и gradient state са 140.77 MB, докато full fine-tuning изисква 7.90 GB, фактор 56. Последствието не е по-евтин training, а това, че един loaded base model може да обслужва много adapters, което е единственият начин фиксираната цена на GPU да се раздели на нещо. Managed training го отразява: $0.48 на милион token-и low-rank до 16B срещу $0.54 full, с $4.00 minimum per job.¹¹ Този floor е детайлът. При 24,389 token-а за три epochs, всяко retraining върху този корпус се таксува $4.00 вместо $0.04, до които стига сметката — $104 minimums през двадесет и шест седмични runs, за деветдесет и един цента аритметика.

Още две колони, които се появяват само във фактурата.

Data residency струва около десет процента, и двама доставчици са съгласни за числото. OpenAI начислява „10 % uplift“ върху data-residency endpoints за модели, пуснати на или след 5 март 2026;⁷ Vertex ценообразува non-global endpoints на $1.65 срещу $1.50, същите десет процента.⁶ Сложете това срещу петдесетте процента, които tuned endpoint струва, и фолклорът се обръща: residency е евтино, а fine-tuning не е — и fine-tuning не е private опцията така или иначе, защото корпусът стига до доставчика и в двата случая, веднъж при training time вместо веднъж на call.

Най-експлицитната цена, поставяна някога върху вашите данни, е на същата страница, която изброява един fine-tuned модел два пъти: с enabled data sharing, inference е точно наполовина — $2.00 срещу $4.00 input, $8.00 срещу $16.00 output.⁷ Да позволите на доставчика да запази това, което сте изпратили, струва 50 % discount, което ви казва колко струва то за тях.

Distillation — training на ваш малък модел върху отговорите на голям — обикновено се предлага като изход и от двете. Остойностете го и не е, защото teacher е системата, която се опитвате да замените: произвеждането на двеста training примера чрез питане на retrieval маршрута с двеста въпроса струва 200 × $0.002906 = $0.58, върху $0.73 за training върху тях. Distillation е нещо, което правите след като retrieval pipeline работи, за да го направите по-евтин, и наследява всеки факт, който retriever-ът е сбъркал.

Парите са видимата половина. Другата идва като чакане, със същата причина като сметката: моделът прочита целия prompt, преди да каже дума. Глава 13 измери prefill срещу decode върху модел, който можехте да докоснете; ето същото измерване, един run, една машина, спрямо prompt length:

Абсолютните числа принадлежат на 0.5B модел върху шестнадесет CPU threads и не казват нищо за hosted frontier model. Формата се пренася точно: prefill расте с prompt length, а цената на token се покачва, когато quadratic term от Глава 9 започне да личи — 4.79 ms при хиляда token-а срещу 6.04 ms при осем хиляди, 26 % penalty само за това, че е по-дълго.

Последицата за трите маршрута е директна. Маршрут едно prefills четиридесет и три хиляди token-а на въпрос, и cache hit е това, което го прави поносим — Глава 16 обясни защо: cache read заменя prefill work, така че купува latency и пари в една transaction. Маршрут две prefills хиляда и първо добавя round trip до index. Маршрут три prefills двадесет и осем и не добавя нищо, което го прави измеримо най-бързият от трите в отговарянето. Просто отговаря на грешното нещо.

Три failure-а, които изглеждат като model problems, а не са — десет минути тук спестяват месец по-късно:

И изискването над всичко това: това решение не може да се вземе без evaluation set, и доставчикът, продаващ fine-tune, го казва. Guide-ът на 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 volume.¹ Двадесет въпроса, което използва тази глава, показват механизъм и не могат да изберат supplier — Глава 4 измери защо, а какво да правите, когато двадесет cases са всичко, което имате — повторете ги, pair-нете ги и измерете spread между runs — е Глава 29.

Четири колони, и само последната решава:

Правилото, което излиза от това, е достатъчно кратко за запомняне: започнете с prompt; добавете retrieval, когато фактите се движат; fine-tune-вайте само когато сте измерили, че това, което все още ви липсва, е форма, не факт — и остойностете отговора, не prompt, преди да го направите.

Неудобната версия, за всеки, който е дошъл вече решил: в измерения случай в тази глава fine-tuning е най-евтиният маршрут над четири хиляди въпроса месечно, а по фактите все още не може да победи отговарянето с CLAUDE.md на всичко.

Всяка цена тук беше на token, и всеки маршрут беше различен начин за подреждане на token-и. Това предстои да спре да е вярно.

Глава 21 напуска текста. Изображение, влизащо в модел, не е string, а grid от patches с token count, който не сте избрали; spoken minute се таксува по секунда при един доставчик и по audio token при друг; synthetic speech се продава по character, transcription по минута, raw compute по GPU-second. Въпросът, на който тази глава отговори с една cost function — кое е по-евтино? — дори не може да бъде зададен, докато units не съвпаднат, и никой calculator в интернет не ги normalise-ва.

Там и training се появява отново: image adapter с trigger word и voice, cloned от sample. Което повдига въпроса, с който следващата глава започва, и той не е реторичен: ако fine-tuning на language model почти винаги е грешната покупка, защо fine-tuning на image model почти винаги е правилната?

Всяка цена, праг и multiplier в тази глава беше прочетена от собствената страница на доставчика на 7 септември 2026 и е цитирана с тази дата, защото всички ще се променят. Измерените стойности — token counts, chunk sizes, retrieval sizes, training loss, scores, latencies и version-history counts — бяха произведени на една машина в същия ден и са възпроизводими от корпуса, описан по-горе.

Локалните експерименти използваха Qwen/Qwen2.5-0.5B-Instruct с greedy decoding, така че се възпроизвеждат точно; adapter-ът е дванадесетредовият class, отпечатан по-горе, при rank 8 върху q_proj и v_proj. Корпусът е tracked Markdown документацията на едно работещо софтуерно repository, без два append-only logs, а rate-ът на промяна беше преброен от version history на това repository.