Fine-Tuning, אחזור או Prompt? ההחלטה היא כלכלית

"האם כדאי לעשות fine-tuning?" נשאל כאילו זו שאלה על מודל. זו שאלה על תקציב, עם צורה ששום benchmark לא עונה עליה: מה משולם פעם אחת, מה משולם לכל שאלה, ומה משולם שוב בכל פעם שהעולם זז.

שלושת ה-routes הם גם לא שלוש דרכים לעשות דבר אחד, והספקים אומרים זאת בפשטות רבה יותר מרוב הפוסטים. הטבלה של OpenAI עצמה לגבי מה supervised fine-tuning הכי מתאים לו מונה ארבעה שימושים: סיווג, תרגום ניואנסי, יצירת תוכן בפורמט מסוים, ותיקון כשלים בציות להוראות.¹ אף אחד מהם אינו "ללמד את המודל משהו שהוא לא יודע". סיכום התועלת שלה הוא ש-"you can use shorter prompts with fewer examples and context data, which saves on token costs at scale and can be lower latency" — טיעון על החשבונית, מהחברה שמוכרת את הפיצ'ר.

אז:

• Fine-tuning מלמד צורה והתנהגות. טון, פורמט, מבנה של תשובה, גבול שאפשר להדגים אבל לא לתאר. הגרסה החזקה ביותר שפורסמה היא Superficial Alignment Hypothesis של LIMA: ידע מגיע מ-pretraining, ו-alignment בעיקר מלמד באיזו תת-התפלגות של פורמטים לדבר — ולכן הספיקו שם אלף דוגמאות מאוצרות.²
• אחזור מספק עובדות שמשתנות. הוא היחיד מבין השלושה שבו עריכה לתיעוד מגיעה לתשובה בלי לגעת במודל.
• Prompting מכסה את רוב המקרים האמיתיים, והוא baseline כן. In-context learning הוא ברירת המחדל מאז Language Models are Few-Shot Learners: המשימה מודגמת בתוך ה-prompt ושום משקל לא זז.³

שני מאמרים מדודים סוגרים את הדלת על הטעות שבאמצע. Ovadia ועמיתיו השוו הזרקת ידע באמצעות fine-tuning לא מפוקח מול הזרקתו באמצעות אחזור, והאחזור ניצח בעקביות, כולל על עובדות שמודל הבסיס כבר ראה ב-pretraining.⁴ Gekhman ועמיתיו מדדו את הנזק: דוגמאות שמכניסות ידע חדש מותאמות לאט, וכשהמודל סוף סוף מתאים אותן, שיעור ההזיות שלו על שאלות אחרות עולה.⁵ לימוד עובדות באמצעות fine-tuning לא רק נכשל; הוא מדרדר תשובות שלא אימנתם עליהן.

החצי הזה סגור. החצי הכלכלי לא, והוא שאר הפרק.

מקרה אחד, מופעל בשלוש דרכים: תמיכה טכנית על התיעוד שלכם, שמשתנה בכל שבוע.

הקורפוס אמיתי ונמצא על הדיסק הזה: 23 מסמכי Markdown שמאגר תוכנה פעיל מחזיק כתיעוד פנימי — מדריך הבנייה, כללי המותג, בריף התרגום, עשרה מדריכי שירות, הערות ביצועים ואבטחה. נמדד עם o200k_base, הקידוד מ-פרק 7:

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

ארבעים ושלושה אלף tokens הם גודל נוח להחלטה הזאת: הוא נכנס לכל חלון מודרני, כך שכל שלושת ה-routes באמת זמינים. בעשרה מיליון ההחלטה כבר מתקבלת בשבילכם, והיא אחזור.

עכשיו העבודה שהמילה "weekly" עושה. לרוב רק טוענים שתיעוד משתנה; כאן זה נספר, מתוך היסטוריית הגרסאות של אותו מאגר:

המסמכים זזים בערך פעם בשבועיים. המחרוזות שהמשתמש רואה — שזה מה שדלפק תמיכה באמת נשאל עליו — זזו בכל שבוע שבו הן התקיימו, בערך עשרים commits בשבוע. כל route שנבחר צריך לשרוד את זה, ו-"באיזו תדירות הדבר שאימנתם עליו משתנה?" מתברר כמספר במאגר שלכם, לא כדעה.

