Fine-Tune, Retrieve หรือ Prompt? คำตอบอยู่ที่เศรษฐศาสตร์

“เราควร fine-tune ไหม?” ถูกถามเหมือนเป็นคำถามเกี่ยวกับ model แต่มันเป็นคำถามเกี่ยวกับงบประมาณ ที่มีรูปทรงซึ่ง benchmark ใดก็ตอบไม่ได้: อะไรจ่ายครั้งเดียว อะไรจ่ายต่อคำถาม และอะไรต้องจ่ายซ้ำทุกครั้งที่โลกเปลี่ยน

route ทั้งสามก็ไม่ใช่วิธีทำสิ่งเดียวกันสามแบบ และ vendor เองก็พูดชัดกว่าบล็อกส่วนใหญ่ ตารางของ OpenAI ว่า supervised fine-tuning เหมาะที่สุดกับอะไร ระบุการใช้งานสี่อย่าง: classification, nuanced translation, generating content in a specific format และ correcting instruction-following failures.¹ ไม่มีข้อไหนคือ “สอน model ให้รู้สิ่งที่มันไม่รู้” สรุปประโยชน์ของมันคือ “คุณใช้ prompt ที่สั้นลงพร้อมตัวอย่างและ context data น้อยลงได้ ซึ่งช่วยประหยัด token costs เมื่อ scale และ latency อาจต่ำลง” — เป็นเหตุผลเรื่องใบแจ้งหนี้ จากบริษัทที่ขาย feature นี้เอง

ดังนั้น:

• Fine-tuning สอนรูปแบบและพฤติกรรม tone, format, รูปร่างของคำตอบ, boundary ที่คุณสาธิตได้แต่บรรยายไม่ได้ เวอร์ชันที่ตีพิมพ์และแข็งแรงที่สุดคือ Superficial Alignment Hypothesis ของ LIMA: ความรู้มาจาก pretraining ส่วน alignment ส่วนใหญ่สอนว่าควรพูดใน sub-distribution ของ format แบบไหน — นั่นคือเหตุผลที่ตัวอย่าง curated หนึ่งพันตัวอย่างก็พอในงานนั้น²
• Retrieval เติม facts ที่เปลี่ยนแปลง มันเป็นวิธีเดียวในสามวิธีที่การแก้ไขเอกสารของคุณไปถึงคำตอบได้โดยไม่แตะ model
• Prompting ครอบคลุมกรณีจริงส่วนใหญ่ และเป็น baseline ที่ซื่อสัตย์ In-context learning เป็นค่าเริ่มต้นมาตั้งแต่ Language Models are Few-Shot Learners: task ถูกสาธิตภายใน prompt และไม่มี weight ใดขยับ³

บทความวัดผลสองชิ้นปิดประตูความเข้าใจผิดตรงกลาง Ovadia และคณะเปรียบเทียบการ inject knowledge ด้วย unsupervised fine-tuning กับการ inject ด้วย retrieval และ retrieval ชนะอย่างสม่ำเสมอ รวมถึง facts ที่ base model เคยเห็นแล้วใน pretraining⁴ Gekhman และคณะวัดความเสียหาย: ตัวอย่างที่นำความรู้ใหม่เข้ามาถูก fit ช้า และเมื่อ model fit มันได้ในที่สุด hallucination rate ต่อคำถาม อื่น ก็สูงขึ้น⁵ การสอน facts ด้วย fine-tuning ไม่เพียงล้มเหลว แต่มันทำให้คำตอบที่คุณไม่ได้ train เสื่อมลงด้วย

ครึ่งนั้นจบแล้ว ครึ่งด้านเศรษฐศาสตร์ยังไม่จบ และส่วนที่เหลือของบทนี้คือเรื่องนั้น

กรณีเดียว run สามแบบ: technical support บนเอกสารของคุณเอง ซึ่งเปลี่ยนทุกสัปดาห์

corpus เป็นของจริงและอยู่บนดิสก์นี้: เอกสาร Markdown 23 ฉบับที่ software repository ซึ่งใช้งานจริงแห่งหนึ่งเก็บไว้เป็นเอกสารภายใน — build guide, brand rules, translation brief, service manual สิบฉบับ, 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 เป็นขนาดที่สบายสำหรับการตัดสินใจนี้: มันเข้า window สมัยใหม่ได้ทุกแบบ ดังนั้น route ทั้งสามจึงใช้ได้จริง ถ้าเป็นสิบล้าน การตัดสินใจถูกบังคับให้เป็น retrieval ไปแล้ว

