Fine-Tune أم استرجاع أم Prompt؟ القرار اقتصادي

يُطرح سؤال «هل ينبغي أن نعمل fine-tune؟» كما لو كان سؤالًا عن نموذج. إنه سؤال عن ميزانية، وبشكل لا يجيب عنه أي benchmark: ما الذي يُدفع مرة واحدة، وما الذي يُدفع لكل سؤال، وما الذي يُدفع من جديد كلما تحرك العالم.

المسارات الثلاثة ليست أيضًا ثلاث طرق لفعل شيء واحد، والبائعون يقولون ذلك بصراحة أكبر من معظم تدوينات المدونات. جدول OpenAI نفسه لما يكون supervised fine-tuning أفضل له يسرد أربعة استخدامات: التصنيف، والترجمة الدقيقة ذات الفروق، وتوليد محتوى بتنسيق محدد، وتصحيح إخفاقات اتباع التعليمات.¹ ولا واحد منها هو «تعليم النموذج شيئًا لا يعرفه». ملخص فائدته يقول إنك «تستطيع استخدام prompts أقصر مع أمثلة وبيانات context أقل، ما يوفر تكاليف token على نطاق واسع ويمكن أن يخفض latency» — حجة عن الفاتورة، من الشركة التي تبيع الميزة.

إذًا:

• fine-tuning يعلّم الشكل والسلوك. النبرة، والتنسيق، وشكل الإجابة، وحدًا يمكنك عرضه ولا يمكنك وصفه. أقوى صياغة منشورة هي فرضية Superficial Alignment في LIMA: المعرفة تأتي من pretraining، وalignment يعلّم في الغالب أي توزيع فرعي من التنسيقات ينبغي التحدث ضمنه — ولهذا كفت ألف عينة منتقاة هناك.²
• الاسترجاع يوفّر الحقائق التي تتغير. هو الوحيد من الثلاثة حيث يصل تعديل في توثيقك إلى الإجابة من دون لمس النموذج.
• Prompting يغطي معظم الحالات الواقعية، وهو خط الأساس الصادق. كان in-context learning هو الافتراضي منذ Language Models are Few-Shot Learners: تُعرَض المهمة داخل prompt ولا يتحرك أي وزن.³

تغلق ورقتان مقاستا النتائج الباب أمام الخطأ الواقع في الوسط. قارن Ovadia وزملاؤه حقن المعرفة عبر fine-tuning غير مراقَب مقابل حقنها عبر الاسترجاع، وفاز الاسترجاع باستمرار، بما في ذلك على حقائق سبق للنموذج الأساسي رؤيتها في pretraining.⁴ وقاس Gekhman وزملاؤه الضرر: الأمثلة التي تُدخل معرفة جديدة تُلائم ببطء، ومع نجاح النموذج أخيرًا في ملاءمتها يرتفع معدل hallucination لديه على أسئلة أخرى.⁵ تعليم الحقائق عبر 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

ثلاثة وأربعون ألف token حجم مريح لهذا القرار: فهو يلائم أي context window حديثة، لذلك تكون المسارات الثلاثة متاحة فعلًا. عند عشرة ملايين يصبح القرار محسومًا نيابة عنك، وهو الاسترجاع.

والآن العمل الذي تؤديه كلمة «أسبوعيًا». عادةً ما يُزعَم تقلب التوثيق؛ هنا عُدَّ من سجل إصدارات ذلك المستودع:

تتحرك الوثائق تقريبًا أسبوعًا بعد أسبوع. أما النصوص المرئية للمستخدم — وهي ما يُسأل عنه مكتب الدعم فعلًا — فقد تحركت في كل أسبوع وُجدت فيه، بمعدل نحو عشرين commit أسبوعيًا. أي مسار نختاره يجب أن ينجو من ذلك، و*«كم مرة يتغير الشيء الذي درّبت عليه؟»* يتبين أن له رقمًا في مستودعك نفسه لا رأيًا.

