LLM API 기초

분류: Layer 12 - AI 시스템 & LLM 애플리케이션 | 선수지식: L11-50 (트랜스포머), L11-70 (토크나이저·임베딩)

LLM API 기초 — 메시지 구조, Sampling, Structured Output, Streaming

1. 한 줄 정의

LLM API는 chat completion 인터페이스(messages + 옵션)를 통해 LLM 추론을 호출하는 표준이며, sampling 파라미터·structured output·streaming·multimodal·function calling이 핵심 운영 변수다.

2. 왜 중요한가

• 모든 LLM 앱의 진입점: 챗봇·RAG·에이전트가 모두 이 API 위에 올라간다
• 비용·지연 직관: input/output 토큰, prefill/decode, streaming 모드가 비용·UX에 직접 영향
• 품질 변수: temperature·top_p·top_k·penalty 같은 sampling이 결과 다양성과 hallucination에 영향
• 운영 안정성: structured output, retry, error handling, rate limit이 production 요건
• provider 호환성: OpenAI 표준이 사실상 industry standard, 여러 provider가 같은 인터페이스 지원

2.5 Lineage — Text Completion에서 Chat Completion으로

GPT-3 출시 시(2020) OpenAI의 표준은 text completion 엔드포인트(/v1/completions)였다. 입력은 단일 문자열 prompt, 멀티턴 챗봇은 개발자가 직접 history를 이어붙였다 — 예: "User: 안녕\nAssistant: 안녕하세요\nUser: 오늘 날씨".

선행 한계 (text completion 시대):

• 역할 경계가 문자열 분리자로만 표현 → 사용자 입력에 "\nAssistant:"가 섞이면 prompt injection이 그대로 통과 (앱 레이어에서 escape 책임)
• system instruction과 user 입력이 한 평면에 → 모델이 둘의 우선순위를 강제할 학습 신호 없음
• tool/function 결과를 다시 모델에 넣을 표준 channel 없음 — JSON을 prompt에 박는 ad-hoc 처리
• 모델별 separator 규약(<|im_start|> 등)이 제각각 → 모델 교체 시 prompt 재작성

2023-03 chat completion이 messages: [{role, content}] 배열을 도입해 4가지를 provider 측에서 처리. 역할 구분이 학습 단계에도 반영돼 RLHF가 system 지시를 우선시하도록 모델을 정렬. OpenAI는 2024-01-04 legacy completion의 GPT-3/3.5 모델군을 shut down했다 (OpenAI Deprecations).

Chat completion이 만든 새 비용·그 해소책 (이하 §3에서 다룸):

• stateless로 매 호출마다 전체 history 전송 → token 비용이 turn 수에 비례 → prompt caching(§3.7)으로 동일 prefix 재사용 시 input 비용 최대 90% ↓
• 응답 길어지면 첫 토큰 대기 ↑ → streaming(§3.4)으로 TTFT 단축
• 자유 텍스트라 JSON 강제 어려움 → structured output strict(§3.3)의 grammar-constrained decoding

이 lineage가 §3.x 절들의 등장 동기다 — caching·streaming·structured output 모두 “messages + stateless + 자유 텍스트”라는 chat completion 기본 가정의 비용을 다스리는 보강책.

3. 핵심 개념

3.1 Chat Completion 메시지 구조

OpenAI가 정착시킨 표준 — 모든 주요 provider(Anthropic, Google, OpenRouter)가 호환.

interface ChatCompletionRequest {
  model: string;
  messages: Array<{
    role: "system" | "user" | "assistant" | "tool";
    content: string | ContentPart[];
    tool_calls?: ToolCall[];
    tool_call_id?: string;
  }>;
  temperature?: number;       // 0~2
  top_p?: number;             // 0~1
  max_tokens?: number;
  stop?: string[];
  stream?: boolean;
  tools?: Tool[];
  response_format?: { type: "json_object" | "json_schema"; ... };
  seed?: number;              // (선택) 결정성
  n?: number;                 // 응답 개수
}

Role 의미

• system: 모델의 역할·페르소나·규칙. 보통 가장 앞
• user: 사용자 입력
• assistant: 모델 응답 (이전 turn) 또는 모델이 호출한 tool
• tool: tool 실행 결과 (function calling 흐름)

