Fine-Tune, retrieve hay prompt? Quyết định nằm ở kinh tế

"Chúng ta có nên fine-tune không?" thường được hỏi như thể đó là câu hỏi về mô hình. Thực ra đó là câu hỏi về ngân sách, với một hình dạng mà không benchmark nào trả lời: khoản nào trả một lần, khoản nào trả theo từng câu hỏi, và khoản nào phải trả lại mỗi khi thế giới thay đổi.

Ba route này cũng không phải là ba cách làm cùng một việc, và các vendor nói điều đó thẳng thắn hơn hầu hết bài blog. Bảng của chính OpenAI về những việc supervised fine-tuning phù hợp nhất liệt kê bốn mục: phân loại, dịch tinh tế, tạo nội dung theo một định dạng cụ thể, và sửa lỗi tuân thủ instruction.¹ Không mục nào là "dạy cho mô hình một điều nó chưa biết". Phần tóm tắt lợi ích của họ nói rằng "bạn có thể dùng prompt ngắn hơn với ít ví dụ và dữ liệu ngữ cảnh hơn, giúp tiết kiệm chi phí token ở quy mô lớn và có thể giảm latency" — một lập luận về hóa đơn, từ chính công ty bán tính năng đó.

Vậy nên:

• Fine-tuning dạy form và hành vi. Giọng điệu, định dạng, hình dạng của câu trả lời, một ranh giới bạn có thể minh họa nhưng khó mô tả. Phiên bản được công bố mạnh nhất là Superficial Alignment Hypothesis của LIMA: knowledge đến từ pretraining, alignment chủ yếu dạy nên nói trong sub-distribution định dạng nào — đó là lý do một nghìn ví dụ tuyển chọn đã đủ trong nghiên cứu đó.²
• Retrieval cung cấp những facts thay đổi. Đây là cách duy nhất trong ba cách mà một chỉnh sửa trong tài liệu của bạn đi vào câu trả lời mà không đụng tới mô hình.
• Prompting bao phủ hầu hết các trường hợp thực tế, và là baseline trung thực. In-context learning đã là mặc định kể từ Language Models are Few-Shot Learners: tác vụ được minh họa ngay trong prompt và không weight nào dịch chuyển.³

Hai bài báo có đo đạc đã khép lại sai lầm ở giữa. Ovadia và cộng sự so sánh việc đưa knowledge vào bằng unsupervised fine-tuning với việc đưa vào bằng retrieval, và retrieval thắng nhất quán, kể cả trên các facts mà base model đã thấy trong pretraining.⁴ Gekhman và cộng sự đo thiệt hại: các ví dụ đưa knowledge mới vào được fit chậm, và khi mô hình cuối cùng fit chúng, tỷ lệ hallucination của nó trên những câu hỏi khác tăng lên.⁵ Dạy facts bằng fine-tuning không chỉ thất bại; nó còn làm suy giảm những câu trả lời bạn không train.

Nửa đó đã rõ. Nửa kinh tế thì chưa, và đó là phần còn lại của chương.

Một trường hợp, chạy theo ba cách: hỗ trợ kỹ thuật trên chính tài liệu của bạn, thứ thay đổi hằng tuần.

Corpus là thật và nằm trên ổ đĩa này: 23 tài liệu Markdown mà một repository phần mềm đang hoạt động giữ làm tài liệu nội bộ — hướng dẫn build, quy tắc thương hiệu, translation brief, mười manual dịch vụ, ghi chú performance và security. Đo bằng o200k_base, encoding từ Chương 7:

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

Bốn mươi ba nghìn token là kích thước thuận lợi cho quyết định này: nó vừa bất kỳ context window hiện đại nào, nên cả ba route đều thật sự khả dụng. Ở mức mười triệu thì quyết định đã được đưa ra hộ bạn, và đó là retrieval.

Bây giờ là công việc mà từ "hằng tuần" đang làm. Độ biến động của tài liệu thường chỉ được khẳng định; ở đây nó được đếm, từ lịch sử phiên bản của repository đó:

Tài liệu dịch chuyển khoảng mỗi hai tuần một lần. Các chuỗi người dùng nhìn thấy — thứ mà bộ phận hỗ trợ thực sự bị hỏi — đã thay đổi mỗi tuần kể từ khi tồn tại, với khoảng hai mươi commit mỗi tuần. Route nào được chọn cũng phải sống sót qua điều đó, và "thứ bạn train trên đó thay đổi thường xuyên đến mức nào?" hóa ra có một con số trong chính repository của bạn, chứ không phải một ý kiến.