ตอนนี้มาดูน้ำหนักของคำว่า “รายสัปดาห์” documentation churn มักถูกพูดแบบลอย ๆ; ที่นี่มันถูกนับจาก version history ของ repository นั้น:

เอกสารขยับประมาณสัปดาห์เว้นสัปดาห์ ส่วน string ที่ผู้ใช้เห็น — ซึ่งคือสิ่งที่ support desk ถูกถามจริง — ขยับทุกสัปดาห์ตั้งแต่มีมันอยู่ ที่ประมาณยี่สิบ commit ต่อสัปดาห์ ไม่ว่าเราจะเลือก route ไหน มันต้องอยู่รอดกับเรื่องนี้ และ “สิ่งที่คุณ train ไว้เปลี่ยนบ่อยแค่ไหน?” กลายเป็นตัวเลขใน repository ของคุณเอง ไม่ใช่ความเห็น

มีการเขียนคำถามซัพพอร์ตที่สมจริงยี่สิบข้อกับ corpus นี้ หนึ่งข้อต่อหัวข้อ และตัวเลขทั้งหมดด้านล่างคำนวณจากยี่สิบข้อนั้น

สิ่งที่ง่ายที่สุดที่ใช้ได้: ใส่ corpus ทั้งหมดไว้ใน system prompt, วางคำถามท้ายสุด แล้วปล่อยให้ model หาเอง

system instructions                       140 tokens
the 23 documents                       43,158 tokens
the question (median of 20 measured)       13 tokens
the answer (the one assumption)           150 tokens

ตัวเลขทุกตัวตรงนั้นถูกนับ ยกเว้นตัวสุดท้าย: 150 output tokens เป็นสมมติฐาน เลือกให้อยู่ในช่วงของ assistant turns ที่บทที่ 16 คิดเงิน มันเป็นตัวเลขเดียวที่นี่ที่ไม่ได้ execute, ถูกใช้เหมือนกันทุก route และส่วน break-even จะแสดงชัดว่าข้อสรุปขยับแค่ไหนเมื่อคุณเปลี่ยนมัน

ตามอัตราที่อ่านจากหน้าของ provider เมื่อ 7 กันยายน 2026 — $1.50 ต่อหนึ่งล้าน input tokens, $9.00 ต่อหนึ่งล้าน output⁶ — นั่นคือ $0.066317 ต่อคำถาม คุณกำลังจ่ายเพื่ออ่านสี่หมื่นสามพัน token ซ้ำเพื่อจะตอบสิบสาม token

วิธีแก้ของบทที่ 16 ใช้ได้ตรง ๆ: corpus stable และอยู่ด้านหน้า จึงเป็น cache prefix ที่สมบูรณ์แบบ และการอ่านกลับมามีราคาแค่หนึ่งในสิบ — $0.007864 ต่อคำถาม ลดลง 88 % คำเตือนของบทที่ 16 ก็ใช้ได้เช่นกัน ในรูปแบบที่บทนั้นชี้ไว้แต่ยังไม่ได้คิดราคา provider นี้ไม่คิด write premium; มันคิด ค่าเช่า explicit cache มีราคา $0.000001 ต่อ stored token ต่อชั่วโมง,⁶ ดังนั้นการ keep warm 43,298 token มีค่าใช้จ่าย

ไม่ว่าจะมีใครถามอะไรหรือไม่ นั่นคือ $189.78 ในหกเดือน สำหรับห้องว่างเปล่า หารค่าเช่าด้วยเงินที่ประหยัดต่อคำถาม เงื่อนไขออกมาในบรรทัดเดียว: caching corpus นี้คุ้มทุนเมื่อสูงกว่า 0.74 คำถามต่อชั่วโมง — 546 ต่อเดือนเมื่อรวมการ rebuild cache รายสัปดาห์ด้วย ต่ำกว่านั้น feature ที่คุณเปิดเพื่อประหยัดเงินจะทำให้เสียเงิน