נכתבו עשרים שאלות תמיכה ריאליסטיות מול הקורפוס הזה, אחת לכל נושא, וכל נתון למטה מחושב על פני העשרים האלה.

הדבר הפשוט שעובד: לשים את כל הקורפוס ב-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 tokens זו הנחה, שנבחרה בתוך הטווח של פניות assistant שפרק 16 חייב עליהן. זה הנתון היחיד כאן שלא הורץ, הוא מיושם באופן זהה על כל שלושת ה-routes, וסעיף נקודת האיזון מראה בדיוק כמה המסקנה זזה כשמשנים אותו.

לפי התעריפים שנקראו מדף הספק ב-7 בספטמבר 2026 — $1.50 למיליון input tokens, $9.00 למיליון output⁶ — זה $0.066317 לשאלה. אתם משלמים כדי לקרוא מחדש ארבעים ושלושה אלף tokens כדי לענות על שלושה עשר.

התיקון של פרק 16 חל ישירות: הקורפוס יציב והוא בהתחלה, ולכן הוא prefix מושלם ל-cache, וקריאתו חזרה עולה עשירית — $0.007864 לשאלה, קיצוץ של 88%. גם האזהרה של פרק 16 חלה, בצורה שהפרק ההוא סימן ולא תמחר. הספק הזה לא גובה פרמיית כתיבה; הוא גובה שכירות. cache מפורש עולה $0.000001 לכל token מאוחסן לשעה,⁶ כך שהחזקת 43,298 tokens חמים עולה

בין אם מישהו שואל משהו ובין אם לא. זה $189.78 במשך שישה חודשים, לחדר ריק. חלקו את השכירות בחיסכון לכל שאלה והתנאי יוצא בשורה אחת: caching לקורפוס הזה מחזיר את עצמו מעל 0.74 שאלות לשעה — 546 בחודש אחרי שסופרים גם בניית cache שבועית מחדש. מתחת לזה, הפיצ'ר שהפעלתם כדי לחסוך כסף מפסיד אותו.

אותו route, אותו קוד, דגל אחד, חשבון גדול פי חמישה. פרק 16 מצא גרסה של זה שנגרמה מ-timestamp במקום הלא נכון; כאן שום דבר לא שגוי חוץ מהתעבורה. Cache הוא הימור על נפח, ואצל הספק הזה שמים אותו לפי שעה.

מנגנון האחזור של פרק 19, ללא שינוי: חיתוך על גבולות מקטעים עם כותרת הקשרית, אינדוקס, הכנסת ארבעת הקטעים הטובים ביותר ל-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 tokens מאשר route ראשון, במחיר $0.002906 לשאלה. בניית האינדקס עולה $0.0070 ב-$0.15 למיליון embedding tokens⁶ — פחות משלוש שאלות — ואותו $0.0070 כדי לבנות אותו מאפס בכל פעם שהתיעוד משתנה. בנייה מחדש של כל האינדקס מדי שבוע במשך שישה חודשים עולה שמונה-עשרה סנט.

דבר אחד שווה לעצור עליו. אחזור הורס prompt caching. ה-prefix היציב הוא עכשיו הוראת system של 140 tokens; מ-token 141 ה-prompt שונה בכל קריאה, כי הקטעים נבחרים לפי השאלה. ו-140 tokens מתחת לכל מינימום cache שפרק 16 ציטט. לכן route שני לא ניתן ל-caching בכלל, וזה נשמע רע ולא כזה: לא לעשות caching ל-1,037 tokens זול יותר מלעשות caching ל-43,298.

זה כלל כללי שכדאי לשאת: שתי טכניקות החיסכון הגדולות ב-tokens סותרות זו את זו על אותו תוכן, והמנצחת היא זו שמסירה יותר tokens. אחזור מסיר 97.6% מהם.

אמנו על מאתיים דוגמאות בסגנון הבית, ואז שאלו שאלות בלי תיעוד מצורף בכלל.

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

האימון עולה 24,389 × 3 × $10.00 למיליון = $0.7317. זו כל עלות ההקמה, פחות מכוס קפה, וזה בדיוק למה כל כך הרבה צוותים משלמים אותה לפני שבודקים אם זה עוזר.

עכשיו המלכודת, והיא הסיבה שהפרק הזה קיים. מודל שעבר fine-tuning לא עולה כמו מודל הבסיס שלו בזמן הרצה. דף התמחור אומר זאת במשפט אחד: "for model inference starting from Gemini 3, tuned model endpoint prediction price will be 1.5 times of the base model."⁶ לא האימון. ה-inference, על כל token, כל עוד המודל חי.