Multi-turn

[
  { role: "system", content: "당신은 친절한 도우미" },
  { role: "user", content: "안녕" },
  { role: "assistant", content: "안녕하세요!" },
  { role: "user", content: "오늘 날씨?" }, // 새 턴
];

→ 모델은 전체 대화를 매 호출마다 입력으로 받음 (stateless API).

3.2 Sampling 파라미터 — Inference Internals

LLM 출력의 다양성과 결정성을 제어. forward pass 후 next-token 분포에서 어떻게 뽑을지의 규칙.

Greedy decoding (temperature=0)

next_token = argmax(softmax(logits))

가장 확률 높은 토큰만 선택. 결정적이지만 다양성 0. 분류·코드처럼 정답이 명확한 작업에 적합.

Temperature

logits를 T로 나누어 softmax 분포의 sharpness 조정 (L11-10 §3.3).

softmax(logits / T)

T → 0:  greedy (가장 가능성 높은 토큰)
T = 1:  raw 분포
T → ∞:  uniform (완전 무작위)

• 분류·코드: T=0 (결정적)
• 요약·번역: T=0.2~0.5 (약간 다양성)
• 창작: T=0.7~1.2 (창의성)
• temperature=0이라도 완전 결정적은 아님: 일부 provider는 floating point·batch 차이로 다른 결과. seed 파라미터로 더 강한 결정성 (OpenAI, 단 system_fingerprint로 검증)

Top-p (nucleus sampling)

확률 누적이 p 이상이 되는 최소 토큰 집합에서만 sampling.

top_p = 0.9: 누적 확률 90% 안의 토큰만 후보

• temperature와 함께 자주 쓰임
• 권장: temperature 또는 top_p 중 하나만 조정 (둘 다 강하게 하면 효과 중첩)

Top-k

상위 k개 토큰만 sampling. top_k=50이 흔한 default. OpenAI API에선 직접 노출 안 함.

Frequency / Presence penalty

frequency_penalty: 등장 빈도에 비례해 logit 감소 (반복 줄임)
presence_penalty:  한 번 등장하면 logit 감소 (다양성 ↑)

• 챗봇 long-running session에서 반복 답변 방지에 유용

3.3 Structured Output

자유 텍스트 대신 검증 가능한 구조 (JSON, schema)로 출력 강제.

JSON Mode

{
  response_format: {
    type: "json_object";
  }
}

JSON 형식 보장. 단 schema 일치는 별도.

Structured Outputs (JSON Schema)

OpenAI의 response_format: { type: "json_schema", strict: true }, Anthropic의 tool_use, outlines/Instructor 같은 라이브러리.

{
  response_format: {
    type: "json_schema",
    json_schema: {
      name: "extracted_info",
      strict: true,
      schema: {
        type: "object",
        properties: {
          name: { type: "string" },
          age: { type: "number" }
        },
        required: ["name", "age"]
      }
    }
  }
}

strict: true는 grammar-constrained decoding으로 schema에서 벗어난 토큰 자체를 막음. 100% schema 일치 보장.

구현 기법 (라이브러리 단)

• Outlines: regex/grammar로 토큰 단위 제약 (FSM)
• Instructor: Pydantic 모델로 schema 정의 + retry
• LMQL / Guidance: prompt-as-program 형식
• vLLM xgrammar / OpenAI strict: backend 직접 grammar-constrained

운영 가치: agent의 tool calling, RAG의 citation, 데이터 추출에서 필수.

3.4 Streaming

응답을 토큰 단위로 흘려보냄 (Server-Sent Events).

{ stream: true }

// 응답 (SSE)
data: {"choices":[{"delta":{"content":"안"}}]}
data: {"choices":[{"delta":{"content":"녕"}}]}
data: {"choices":[{"delta":{"content":"하세요"}}]}
data: [DONE]

• 장점: TTFT(Time To First Token) 개선 — UX 핵심
• 단점: structured output·tool calling과 결합 까다로움 (부분 JSON parsing 필요)
• TTFT vs Total latency: 첫 토큰까지의 시간 (사용자 체감) vs 전체 응답 시간
• 결합 도구: Vercel AI SDK, LangChain·LlamaIndex streaming, Anthropic streaming=true