route เดิม code เดิม flag เดียว บิลเพิ่มห้าเท่า บทที่ 16 เจอเวอร์ชันหนึ่งของเรื่องนี้ที่เกิดจาก timestamp อยู่ผิดที่; ที่นี่ไม่มีอะไรผิดนอกจาก traffic cache คือการเดิมพันกับ volume และบน provider นี้คุณเดิมพันเป็นรายชั่วโมง

retriever ของบทที่ 19 ไม่เปลี่ยน: ตัดตาม section boundary พร้อม 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 tokens น้อยกว่า route ที่หนึ่งสี่สิบสองเท่า ที่ $0.002906 ต่อคำถาม index มีค่าใช้จ่าย $0.0070 ในการ build ที่ $0.15 ต่อหนึ่งล้าน embedding tokens⁶ — น้อยกว่าคำถามสามข้อ — และ $0.0070 เท่ากันในการ rebuild ใหม่ทั้งหมดทุกครั้งที่เอกสารเปลี่ยน การ rebuild index ทั้งหมดทุกสัปดาห์เป็นเวลาหกเดือนมีค่าใช้จ่าย สิบแปดเซนต์

มีเรื่องหนึ่งที่ควรหยุดดู Retrieval ทำลาย prompt caching stable prefix ตอนนี้คือ system instruction 140 token; ตั้งแต่ token ที่ 141 prompt แตกต่างทุก call เพราะ extract ถูกเลือกตามคำถาม และ 140 token ต่ำกว่า cache minimum ทุกตัวที่บทที่ 16 อ้างไว้ ดังนั้น route ที่สอง cache ไม่ได้เลย ซึ่งฟังดูแย่ แต่ไม่แย่: การไม่ cache 1,037 token ถูกกว่าการ cache 43,298

นี่คือกฎทั่วไปที่ควรพกติดตัว: เทคนิคใหญ่สองอย่างที่ประหยัด token ใช้ร่วมกันไม่ได้กับ content ชุดเดียวกัน และตัวที่ชนะคือตัวที่เอา token ออกได้มากกว่า Retrieval เอาออกไป 97.6 %

Train ด้วยตัวอย่างสองร้อยรายการใน house style แล้วถามคำถามโดยไม่แนบเอกสารเลย

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

Training costs 24,389 × 3 × $10.00 ต่อหนึ่งล้าน = $0.7317 นั่นคือ construction cost ทั้งหมด ถูกกว่ากาแฟหนึ่งแก้ว ซึ่งเป็นเหตุผลที่ทีมจำนวนมากจ่ายก่อนตรวจว่ามันช่วยจริงไหม

ตอนนี้คือกับดัก และเป็นเหตุผลที่บทนี้มีอยู่ model ที่ fine-tuned ไม่ได้มีค่าใช้จ่าย run เท่ากับ base model ของมัน pricing page พูดไว้ในประโยคเดียว: “for model inference starting from Gemini 3, tuned model endpoint prediction price will be 1.5 times of the base model.”⁶ ไม่ใช่ training แต่เป็น inference ในทุก token ตราบเท่าที่ model มีชีวิต

ดังนั้นใส่ในสูตร ให้ $p_i$ และ $p_o$ เป็น base input และ output prices, $m$ เป็น tuned multiplier, $L_R$ เป็น prompt length ของ route ที่คุณจะแทนที่, $L_F$ เป็น prompt length หลัง fine-tuning และ $O$ เป็น answer length 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

ที่ answer length ที่วัดได้ คือ 492 token — ซึ่ง 450 เป็น answer surcharge ไม่ใช่ prompt การแทนที่ prompt ที่สั้นกว่านั้นจะแพงขึ้นต่อคำถาม ตลอดไป ไม่ว่า volume เท่าใด; และ threshold โตแบบเส้นตรงตามปริมาณที่ assistant ของคุณพูด ดังนั้นตัวที่เขียนคำตอบยาวจึงไม่มีวัน fine-tune ให้ token ถูกลงได้ ไม่ว่าจะลบ prompt ออกมากแค่ไหน

พูดจากอีกด้านหนึ่งคือประโยคที่ควรจำ จาก $0.002088 ต่อคำถามของ route ที่ fine-tuned, 97.0 % คือคำตอบ Fine-tuning optimise อีกสามเปอร์เซ็นต์ที่เหลือ