אז נכניס את זה לנוסחה. יהי $p_i$ ו-$p_o$ מחירי ה-input וה-output הבסיסיים, $m$ המכפיל של המודל המכוונן, $L_R$ אורך ה-prompt של ה-route שאתם מחליפים, $L_F$ אורך ה-prompt אחרי fine-tuning, ו-$O$ אורך התשובה. Fine-tuning זול יותר לכל שאלה רק כאשר

האיבר הראשון ברור: ה-prompt הקצר החדש שלכם, עם תוספת המחיר. השני לא, ושם נמצא הכסף — התוספת על התשובה, שאין לה שום קשר ל-prompt שלכם ושאימון לא יכול לקצר. עם המספרים שנמדדו — $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 tokens — שמתוכם 450 הם תוספת המחיר על התשובה, לא ה-prompt. החלפת prompt קצר מזה יקרה יותר לכל שאלה, לנצח, בכל נפח; והסף גדל ליניארית עם כמות המילים שה-assistant שלכם כותב, כך ש-assistant שכותב תשובות ארוכות לעולם לא יוכל לעשות fine-tuning בדרך ל-token זול יותר, לא משנה כמה prompt הוא מוחק.

אותה עובדה מהקצה השני היא המשפט שכדאי לזכור. מתוך $0.002088 לשאלה של route ה-fine-tuned, 97.0% הם התשובה. Fine-tuning ממטב את שלושת האחוזים שנותרו.

ארבעה מספרים מתארים כל אחד מה-routes האלה: מה משלמים פעם אחת, מה משלמים כשהתיעוד משתנה, מה משלמים לשעה בלי קשר לכלום, ומה משלמים לכל שאלה. זה מרחיב את 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);
}

המודל המכוונן אינו מחירון אחר, הוא אותו מחירון מוכפל:

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

השורה המודגשת הזאת היא כל הטיעון של הסעיף הקודם כתוב כקוד: המכפיל נוחת גם על output.

שישה חודשים, עם רענון שבועי של התיעוד:

ונקודות החציה, שהן ארבעת המספרים שתקציב באמת צריך:

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 להחזיר את עצמו במאה וחמישים שאלות; קורפוס שמשתנה מדי שבוע מזיז את אותה נקודת חציה פי עשרים ושבע, ושום דבר במודל לא השתנה — רק התדירות שבה אתם משלמים עליו שוב. עלות ההקמה היא הערת שוליים; עלות התחזוקה היא ההחלטה.

אם עכשיו אתם מסיקים שדלפק תמיכה עמוס צריך לעשות fine-tuning, האריתמטיקה מסכימה איתכם. זה עדיין שגוי, והסעיף הבא מסביר למה.

לגיליון העלויות יש עמודה אחת שהוא לא יכול לחשב, ולכן הסעיף הזה מריץ את ה-fine-tune: מקומית, על מודל פתוח קטן, עם adapter שנכתב ידנית במקום להימשך מספרייה. פרק 11 בנה LoRA; הנה הוא, על ה-q_proj וה-v_proj של כל 24 השכבות של Qwen2.5-0.5B-Instruct בדרגה 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

מאתיים דוגמאות האימון מגיעות מכנית מהקורפוס, ולכן הן ניתנות לשחזור: השאלה היא כותרת מקטע שהפכה לשאלה, והתשובה היא הטקסט של אותו מקטע עצמו בסגנון בית נוקשה — שורה אחת שמתחילה ב-Short answer:, שורה אחת שמתחילה ב-Source: עם נתיב הקובץ. הפורמט הוא הצורה שנלמדת; הנתיב הוא העובדה. ואז שני מספרים על עשרים שאלות held-out: האם התשובה יוצאת בסגנון הבית, והאם היא מציינת את הקובץ שבאמת עונה לשאלה?

שני baselines הופכים את הטבלה לקריאה, ושניהם הם ההתעקשות של פרק 4, לא מחשבה מאוחרת. עשר מתוך עשרים התשובות הנכונות הן אותו קובץ, ולכן מודל שמתעלם מהשאלה ותמיד עונה CLAUDE.md מקבל 10/20. וגם למנגנון האחזור יש תקרה משלו: על פני עשרים השאלות האלה, ארבעת הקטעים שלו מכילים את הקובץ הנכון 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% מהמודל — בחמש דקות אימון על מעבד בלי כרטיס גרפי באופק.

