blog.ruahverce Vol · 2026 · Issue 013 — A field log of LLMs, RAG, and ML systems

Field Log · Entry

Model Routing과 Cascades: Compound AI System 설계 (10/10)

요청 특징과 정책 제약을 router가 분석해 작은 모델 RAG 강한 모델로 보내고 confidence gate가 필요할 때만 cascade하며 품질 비용 지연을 평가하는 구조

오늘의 결론

  • Router는 호출 전에 모델이나 경로를 고르고, cascade는 싼 경로의 결과를 본 후 부족할 때 강한 경로로 올립니다. Ensemble은 여러 결과를 동시에 만들어 결합하므로 비용 구조가 다릅니다.
  • “가장 싼 모델”이 목적 함수가 아닙니다. 품질·안전·지연 SLO를 만족하면서 기대 비용을 줄이거나, 예산 안에서 기대 효용을 최대화해야 합니다.
  • Router 학습에는 같은 요청에 대한 여러 후보 모델의 결과가 필요합니다. Production이 선택한 모델의 결과만 기록하면 선택되지 않은 모델의 counterfactual 품질을 알 수 없어 편향이 생깁니다.
  • Confidence threshold는 고정하지 않습니다. Task·언어·길이·retrieval 상태·모델 version별로 calibration하고, drift·load·provider 장애에 따라 fallback policy를 운영합니다.
  • RAG Agent에서 route는 모델 이름만 고르지 않습니다. Retrieval 여부, context budget, reasoning budget, verifier, tool policy까지 포함한 system configuration을 선택합니다.

앞 글에서는 여러 state와 action으로 이루어진 Agent episode를 학습했습니다. 시리즈 마지막 글에서는 매 요청과 episode에 어떤 모델·검색·검증·compute 경로를 배분할지 설계합니다.

request + tenant policy + load + conversation state
        ↓
pre-call router
  ├─ direct small model
  ├─ small model + retrieval
  ├─ strong model + retrieval + verifier
  └─ human / deny / unavailable
        ↓
candidate answer + uncertainty + evidence sufficiency
        ↓
cascade gate: accept / retrieve more / stronger model / ask / abstain
        ↓
task outcome + quality + cost + latency + safety → router learning and drift audit

이 글에서 답하는 질문

  1. Routing, cascade, ensemble은 무엇이 다른가?
  2. 품질·비용·지연을 하나의 최적화 문제로 어떻게 표현하는가?
  3. Router는 요청 전에 어떤 feature를 사용할 수 있는가?
  4. 선택되지 않은 모델의 counterfactual label을 어떻게 모으는가?
  5. RAG·tool·test-time compute를 모델과 함께 어떻게 route하는가?
  6. Drift, provider 장애, privacy, multi-turn consistency를 어떻게 운영하는가?

Pre-call router가 요청과 정책 및 load를 바탕으로 여러 system configuration을 선택하고 candidate 결과의 uncertainty와 evidence sufficiency를 cascade gate가 평가해 accept 또는 escalation하며 품질 비용 지연 안전을 학습하는 파이프라인

1. Compound AI System은 여러 구성 요소의 정책이다

하나의 거대한 모델에 모든 요청을 보내는 대신 여러 모델, retriever, verifier, tool, cache를 조합할 수 있습니다.

system configuration c
  = model
  + prompt / context policy
  + retrieval strategy
  + reasoning budget
  + verifier
  + tool allowlist
  + serving region / provider

Router가 고르는 action을 모델 ID 하나가 아니라 configuration $c\in\mathcal{C}$로 정의하면 실제 제품 의사결정에 가깝습니다.

예를 들어 다음 경로는 모두 다릅니다.

  • Small model, no retrieval, 256 output tokens
  • Small model, hybrid retrieval top-8, one verifier
  • Strong model, multi-hop retrieval, best-of-4
  • Domain model, private on-premise index, no external egress
  • Human escalation with collected evidence

이 조합이 Compound AI System의 실행 정책입니다.

2. Router, cascade, ensemble을 구분한다

Router: 결과를 보기 전에 고른다

입력 $x$와 시스템 상태 $z$를 보고 configuration을 선택합니다.

$$ c = \pi_\phi(x,z) $$

장점은 한 경로만 호출하므로 비용과 지연을 예측하기 쉽다는 점입니다. 단점은 답을 보기 전 난이도를 추정해야 한다는 점입니다.

