Fine-Tune, Retrieval, Prompt? 결정은 경제성입니다

"fine-tune해야 할까?"는 마치 model에 관한 질문처럼 묻습니다. 하지만 이것은 budget에 관한 질문이며, benchmark가 답하지 못하는 형태를 가집니다. 한 번 무엇을 지불하는지, 질문마다 무엇을 지불하는지, 세상이 바뀔 때마다 다시 무엇을 지불하는지입니다.

세 경로는 하나의 일을 하는 세 가지 방식도 아니며, vendor들도 대부분의 blog post보다 더 분명하게 그렇게 말합니다. OpenAI가 supervised fine-tuning이 가장 적합한 용도를 정리한 표에는 네 가지가 있습니다. classification, nuanced translation, 특정 format의 content 생성, instruction-following 실패 교정입니다.¹ 그 어디에도 "model이 모르는 것을 가르치기"는 없습니다. 이점 요약도 "더 적은 예시와 context data로 더 짧은 prompts를 사용할 수 있어 scale에서 token 비용을 절감하고 latency를 낮출 수 있다"입니다 — 이 기능을 파는 회사가 말하는, invoice에 관한 주장입니다.

그러므로:

• Fine-tuning은 형식과 행동을 가르칩니다. 어조, format, 답변의 형태, 설명할 수는 없지만 보여줄 수 있는 boundary입니다. 가장 강한 공개 버전은 LIMA의 Superficial Alignment Hypothesis입니다. 지식은 pretraining에서 오고, alignment는 주로 어떤 format의 sub-distribution으로 말할지를 가르칩니다 — 그래서 거기서는 선별된 예시 1,000개로 충분했습니다.²
• Retrieval은 변하는 사실을 공급합니다. 세 가지 중 문서를 수정했을 때 model을 건드리지 않고 답변에 반영되는 유일한 방식입니다.
• Prompting은 대부분의 실제 사례를 커버합니다, 그리고 정직한 baseline입니다. In-context learning은 Language Models are Few-Shot Learners 이후 기본값이었습니다. task를 prompt 안에서 보여주고 weight는 움직이지 않습니다.³

가운데의 실수를 두 편의 측정 논문이 닫아줍니다. Ovadia와 동료들은 unsupervised fine-tuning으로 지식을 주입하는 것과 retrieval로 주입하는 것을 비교했고, base model이 pretraining에서 이미 본 사실까지 포함해 retrieval이 일관되게 이겼습니다.⁴ Gekhman과 동료들은 피해를 측정했습니다. 새로운 지식을 도입하는 예시는 천천히 fitted되고, model이 마침내 그것을 fit할수록 다른 질문에서 hallucination rate가 올라갑니다.⁵ fine-tuning으로 사실을 가르치는 것은 단순히 실패하는 데 그치지 않습니다. training하지 않은 답변까지 악화시킵니다.

그 절반은 결론이 났습니다. 경제적 절반은 아직이며, 나머지 장이 그것입니다.

하나의 사례를 세 방식으로 실행합니다. 매주 바뀌는 자체 문서에 대한 기술 지원입니다.

corpus는 실제이며 이 disk 위에 있습니다. 실제로 쓰이는 software repository 하나가 내부 문서로 보관하는 23개의 Markdown 문서입니다 — build guide, brand rules, translation brief, 10개의 service manual, performance와 security notes입니다. Chapter 7의 encoding인 o200k_base로 측정했습니다.

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

4만 3천 token은 이 결정을 내리기에 편안한 크기입니다. 현대적인 window라면 어디든 들어가므로 세 경로가 모두 실제로 가능합니다. 천만이라면 결정은 이미 내려져 있고, 그것은 retrieval입니다.

이제 "weekly"라는 말이 하는 일을 봅니다. 문서 churn은 보통 주장으로 끝납니다. 여기서는 해당 repository의 version history에서 세었습니다.

문서는 대략 격주로 움직입니다. user-visible string — 지원 desk가 실제로 질문받는 것 — 은 존재한 모든 주에 움직였고, 주당 약 20개의 commit이 있었습니다. 어떤 경로를 선택하든 이것을 견뎌야 하며, *"training한 대상은 얼마나 자주 바뀌는가?"*는 의견이 아니라 여러분 자신의 repository 안에 숫자로 있습니다.