كُتبت عشرون مسألة دعم واقعية مقابل هذا المتن، واحدة لكل موضوع، وكل رقم أدناه محسوب على تلك العشرين.

أبسط شيء يعمل: ضع المتن كله في 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 افتراض، اختير داخل نطاق أدوار المساعد التي فوترها الفصل 16. إنه الرقم الوحيد هنا الذي لم يُنفَّذ، ويُطبق بالضبط على المسارات الثلاثة كلها، ويُظهر قسم نقطة التعادل بدقة مقدار تحرك الخلاصة عندما تغيّره.

وفق الأسعار المقروءة من صفحة المزوّد في 7 سبتمبر 2026 — $1.50 لكل مليون input tokens، و$9.00 لكل مليون output⁶ — تكون التكلفة $0.066317 للسؤال. أنت تدفع لإعادة قراءة ثلاثة وأربعين ألف token كي تجيب عن ثلاثة عشر.

ينطبق إصلاح الفصل 16 مباشرة: المتن مستقر وفي المقدمة، لذا فهو بادئة cache مثالية، وتكلفة قراءته ثانية عُشر التكلفة — $0.007864 للسؤال، خفض بنسبة 88 %. وينطبق تحذير الفصل 16 أيضًا، بالشكل الذي لمّح إليه ذلك الفصل ولم يسعّره. هذا المزوّد لا يفرض علاوة كتابة؛ بل يفرض إيجارًا. تكلف cache صريحة $0.000001 لكل token مخزّن في الساعة،⁶ لذا إبقاء 43,298 token دافئة يكلف

سواء سأل أحد شيئًا أم لا. ذلك $189.78 خلال ستة أشهر، لغرفة فارغة. اقسم الإيجار على التوفير لكل سؤال وستخرج الحالة في سطر واحد: caching هذا المتن يرد تكلفته فوق 0.74 سؤالًا في الساعة — 546 شهريًا بعد احتساب إعادة بناء cache أسبوعيًا أيضًا. تحت ذلك، الميزة التي فعّلتها لتوفير المال تخسره.

المسار نفسه، الكود نفسه، علم واحد، فاتورة بخمسة أضعاف. وجد الفصل 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 أقل باثنتين وأربعين مرة من المسار الأول، بتكلفة $0.002906 للسؤال. يكلف بناء الفهرس $0.0070 عند $0.15 لكل مليون embedding tokens⁶ — أقل من قيمة ثلاثة أسئلة — والتكلفة نفسها $0.0070 لإعادة بنائه من الصفر كلما تغيّر التوثيق. إعادة بناء الفهرس كاملًا كل أسبوع لستة أشهر تكلف ثمانية عشر سنتًا.

هناك أمر يستحق التوقف عنده. الاسترجاع يدمّر prompt caching. البادئة المستقرة الآن هي تعليمة النظام ذات الـ 140 token؛ من token 141 يختلف prompt في كل استدعاء، لأن المقتطفات تُختار لكل سؤال. و140 token أقل من كل حد أدنى للـ cache اقتبسه الفصل 16. لذلك لا يمكن عمل cache للمسار الثاني إطلاقًا، وهذا يبدو سيئًا وليس كذلك: عدم عمل cache لـ 1,037 token أرخص من عمل cache لـ 43,298.

هذه قاعدة عامة تستحق أن تحملها معك: تقنيتا توفير token الكبيرتان متعارضتان على المحتوى نفسه، والفائزة هي التي تزيل 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-tuned لا يكلف تكلفة النموذج الأساسي نفسها عند التشغيل. تقول صفحة الأسعار ذلك في جملة واحدة: «بالنسبة إلى inference النموذج بدءًا من Gemini 3، سيكون سعر تنبؤ tuned model endpoint 1.5 مرة من النموذج الأساسي.»⁶ ليس التدريب. بل inference، على كل token، ما دام النموذج حيًا.