ตัวเลขสี่ตัวอธิบาย route เหล่านี้ได้ทั้งหมด: สิ่งที่คุณจ่ายครั้งเดียว สิ่งที่คุณจ่ายเมื่อเอกสารเปลี่ยน สิ่งที่คุณจ่ายรายชั่วโมงไม่ว่าอะไรเกิดขึ้น และสิ่งที่คุณจ่ายต่อคำถาม นี่ขยาย 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 model ไม่ใช่ 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 เดิมไป ยี่สิบเจ็ดเท่า และไม่มีอะไรเกี่ยวกับ model เปลี่ยน — มีเพียงความถี่ที่คุณต้องจ่ายซ้ำ Construction cost เป็นเชิงอรรถ; maintenance cost คือการตัดสินใจ

ถ้าตอนนี้คุณสรุปว่า support desk ที่งานยุ่งควร fine-tune เลขเห็นด้วยกับคุณ แต่มันยังผิดอยู่ และส่วนถัดไปคือเหตุผล

cost sheet มีคอลัมน์หนึ่งที่มันคำนวณไม่ได้ ดังนั้นส่วนนี้จึง run fine-tune: locally, บน 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 สองร้อยรายการมาจาก corpus แบบกลไก จึง reproduce ได้: คำถามคือ section heading ที่ถูกเปลี่ยนเป็นคำถาม คำตอบคือ text ของ section นั้นเองใน house style ที่แข็งตัว — หนึ่งบรรทัดขึ้นต้นด้วย Short answer:, หนึ่งบรรทัดขึ้นต้นด้วย Source: พร้อม file path format คือ form ที่ถูกสอน; path คือ fact จากนั้นวัดสองตัวเลขบนคำถาม held-out ยี่สิบข้อ: คำตอบออกมาใน house style ไหม และมันระบุไฟล์ที่ตอบคำถามจริงไหม

baseline สองตัวทำให้ตารางอ่านรู้เรื่อง และทั้งสองเป็นการยืนยันของ บทที่ 4 ไม่ใช่สิ่งที่คิดทีหลัง คำตอบที่ถูกสิบจากยี่สิบเป็นไฟล์เดียวกัน ดังนั้น model ที่เมินคำถามและตอบ CLAUDE.md เสมอ ได้คะแนน 10/20 และ retriever ก็มี ceiling ของตัวเอง: ในคำถามยี่สิบข้อนี้ extract สี่รายการของมันมีไฟล์ที่ถูก 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

form ถูกเรียนรู้ ครบและเร็ว จากศูนย์เป็นสิบเก้าจากยี่สิบ ด้วย adapter 540,672-parameter — 0.109 % ของ model — ในห้านาทีของ training บน processor ที่ไม่มี graphics card ให้เห็น

facts ไม่ได้ถูกเรียนรู้ แปดจากยี่สิบแยกไม่ออกจากสิบที่ได้จากการเมินคำถามทั้งหมด และ interval ของบทที่ 4 บนตัวอย่างยี่สิบตัวก็บอกออกมาตรง ๆ file path เหล่านั้นอยู่ใน training data สามรอบ; สิ่งที่ออกมาคือนิสัยการลงท้ายด้วยบรรทัด Source: ที่ดูน่าเชื่อถือ เมื่อถูกถามคำถามบนสุดของบทนี้ model ที่ fine-tuned ตอบ Short answer: 10.x . . . และ cite CLAUDE.md คำตอบที่ถูก ซึ่งอยู่ใน CLAUDE.md คือ 18.17.0

แล้ว form ก็พัง ซึ่งเป็น row ที่ทำให้ experiment นี้คุ้มค่า ส่ง retrieved extracts หนึ่งพัน token ให้ model ที่ fine-tuned — prompt shape ที่มันไม่เคยเห็น เพราะ training prompt ทุกอันมี 28 token — แล้ว house style ร่วงจาก 19/20 เหลือ 1/20 สำหรับคำถามบนสุดของบทนี้ มันตอบ 18.17.0 — ถูกต้อง และไม่มี format ที่มันถูก train มาเลย ดังนั้น fine-tuning ไม่ได้สอน format; มันสอน format ที่มีเงื่อนไขกับ prompts ใน training set และ prompt แรกที่หน้าตาต่างไปก็พา format หายไปด้วย สิ่งใดก็ตามที่คุณ fine-tune ไว้จะกลายเป็น input distribution เดียวที่ model ของคุณเก่ง และไม่มีใครใส่เรื่องนั้นใน spreadsheet