이 corpus를 기준으로 현실적인 지원 질문 20개를 작성했습니다. topic당 하나이며, 아래 모든 수치는 그 20개를 기준으로 계산했습니다.

작동하는 가장 단순한 방법입니다. 전체 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

마지막을 제외한 모든 숫자는 실제로 세었습니다. output token 150개는 가정이며, Chapter 16에서 과금한 assistant turn 범위 안에서 선택했습니다. 여기서 실행되지 않은 유일한 수치이고, 세 경로 모두에 동일하게 적용되며, break-even section은 이것을 바꾸면 결론이 얼마나 움직이는지 정확히 보여줍니다.

2026년 9월 7일 provider page에서 읽은 rate — input token 백만 개당 $1.50, output 백만 개당 $9.00⁶ — 로 계산하면 질문 하나에 $0.066317입니다. 13개 token으로 답하기 위해 4만 3천 token을 다시 읽는 비용을 내고 있습니다.

Chapter 16의 해결책이 그대로 적용됩니다. corpus는 안정적이고 앞에 있으므로 완벽한 cache prefix이며, 다시 읽는 비용은 10분의 1 — 질문 하나에 $0.007864, 88 % 절감입니다. Chapter 16의 warning도 그대로 적용됩니다. 그 장이 표시만 하고 가격을 매기지 않았던 형태입니다. 이 provider는 write premium을 청구하지 않습니다. rent를 청구합니다. explicit cache는 stored token당 시간당 $0.000001입니다.⁶ 따라서 43,298 token을 warm하게 유지하는 비용은

아무도 질문하지 않아도 발생합니다. 이것은 6개월 동안 $189.78, 빈 방에 대한 비용입니다. rent를 질문당 절감액으로 나누면 조건은 한 줄로 나옵니다. 이 corpus를 caching하는 것은 시간당 0.74개 질문을 넘을 때 본전입니다 — weekly cache rebuild까지 계산하면 월 546개입니다. 그보다 낮으면 돈을 아끼려고 켠 기능이 오히려 돈을 잃게 합니다.

같은 경로, 같은 code, flag 하나, 다섯 배의 청구서입니다. Chapter 16은 timestamp가 잘못된 위치에 있어서 생긴 버전을 찾았습니다. 여기서는 traffic 말고는 아무것도 잘못되지 않았습니다. cache는 volume에 대한 bet이며, 이 provider에서는 시간 단위로 그 bet을 겁니다.

Chapter 19의 retriever를 그대로 사용합니다. section boundary에서 contextual header와 함께 자르고, index를 만들고, 가장 좋은 네 개의 발췌문을 prompt에 넣습니다. 20개 질문에서 측정했습니다.

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

경로 1보다 prompt token이 42배 적고, 질문 하나에 $0.002906입니다. index 구축 비용은 embedding token 백만 개당 $0.15⁶일 때 $0.0070입니다 — 질문 세 개도 안 되는 비용 — 문서가 바뀔 때마다 처음부터 rebuild해도 같은 $0.0070입니다. 6개월 동안 매주 전체 index를 rebuild해도 18센트입니다.

여기서 멈춰 볼 만한 점이 하나 있습니다. Retrieval은 prompt caching을 파괴합니다. 이제 stable prefix는 140-token system instruction입니다. token 141부터는 call마다 prompt가 달라집니다. 발췌문이 질문별로 선택되기 때문입니다. 그리고 140 token은 Chapter 16이 인용한 모든 cache minimum보다 낮습니다. 따라서 경로 2는 전혀 caching할 수 없습니다. 나쁘게 들리지만 그렇지 않습니다. 1,037 token을 caching하지 않는 것이 43,298 token을 caching하는 것보다 저렴합니다.

가져갈 만한 일반 규칙입니다. 두 가지 큰 token 절감 기법은 같은 content에서는 서로 배타적이며, 이기는 것은 더 많은 token을 제거하는 쪽입니다. Retrieval은 그중 97.6 %를 제거합니다.

house style의 예시 200개로 training한 뒤, 문서를 전혀 붙이지 않고 질문합니다.

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

training 비용은 24,389 × 3 × 백만 개당 $10.00 = $0.7317입니다. 전체 구축 비용이 커피 한 잔보다 낮습니다. 그래서 많은 팀이 도움이 되는지 확인하기 전에 이 비용을 먼저 냅니다.