העובדות לא. שמונה מתוך עשרים אינו ניתן להבחנה מעשר שמקבלים אם מתעלמים לגמרי מהשאלה, והמרווח של פרק 4 על עשרים דגימות אומר זאת בקול. נתיבי הקבצים האלה היו בנתוני האימון שלוש פעמים; מה שיצא היה הרגל לסיים בשורת Source: שנראית סבירה. כשנשאל את השאלה שבראש הפרק הזה, המודל שעבר fine-tuning ענה Short answer: 10.x . . . וציטט את CLAUDE.md. התשובה הנכונה, שנמצאת ב-CLAUDE.md, היא 18.17.0.

ואז הצורה נשברה, וזו השורה שמצדיקה את הניסוי. תנו למודל שעבר fine-tuning אלף tokens של קטעים שאוחזרו — צורת prompt שהוא מעולם לא ראה, כי כל prompt אימון היה בן עשרים ושמונה tokens — וסגנון הבית קורס מ-19/20 ל-1/20. בשאלה שבראש הפרק הזה הוא עונה 18.17.0 — נכון, ובלי שום דבר מהפורמט שעליו אומן. אז fine-tuning לא לימד פורמט; הוא לימד פורמט בתנאי שה-prompts נראים כמו אלה שבסט האימון, וה-prompt הראשון שנראה אחרת לקח איתו את הפורמט. כל מה שאתם עושים עליו fine-tuning הופך להתפלגות הקלט היחידה שהמודל שלכם טוב בה, ואף אחד לא מכניס את זה לגיליון.

הערה אחרונה על המדד, שמצביעה ישר ל-פרק 29: "מקור נכון" מציינן צורה ועובדה יחד, ולכן שתי שורות האחזור נראות גרועות אף ששני המודלים קיבלו נכון את העובדה של השאלה הזאת. מספר end-to-end אחד הסתיר שלושה דברים — מנגנון אחזור עם recall של 14/20, reader של 0.5B ופורמט ציטוט — ובחירה במה לתקן דורשת להפריד אותם לפני המדידה, לא אחריה.

עכשיו העמודה שהספקים ממלאים בשבילכם. מודל שעבר fine-tuning אינו נכס שבבעלותכם; הוא חוזה שכירות על מודל בסיס של מישהו אחר, עם תאריך סיום מודפס עליו. ב-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.⁷

ציר הזמן מתוארך ליום: 7 במאי 2026, סגור לארגונים שמעולם לא עשו fine-tuning; 2 ביולי 2026, סגור לאלה שלא הריצו inference על מודל שעבר fine-tuning במשך שישים יום; 6 בינואר 2027, אין jobs חדשים בכלל.⁸ אותו דף מתזמן את כיבוי המודלים שעברו fine-tuning עצמם — ft-gpt-3.5-turbo, ft-gpt-4, ft-gpt-4.1-nano, ft-babbage-002, ft-davinci-002 — ב-23 באוקטובר 2026, כל אחד עם מודל בסיס חלופי מומלץ, שזו דרך מנומסת לומר: אמנו אותו שוב.

הספק ה-frontier האחר מעולם לא מכר לכם את חוזה השכירות. אינדקס התיעוד של Anthropic מונה 699 עמודים ואף אחד מהם אינו על fine-tuning; סעיפי התאמת המודלים בדף התמחור של Bedrock מכסים את Amazon Nova, Amazon Titan, Cohere, Meta ומודלים open-weight של OpenAI, ולא Claude.⁹¹⁰ אם הארכיטקטורה שלכם תלויה ב-fine-tune, אחת משלוש משפחות ה-frontier פשוט לא זמינה לכם בשום תקציב.

Self-hosting מחליף שכירות על מודל בשכירות על מכונה, ו-AWS עושה את האריתמטיקה הזאת בדף שלה: יחידת מודל אחת של תפוקה מוקצית למודל מותאם, התחייבות לחודש אחד, היא "1 model unit × $21.18 × 24 hours × 31 days = $15,757.92" בחודש.¹⁰ שכירת המתכת ישירות זולה יותר ולא חינמית — $3.99 לשעת GPU לפי דרישה ל-H100, $1.99 preemptible¹¹ — בערך $2,900 בחודש לכרטיס אחד שחייב להיות למעלה בין אם מישהו שואל משהו ובין אם לא. כל route האחזור בעשרת אלפים שאלות בחודש עולה $174.52 לשישה חודשים.