Cascade: 먼저 싼 결과를 보고 결정한다

cheap model → answer + confidence
                    ├─ sufficient → accept
                    └─ insufficient → stronger path

FrugalGPT는 여러 LLM을 cascade로 조합해 비용·성능을 최적화하는 방향을 제시했고, AutoMix는 작은 모델 output의 approximate correctness를 바탕으로 더 큰 모델로 routing하는 접근을 연구했습니다.

Cascade는 쉬운 요청을 싸게 끝내고 어려운 요청만 올릴 수 있지만, escalation된 요청은 이미 싼 모델 비용과 지연을 지불했습니다.

Ensemble: 여러 결과를 만들고 결합한다

LLM-Blender는 여러 model output을 pairwise ranking하고 generative fusion하는 ensemble 방향을 제안했습니다. Ensemble은 diversity를 활용할 수 있지만 기본적으로 여러 호출 비용을 냅니다.

방식첫 결정 시점호출 수핵심 위험
Router출력 전보통 1난이도·품질 예측 오류
Cascade싼 출력 후1 이상이중 비용·tail latency
Ensemble병렬 출력 후여러 개높은 비용·fusion 오류

실전에서는 router로 후보 경로를 좁히고, 선택된 경로 안에서 cascade를 사용하는 hybrid가 흔합니다.

3. 목적 함수를 먼저 정의한다

요청 $x$에 configuration $c$를 선택했을 때 품질 $Q(x,c)$, 비용 $C(x,c)$, 지연 $L(x,c)$, 안전 위반 $S(x,c)$가 있다고 합시다.

효용 최대화

$$ \max_{\pi};\mathbb{E}_x\left[ Q(x,\pi(x)) -\lambda_C C(x,\pi(x)) -\lambda_L L(x,\pi(x)) -\lambda_S S(x,\pi(x)) \right] $$

제약 최적화

$$ \min_{\pi};\mathbb{E}[C] \quad\text{s.t.}\quad \mathbb{E}[Q]\ge q_0,; P(L>L_\text{SLO})\le\epsilon,; S=0 $$

$\lambda$와 threshold는 보편값이 아닙니다. High-risk policy answer와 brainstorming request의 품질 하한선이 같아서는 안 됩니다.

Hard constraint와 soft objective를 분리한다

  • Privacy region, data egress, authorization: hard policy
  • Safety critical threshold: hard gate
  • Cost, 평균 latency, verbosity: soft objective
  • Provider preference와 user choice: contract에 따라 hard 또는 soft

안전 위반을 싼 비용으로 상쇄하는 objective를 만들면 안 됩니다.

4. Pre-call router가 볼 수 있는 feature

Router는 아직 모델 답을 보지 않았으므로 요청과 운영 상태만 사용합니다.

Request feature

  • Task domain과 intent
  • 입력 token 수, 예상 출력 길이
  • 언어·코드·수식·표 포함 여부
  • Multi-hop·tool·freshness 필요성
  • 민감도와 risk class
  • Retrieval candidate 수와 query ambiguity
  • Conversation history와 이전 failure

System feature

  • Model availability와 queue depth
  • 현재 TTFT·tokens/s·error rate
  • Provider rate limit과 budget 잔여량
  • Region·privacy constraint
  • Cache hit 가능성
  • Index freshness와 tool health

Feature leakage를 피한다

Training 때만 알 수 있는 final answer score나 future latency를 input feature로 쓰면 offline 성능은 좋아 보이지만 production에서 사용할 수 없습니다. Label과 serving-time feature를 명확히 분리합니다.

5. 간단한 규칙 router가 강한 baseline이다

학습 router 전에 이해 가능한 rule을 만듭니다.

def route(req, system):
    if not policy_allows_external_provider(req):
        return "private-domain-model+private-rag"

    if req.risk == "high":
        return "strong-model+rag+claim-verifier"

    if req.needs_fresh_evidence:
        return "small-model+hybrid-rag"

    if req.tokens < 300 and req.intent in SIMPLE_INTENTS:
        return "small-model-direct"

    if system.strong_model_queue_ms > 1000:
        return "medium-model+rag"

    return "strong-model-direct"

Rule router는 복잡한 경계를 놓치지만 다음 장점이 있습니다.

  • 의도와 policy가 명확하다.
  • 새로운 모델의 cold start가 쉽다.
  • Learned router의 실제 이득을 측정할 baseline이 된다.
  • 장애 때 fallback policy로 쓸 수 있다.