Hai mươi câu hỏi hỗ trợ thực tế được viết dựa trên corpus này, mỗi topic một câu, và mọi số liệu bên dưới được tính trên hai mươi câu đó.

Cách đơn giản nhất có hiệu quả: đặt toàn bộ corpus vào system prompt, câu hỏi ở cuối, và để mô hình tự tìm.

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

Mọi con số ở đó đều được đếm, trừ con số cuối: 150 output token là một giả định, được chọn trong phạm vi các lượt assistant mà Chương 16 đã tính phí. Đây là con số duy nhất ở đây không được thực thi, nó được áp dụng giống hệt cho cả ba route, và phần break-even cho thấy chính xác kết luận dịch chuyển bao nhiêu khi bạn thay đổi nó.

Ở mức giá đọc từ trang của provider ngày 7 tháng 9 năm 2026 — $1.50 cho mỗi triệu input token, $9.00 cho mỗi triệu output⁶ — chi phí là $0.066317 mỗi câu hỏi. Bạn đang trả tiền để đọc lại bốn mươi ba nghìn token nhằm trả lời mười ba token.

Cách sửa của Chương 16 áp dụng trực tiếp: corpus ổn định và nằm ở đầu, nên nó là cache prefix hoàn hảo, và đọc lại nó chỉ tốn một phần mười — $0.007864 mỗi câu hỏi, giảm 88 %. Cảnh báo của Chương 16 cũng áp dụng, đúng dạng mà chương đó đã gắn cờ nhưng chưa định giá. Provider này không tính premium khi ghi; họ tính tiền thuê. Một cache tường minh tốn $0.000001 cho mỗi token được lưu mỗi giờ,⁶ nên giữ 43,298 token luôn warm tốn

dù có ai hỏi gì hay không. Đó là $189.78 trong sáu tháng, cho một căn phòng trống. Chia tiền thuê cho khoản tiết kiệm trên mỗi câu hỏi, điều kiện hiện ra trong một dòng: cache corpus này tự hoàn vốn khi vượt 0.74 câu hỏi mỗi giờ — 546 câu mỗi tháng khi tính cả việc rebuild cache hằng tuần. Dưới mức đó, tính năng bạn bật để tiết kiệm tiền lại làm bạn mất tiền.

Cùng route, cùng code, một flag, hóa đơn gấp năm lần. Chương 16 đã tìm thấy một phiên bản của chuyện này do timestamp đặt sai chỗ; ở đây không có gì sai ngoài traffic. Cache là một canh bạc vào volume, và với provider này bạn đặt cược theo giờ.

Retriever của Chương 19, không thay đổi: cắt theo ranh giới section với header theo ngữ cảnh, index, đặt bốn đoạn trích tốt nhất vào prompt. Đo trên hai mươi câu hỏi:

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

Ít prompt token hơn bốn mươi hai lần so với route một, với $0.002906 mỗi câu hỏi. Index tốn $0.0070 để build ở mức $0.15 cho mỗi triệu embedding token⁶ — chưa bằng chi phí của ba câu hỏi — và cũng tốn $0.0070 để rebuild từ đầu mỗi khi tài liệu thay đổi. Rebuild toàn bộ index mỗi tuần trong sáu tháng tốn mười tám xu.

Có một điều đáng dừng lại. Retrieval phá prompt caching. Stable prefix bây giờ là system instruction 140 token; từ token 141, prompt khác nhau ở mỗi call, vì các đoạn trích được chọn theo từng câu hỏi. Và 140 token nằm dưới mọi ngưỡng tối thiểu để cache mà Chương 16 đã trích dẫn. Vì vậy route hai không thể cache chút nào, nghe có vẻ tệ nhưng không tệ: không cache 1,037 token rẻ hơn cache 43,298 token.

Đó là một quy tắc chung đáng mang theo: hai kỹ thuật tiết kiệm token lớn loại trừ nhau trên cùng một nội dung, và kỹ thuật thắng là kỹ thuật loại bỏ nhiều token hơn. Retrieval loại bỏ 97.6 % trong số chúng.

Train trên hai trăm ví dụ theo house style, rồi hỏi không kèm tài liệu nào.

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

Training tốn 24,389 × 3 × $10.00 mỗi triệu = $0.7317. Đó là toàn bộ chi phí xây dựng, rẻ hơn một cốc cà phê, và chính vì thế rất nhiều team trả khoản này trước khi kiểm tra xem nó có giúp gì không.