כאן LoRA מצדיק את מקומו, כטיעון תקציבי ולא טכני. נמדד על אותו מודל, adapter בדרגה 16 מעל attention ושכבות feed-forward הוא 8,798,208 פרמטרים — 1.781% מהמודל, 17.6 MB ב-bfloat16 — מול 0.988 GB של משקלי בסיס, ומצב ה-optimiser וה-gradient שלו הוא 140.77 MB במקום 7.90 GB שנדרשים ל-full fine-tuning, פקטור של 56. התוצאה אינה אימון זול יותר אלא שמודל בסיס טעון אחד יכול לשרת adapters רבים, וזו הדרך היחידה שבה עלות קבועה של GPU מתחלקת במשהו. אימון מנוהל משקף זאת: $0.48 למיליון tokens ב-low-rank עד 16B מול $0.54 מלא, עם מינימום $4.00 לכל job.¹¹ הרצפה הזאת היא הפרט. ב-24,389 tokens לשלושה epochs, כל אימון מחדש על הקורפוס הזה מחויב ב-$4.00 במקום ה-$0.04 שהחישוב נותן — $104 של מינימוםים על פני עשרים ושישה ריצות שבועיות, עבור תשעים ואחד סנט של אריתמטיקה.

עוד שתי עמודות שמופיעות רק בחשבונית.

Data residency עולה בערך עשרה אחוזים, ושני ספקים מסכימים על המספר. OpenAI גובה "a 10 % uplift" על נקודות קצה של data-residency למודלים שיצאו ב-5 במרץ 2026 או אחריו;⁷ Vertex מתמחרת את נקודות הקצה הלא-גלובליות שלה ב-$1.65 מול $1.50, אותם עשרה אחוזים.⁶ שימו זאת מול חמישים האחוזים ש-endpoint מכוונן עולה, והפולקלור מתהפך: residency זול ו-fine-tuning לא — ו-fine-tuning אינו האפשרות הפרטית בכל מקרה, כי הקורפוס מגיע לספק כך או כך, פעם אחת בזמן אימון במקום פעם אחת לכל קריאה.

המחיר המפורש ביותר שהוצמד אי פעם לנתונים שלכם נמצא באותו דף, שמציג מודל אחד שעבר fine-tuning פעמיים: עם שיתוף נתונים מופעל, inference הוא בדיוק חצי — $2.00 מול $4.00 input, $8.00 מול $16.00 output.⁷ לתת לספק לשמור את מה ששלחתם שווה הנחה של 50%, וזה אומר לכם כמה זה שווה לו.

Distillation — אימון מודל קטן משלכם על תשובות של מודל גדול — מוצג בדרך כלל כמוצא משניהם. תמחרו אותו והוא לא, כי המורה הוא המערכת שניסיתם להחליף: יצירת מאתיים דוגמאות אימון באמצעות שאילת route האחזור מאתיים שאלות עולה 200 × $0.002906 = $0.58, נוסף על $0.73 כדי להתאמן עליהן. Distillation הוא משהו שעושים אחרי שצינור האחזור עובד, כדי להפוך אותו לזול יותר, והוא יורש כל עובדה שה-retriever טעה בה.

כסף הוא החצי הנראה. השני מגיע כהמתנה, מאותה סיבה כמו החשבון: המודל קורא את כל ה-prompt לפני שהוא אומר מילה. פרק 13 מדד prefill מול decode על מודל שאפשר לגעת בו; הנה אותה מדידה, ריצה אחת, מכונה אחת, מול אורך prompt:

המספרים המוחלטים שייכים למודל 0.5B על שישה-עשר threads של CPU ואינם אומרים דבר על מודל frontier מתארח. הצורה עוברת בדיוק: prefill גדל עם אורך ה-prompt, והעלות לכל token מטפסת ככל שהאיבר הריבועי של פרק 9 מתחיל להיראות — 4.79 ms באלף tokens מול 6.04 ms בשמונה אלף, קנס של 26% רק על כך שזה ארוך יותר.