3.5 Multimodal I/O

텍스트만이 아니라 이미지·오디오·비디오 입출력.

Vision (이미지 입력)

{
  role: "user",
  content: [
    { type: "text", text: "이 이미지에 뭐가 있어?" },
    { type: "image_url", image_url: { url: "data:image/png;base64,..." } }
  ]
}

• OpenAI GPT-4o, Anthropic Claude 4.x, Google Gemini 2.x 모두 지원
• 비용: 이미지가 토큰화돼 비용 누적 (1024×1024 이미지 ≈ 765 tokens for OpenAI)

Audio·Video

• OpenAI gpt-4o-audio: 음성 입력·출력 통합
• Gemini: 비디오 직접 입력 (1시간 비디오 = ~1M tokens)
• Whisper: 음성 → 텍스트 전용

운영 시 주의

• 이미지 토큰은 가격이 다름 (provider 가이드 확인)
• 비전 모델 latency가 텍스트보다 큼
• privacy: 이미지에 PII 포함 여부 점검

3.6 Provider 비교 (2025+)

Provider	2026-04 라인업	특징
OpenAI	GPT-5.4(flagship), GPT-4.1(1M ctx), o3/o4-mini(reasoning)	structured output strict, Responses API, Realtime
Anthropic	Claude Opus 4.7, Sonnet 4.6, Haiku 4.5	긴 출력 안정, extended thinking, tool use 자연스러움
Google	Gemini 2.5 Pro/Flash	1M+ context, multimodal·video 강함
OpenAI-호환 (OpenRouter, Together, Groq, Fireworks)	open-weight (Llama 4, DeepSeek-V3/R1, Qwen3, gpt-oss)	가격·latency 다양
AWS Bedrock	다중 provider	enterprise IAM·VPC 통합
Azure OpenAI	OpenAI 모델	enterprise 컴플라이언스

대부분 OpenAI chat completion 인터페이스를 흉내 — provider 교체가 비교적 쉬움.

3.7 비용 모델 — Input vs Output

LLM 비용 = input_tokens × price_in + output_tokens × price_out. output이 보통 4~5× 비싸다.

모델	Input ($/1M)	Output ($/1M)	비고
GPT-4o	$2.50	$10	멀티모달 표준
GPT-4o-mini	$0.15	$0.60	가성비
o3	$2	$8	reasoning. o1 대비 가격 큰 폭 인하 (2026 출시)
GPT-5.4	(provider 확인)	(provider 확인)	flagship chat, 2026 출시
Claude Opus 4.7	$5	$25	2026-04 출시. Opus 4.6과 동일 단가 (단 새 토크나이저로 +35% 토큰 가능)
Claude Sonnet 4.6	$3	$15	긴 출력 안정
Claude Haiku 4.5	$1	$5	빠르고 싸다
Gemini 2.5 Pro	$1.25	$5	1M+ context
Gemini 2.5 Flash	$0.075	$0.30	매우 싸다
gpt-oss-20b (open)	$0.03	(provider 별)	open-weight, OpenRouter/Together 등에서 호스팅

(2026-04 기준. 실가는 provider docs 확인. Opus 4.7의 새 토크나이저는 같은 텍스트에 최대 35% 더 많은 토큰을 만들 수 있어 명목 단가 동일이라도 실비용↑ — 운영 시 a/b 토큰 카운트 검증 필수.)

비용 절감 기법

• Prompt caching (Anthropic, OpenAI, Gemini): 같은 prefix 재사용 시 cache hit이 input 가격의 10% (Anthropic 5분 TTL 기준 — write 1.25×, hit 0.1×). 시스템 프롬프트·few-shot·RAG context 길 때 핵심. OpenAI는 automatic prefix caching — prompt가 1024 토큰 이상이면 자동 활성, 이후 128 토큰 단위로 cache hit이 누적, 공식 수치로 latency 최대 80% ↓ / input 비용 최대 90% ↓ (OpenAI Prompt Caching). 깨지는 조건: prompt 길이 <1024이면 캐시 자체 비활성(보일러플레이트가 부족), prefix 중간에 user_id·timestamp 같은 변동 토큰이 들어가면 그 지점부터 전부 miss → 고정 prefix(system + few-shot)를 맨 앞, 사용자별 변동 데이터는 뒤로 배치하는 게 가장 큰 단일 leverage
• Batch API: 24시간 비동기 처리 시 input·output 모두 50% 할인 (OpenAI, Anthropic 모두 지원)
• 모델 라우팅: 쉬운 요청은 작은 모델, 어려운 요청만 큰 모델 (L12-70)
• Output 길이 제한: max_tokens 적정 + structured output으로 verbose 차단
• Reasoning budget 조절 (Anthropic extended thinking, OpenAI o-series): reasoning token 사용량을 한도 내로 — reasoning 모델 비용의 가장 큰 변수