Giờ đến cái bẫy, và đó là lý do chương này tồn tại. Một mô hình fine-tuned không có cùng chi phí chạy như base model của nó. Trang pricing nói trong một câu: "for model inference starting from Gemini 3, tuned model endpoint prediction price will be 1.5 times of the base model."⁶ Không phải training. Là inference, trên mọi token, trong suốt vòng đời mô hình.

Vậy đưa nó vào công thức. Gọi $p_i$ và $p_o$ là giá input và output cơ sở, $m$ là tuned multiplier, $L_R$ là độ dài prompt của route bạn đang thay thế, $L_F$ là độ dài prompt sau fine-tuning, và $O$ là độ dài câu trả lời. Fine-tuning chỉ rẻ hơn trên mỗi câu hỏi khi

Hạng đầu tiên thì hiển nhiên: prompt mới ngắn hơn của bạn, có markup. Hạng thứ hai thì không, và đó là nơi tiền chảy đi — phụ phí trên câu trả lời, thứ không liên quan gì tới prompt của bạn và training không thể làm ngắn lại. Với các con số đã đo — $m = 1.5$, $L_F = 28$, $O = 150$, $p_o/p_i = 6$ — ngưỡng là

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

Ở độ dài câu trả lời đã đo, 492 token — trong đó 450 là phụ phí câu trả lời, không phải prompt. Thay thế một prompt ngắn hơn ngưỡng đó sẽ đắt hơn trên mỗi câu hỏi, mãi mãi, ở mọi volume; và ngưỡng tăng tuyến tính theo mức độ assistant của bạn nói nhiều, nên một assistant viết câu trả lời dài không thể fine-tune để có token rẻ hơn, dù xóa được bao nhiêu prompt.

Cùng sự thật nhìn từ đầu kia là câu cần nhớ. Trong $0.002088 mỗi câu hỏi của route fine-tuned, 97.0 % là câu trả lời. Fine-tuning tối ưu ba phần trăm còn lại.

Bốn con số mô tả bất kỳ route nào trong số này: bạn trả gì một lần, bạn trả gì khi tài liệu thay đổi, bạn trả gì theo giờ bất kể có dùng hay không, và bạn trả gì trên mỗi câu hỏi. Điều đó mở rộng computeCost của Chương 16 mà không sửa nó.

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

Mô hình tuned không phải một bảng giá khác, mà là cùng bảng giá được nhân lên:

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

Dòng được nhấn mạnh đó chính là toàn bộ lập luận của phần trước được viết thành code: multiplier cũng rơi lên output.

Sáu tháng, với tài liệu được làm mới hằng tuần:

Và các điểm giao, tức bốn con số mà ngân sách thật sự cần:

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

Hãy đọc hai dòng đầu cùng nhau, vì đó là trọng tâm của chương. Một corpus đứng yên khiến fine-tuning hoàn vốn sau một trăm năm mươi câu hỏi; một corpus thay đổi hằng tuần đẩy cùng điểm giao đó lên hai mươi bảy lần, và mô hình không thay đổi gì — chỉ thay đổi tần suất bạn phải trả tiền lại cho nó. Chi phí xây dựng là chú thích; chi phí bảo trì mới là quyết định.

Nếu bây giờ bạn kết luận rằng một support desk bận rộn nên fine-tune, phép tính đồng ý với bạn. Nó vẫn sai, và phần tiếp theo giải thích vì sao.

Bảng chi phí có một cột nó không thể tính, nên phần này chạy fine-tune: local, trên một mô hình mở nhỏ, với adapter viết tay thay vì lấy từ library. Chương 11 đã xây dựng LoRA; đây là nó, trên q_proj và v_proj của tất cả 24 layer của 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

Hai trăm ví dụ training được tạo cơ học từ corpus, nên chúng có thể tái lập: câu hỏi là tiêu đề section được chuyển thành câu hỏi, câu trả lời là chính text của section đó theo một house style cứng — một dòng bắt đầu bằng Short answer:, một dòng bắt đầu bằng Source: với đường dẫn file. Định dạng là form được dạy; đường dẫn là fact. Sau đó có hai con số trên hai mươi câu hỏi giữ lại: câu trả lời có ra đúng house style không, và nó có nêu file thật sự trả lời câu hỏi không?