หมายเหตุสุดท้ายเรื่อง metric ชี้ตรงไปที่ บทที่ 29: “correct source” ให้คะแนน form และ fact รวมกัน ซึ่งเป็นเหตุผลที่ retrieval rows ทั้งคู่ดูแย่มาก แม้ทั้งสอง models ตอบ fact ของคำถามนั้นถูกก็ตาม ตัวเลข end-to-end ตัวเดียวซ่อนสามสิ่งไว้ — retriever ที่ recall 14/20, reader 0.5B และ citation format — และการเลือกว่าจะซ่อมอะไรต้องแยกพวกมันก่อนวัด ไม่ใช่หลังวัด

ตอนนี้คือคอลัมน์ที่ vendor เติมให้คุณ model ที่ fine-tuned ไม่ใช่ asset ที่คุณเป็นเจ้าของ; มันคือสัญญาเช่าบน base model ของคนอื่น พร้อมวันหมดอายุพิมพ์ติดไว้ เมื่อ 7 กันยายน 2026 ส่วน fine-tuning ของ pricing page ของ 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-tuned; 2 กรกฎาคม 2026 ปิดสำหรับองค์กรที่ไม่ได้ run inference บน model ที่ fine-tuned ในหกสิบวัน; 6 มกราคม 2027 ไม่มี job ใหม่เลย⁸ หน้าเดียวกันกำหนดการ shutdown ของ models ที่ 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 ใหม่

frontier vendor อีกรายไม่เคยขายสัญญาเช่านี้ให้คุณ index เอกสารของ Anthropic มี 699 หน้า และ ไม่มีแม้แต่หน้าเดียวเกี่ยวกับ fine-tuning; ส่วน model-customisation ของ pricing page ของ Bedrock ครอบคลุม Amazon Nova, Amazon Titan, Cohere, Meta และ OpenAI open-weight models แต่ไม่มี Claude⁹¹⁰ ถ้าสถาปัตยกรรมของคุณพึ่ง fine-tune หนึ่งในสามตระกูล frontier ก็ไม่พร้อมให้คุณใช้ ไม่ว่างบจะเท่าไร

Self-hosting แทนที่สัญญาเช่าบน model ด้วยสัญญาเช่าบนเครื่อง และ AWS ทำเลขนั้นไว้บนหน้าของตัวเอง: one model unit of 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 ต่อเดือนสำหรับการ์ดหนึ่งใบที่ต้องเปิดอยู่ไม่ว่าจะมีใครถามหรือไม่ route retrieval ทั้งหมดที่เดือนละหมื่นคำถามมีค่าใช้จ่าย $174.52 สำหรับหกเดือน

นี่คือจุดที่ LoRA สมควรมีที่ยืน ในฐานะเหตุผลด้านงบประมาณ ไม่ใช่ด้านเทคนิค วัดบน model เดียวกัน adapter rank-16 บน attention และ feed-forward layers มี 8,798,208 parameters — 1.781 % ของ model, 17.6 MB ใน bfloat16 — เทียบกับ base weights 0.988 GB และ optimiser กับ gradient state ของมันคือ 140.77 MB ขณะที่ full fine-tuning ต้องใช้ 7.90 GB ต่างกัน 56 เท่า ผลลัพธ์ไม่ใช่ training ที่ถูกลง แต่คือ base model ที่โหลดไว้หนึ่งตัวสามารถ serve adapters ได้หลายตัว ซึ่งเป็นทางเดียวที่ fixed cost ของ GPU จะถูกหารด้วยอะไรบางอย่าง Managed training สะท้อนสิ่งนี้: $0.48 ต่อหนึ่งล้าน token แบบ low-rank ถึง 16B เทียบกับ $0.54 แบบ full โดยมี minimum $4.00 ต่อ job¹¹ floor นั้นคือรายละเอียด ที่ 24,389 tokens สำหรับสาม epochs, ทุก retraining บน corpus นี้ถูกคิดเงิน $4.00 แทนที่จะเป็น $0.04 ตามเลขคำนวณ — minimums $104 ตลอดการ run รายสัปดาห์ยี่สิบหกครั้ง สำหรับเลขจริงเก้าสิบเอ็ดเซนต์