3.8 Inference Internals — Prefill vs Decode

trans former inference의 두 단계.

Prefill: 입력 prompt 전체를 한 번의 forward pass로 처리 → KV cache 생성 (병렬, GPU 활용 ↑)
Decode:  토큰을 한 개씩 autoregressive 생성 (순차, memory-bound)

• prefill은 input 토큰에 비례, batch 처리 효율적
• decode는 output 토큰에 비례, batch 1로는 GPU 활용률 낮음
• continuous batching·PagedAttention(L11-50 §3.10)이 decode throughput을 끌어올리는 도구
• Speculative decoding: 작은 draft 모델로 K개 토큰을 미리 생성하고 target 모델이 한 번의 forward pass로 일괄 검증 (Leviathan et al. 2022). 2026 벤치마크: vLLM + EAGLE-3로 low-concurrency(<10 동시 요청) 구간 2~3× decode 가속, AWS Trainium decode-heavy 워크로드 최대 3×, Snowflake Arctic의 conversational/coding 워크로드 2.8× (Red Hat 2026-04). 깨지는 조건: draft 모델 acceptance rate <0.55면 검증 오버헤드가 이득을 상쇄해 오히려 느려지고, 응답 길이 <100 토큰이면 prefill 비중이 커서 효과 미미, 동시 요청 수가 100+로 올라가 batch가 이미 GPU를 채우면 추가 이득 거의 0

3.9 Determinism과 Reproducibility

LLM은 본질적으로 비결정적이지만 운영에선 재현성이 중요.

• temperature=0: greedy. 그러나 floating point·batch·GPU에 따라 미세한 차이
• seed 파라미터: OpenAI는 seed로 결정성 시도, system_fingerprint로 검증 가능 (변경 시 재현 깨짐)
• logprobs: 각 토큰의 로그 확률 반환. eval에서 정답 확률 측정에 유용
• n 파라미터: 같은 prompt에 N개 응답 (best-of-N, self-consistency 평가)

3.10 Error Handling과 Rate Limits

production 운영의 80%가 이 영역.

흔한 오류

• rate limit (429): TPM·RPM·concurrency 한도 초과 → exponential backoff
• context length exceeded (400): input + output > max_context. truncate 또는 RAG 분할
• content filter (400/403): provider 안전 필터 (Azure OpenAI 흔함)
• timeout (504): 긴 응답 또는 provider 부하
• invalid JSON: structured output strict=false일 때 발생 → strict mode 또는 retry

Production 패턴

async function callLLM(messages, retries = 3) {
  for (let i = 0; i < retries; i++) {
    try {
      return await openai.chat.completions.create({
        model: "gpt-4o",
        messages,
        timeout: 30000,
      });
    } catch (e) {
      if (e.status === 429) {
        await sleep(Math.pow(2, i) * 1000); // exponential
        continue;
      }
      if (e.status === 400 || e.status === 403) throw e; // 재시도 X
      throw e;
    }
  }
}

• circuit breaker, fallback model, dead-letter queue 표준 패턴
• LangChain·LlamaIndex·Vercel AI SDK 모두 retry·fallback 빌트인

3.11 Fine-tune vs RAG vs Prompt 결정 (재방문)

L11-30 §3.5의 결정 프레임을 LLM API 시점으로 짧게.

1. 일반 작업·prototype:           prompt만으로
2. 자주 갱신되는 외부 지식:        RAG (L12-40)
3. 행동·톤·포맷·도메인 전문성:     fine-tune (L11-90)
4. multi-step·tool 사용:           agent (L12-60)