6. Router 학습에는 counterfactual outcome이 필요하다

요청 $x_i$를 여러 모델 $m_j$에 실행한 outcome matrix를 생각해 봅시다.

$$ Y_{ij} = {Q_{ij}, C_{ij}, L_{ij}, S_{ij}} $$

Oracle router는 각 요청에서 objective가 가장 좋은 모델을 압니다. 하지만 production log에는 실제 선택한 하나의 outcome만 있습니다.

request x
  chosen small model → observed quality 0.7
  strong model       → unknown counterfactual
  domain model       → unknown counterfactual

이 logged policy data만 supervised learning하면 기존 router의 선택 편향을 복제합니다.

Label 수집 방식

  • Offline representative set을 모든 후보 모델에 실행
  • 일부 traffic에서 안전한 randomized exploration
  • 동일 요청의 shadow inference
  • Human·judge pairwise preference
  • Task-specific deterministic evaluator
  • Inverse propensity weighting 같은 logged-policy correction

Shadow inference는 비용이 들고 민감 데이터를 다른 provider에 보낼 수 있으므로 privacy policy를 먼저 확인합니다.

RouterBench는 여러 LLM의 대규모 inference outcome을 바탕으로 router 평가 framework를 제안했고, RouteLLM은 strong·weak model 사이 routing을 human preference data로 학습하는 방법을 연구했습니다.

7. Router의 세 가지 학습 target

7.1 Per-model quality prediction

각 model의 expected quality를 예측합니다.

$$ \hat Q_j(x)=f_\phi(x,m_j) $$

새 모델 metadata를 feature로 넣을 수 있지만 실제 transfer는 검증해야 합니다.

7.2 Pairwise preference

요청 $x$에서 strong model이 weak model보다 유의미하게 나은지 예측합니다.

$$ P(m_s \succ m_w\mid x) $$

RouteLLM의 핵심 설정과 연결됩니다. Threshold로 strong model 호출 비율을 조정할 수 있습니다.

7.3 Direct policy

여러 configuration 중 action을 직접 선택합니다. Load와 budget까지 포함하기 쉽지만, 후보 모델이 바뀌면 재학습이 필요할 수 있습니다.

어떤 target을 쓰든 calibration과 regret를 평가합니다.

8. Cascade gate는 답의 충분성을 평가한다

싼 모델의 answer $y_w$를 본 뒤 accept 또는 escalate합니다.

$$ \text{accept if } \hat q(x,y_w,e) \ge \tau(x) $$

$e$는 retrieved evidence나 verifier signal입니다.

Gate signal

  • Calibrated correctness probability
  • Semantic entropy와 sample disagreement
  • Evidence sufficiency와 citation coverage
  • Claim verifier의 critical failure
  • Tool execution success
  • Output schema·business rule validation
  • User risk class와 required confidence

Gate가 하면 안 되는 것

  • Model의 “확신합니다” 문장만 믿기
  • 모든 task에 같은 threshold 사용
  • Empty answer를 높은 precision으로 인정
  • Escalation 뒤에도 같은 prompt·evidence를 그대로 반복
  • 최대 cascade depth 없이 loop하기

Escalation에는 이유와 새 자원이 있어야 합니다.

low evidence → retrieve more
reasoning disagreement → stronger model / more samples
missing slot → ask user
policy ambiguity → human review
tool failure → retry or alternate tool

9. Routing과 test-time compute를 결합한다

52편의 sample 수, search depth, verifier budget도 route 대상입니다.

easy factual lookup
  → small model + one retrieval + greedy decode

ambiguous multi-hop
  → medium model + iterative retrieval + verifier

high-risk policy
  → strong model + claim decomposition + dual verifier + abstention gate

모델 크기만 키우는 것보다 retrieval이나 verifier를 추가하는 편이 특정 실패에 더 효율적일 수 있습니다. Router action space에 system component를 포함해야 하는 이유입니다.

10. RAG routing은 retrieval 필요성과 경로를 고른다

23편의 adaptive RAG를 model router와 통합합니다.

선택 가능한 경로

  • No retrieval: 창의적 변환, 제공된 text 요약
  • Lexical retrieval: 정확한 ID·error code
  • Dense retrieval: 의미적 질문
  • Hybrid + reranker: 높은 recall과 precision 필요
  • Multi-hop retrieval: 여러 evidence 결합
  • Long-context direct: 작은 문서 묶음 전체 비교
  • Ask/abstain: query가 불완전하거나 권한이 없음