อีกสองคอลัมน์ที่ปรากฏเฉพาะบนใบแจ้งหนี้

Data residency มีค่าใช้จ่ายประมาณสิบเปอร์เซ็นต์ และ provider สองรายเห็นตรงกันในตัวเลขนี้ OpenAI คิด “a 10 % uplift” บน data-residency endpoints สำหรับ models ที่ release ตั้งแต่ 5 มีนาคม 2026 เป็นต้นไป;⁷ Vertex ตั้งราคา non-global endpoints ที่ $1.65 เทียบกับ $1.50 เป็นสิบเปอร์เซ็นต์เดียวกัน⁶ เทียบกับห้าสิบเปอร์เซ็นต์ที่ tuned endpoint มีค่าใช้จ่าย แล้ว folklore จะกลับหัว: residency ถูกและ fine-tuning ไม่ถูก — และ fine-tuning ก็ไม่ใช่ตัวเลือกที่ private อยู่ดี เพราะ corpus ไปถึง provider ไม่ทางใดก็ทางหนึ่ง แค่ครั้งเดียวตอน training แทนที่จะเป็นครั้งหนึ่งต่อ call

ราคาที่ explicit ที่สุดที่เคยติดไว้กับข้อมูลของคุณอยู่บนหน้าเดียวกัน ซึ่ง list model ที่ fine-tuned หนึ่งตัวสองครั้ง: เมื่อเปิด data sharing, inference ถูกลงครึ่งหนึ่งพอดี — $2.00 เทียบกับ $4.00 input, $8.00 เทียบกับ $16.00 output⁷ การปล่อยให้ provider เก็บสิ่งที่คุณส่งมีมูลค่าเป็นส่วนลด 50 % ซึ่งบอกคุณว่ามันมีมูลค่าต่อพวกเขาเท่าไร

Distillation — การ train model เล็กของคุณเองจากคำตอบของ model ใหญ่ — มักถูกเสนอเป็นทางออกจากทั้งสองเรื่อง คิดราคาแล้วไม่ใช่ เพราะ teacher คือระบบที่คุณพยายามแทนที่: การสร้างตัวอย่าง training สองร้อยรายการด้วยการถาม route retrieval สองร้อยคำถามมีค่าใช้จ่าย 200 × $0.002906 = $0.58 เพิ่มจาก $0.73 ที่ใช้ train ด้วยตัวอย่างนั้น Distillation คือสิ่งที่คุณทำ หลังจาก retrieval pipeline ใช้งานได้แล้ว เพื่อทำให้มันถูกลง และมัน inherit fact ทุกอย่างที่ retriever ทำผิด

เงินคือครึ่งที่มองเห็น อีกครึ่งมาถึงในรูปการรอ ด้วยสาเหตุเดียวกับบิล: model อ่าน prompt ทั้งหมดก่อนจะพูดคำแรก บทที่ 13 วัด prefill เทียบกับ decode บน model ที่คุณแตะได้; นี่คือการวัดแบบเดียวกัน run เดียว เครื่องเดียว เทียบกับ prompt length:

ตัวเลข absolute เป็นของ model 0.5B บน CPU threads สิบหกตัว และไม่ได้บอกอะไรเกี่ยวกับ hosted frontier model แต่ shape ถ่ายทอดตรง ๆ: prefill โตตาม prompt length และ cost per token ค่อย ๆ เพิ่มเมื่อพจน์กำลังสองของ บทที่ 9 เริ่มปรากฏ — 4.79 ms ที่หนึ่งพัน token เทียบกับ 6.04 ms ที่แปดพัน เป็น penalty 26 % เพียงเพราะยาวขึ้น

ผลต่อ route ทั้งสามตรงไปตรงมา route ที่หนึ่ง prefill สี่หมื่นสามพัน token ต่อคำถาม และ cache hit คือสิ่งที่ทำให้พอรับได้ — บทที่ 16 อธิบายว่าทำไม: cache read แทนที่งาน prefill จึงซื้อ latency และเงินในธุรกรรมเดียว route ที่สอง prefill หนึ่งพันและเพิ่ม round trip ไป index ก่อน route ที่สาม prefill ยี่สิบแปดและไม่เพิ่มอะไร ซึ่งทำให้มันวัดได้ว่าเร็วที่สุดในสาม route ในการตอบคำถาม เพียงแต่มันตอบผิดสิ่ง