이제 함정입니다. 이것이 이 장이 존재하는 이유입니다. fine-tuned model은 실행 비용이 base model과 같지 않습니다. pricing page는 한 문장으로 말합니다. "Gemini 3부터 model inference의 경우, tuned model endpoint prediction price는 base model의 1.5배가 됩니다."⁶ training이 아닙니다. inference입니다. model이 살아 있는 동안, 모든 token마다입니다.

그러니 공식에 넣어봅니다. $p_i$와 $p_o$를 base input 및 output price, $m$를 tuned multiplier, $L_R$를 대체하려는 경로의 prompt length, $L_F$를 fine-tuning 이후 prompt length, $O$를 answer length라고 하겠습니다. fine-tuning이 질문당 더 저렴한 것은 오직 다음 조건에서입니다.

첫 번째 항은 분명합니다. markup된 새 short prompt입니다. 두 번째는 그렇지 않으며, 돈이 가는 곳입니다 — answer에 붙는 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개는 prompt가 아니라 answer surcharge입니다. 그보다 짧은 prompt를 대체하면 어떤 volume에서도 질문당 비용이 영원히 더 비쌉니다. 그리고 threshold는 assistant가 말하는 양에 비례해 선형으로 커지므로, 긴 답변을 쓰는 assistant는 아무리 prompt를 많이 지워도 fine-tuning으로 더 싼 token에 도달할 수 없습니다.

같은 사실을 반대쪽에서 보면 기억할 문장이 됩니다. fine-tuned route의 질문당 $0.002088 중 97.0 %가 answer입니다. Fine-tuning은 나머지 3 %를 최적화합니다.

이들 경로는 네 숫자로 설명할 수 있습니다. 한 번 내는 비용, 문서가 바뀔 때 내는 비용, 아무 일 없어도 시간마다 내는 비용, 질문마다 내는 비용입니다. 이것은 Chapter 16의 computeCost를 수정하지 않고 확장합니다.

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가 아니라, 같은 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된 그 한 줄이 이전 section의 전체 논증을 code로 쓴 것입니다. multiplier는 output에도 적용됩니다.

문서를 매주 refresh하는 6개월 기준입니다.

그리고 crossover입니다. budget이 실제로 필요로 하는 네 숫자입니다.

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

첫 두 개를 함께 읽어야 합니다. 그것이 이 장의 핵심입니다. stationary corpus라면 fine-tuning은 150개 질문에서 본전을 찾습니다. 매주 바뀌는 corpus는 같은 crossover를 27배 움직입니다. model에 관해서는 아무것도 바뀌지 않았습니다 — 다시 비용을 내는 빈도만 바뀌었습니다. construction cost는 footnote입니다. maintenance cost가 결정입니다.

이제 바쁜 support desk는 fine-tune해야 한다고 결론 내린다면, 산술은 여러분에게 동의합니다. 그래도 틀렸습니다. 다음 section이 그 이유입니다.

비용표에는 계산할 수 없는 column이 하나 있으므로, 이 section은 fine-tune을 실행합니다. local에서, 작은 open model로, library에서 가져오지 않고 손으로 쓴 adapter를 사용합니다. Chapter 11은 LoRA를 만들었습니다. 여기서는 Qwen2.5-0.5B-Instruct의 24개 layer 전체에 있는 q_proj와 v_proj에 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 example 200개는 corpus에서 기계적으로 만들어졌으므로 재현됩니다. question은 section heading을 질문으로 바꾼 것이고, answer는 그 section 자신의 text를 딱딱한 house style로 쓴 것입니다 — Short answer:로 시작하는 한 줄, file path가 있는 Source:로 시작하는 한 줄입니다. format은 가르치는 form이고, path는 fact입니다. 그런 다음 held-out question 20개에 대해 두 숫자를 봅니다. answer가 house style로 나오는가, 그리고 그 질문에 실제로 답하는 file을 이름으로 말하는가입니다.

두 baseline이 표를 읽기 쉽게 만들며, 둘 다 사후 생각이 아니라 Chapter 4의 insistence입니다. 20개 정답 중 10개는 같은 file이므로, 질문을 무시하고 항상 CLAUDE.md라고 답하는 model은 10/20을 받습니다. 그리고 retriever에는 자체 ceiling이 있습니다. 이 20개 질문에서 네 발췌문 안에 right file이 14번 들어 있었고 7번은 1위였으므로, 이를 사용하는 어떤 reader도 받을 수 있는 최고 점수는 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