Router label

답 품질만 보면 strong model이 retrieval 없이 기억으로 맞힌 사례를 “성공”으로 볼 수 있습니다. Production RAG contract가 citation과 최신성을 요구한다면 evidence-grounded success를 label로 써야 합니다.

11. Multi-turn Agent에서는 route를 함부로 바꾸지 않는다

대화 중간에 model이나 provider를 바꾸면 다음 문제가 생깁니다.

  • Tool call format과 special token 차이
  • 이전 reasoning state와 memory 해석 차이
  • Safety policy와 refusal style 차이
  • Provider 간 data transfer
  • Cache와 KV state 재사용 불가

Sticky episode policy

Episode 시작에 route를 선택하고 특별한 이유가 있을 때만 전환합니다.

{
  "route": "private-medium+rag@4",
  "sticky_until": "episode_terminal",
  "switch_reasons": ["model_unavailable", "critical_verifier_fail", "user_opt_in"],
  "max_switches": 1
}

전환 시 state를 typed handoff format으로 다시 구성하고, tool schema와 permission을 재검증합니다.

12. Privacy와 user choice는 품질 feature가 아니다

민감한 문서를 외부 provider에 보낼 수 없다면 해당 model의 예상 품질이 아무리 높아도 후보에서 제거해야 합니다.

candidate set
  → policy filter: region · tenant · data class · contract
  → user preference / provider consent
  → availability and SLO
  → quality-cost router

2026년 preprint Routing, Cascades, and User Choice for LLMs는 routing·cascade와 사용자 선택을 함께 논의합니다. 이 자료는 최신 preprint이므로 보편적인 결론으로 받아들이기보다, router 목적 함수에 user preference와 control을 명시적으로 포함해야 한다는 설계 질문으로 사용합니다.

사용자에게 선택권을 제공할 때는 “빠름”, “저렴함”, “고품질” 같은 label이 실제 측정과 일치해야 하고, 민감 데이터 처리 차이를 숨기지 않습니다.

13. Load-aware routing과 SLO

가장 정확한 model이 queue에 막히면 p95 latency가 무너질 수 있습니다. Router는 정적 benchmark뿐 아니라 현재 serving 상태를 봐야 합니다.

실시간 signal

  • Queue depth와 estimated wait
  • TTFT·tokens/s·error rate EWMA
  • GPU memory pressure
  • Provider rate-limit remaining
  • Circuit breaker state
  • Region health

위험

Load에 따라 model을 자주 바꾸면 같은 요청이 다른 품질을 내고 router가 불안정해집니다. Hysteresis, minimum dwell time, sticky session, bounded fallback을 사용합니다.

healthy → degraded only if p95 > threshold for N windows
degraded → healthy only after M stable windows

14. Drift: Router는 모델보다 먼저 낡을 수 있다

Router가 학습한 상대 우위는 다음 변화로 깨집니다.

  • Candidate model upgrade·quantization
  • 가격과 rate limit 변경
  • Prompt·tool schema·retrieval corpus 변경
  • 사용자 task mix 변화
  • Evaluator drift
  • 새로운 language·domain 유입

모니터링

  • Route share by task·tenant·language
  • Model별 observed quality와 calibration
  • Strong-model escalation rate
  • Cascade depth와 double-spend rate
  • Quality·cost·latency Pareto 이동
  • Oracle regret on shadow sample
  • Policy fallback·provider error

특정 route share가 급변하면 성능 개선이 아니라 classifier drift일 수 있습니다.

15. Pareto frontier와 regret로 평가한다

한 scalar score만 보고 router를 고르면 weight 선택에 결과가 좌우됩니다.

Pareto frontier

다른 policy보다 품질이 낮지 않으면서 비용·지연이 더 나쁜 policy를 제거합니다. 남은 frontier에서 제품 SLO와 예산에 맞는 operating point를 고릅니다.

Oracle regret

각 요청의 모든 후보 outcome을 아는 oracle의 utility $U^*(x)$와 router utility를 비교합니다.

$$ \text{regret} = \mathbb{E}_x[U^*(x)-U(x,\pi(x))] $$

Oracle 자체가 noisy evaluator에 기반하면 regret도 왜곡되므로 human·deterministic task slice를 함께 둡니다.