각 선택지가 깨지는 정량 신호:

• Prompt only → RAG로 이동: prompt에 inline한 context가 input 50k tokens를 넘어 호출당 비용이 $0.10+로 폭발하거나, 갱신 주기 <24h인 외부 지식(가격·재고·문서)이 필요해 stale 답변이 발생할 때
• RAG → fine-tune 검토: retrieval recall <0.7로 정답 chunk가 누락되거나(검색 자체가 못 잡는 표현·언어 스타일), 동일 system prompt가 1k 토큰 넘어가는데 핵심 행동·톤이 여전히 안 박힐 때
• Prompt → agent: 단일 호출 + 후처리 1회 패턴이 깨지고 분기(검색→요약→DB쓰기 같은 multi-step)가 필요할 때
• Agent → 단순 prompt로 회귀: agent의 평균 step 수가 1.5회 이하면 router/tool overhead만 늘고 정확도 이득 없음 — 단일 호출 + structured output으로 통합

이 결정이 시스템 아키텍처를 갈라놓는다. 공통 일반 매핑: “static 데이터 → prompt 인라인 / dynamic 데이터 → 외부 store + lookup”이라는 캐시 vs DB 패턴과 동형 — RAG는 LLM 시점의 “cold cache miss시 외부 store fetch”다 (§3.14 참조).

3.12 깨지는 조건 정량 표 (운영 결정용)

기법	효과 발휘 범위	깨지는 조건
Temperature=0	분류·코드·정답 명확	창의성 작업 → 0.7~1.2
Temperature=0.7	챗봇·일반 대화	결정성 필요 → 0
Top-p=0.9	일반	T·top-p 둘 다 강하게 조정 시 효과 중첩
JSON mode	JSON 형식 보장	schema 일치 X — strict mode 또는 Instructor 필요
Structured strict	schema 100% 일치	미지원 모델은 fallback 필요
Streaming	TTFT 개선 UX	structured/tool 결합 까다로움 (partial JSON)
Prompt caching	같은 prefix 재사용 多	prefix 자주 변경 → cache miss로 비용↑
Batch API	비실시간 작업 50% 할인	채팅·실시간 agent엔 부적합 (24h 지연)
Speculative decoding	output 多 (>100 tokens)	짧은 응답에선 오버헤드만

3.13 Silent Failure 시나리오와 복구

증상	정량 시그널	원인	복구
Cache hit ratio 폭락	hit ratio <30% (목표 50%+)	prompt 구조 변경 (caching 단위 prefix)	고정 prefix + 동적 suffix 분리
TTFT P99 폭증	P99 > 3s (target <1s)	서버 큐 depth, 시간대 패턴	Provider 라우팅 fallback, off-peak 분배
Streaming + tool 깨짐	partial JSON parse 실패	chunk를 그대로 client에 흘려	백엔드에서 buffer 후 처리
Rate limit 빈발	429 비율 5%+	TPM·RPM 한도 초과	exponential backoff + queue + 요금제 ↑
Content filter (400/403)	filter rate 1%+	safety policy 강	사용자 input sanitize, fallback model
Determinism 깨짐 (T=0)	같은 input 다른 output 빈발	system_fingerprint 변경	seed + fingerprint 검증, 모델 버전 고정
Circuit breaker 미적용	한 provider 장애로 전체 다운	fallback 미설정	LiteLLM·OpenRouter로 multi-provider 라우팅

3.14 LLM API의 일반 매핑 (Transferable Pattern)

LLM API의 핵심 — “input + 옵션 → output” — 은 다른 API/RPC 시스템과 같은 패턴.

LLM API 구성요소	일반 시스템 매핑
Chat completion	RPC, REST endpoint
Streaming (SSE)	Server-Sent Events, WebSocket
Structured output (strict)	gRPC schema, JSON Schema validation
Sampling 파라미터	DB query plan hint, cache TTL, rate limit
Prompt caching	HTTP cache (ETag), CDN, redis cache
Tool calling	RPC chain, microservice composition
Rate limit + retry	API gateway pattern (Throttling, Backoff, Circuit Breaker)
Multi-provider 라우팅	LB·service mesh·feature flag