form은 완전히, 빠르게 학습됐습니다. graphics card가 보이지 않는 processor에서 5분 training으로, model의 0.109 %인 540,672-parameter adapter가 0에서 20개 중 19개로 올라갔습니다.

fact는 그렇지 않았습니다. 20개 중 8개는 질문을 완전히 무시하면 얻는 10개와 구별되지 않으며, Chapter 4의 20-sample interval이 그것을 큰 소리로 말해줍니다. 그 file path들은 training data 안에 세 번씩 있었습니다. 나온 것은 그럴듯해 보이는 Source: 줄로 끝내는 습관이었습니다. 이 장 맨 위의 질문을 하자 fine-tuned model은 Short answer: 10.x . . .라고 답하고 CLAUDE.md를 cite했습니다. CLAUDE.md에 있는 정답은 18.17.0입니다.

그리고 form이 깨졌습니다. 이것이 실험을 정당화하는 행입니다. fine-tuned model에 retrieved extracts 1,000 token을 건네면 — 모든 training prompt가 28 token이었으므로 한 번도 보지 못한 prompt shape입니다 — house style은 19/20에서 1/20으로 무너집니다. 이 장 맨 위의 질문에서는 18.17.0라고 답합니다 — 정답이지만, training된 format은 하나도 없습니다. 따라서 fine-tuning은 format을 가르친 것이 아닙니다. training set 안의 prompts에 조건부인 format을 가르친 것이며, 처음으로 달라 보이는 prompt가 format을 함께 가져가 버렸습니다. 여러분이 fine-tune한 대상은 model이 잘하는 하나의 input distribution이 되며, 아무도 그것을 spreadsheet에 넣지 않습니다.

metric에 대한 마지막 note입니다. Chapter 29를 정면으로 가리킵니다. "correct source"는 form과 fact를 함께 채점합니다. 그래서 두 retrieval 행이 모두 끔찍해 보이지만, 두 model 모두 그 질문의 fact는 맞혔습니다. end-to-end 숫자 하나가 세 가지 — 14/20 recall의 retriever, 0.5B reader, citation format — 를 숨기고 있었고, 무엇을 고칠지 선택하려면 측정한 뒤가 아니라 측정하기 전에 분리해야 합니다.

이제 vendor가 대신 채워 넣는 column입니다. fine-tuned model은 여러분이 소유한 asset이 아닙니다. 종료일이 인쇄된, 남의 base model에 대한 lease입니다. 2026년 9월 7일 OpenAI pricing page의 fine-tuning section에는 다음 notice가 전문으로 실려 있었습니다.

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은 날짜까지 찍혀 있습니다. 2026년 5월 7일, 한 번도 fine-tune한 적 없는 organisation에는 닫혔습니다. 2026년 7월 2일, 60일 동안 fine-tuned model에서 inference를 실행하지 않은 organisation에는 닫혔습니다. 2027년 1월 6일, 새 job이 완전히 중단됩니다.⁸ 같은 page는 fine-tuned model 자체의 shutdown도 schedule합니다 — ft-gpt-3.5-turbo, ft-gpt-4, ft-gpt-4.1-nano, ft-babbage-002, ft-davinci-002 — 2026년 10월 23일이며, 각각 recommended replacement base model이 붙어 있습니다. 정중하게 말하면, 다시 training하라는 뜻입니다.

다른 frontier vendor는 lease를 판 적도 없습니다. Anthropic의 documentation index에는 699개 page가 있고, fine-tuning에 관한 것은 하나도 없습니다. Bedrock pricing page의 model-customisation section은 Amazon Nova, Amazon Titan, Cohere, Meta, OpenAI open-weight models를 다루며 Claude는 없습니다.⁹¹⁰ architecture가 fine-tune에 의존한다면, 세 frontier family 중 하나는 어떤 budget에서도 사용할 수 없습니다.

Self-hosting은 model에 대한 lease를 machine에 대한 lease로 바꾸며, AWS는 그 산술을 자신의 page에서 직접 합니다. customised model을 위한 provisioned throughput의 model unit 1개, 1개월 commitment는 "1 model unit × $21.18 × 24 hours × 31 days = $15,757.92"입니다.¹⁰ metal을 직접 renting하면 더 싸지만 공짜는 아닙니다 — H100 on demand는 GPU-hour당 $3.99, preemptible은 $1.99¹¹ — 아무도 질문하지 않아도 켜져 있어야 하는 card 하나에 대략 월 $2,900입니다. 월 1만 개 질문에서 retrieval route 전체 비용은 6개월에 $174.52입니다.