반드시 비교할 baseline

  • Always weakest
  • Always strongest
  • Random under same budget
  • Simple rule router
  • Learned router
  • Learned router + cascade
  • Oracle upper bound

16. Offline 평가와 online 실험

Offline outcome matrix

같은 request set을 모든 candidate configuration에 실행합니다. 다음을 저장합니다.

{
  "request_id": "route-00184",
  "slice": {"task": "multi_hop_rag", "language": "ko", "risk": "medium"},
  "outcomes": {
    "small-direct": {"quality": 0.21, "cost": 0.001, "latency_ms": 210},
    "small-rag": {"quality": 0.78, "cost": 0.004, "latency_ms": 510},
    "strong-rag-verify": {"quality": 0.91, "cost": 0.031, "latency_ms": 1840}
  },
  "policy_allowed": ["small-rag", "strong-rag-verify"]
}

Candidate version과 evaluator version이 필수입니다.

Online canary

  • 작은 traffic과 hard budget cap
  • 기존 policy와 paired 또는 randomized comparison
  • User-visible quality와 correction rate
  • Policy violation hard stop
  • Route decision과 propensity logging
  • 즉시 rollback 가능한 config

Exploration은 side-effect가 없는 요청과 privacy가 허용된 candidate에서만 수행합니다.

17. 흔한 실패 패턴

실패 1. 평균 benchmark 하나로 router를 학습한다

Task·언어·risk별 상대 우위가 사라집니다.

대응: Slice-aware outcome matrix와 worst-group 성능을 둡니다.

실패 2. 선택한 모델의 결과만 label로 쓴다

기존 policy의 편향을 반복합니다.

대응: Shadow·offline all-model evaluation과 exploration propensity를 수집합니다.

실패 3. Self-reported confidence로 cascade한다

모델의 언어적 확신은 calibration되지 않았을 수 있습니다.

대응: Task-specific correctness, semantic entropy, evidence verifier를 human set에 calibration합니다.

실패 4. Escalation이 같은 일을 반복한다

같은 evidence와 prompt로 더 비싼 model만 부르면 실패 원인이 retrieval일 때 비용만 늘어납니다.

대응: Failure reason별로 retrieve, clarify, verify, stronger model을 다르게 선택합니다.

실패 5. 비용만 줄이고 tail latency를 무시한다

Cascade가 싼 model과 강한 model을 순차 호출해 p95를 악화시킬 수 있습니다.

대응: End-to-end latency와 double-spend를 측정하고 pre-route로 바로 strong path에 보낼 slice를 둡니다.

실패 6. 모델 전환 때 privacy boundary를 넘는다

Fallback provider로 민감 context가 전송될 수 있습니다.

대응: Policy filter를 quality router보다 먼저 적용하고 route별 allowed context를 명시합니다.

18. 최소 구현 순서

  1. Weak·strong model과 RAG 여부를 조합한 3개 configuration만 시작합니다.
  2. Quality, cost, p95 latency, safety hard constraint를 정의합니다.
  3. Representative request set을 모든 configuration에 실행합니다.
  4. Always-weak, always-strong, rule router baseline을 만듭니다.
  5. Pairwise quality predictor와 calibrated threshold를 학습합니다.
  6. Evidence sufficiency 기반 한 단계 cascade를 추가합니다.
  7. Task·언어·risk slice별 Pareto와 regret를 봅니다.
  8. Privacy·region·provider policy를 router 앞단 hard filter로 둡니다.
  9. Shadow sample로 drift와 counterfactual outcome을 갱신합니다.
  10. Small canary, budget cap, circuit breaker로 배포합니다.

19. 실전 체크리스트

  • Router, cascade, ensemble의 호출 시점과 비용을 구분했다.
  • Action이 model ID가 아니라 full system configuration이다.
  • Quality·cost·latency·safety objective와 constraint가 명시됐다.
  • Serving-time에 사용할 수 있는 feature만 router input에 넣었다.
  • Always-weak·always-strong·rule baseline이 있다.
  • 같은 request의 multi-model outcome matrix가 있다.
  • 선택되지 않은 model의 counterfactual label 수집 경로가 있다.
  • Cascade confidence가 task slice별로 calibration됐다.
  • Escalation reason에 따라 새 자원을 추가한다.
  • Retrieval·reasoning·verifier budget도 route action에 포함된다.
  • Multi-turn episode의 sticky route와 switch limit가 있다.
  • Privacy·region·user choice가 hard policy로 먼저 적용된다.
  • Load-aware routing에 hysteresis와 circuit breaker가 있다.
  • Pareto frontier, regret, worst-group quality를 평가한다.
  • Route share·escalation·double-spend·drift를 모니터링한다.