Hai baseline làm bảng dễ đọc, và cả hai đến từ sự nhấn mạnh của Chương 4, không phải phần bổ sung sau cùng. Mười trong hai mươi câu trả lời đúng là cùng một file, nên một mô hình phớt lờ câu hỏi và luôn trả lời CLAUDE.md sẽ đạt 10/20. Và retriever có trần riêng: trên hai mươi câu hỏi này, bốn đoạn trích của nó chứa file đúng 14 lần và xếp file đó hạng nhất 7 lần, nên 14/20 là mức tối đa mà bất kỳ reader nào có thể đạt khi dùng nó.

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 đã được học, hoàn toàn và nhanh chóng. Từ không lên mười chín trên hai mươi, với adapter 540,672 tham số — 0.109 % của mô hình — trong năm phút training trên một bộ xử lý không thấy bóng dáng card đồ họa.

Facts thì không. Tám trên hai mươi không phân biệt được với mười điểm bạn có khi phớt lờ hoàn toàn câu hỏi, và khoảng tin cậy của Chương 4 trên hai mươi mẫu nói thẳng điều đó. Những đường dẫn file đó đã nằm trong training data ba lần; thứ đi ra là thói quen kết thúc bằng một dòng Source: trông có vẻ hợp lý. Khi được hỏi câu ở đầu chương này, mô hình fine-tuned trả lời Short answer: 10.x . . . và cite CLAUDE.md. Câu trả lời đúng, nằm trong CLAUDE.md, là 18.17.0.

Rồi form cũng vỡ, và đó là hàng biện minh cho thí nghiệm. Đưa cho mô hình fine-tuned một nghìn token đoạn trích retrieved — một hình dạng prompt nó chưa từng thấy, vì mọi training prompt đều là hai mươi tám token — và house style sụp từ 19/20 xuống 1/20. Với câu hỏi ở đầu chương này, nó trả lời 18.17.0 — đúng, và không còn định dạng nào nó đã được train. Vậy fine-tuning không dạy một định dạng; nó dạy một định dạng có điều kiện trên các prompt trong training set, và prompt đầu tiên trông khác đã mang định dạng đi cùng nó. Thứ bạn fine-tune trên đó trở thành input distribution duy nhất mà mô hình của bạn giỏi, và không ai đưa điều đó vào spreadsheet.

Một ghi chú cuối về metric, chỉ thẳng tới Chương 29: "correct source" chấm form và fact cùng nhau, đó là lý do cả hai hàng retrieval trông rất tệ dù cả hai mô hình đều trả lời đúng fact của câu hỏi đó. Một con số end-to-end đã che ba thứ — một retriever ở recall 14/20, một reader 0.5B và một citation format — và chọn sửa cái nào nghĩa là tách chúng ra trước khi đo, không phải sau đó.

Giờ đến cột mà các vendor điền hộ bạn. Một mô hình fine-tuned không phải tài sản bạn sở hữu; nó là hợp đồng thuê base model của người khác, với ngày kết thúc in sẵn. Ngày 7 tháng 9 năm 2026, mục fine-tuning trên trang pricing của OpenAI có nguyên văn thông báo này:

OpenAI đang thu hẹp nền tảng fine-tuning. Nền tảng này không còn mở cho người dùng mới, nhưng người dùng hiện tại của nền tảng fine-tuning sẽ có thể tạo training jobs trong những tháng tới. Tất cả mô hình fine-tuned sẽ tiếp tục khả dụng cho inference cho đến khi base model của chúng bị deprecated.⁷

Timeline được ghi đến từng ngày: 7 tháng 5 năm 2026, đóng với các tổ chức chưa từng fine-tune; 2 tháng 7 năm 2026, đóng với những tổ chức không chạy inference trên mô hình fine-tuned trong sáu mươi ngày; 6 tháng 1 năm 2027, không còn job mới nào.⁸ Cùng trang đó lên lịch shutdown chính các mô hình fine-tuned — ft-gpt-3.5-turbo, ft-gpt-4, ft-gpt-4.1-nano, ft-babbage-002, ft-davinci-002 — vào 23 tháng 10 năm 2026, mỗi mô hình có một base model thay thế được khuyến nghị, cách nói lịch sự của: train lại đi.