여기서 LoRA가 기술적 주장이 아니라 budget 주장으로 자리를 얻습니다. 같은 model에서 측정하면, attention과 feed-forward layer 위의 rank-16 adapter는 8,798,208 parameter입니다 — model의 1.781 %, bfloat16에서 17.6 MB — base weight 0.988 GB와 대비됩니다. 그리고 optimiser와 gradient state는 140.77 MB이고 full fine-tuning은 7.90 GB가 필요해 56배 차이가 납니다. 결과는 training이 더 싸다는 것이 아니라, 하나의 loaded base model이 많은 adapter를 serve할 수 있다는 것입니다. GPU의 fixed cost가 무언가로 나뉘는 유일한 방법입니다. managed training도 이를 반영합니다. 16B까지는 low-rank가 token 백만 개당 $0.48, full이 $0.54이며 job당 minimum은 $4.00입니다.¹¹ 그 floor가 detail입니다. 24,389 token을 3 epoch로 돌리면, 이 corpus의 retraining은 산술상 $0.04가 아니라 매번 $4.00가 청구됩니다 — 26번의 weekly run에서 산술상 91센트인 것이 minimum으로 $104가 됩니다.

invoice에만 나타나는 column 두 개가 더 있습니다.

Data residency는 약 10퍼센트가 들며, 두 provider가 그 수치에 동의합니다. OpenAI는 2026년 3월 5일 이후 release된 model의 data-residency endpoint에 "10 % uplift"를 부과합니다.⁷ Vertex는 non-global endpoint를 $1.50이 아니라 $1.65로 가격 책정합니다. 같은 10퍼센트입니다.⁶ tuned endpoint가 드는 50퍼센트와 비교하면 통념이 뒤집힙니다. residency는 싸고 fine-tuning은 그렇지 않습니다 — 그리고 fine-tuning이 private option도 아닙니다. corpus는 어느 쪽이든 provider에 도달하며, call마다 한 번이 아니라 training time에 한 번일 뿐입니다.

여러분의 data에 붙은 가장 노골적인 가격도 같은 page에 있습니다. 하나의 fine-tuned model을 두 번 나열하는데, data sharing이 enabled이면 inference가 정확히 절반입니다 — input $4.00 대비 $2.00, output $16.00 대비 $8.00입니다.⁷ provider가 여러분이 보낸 것을 보관하도록 허용하는 가치는 50 % discount입니다. 그것이 그들에게 얼마짜리인지 말해줍니다.

Distillation — 큰 model의 답변으로 여러분 자신의 작은 model을 training하는 것 — 은 보통 둘 모두에서 빠져나오는 방법으로 제시됩니다. 가격을 매겨보면 그렇지 않습니다. teacher가 여러분이 대체하려던 system이기 때문입니다. retrieval route에 질문 200개를 던져 training example 200개를 만들면 200 × $0.002906 = $0.58이 듭니다. 거기에 training 비용 $0.73이 추가됩니다. Distillation은 retrieval pipeline이 작동한 뒤에 더 싸게 만들기 위해 하는 일이며, retriever가 틀린 모든 fact를 상속합니다.

돈은 보이는 절반입니다. 다른 절반은 기다림으로 옵니다. 원인은 bill과 같습니다. model은 한 단어를 말하기 전에 전체 prompt를 읽습니다. Chapter 13은 만질 수 있는 model에서 prefill과 decode를 측정했습니다. 여기서는 같은 측정을 prompt length에 대해, 한 번, 한 machine에서 실행했습니다.

절대 숫자는 16개 CPU thread 위의 0.5B model에 속하며 hosted frontier model에 대해 아무것도 말하지 않습니다. shape은 정확히 이전됩니다. prefill은 prompt length와 함께 커지고, Chapter 9의 quadratic term이 보이기 시작하면서 token당 cost가 조금씩 올라갑니다 — 1,000 token에서 4.79 ms, 8,000 token에서 6.04 ms로, 그저 길다는 이유만으로 26 % penalty입니다.