لذا ضعه في صيغة. لتكن $p_i$ و$p_o$ سعري input وoutput الأساسيين، و$m$ مضاعف النموذج tuned، و$L_R$ طول prompt للمسار الذي تستبدله، و$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 token — منها 450 رسوم زيادة على الإجابة، لا على prompt. استبدال prompt أقصر من ذلك أغلى لكل سؤال، إلى الأبد، عند أي حجم؛ والعتبة تكبر خطيًا بقدر ما يقوله مساعدك، لذا فالمساعد الذي يكتب إجابات طويلة لا يستطيع أبدًا أن يعمل fine-tune في طريقه إلى token أرخص مهما حذف من prompt.

الحقيقة نفسها من الطرف الآخر هي الجملة التي ينبغي تذكرها. من تكلفة المسار fine-tuned البالغة $0.002088 لكل سؤال، 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 })),   
});

ذلك السطر المظلَّل هو حجة القسم السابق كلها مكتوبة ككود: المضاعف يقع على 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-tune، فالحساب يوافقك. وما زال ذلك خاطئًا، والقسم التالي يشرح السبب.

تضم ورقة التكلفة عمودًا لا تستطيع حسابه، لذا يشغّل هذا القسم 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: مع مسار الملف. التنسيق هو الشكل الذي يُعلَّم؛ والمسار هو الحقيقة. ثم رقمان على عشرين سؤالًا محجوبًا: هل تخرج الإجابة بأسلوب المؤسسة، وهل تسمي الملف الذي يجيب فعلًا عن السؤال؟

يجعل خطا أساس الجدول مقروءًا، وكلاهما إصرار الفصل 4 لا فكرة لاحقة. عشر إجابات صحيحة من العشرين هي الملف نفسه، لذا النموذج الذي يتجاهل السؤال ويجيب دائمًا CLAUDE.md يحصل على 10/20. وللمسترجِع سقفه أيضًا: عبر هذه الأسئلة العشرين تحتوي مقتطفاته الأربعة على الملف الصحيح 14 مرة وتضعه أولًا 7 مرات، لذا 14/20 هي أعلى نتيجة يمكن لأي قارئ تحقيقها باستخدامه.

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-tuned ‏Short answer: 10.x . . . واستشهد بـ CLAUDE.md. الإجابة الصحيحة، الموجودة في CLAUDE.md، هي 18.17.0.

ثم انكسر الشكل، وهذا هو الصف الذي يبرر التجربة. أعطِ النموذج fine-tuned ألف token من المقتطفات المسترجعة — شكل prompt لم يره قط، لأن كل prompt تدريب كان ثمانية وعشرين token — فينهار أسلوب المؤسسة من 19/20 إلى 1/20. في السؤال الموجود أعلى هذا الفصل يجيب 18.17.0 — صحيحًا، ومن دون أي من التنسيق الذي دُرّب عليه. إذًا لم يعلّم fine-tuning تنسيقًا؛ بل علّم تنسيقًا مشروطًا بالـ prompts الموجودة في مجموعة التدريب، وأول prompt بدا مختلفًا أخذ التنسيق معه. أي شيء تعمل عليه fine-tune يصبح توزيع input الوحيد الذي يجيد نموذجك العمل عليه، ولا أحد يضع ذلك في جدول البيانات.

ملاحظة أخيرة عن المقياس، تشير مباشرة إلى الفصل 29: «المصدر الصحيح» يسجل الشكل والحقيقة معًا، ولهذا يبدو صفا الاسترجاع سيئين مع أن كلا النموذجين أصاب حقيقة ذلك السؤال. كان رقم end-to-end واحد يخفي ثلاثة أشياء — مسترجِعًا عند 14/20 recall، وقارئًا 0.5B، وتنسيق استشهاد — واختيار ما ينبغي إصلاحه يعني فصلها قبل القياس، لا بعده.

والآن العمود الذي يملؤه البائعون نيابة عنك. النموذج fine-tuned ليس أصلًا تملكه؛ إنه عقد إيجار على نموذج أساسي يملكه شخص آخر، وله تاريخ انتهاء مطبوع عليه. في 7 سبتمبر 2026 حمل قسم fine-tuning من صفحة أسعار OpenAI هذا الإشعار كاملًا:

تقوم OpenAI بإنهاء منصة fine-tuning تدريجيًا. لم تعد المنصة متاحة للمستخدمين الجدد، لكن المستخدمين الحاليين لمنصة fine-tuning سيتمكنون من إنشاء مهام تدريب خلال الأشهر المقبلة. ستبقى كل النماذج fine-tuned متاحة لـ inference إلى أن تُلغى نماذجها الأساسية.⁷

الجدول الزمني مؤرخ باليوم: 7 مايو 2026، الإغلاق أمام المؤسسات التي لم تعمل fine-tune من قبل؛ 2 يوليو 2026، الإغلاق أمام من لم يشغّل inference على نموذج fine-tuned خلال ستين يومًا؛ 6 يناير 2027، لا مهام جديدة إطلاقًا.⁸ وتحدد الصفحة نفسها إيقاف النماذج fine-tuned ذاتها — ft-gpt-3.5-turbo، ft-gpt-4، ft-gpt-4.1-nano، ft-babbage-002، ft-davinci-002 — في 23 أكتوبر 2026، ولكل واحد نموذج أساسي بديل موصى به، وهي طريقة مهذبة للقول: درّبه مرة أخرى.

البائع الحدودي الآخر لم يبعك عقد الإيجار أصلًا. يفهرس دليل توثيق Anthropic ‏699 صفحة ولا واحدة منها عن fine-tuning؛ وأقسام تخصيص النماذج في صفحة أسعار Bedrock تغطي Amazon Nova وAmazon Titan وCohere وMeta ونماذج OpenAI ذات الأوزان المفتوحة، ولا Claude.⁹¹⁰ إذا كانت بنيتك تعتمد على fine-tune، فواحدة من عائلات النماذج الحدودية الثلاث غير متاحة لك ببساطة بأي ميزانية.

يستبدل الاستضافة الذاتية عقد إيجار النموذج بعقد إيجار آلة، وتقوم AWS بهذا الحساب على صفحتها: وحدة نموذج واحدة من throughput مخصص لنموذج مخصص، التزام شهر واحد، هي «1 model unit × $21.18 × 24 hours × 31 days = $15,757.92» شهريًا.¹⁰ استئجار المعدن مباشرة أرخص وليس مجانيًا — $3.99 لكل GPU-hour عند الطلب لـ H100، و$1.99 preemptible¹¹ — نحو $2,900 شهريًا لبطاقة واحدة يجب أن تبقى عاملة سواء سأل أحد شيئًا أم لا. مسار الاسترجاع كله عند عشرة آلاف سؤال شهريًا يكلف $174.52 لستة أشهر.

هنا يستحق LoRA مكانه، كحجة ميزانية لا كحجة تقنية. عند قياسه على النموذج نفسه، يكون adapter برتبة 16 فوق attention وطبقات feed-forward بحجم 8,798,208 معاملات — 1.781 % من النموذج، 17.6 MB بصيغة bfloat16 — مقابل 0.988 GB من أوزان الأساس، وتكون حالتا optimizer وgradient لديه 140.77 MB حيث يحتاج full fine-tuning إلى 7.90 GB، أي عامل 56. النتيجة ليست تدريبًا أرخص، بل أن نموذجًا أساسيًا واحدًا محمّلًا يمكنه خدمة adapters كثيرة، وهذه هي الطريقة الوحيدة لتقسيم التكلفة الثابتة لـ GPU على أي شيء. التدريب المُدار يعكس ذلك: $0.48 لكل مليون tokens منخفض الرتبة حتى 16B مقابل $0.54 كامل، مع حد أدنى $4.00 لكل مهمة.¹¹ هذا الحد الأدنى هو التفصيل. عند 24,389 token لثلاث epochs، كل إعادة تدريب على هذا المتن تُفوَّتر $4.00 بدلًا من $0.04 التي يحسبها الحساب — $104 من الحدود الدنيا عبر ست وعشرين عملية أسبوعية، مقابل واحد وتسعين سنتًا من الحساب.