Frontier vendor còn lại chưa từng bán cho bạn hợp đồng thuê đó. Index tài liệu của Anthropic liệt kê 699 trang và không trang nào nói về fine-tuning; các mục model-customisation trên trang pricing của Bedrock bao phủ Amazon Nova, Amazon Titan, Cohere, Meta và các mô hình OpenAI open-weight, nhưng không có Claude.⁹¹⁰ Nếu kiến trúc của bạn phụ thuộc vào một fine-tune, một trong ba họ frontier đơn giản là không khả dụng ở bất kỳ ngân sách nào.

Self-hosting thay hợp đồng thuê mô hình bằng hợp đồng thuê máy, và AWS tự làm phép tính đó trên trang của họ: một model unit của provisioned throughput cho mô hình tùy chỉnh, cam kết một tháng, là "1 model unit × $21.18 × 24 hours × 31 days = $15,757.92" mỗi tháng.¹⁰ Thuê phần cứng trực tiếp rẻ hơn nhưng không miễn phí — $3.99 mỗi GPU-giờ on demand cho H100, $1.99 preemptible¹¹ — khoảng $2,900 mỗi tháng cho một card phải bật dù có ai hỏi gì hay không. Toàn bộ route retrieval ở mười nghìn câu hỏi mỗi tháng là $174.52 cho sáu tháng.

Đây là nơi LoRA xứng đáng có mặt, như một lập luận ngân sách thay vì kỹ thuật. Đo trên cùng mô hình, một adapter rank-16 trên attention và các layer feed-forward có 8,798,208 tham số — 1.781 % của mô hình, 17.6 MB ở bfloat16 — so với 0.988 GB base weights, và optimizer cùng gradient state của nó là 140.77 MB trong khi full fine-tuning cần 7.90 GB, hệ số 56. Hệ quả không phải training rẻ hơn mà là một base model đã load có thể phục vụ nhiều adapter, đó là cách duy nhất để chi phí cố định của GPU được chia nhỏ. Managed training phản ánh điều đó: $0.48 mỗi triệu token low-rank tới 16B so với $0.54 full, với mức tối thiểu $4.00 mỗi job.¹¹ Mức sàn đó mới là chi tiết. Với 24,389 token trong ba epoch, mỗi lần retraining trên corpus này bị tính $4.00 thay vì $0.04 như phép tính — $104 tiền tối thiểu qua hai mươi sáu lần chạy hằng tuần, cho chín mươi mốt xu số học.

Hai cột nữa chỉ xuất hiện trên hóa đơn.

Data residency tốn khoảng mười phần trăm, và hai provider đồng ý về con số đó. OpenAI tính "a 10 % uplift" trên endpoint data-residency cho các mô hình phát hành từ ngày 5 tháng 3 năm 2026 trở đi;⁷ Vertex định giá endpoint non-global ở $1.65 so với $1.50, cùng mười phần trăm.⁶ Đặt điều đó cạnh năm mươi phần trăm mà tuned endpoint tốn thêm và truyền miệng bị đảo ngược: residency rẻ còn fine-tuning thì không — và fine-tuning cũng không phải lựa chọn private, vì corpus vẫn tới provider theo cách nào đó, một lần lúc training thay vì một lần mỗi call.

Mức giá rõ ràng nhất từng được đặt lên dữ liệu của bạn nằm trên cùng trang, nơi liệt kê một mô hình fine-tuned hai lần: bật data sharing thì inference đúng bằng một nửa — $2.00 so với $4.00 input, $8.00 so với $16.00 output.⁷ Cho phép provider giữ thứ bạn gửi đáng giá chiết khấu 50 %, và điều đó cho bạn biết nó đáng giá thế nào với họ.

Distillation — train một mô hình nhỏ của riêng bạn trên câu trả lời của mô hình lớn — thường được đưa ra như lối thoát khỏi cả hai. Định giá nó thì không phải, vì teacher chính là hệ thống bạn đang cố thay thế: tạo hai trăm ví dụ training bằng cách hỏi route retrieval hai trăm câu tốn 200 × $0.002906 = $0.58, ngoài $0.73 để train trên chúng. Distillation là việc bạn làm sau khi pipeline retrieval chạy được, để làm nó rẻ hơn, và nó thừa hưởng mọi fact mà retriever lấy sai.

Tiền là nửa nhìn thấy. Nửa còn lại đến dưới dạng chờ đợi, với cùng nguyên nhân như hóa đơn: mô hình đọc toàn bộ prompt trước khi nói một từ. Chương 13 đo prefill so với decode trên một mô hình bạn có thể chạm vào; đây là cùng phép đo, một lần chạy, một máy, theo độ dài prompt:

Các con số tuyệt đối thuộc về một mô hình 0.5B trên mười sáu CPU thread và không nói gì về hosted frontier model. Hình dạng thì chuyển nguyên vẹn: prefill tăng theo độ dài prompt, và cost per token nhích lên khi hạng bậc hai của Chương 9 bắt đầu hiện ra — 4.79 ms ở một nghìn token so với 6.04 ms ở tám nghìn, penalty 26 % chỉ vì dài hơn.

Hệ quả cho ba route là trực tiếp. Route một prefill bốn mươi ba nghìn token mỗi câu hỏi, và cache hit là thứ khiến điều đó chịu được — Chương 16 đã giải thích vì sao: cache read thay thế công việc prefill, nên nó mua latency và tiền trong cùng một giao dịch. Route hai prefill một nghìn và thêm một round trip tới index trước. Route ba prefill hai mươi tám và không thêm gì, nên nó nhanh nhất trong ba cách khi trả lời, một cách đo được. Nó chỉ đang trả lời sai thứ.

Ba thất bại trông như vấn đề mô hình nhưng không phải — mười phút ở đây tiết kiệm một tháng về sau:

Và yêu cầu bao trùm tất cả: quyết định này không thể được đưa ra nếu thiếu evaluation set, và vendor bán fine-tune cũng nói vậy. Guide của OpenAI mở đầu bằng "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", và thêm rằng nếu năm mươi ví dụ tốt không thay đổi gì, vấn đề nằm ở task hoặc prompt, không phải data volume.¹ Hai mươi câu hỏi, đúng như chương này dùng, cho thấy một cơ chế và không thể chọn supplier — Chương 4 đã đo vì sao, và cần làm gì khi hai mươi case là tất cả những gì bạn có — lặp lại chúng, ghép cặp chúng, và đo độ spread giữa các lần chạy — là Chương 29.

Bốn cột, và chỉ cột cuối quyết định:

Quy tắc rút ra, đủ ngắn để nhớ: bắt đầu với prompt; thêm retrieval khi facts dịch chuyển; chỉ fine-tune khi bạn đã đo rằng thứ vẫn thiếu là một hình dạng, không phải một fact — và hãy định giá câu trả lời, không phải prompt, trước khi làm.

Phiên bản khó chịu, dành cho những ai đến đây sau khi đã quyết: trong case đã đo của chương này, fine-tuning là route rẻ nhất khi vượt bốn nghìn câu hỏi mỗi tháng, và về facts thì nó vẫn không thắng được việc trả lời CLAUDE.md cho mọi thứ.

Mọi giá ở đây đều tính theo token, và mọi route là một cách sắp xếp token khác nhau. Điều đó sắp không còn đúng nữa.

Chương 21 rời khỏi text. Một image đi vào mô hình không phải string mà là lưới patch với số token bạn không chọn; một phút nói được một provider tính theo giây và provider khác tính theo audio token; synthetic speech được bán theo ký tự, transcription theo phút, raw compute theo GPU-giây. Câu hỏi mà chương này trả lời bằng một hàm chi phí — cái nào rẻ hơn? — thậm chí không thể được hỏi cho tới khi các đơn vị khớp nhau, và không calculator nào trên internet chuẩn hóa chúng.

Đó cũng là nơi training xuất hiện trở lại: một image adapter với trigger word, và một voice được clone từ mẫu. Điều này đặt ra câu hỏi mà chương tiếp theo mở đầu, và nó không phải câu hỏi tu từ: nếu fine-tuning một language model hầu như luôn là khoản mua sai, vì sao fine-tuning một image model hầu như luôn là khoản mua đúng?

Mọi mức giá, ngưỡng và multiplier trong chương này được đọc từ chính trang của provider vào 7 tháng 9 năm 2026 và được trích với ngày đó, vì tất cả sẽ thay đổi. Các số liệu đo được — token count, chunk size, retrieval size, training loss, score, latency và count từ version history — được tạo trên một máy trong cùng ngày và có thể tái lập từ corpus mô tả ở trên.

Các thí nghiệm local dùng Qwen/Qwen2.5-0.5B-Instruct với greedy decoding, nên chúng tái lập chính xác; adapter là class mười hai dòng được in ở trên, ở rank 8 trên q_proj và v_proj. Corpus là tài liệu Markdown được track của một repository phần mềm đang hoạt động, không gồm hai log append-only, và tốc độ thay đổi của nó được đếm từ version history của repository đó.