세 경로에 대한 결과는 직접적입니다. 경로 1은 질문마다 4만 3천 token을 prefill하며, cache hit가 그것을 견딜 만하게 만듭니다 — Chapter 16이 이유를 설명했습니다. cache read는 prefill work를 대체하므로 latency와 money를 한 번에 삽니다. 경로 2는 1,000개를 prefill하고 먼저 index로 round trip을 추가합니다. 경로 3은 28개를 prefill하고 아무것도 추가하지 않으므로, 답변 속도에서는 세 가지 중 측정상 가장 빠릅니다. 단지 틀린 것에 답하고 있을 뿐입니다.

model 문제처럼 보이지만 그렇지 않은 실패 세 가지입니다 — 여기서 10분을 쓰면 나중에 한 달을 아낍니다.

그리고 그 전체에 걸친 requirement가 있습니다. 이 결정은 evaluation set 없이는 내릴 수 없으며, fine-tune을 판매하는 vendor도 그렇게 말합니다. OpenAI guide는 "evals를 설정한 뒤에만 fine-tuning에 투자하라. fine-tuned model이 base model보다 더 잘 수행하는지 판단할 reliable way가 필요하다"로 시작합니다. 또한 좋은 예시 50개로 아무 변화가 없다면 문제는 data volume이 아니라 task나 prompt라고 덧붙입니다.¹ 이 장에서 사용한 20개 질문은 mechanism을 보여줄 뿐 supplier를 선택할 수는 없습니다 — Chapter 4가 그 이유를 측정했고, 20개 case가 전부일 때 해야 할 일 — 반복하고, 짝지어 측정하고, run 사이의 spread를 재는 것 — 은 Chapter 29입니다.

네 column이 있으며, 마지막 column만 결정합니다.

여기서 나오는 규칙은 짧아서 기억할 만합니다. prompt로 시작하고, fact가 움직이면 retrieval을 추가하고, 아직 부족한 것이 fact가 아니라 shape임을 측정했을 때만 fine-tune하라 — 그리고 그 전에 prompt가 아니라 answer의 가격을 계산하라.

이미 결론을 정하고 온 사람에게 불편한 버전은 이렇습니다. 이 장에서 측정한 사례에서 fine-tuning은 월 4천 개 질문을 넘으면 가장 저렴한 경로입니다. 그리고 fact에서는 여전히 모든 것에 CLAUDE.md라고 답하는 것을 이기지 못합니다.

여기까지 모든 price는 token당이었고, 모든 경로는 token을 배열하는 다른 방식이었습니다. 이제 그것이 더 이상 사실이 아니게 됩니다.

Chapter 21은 text를 떠납니다. model에 들어가는 image는 string이 아니라 여러분이 선택하지 않은 token count를 가진 patch grid입니다. spoken minute은 어떤 provider에서는 초 단위로, 다른 provider에서는 audio token으로 과금됩니다. synthetic speech는 character로, transcription은 minute으로, raw compute는 GPU-second로 팔립니다. 이 장이 하나의 cost function으로 답한 질문 — 어느 쪽이 더 싼가? — 은 unit이 맞기 전에는 물어볼 수도 없고, 인터넷의 어떤 calculator도 그것들을 normalize하지 않습니다.

또한 training이 다시 등장하는 곳이기도 합니다. trigger word가 있는 image adapter, 그리고 sample에서 clone된 voice입니다. 이는 다음 장이 여는 질문으로 이어지며, 수사적 질문이 아닙니다. language model을 fine-tuning하는 것이 거의 항상 잘못된 구매라면, image model을 fine-tuning하는 것은 왜 거의 항상 올바른 구매일까요?

이 장의 모든 price, threshold, multiplier는 2026년 9월 7일 provider 자신의 page에서 읽었고 그 날짜와 함께 인용했습니다. 모두 움직일 것이기 때문입니다. 측정된 수치 — token count, chunk size, retrieval size, training loss, score, latency, version-history count — 는 같은 날 한 machine에서 생성했으며, 위에서 설명한 corpus로 재현할 수 있습니다.

local experiment는 greedy decoding과 함께 Qwen/Qwen2.5-0.5B-Instruct를 사용했으므로 정확히 재현됩니다. adapter는 위에 printed된 12-line class이며, q_proj와 v_proj 위에 rank 8로 적용했습니다. corpus는 실제로 쓰이는 software repository 하나의 tracked Markdown documentation이며, append-only log 두 개는 제외했습니다. change rate는 그 repository의 version history에서 세었습니다.