عمودان آخران لا يظهران إلا على الفاتورة.

تكلف data residency نحو عشرة في المئة، ويتفق مزوّدان على الرقم. تفرض OpenAI «زيادة 10 %» على endpoints الخاصة بـ data residency للنماذج الصادرة في 5 مارس 2026 أو بعده؛⁷ وتضع Vertex أسعار endpoints غير العالمية عند $1.65 مقابل $1.50، وهي العشرة في المئة نفسها.⁶ ضع ذلك مقابل الخمسين في المئة التي تكلفها tuned endpoint فينقلب الاعتقاد الشائع: residency رخيصة وfine-tuning ليس كذلك — وfine-tuning ليس خيار الخصوصية أصلًا، لأن المتن يصل إلى المزوّد في الحالتين، مرة عند التدريب بدلًا من مرة في كل استدعاء.

السعر الأكثر صراحة الذي وُضع لبياناتك موجود في الصفحة نفسها، إذ تسرد نموذجًا fine-tuned واحدًا مرتين: مع تفعيل مشاركة البيانات، يكون inference نصف السعر تمامًا — $2.00 مقابل $4.00 للـ input، و$8.00 مقابل $16.00 للـ output.⁷ السماح للمزوّد بالاحتفاظ بما أرسلته يستحق خصمًا قدره 50 %، وهذا يخبرك بما يساويه لهم.

Distillation — تدريب نموذج صغير خاص بك على إجابات نموذج كبير — يُطرح عادة كمخرج من الأمرين. سعّره ولن يكون كذلك، لأن المعلم هو النظام الذي كنت تحاول استبداله: إنتاج مئتي مثال تدريب عبر سؤال مسار الاسترجاع مئتي سؤال يكلف 200 × $0.002906 = $0.58، فوق $0.73 لتدريبها. Distillation شيء تفعله بعد أن تعمل أنبوبة الاسترجاع، لجعلها أرخص، وهو يرث كل حقيقة أخطأ فيها المسترجِع.

المال هو النصف المرئي. أما الآخر فيأتي كنوع من الانتظار، وبالسبب نفسه للفواتير: يقرأ النموذج prompt كله قبل أن ينطق بكلمة. قاس الفصل 13 prefill مقابل decode على نموذج يمكن لمسه؛ وهنا القياس نفسه، تشغيل واحد، آلة واحدة، مقابل طول prompt:

الأرقام المطلقة تخص نموذج 0.5B على ستة عشر خيط CPU ولا تقول شيئًا عن نموذج حدودي مستضاف. أما الشكل فينتقل بالضبط: prefill يكبر مع طول prompt، وتكلفة كل token تزحف صعودًا عندما يبدأ الحد التربيعي من الفصل 9 بالظهور — 4.79 ms عند ألف token مقابل 6.04 ms عند ثمانية آلاف، عقوبة 26 % لمجرد الطول.

النتيجة على المسارات الثلاثة مباشرة. المسار الأول يعمل prefill لثلاثة وأربعين ألف token لكل سؤال، وضربة cache هي ما يجعله محتملًا — شرح الفصل 16 السبب: قراءة cache تستبدل عمل prefill، لذا تشتري latency والمال في صفقة واحدة. المسار الثاني يعمل prefill لألف ويضيف رحلة ذهاب وإياب إلى الفهرس أولًا. المسار الثالث يعمل prefill لثمانية وعشرين ولا يضيف شيئًا، مما يجعله الأسرع قياسًا بين الثلاثة في الإجابة. لكنه يجيب عن الشيء الخطأ.

ثلاث إخفاقات تبدو مشكلات نماذج وليست كذلك — عشر دقائق هنا توفر شهرًا لاحقًا:

والشرط فوق ذلك كله: لا يمكن اتخاذ هذا القرار من دون مجموعة تقييم، والبائع الذي يبيع fine-tune يقول ذلك. يفتتح دليل OpenAI بعبارة «لا تستثمر في fine-tuning إلا بعد إعداد evals. تحتاج إلى طريقة موثوقة لتحديد ما إذا كان نموذجك fine-tuned يؤدي أداء أفضل من نموذج أساسي»، ويضيف أنه إذا لم تغيّر خمسون عينة جيدة شيئًا، فالمشكلة في المهمة أو prompt، لا في حجم البيانات.¹ عشرون سؤالًا، وهو ما استخدمه هذا الفصل، تُظهر آلية ولا تستطيع اختيار مورّد — قاس الفصل 4 السبب، وما ينبغي فعله عندما تكون عشرون حالة كل ما لديك — كررها، وازوجها، وقِس التباين بين التشغيلات — هو الفصل 29.

أربعة أعمدة، وآخرها فقط يقرر:

القاعدة التي تخرج منه قصيرة بما يكفي للاحتفاظ بها: ابدأ بـ prompt؛ أضف الاسترجاع عندما تتحرك الحقائق؛ لا تعمل fine-tune إلا عندما تقيس أن ما ينقصك ما زال شكلًا لا حقيقة — وسعّر الإجابة، لا prompt، قبل أن تفعل.

والنسخة غير المريحة، لمن وصل وقد قرر مسبقًا: في الحالة المقاسة في هذا الفصل، يكون fine-tuning هو المسار الأرخص فوق أربعة آلاف سؤال شهريًا، وعلى مستوى الحقائق ما زال لا يستطيع التغلب على إجابة CLAUDE.md عن كل شيء.

كل سعر هنا كان لكل token، وكل مسار كان طريقة مختلفة لترتيب tokens. هذا على وشك أن يتوقف عن كونه صحيحًا.

يغادر الفصل 21 النص. الصورة التي تدخل نموذجًا ليست string بل شبكة من patches لها عدد tokens لم تختره؛ الدقيقة المنطوقة تُفوَّتر بالثانية عند مزوّد وبـ audio token عند آخر؛ الكلام الاصطناعي يُباع بالحرف، والتفريغ بالدقيقة، والحوسبة الخام بـ GPU-second. السؤال الذي أجاب عنه هذا الفصل بدالة تكلفة واحدة — أيها أرخص؟ — لا يمكن حتى طرحه قبل أن تتطابق الوحدات، ولا توجد آلة حاسبة على الإنترنت تطبعها.

وهناك أيضًا يعود التدريب إلى الظهور: adapter صورة مع trigger word، وصوت مستنسخ من عينة. وهذا يثير السؤال الذي يفتتح به الفصل التالي، وليس سؤالًا بلاغيًا: إذا كان fine-tuning نموذج لغوي هو تقريبًا دائمًا الشراء الخطأ، فلماذا يكون fine-tuning نموذج صورة تقريبًا دائمًا الشراء الصحيح؟

كل سعر وعتبة ومضاعف في هذا الفصل قُرئ من صفحة المزوّد نفسه في 7 سبتمبر 2026 ويُقتبس مع ذلك التاريخ، لأن كلها ستتحرك. الأرقام المقاسة — أعداد tokens، وأحجام chunks، وأحجام الاسترجاع، وخسارة التدريب، والدرجات، وlatencies، وعدّ سجل الإصدارات — أُنتجت على آلة واحدة في اليوم نفسه ويمكن إعادة إنتاجها من المتن الموصوف أعلاه.

استخدمت التجارب المحلية Qwen/Qwen2.5-0.5B-Instruct مع greedy decoding، لذا فهي تعاد بالضبط؛ والـ adapter هو الصنف ذو الاثني عشر سطرًا المطبوع أعلاه، عند الرتبة 8 فوق q_proj وv_proj. المتن هو توثيق Markdown المتتبع لمستودع برمجيات واحد قيد الاستخدام، باستثناء سجلين append-only، وحُسب معدل تغيره من سجل إصدارات ذلك المستودع.