failure สามแบบที่ดูเหมือนปัญหา model แต่ไม่ใช่ — สิบนาทีตรงนี้ช่วยประหยัดหนึ่งเดือนทีหลัง:

และ requirement ที่ครอบทั้งหมดคือ: การตัดสินใจนี้ทำไม่ได้หากไม่มี evaluation set และ vendor ที่ขาย 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¹ คำถามยี่สิบข้อ ซึ่งเป็นสิ่งที่บทนี้ใช้ แสดง mechanism ได้แต่เลือก supplier ไม่ได้ — บทที่ 4 วัดว่าทำไม และเมื่อยี่สิบเคสคือทั้งหมดที่คุณมี ควรทำอะไร — repeat, pair และวัด spread ระหว่าง runs — คือบทที่ 29

สี่คอลัมน์ และมีแค่คอลัมน์สุดท้ายที่ตัดสิน:

กฎที่ได้จากมัน และสั้นพอให้จำ: เริ่มด้วย prompt; เพิ่ม retrieval เมื่อ facts ขยับ; fine-tune เฉพาะเมื่อคุณวัดแล้วว่าสิ่งที่ยังขาดคือ shape ไม่ใช่ fact — และคิดราคาคำตอบ ไม่ใช่ prompt ก่อนทำ

เวอร์ชันที่ไม่สบายใจ สำหรับคนที่มาถึงโดยตัดสินใจไว้แล้ว: ในกรณีที่วัดในบทนี้ fine-tuning เป็น route ที่ถูกที่สุดเมื่อสูงกว่าสี่พันคำถามต่อเดือน และในด้าน facts มันก็ยังเอาชนะการตอบ CLAUDE.md กับทุกอย่างไม่ได้

ราคาทุกอย่างที่นี่คิดต่อ token และทุก route คือวิธีจัดเรียง token แบบต่าง ๆ เรื่องนั้นกำลังจะหยุดจริง

บทที่ 21 ออกจาก text image ที่เข้า model ไม่ใช่ string แต่เป็น grid ของ patches พร้อม token count ที่คุณไม่ได้เลือก; เสียงพูดหนึ่งนาทีถูกคิดเงินเป็นวินาทีใน provider หนึ่งและเป็น audio token ในอีก provider; synthetic speech ขายเป็นตัวอักษร, transcription ขายเป็นนาที, raw compute ขายเป็น GPU-second คำถามที่บทนี้ตอบด้วย cost function เดียว — อะไรถูกกว่า? — ยัง ถามไม่ได้ จนกว่า units จะตรงกัน และไม่มี calculator บนอินเทอร์เน็ต normalize ให้

และยังเป็นจุดที่ training ปรากฏอีกครั้ง: image adapter พร้อม trigger word และ voice ที่ clone จาก sample ซึ่งทำให้เกิดคำถามที่บทถัดไปเปิดด้วย และมันไม่ใช่คำถามเชิงวาทศิลป์: ถ้า fine-tuning language model แทบจะเป็นการซื้อที่ผิดเสมอ ทำไม fine-tuning image model แทบจะเป็นการซื้อที่ถูกเสมอ?

ทุก price, threshold และ multiplier ในบทนี้อ่านจากหน้าของ provider เองเมื่อ 7 กันยายน 2026 และ quote พร้อมวันที่นั้น เพราะทั้งหมดจะขยับ ตัวเลขที่วัดได้ — token counts, chunk sizes, retrieval sizes, training loss, scores, latencies และ version-history counts — ถูกผลิตบนเครื่องเดียวในวันเดียวกัน และ reproduce ได้จาก corpus ที่อธิบายไว้ข้างต้น

local experiments ใช้ Qwen/Qwen2.5-0.5B-Instruct พร้อม greedy decoding จึง reproduce ได้ตรงเป๊ะ; adapter คือ class สิบสองบรรทัดที่พิมพ์ไว้ข้างต้น ที่ rank 8 บน q_proj และ v_proj corpus คือ tracked Markdown documentation ของ software repository ที่ใช้งานจริงแห่งหนึ่ง โดยไม่รวม append-only logs สองชุด และ change rate ของมันถูกนับจาก version history ของ repository นั้น