스스로 확인하기

Q1. Router와 cascade의 가장 중요한 차이는 무엇인가?

Router는 후보 output을 보기 전에 경로를 고르고, cascade는 첫 결과의 품질·불확실성을 본 뒤 escalation 여부를 정합니다.

Q2. Production log만으로 최적 router를 학습하기 어려운 이유는 무엇인가?

선택된 모델의 outcome만 관찰되고 선택되지 않은 모델의 counterfactual 품질은 없기 때문입니다.

Q3. Strong model로 escalation하면 항상 품질이 오르는가?

아닙니다. 실패 원인이 잘못된 retrieval, 누락된 사용자 정보, 권한 문제라면 더 큰 모델도 해결하지 못합니다.

Q4. 가장 싼 route 비율이 높으면 좋은 router인가?

품질·안전·SLO가 유지될 때만 그렇습니다. 비용 절감은 제약을 만족한 Pareto point에서 평가해야 합니다.

Q5. RAG Agent에서 router가 고르는 것은 무엇인가?

Model뿐 아니라 retrieval 전략, context·reasoning budget, verifier, tool policy, provider를 포함한 system configuration입니다.

20. 51–60편 시리즈 되돌아보기

이 시리즈는 모델이 “답을 낸다”에서 끝나지 않고, 추론을 만들고 검증하며 시스템 자원을 배분하는 과정까지 확장했습니다.

  1. Chain-of-Thought와 Reasoning — 정답, reasoning, faithfulness를 분리했습니다.
  2. Test-Time Compute Scaling — sample·search·verifier budget을 배분했습니다.
  3. Verifier와 Process Supervision — 결과와 중간 단계를 평가했습니다.
  4. Uncertainty와 Calibration — 신뢰도를 answer·retrieve·ask·abstain 결정으로 바꿨습니다.
  5. Hallucination과 Factuality — claim과 evidence, citation을 연결했습니다.
  6. Structured Generation — grammar와 schema로 출력 contract를 강제했습니다.
  7. Synthetic Data와 Distillation — teacher 후보를 검증해 student data로 만들었습니다.
  8. Tool-Use Learning — function call을 실제 실행 결과와 연결했습니다.
  9. Agent Trajectory Learning — 긴 episode의 실패·복구와 credit을 학습했습니다.
  10. Model Routing과 Cascades — 이 모든 구성 요소를 요청별 품질·비용·지연 정책으로 조합했습니다.

이제 독자는 특정 논문 기법을 추가하기 전에 다음 질문을 할 수 있습니다.

무엇을 생성하는가?
무엇으로 검증하는가?
불확실할 때 어떤 행동을 하는가?
어떤 contract와 policy가 강제되는가?
어느 state와 failure에서 학습하는가?
어떤 configuration에 compute를 배분하는가?

마무리

Model routing은 “싼 모델을 최대한 많이 쓰는 요령”이 아닙니다. 각 요청과 episode에 필요한 모델·검색·검증·compute를 policy 제약 안에서 배분하는 시스템 의사결정입니다.

좋은 router는 strong model 호출률만 자랑하지 않습니다. Counterfactual outcome을 모으고, uncertainty를 calibration하며, RAG 실패 원인에 맞는 escalation을 선택하고, privacy와 user choice를 우선합니다. 그리고 Pareto frontier와 regret, drift를 지속적으로 측정합니다.

이 글로 LLM 추론·신뢰성·Agent 학습 10편을 마칩니다. 전체 학습 순서는 시리즈 페이지에서 다시 확인할 수 있습니다.

다음 시리즈에서는 선택한 모델이 실제 GPU에서 어떤 비용으로 실행되는지 내려갑니다. 첫 글은 GPU Roofline으로 LLM 추론 병목 읽기입니다. FLOPS와 memory bandwidth를 따로 외우지 않고 arithmetic intensity로 prefill과 decode의 병목을 예측합니다.

참고문헌

검증 메모 — 문헌 링크와 서지 정보는 2026년 7월 16일 확인했습니다. 가격·모델 성능·provider 정책은 빠르게 변하므로 특정 논문의 절감률을 일반화하지 않고, 현재 후보 configuration으로 outcome matrix를 다시 만들어야 합니다.