일반 공식: “input → 정책 → 처리 → output” 의 4단계는 모든 API·RPC·DB 시스템 공통. LLM API가 특별한 점은 비결정성 + 토큰 비용이며, 이를 SLO·observability로 다스리는 게 운영자 역할.

운영 시나리오 — multi-provider 라우팅 + caching 비용 절감 (예시)

상황: 사내 챗봇 GPT-4o 단독 사용. 월 5M 호출 = ~$15k. cache hit ratio 20%.
선택지:
  A. Anthropic prompt caching (cache_control):
     - 시스템 prompt 2k 토큰을 명시적 cache → 5분 TTL
     - cache hit 시 input 10% 비용
     - 예상 hit ratio 70%+ → input 비용 -63%
  B. OpenRouter multi-provider:
     - GPT-4o (고품질) + Claude Sonnet (대안) + DeepSeek-V3 (저비용)
     - confidence 기반 cascade
  C. Batch API (비실시간 작업):
     - 50% 할인, 24h SLA OK인 작업만
  D. 모두 결합 (A + B + C)

선택: D (모두 결합).
대안 비선택: A 단독은 cascade 효과 X, B 단독은 caching 효과 X.
결과 (가상): $15k → $4k (~73% ↓), P95 TTFT 1.2s → 600ms.

§3.7 비용 + §3.12 깨지는 조건 + §3.13 silent failure + §3.14 일반 매핑 모두 적용.

4. 실무에서 어디에 쓰이나

• 챗봇·코드 어시스턴트
• 데이터 추출 (structured output)
• 요약·번역·분류
• 콘텐츠 생성 (마케팅·이메일·블로그)
• agent의 tool 호출 backbone
• 멀티모달 (이미지 분석, 음성 챗봇)

5. 현재 내 업무와 연결점

플랫폼 엔지니어가 LLM API를 운영할 때 다음에 도움된다.

• API 추상화 layer 설계: provider 교체 가능하게 (OpenAI 호환 인터페이스로 통일)
• 비용 모니터링: input/output 토큰 분리 측정, prompt caching hit ratio 추적
• structured output 강제: agent·RAG에서 hallucination 방지. strict mode 디폴트
• streaming UX: TTFT 개선이 사용자 만족도 핵심
• error handling: rate limit·timeout·content filter에 대한 retry·fallback 표준화
• 다국어: 한국어 토큰 비효율(L11-70)을 감안한 비용 견적

6. 자주 헷갈리는 개념 비교

개념 A	개념 B	차이점
Temperature	Top-p	분포 sharpness vs 누적 확률 cutoff
Greedy	Sampling	항상 argmax vs 확률적 선택
JSON mode	Structured output (strict)	JSON 형식만 vs schema 100% 일치 (grammar-constrained)
Streaming TTFT	Total latency	첫 토큰 도착 vs 전체 완료
Prefill	Decode	input 병렬 처리 vs output 순차 1토큰씩
Input price	Output price	보통 4~5× 차이. output이 비싸다
Prompt caching	Batch API	prefix 재사용 5090% ↓ vs 24h 비동기 ~50% ↓
seed	temperature=0	(이론상) 결정성 vs greedy. 둘 다 100% 결정 보장 X
OpenAI chat	Anthropic Messages	구조 거의 동일. system 처리 방식·tool 형식이 미묘하게 다름

7. 체크리스트

• Chat completion 표준 메시지 구조(system/user/assistant/tool 4 role)를 설명할 수 있다
• Temperature·top_p·top_k의 차이와 권장 사용처를 말할 수 있다
• Structured output (JSON mode vs strict json_schema)의 차이와 grammar-constrained decoding을 설명할 수 있다
• Streaming의 TTFT·Total latency·UX 영향을 설명할 수 있다
• Input·Output 토큰 가격 차이와 prompt caching·batch API의 절감 메커니즘을 설명할 수 있다
• Prefill·Decode의 차이와 output이 더 비싼 이유를 inference 단계로 설명할 수 있다
• Rate limit·timeout·content filter에 대한 retry·fallback 패턴을 짤 수 있다

8. 추가 학습 키워드