התוצאה עבור שלושת ה-routes ישירה. Route ראשון עושה prefill לארבעים ושלושה אלף tokens לכל שאלה, ו-cache hit הוא מה שהופך זאת לנסבל — פרק 16 הסביר למה: קריאת cache מחליפה עבודת prefill, ולכן קונה latency וכסף בעסקה אחת. Route שני עושה prefill לאלף ומוסיף קודם round trip לאינדקס. Route שלישי עושה prefill לעשרים ושמונה ולא מוסיף כלום, מה שהופך אותו מדיד למהיר ביותר מבין השלושה במתן תשובה. הוא פשוט עונה על הדבר הלא נכון.

שלושה כשלים שנראים כמו בעיות מודל ואינם כאלה — עשר דקות כאן חוסכות חודש אחר כך:

והדרישה מעל כל זה: אי אפשר לקבל את ההחלטה הזאת בלי סט הערכה, והספק שמוכר את ה-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", ומוסיף שאם חמישים דוגמאות טובות לא משנות דבר, הבעיה היא המשימה או ה-prompt, לא נפח הנתונים.¹ עשרים שאלות, וזה מה שהפרק הזה השתמש בו, מציגות מנגנון ולא יכולות לבחור ספק — פרק 4 מדד למה, ומה לעשות כשעשרים מקרים הם כל מה שיש לכם — לחזור עליהם, לזווג אותם, ולמדוד את הפיזור בין ריצות — הוא פרק 29.

ארבע עמודות, ורק האחרונה מחליטה:

הכלל שיוצא מזה, והוא קצר מספיק לשמור: התחילו עם ה-prompt; הוסיפו אחזור כשהעובדות זזות; עשו fine-tuning רק כשמדדתם שמה שעדיין חסר לכם הוא צורה, לא עובדה — ותמחרו את התשובה, לא את ה-prompt, לפני שאתם עושים זאת.

הגרסה הלא נוחה, למי שהגיע אחרי שכבר החליט: במקרה המדוד בפרק הזה fine-tuning הוא route הזול ביותר מעל ארבעת אלפים שאלות בחודש, ועל העובדות הוא עדיין לא מצליח לנצח תשובה של CLAUDE.md להכול.

כל מחיר כאן היה לכל token, וכל route היה דרך אחרת לסדר tokens. זה עומד להפסיק להיות נכון.

פרק 21 עוזב את הטקסט. תמונה שנכנסת למודל אינה מחרוזת אלא רשת של טלאים עם מספר tokens שלא אתם בחרתם; דקת דיבור מחויבת לפי שנייה אצל ספק אחד ולפי audio token אצל אחר; דיבור סינתטי נמכר לפי תו, תמלול לפי דקה, compute גולמי לפי GPU-second. את השאלה שהפרק הזה ענה עליה עם פונקציית עלות אחת — מה זול יותר? — אי אפשר אפילו לשאול עד שהיחידות תואמות, ואין מחשבון באינטרנט שמנרמל אותן.

זה גם המקום שבו האימון מופיע שוב: image adapter עם מילת trigger, וקול משוכפל מדגימה. וזה מעלה את השאלה שהפרק הבא נפתח בה, והיא לא רטורית: אם fine-tuning למודל שפה הוא כמעט תמיד רכישה שגויה, למה fine-tuning למודל תמונה הוא כמעט תמיד הרכישה הנכונה?

כל מחיר, סף ומכפיל בפרק הזה נקראו מדף הספק עצמו ב-7 בספטמבר 2026 ומצוטטים עם התאריך הזה, כי כולם יזוזו. הנתונים המדודים — ספירות tokens, גדלי chunks, גדלי אחזור, הפסד אימון, ציונים, latencies וספירות היסטוריית גרסאות — הופקו על מכונה אחת באותו יום וניתנים לשחזור מהקורפוס שתואר למעלה.

הניסויים המקומיים השתמשו ב-Qwen/Qwen2.5-0.5B-Instruct עם greedy decoding, ולכן הם משתחזרים בדיוק; ה-adapter הוא המחלקה בת שתים-עשרה השורות שמודפסת למעלה, בדרגה 8 מעל q_proj ו-v_proj. הקורפוס הוא תיעוד Markdown מנוהל-גרסאות של מאגר תוכנה פעיל אחד, למעט שני logs append-only, וקצב השינוי שלו נספר מהיסטוריית הגרסאות של אותו מאגר.