• Sampling: temperature, top_p, top_k, repetition penalty, frequency penalty, presence penalty, mirostat, typical_p
• Structured output: JSON mode, json_schema, Outlines, Instructor, Guidance, LMQL, xgrammar
• Streaming: SSE, chunk parsing, partial JSON, async iterator
• Multimodal: vision API, audio API, gpt-4o-audio, Whisper, Gemini video
• 추론 최적화: prefill, decode, KV cache, continuous batching, speculative decoding, FlashDecoding
• API 인프라: rate limit, exponential backoff, circuit breaker, fallback, retry-after, idempotency
• provider: OpenAI, Anthropic, Google, AWS Bedrock, Azure OpenAI, OpenRouter, Together, Groq, Fireworks
• SDK: openai-python, anthropic-sdk, Vercel AI SDK, LiteLLM (provider 추상화)

9. 내가 직접 확인해볼 것

기본 호출

• OpenAI Python SDK로 GPT-4o-mini에 같은 prompt를 temperature 0/0.7/1.5로 3번 호출 — 다양성 변화 직접 비교
• Claude SDK로 같은 prompt를 호출 — system 메시지 처리 방식이 OpenAI와 다른 점 체감 (system이 별도 인자)

Structured output

• OpenAI response_format json_schema strict: true로 {name: string, age: number} 추출. 잘못된 schema(추가 필드 X) 입력해 실패 확인
• Instructor 라이브러리로 Pydantic 모델 정의 → 같은 추출 작업 비교

Streaming

• streaming on/off로 같은 prompt의 TTFT 측정 (time.perf_counter로 첫 청크 시점)
• streaming + tool calling 결합 시 partial JSON 수신을 직접 처리 (chunk 누적 후 parse)

비용·캐싱

• Anthropic prompt caching으로 같은 system prompt(2000+ 토큰)를 10회 호출 — 첫 호출 vs 캐시 히트 비용·latency 비교 (50~90% 절감 확인)
• OpenAI Batch API로 100개 요청 던지고 24시간 후 결과 수신 — 50% 절감 체감

Multimodal

• GPT-4o로 이미지 입력 (스크린샷 UI 분석) — 토큰 수가 어떻게 카운트되는지 확인

결과가 예상과 다를 때

• temperature=0인데 응답이 다름 → seed 추가 + system_fingerprint 점검. floating point 차이는 완전 제거 불가
• structured output strict가 schema 위반 → strict 미지원 모델일 가능성. JSON mode + Instructor retry로 우회
• streaming + tool_calling 깨짐 → chunk를 그대로 client에 흘리지 말고 백엔드에서 buffer 후 처리

10. 5줄 요약

1. LLM API의 표준은 OpenAI chat completion (system/user/assistant/tool 4 role)이고, 모든 주요 provider가 이를 흉내낸다.
2. Sampling 파라미터(temperature, top_p)와 structured output strict mode가 출력 품질·결정성·schema 일치를 좌우한다.
3. Streaming은 TTFT를 줄여 UX 핵심이지만 structured/tool 결합이 까다롭다.
4. Output 토큰이 input보다 4~5× 비싸고, prompt caching·batch API·모델 라우팅이 비용 절감 표준 도구.
5. Production은 retry·fallback·circuit breaker·content filter 처리가 80%를 차지한다.

11. 출처

• OpenAI API reference — Chat Completions
• OpenAI API Deprecations (legacy completion 종료 일정)
• OpenAI Prompt Caching guide (automatic prefix, 1024 token threshold)
• Red Hat — Performance improvements with speculative decoding in vLLM (2026-04)
• OpenAI Structured Outputs guide
• Anthropic Messages API reference
• Anthropic Prompt Caching docs
• Google Gemini API docs
• OpenRouter docs
• Outlines — Structured generation
• Instructor (Python) docs
• Vercel AI SDK
• LiteLLM — provider abstraction
• Kwon et al., vLLM / PagedAttention (arXiv:2309.06180)
• Leviathan et al., Speculative Decoding (arXiv:2211.17192)
• Anthropic Claude Opus 4.7 announcement (2026-04)
• Claude API Pricing (2026)
• OpenAI API Pricing
• OpenAI Realtime API docs
• OpenAI Responses API docs
• Anthropic Computer Use API docs

---

최종 수정: 2026-04-26