News실전

Claude API 프롬프트 캐싱 워크스페이스 격리 전환, 반복 컨텍스트 비용 최대 90% 절감

Prompt caching — Claude API Docs

Anthropic의 Claude API 프롬프트 캐싱이 2026년 2월부터 조직 단위가 아닌 워크스페이스 단위 격리로 바뀌었다. 같은 조직 안에서도 워크스페이스 간 캐시가 분리돼 데이터 경계가 명확해진다. 캐시 읽기 비용은 표준 입력가의 10% 수준이라 동일 컨텍스트를 반복 주입할 때 최대 90%를 아낄 수 있고, 기본 5분 TTL 외에 추가 비용으로 1시간 캐시도 선택할 수 있다. 긴 시스템 프롬프트, 도구 정의, RAG로 끌어온 문서 블록처럼 매 호출 동일하게 들어가는 앞부분에 cache breakpoint를 두는 것이 핵심 패턴이다. 여기에 Batch API(입·출력 50% 할인), 모델 라우팅, 컨텍스트 편집(오래된 도구 결과·thinking 블록 정리)을 결합하면 에이전트 워크로드의 토큰 비용 구조를 크게 바꿀 수 있다. 한국 팀이 다회전 대화형 서비스를 운영한다면 캐시 적중률을 KPI로 잡을 만하다.

에이전트와 RAG 서비스의 운영비 대부분이 반복 입력 토큰에서 나오므로, 캐싱 설계가 곧 마진과 직결된다.

원문 출처

Anthropic

원문 보기 ↗

← Today

AI 개발 더 보기

NewsAI 개발중급·2026년 4월 6일

RAG 임베딩·리랭커 지형 2026: 'embedding 교체'보다 '리랭커 추가'가 답일 때

2026 상반기 RAG 검색 품질의 정석 조합이 굳어졌다. 임베딩은 최고 품질 API로 Voyage voyage-3-large, 범용으로 OpenAI text-embedding-3-large, 멀티미디어(텍스트+이미지 단일 임베딩)로 Cohere embed-v4, 다국어/교차언어로 Gemini Embedding 2가 꼽힌다. 셀프호스팅은 BGE-M3가 dense+BM25+리랭커 세 모델을 하나로 대체하는 하이브리드 모드로 현실적 1순위이고, Apache-2.0로 풀린 Qwen3-Embedding 시리즈(0.6B/4B/8B)는 8B가 MTEB 다국어 리더보드 1위(70.58, 2025-06 기준)에 100개 이상 언어를 지원해 오픈소스 진영을 끌어올렸다. 핵심 실무 원칙: 'top-50 안에는 정답 문서가 있는데 top-5에는 없다'면 더 좋은 임베딩으로 갈아타는 것보다 리랭커 추가가 더 큰 이득을 준다. 리랭커는 프로토타입엔 CPU에서 도는 무료 ms-marco-MiniLM-L-6-v2, 운영엔 Cohere rerank-v3나 BGE 리랭커를 붙이는 식으로 비용·지연·언어지원을 저울질한다.

임베딩 모델 벤치마크 순위에만 매달리는 팀이 많지만, 실제 정확도 병목은 1차 검색이 아니라 재정렬 단계에 있는 경우가 흔하다. AIPida처럼 한국어 콘텐츠를 다루면 영어 MTEB 1위보다 다국어/한국어 실측이 중요하므로, Gemini Embedding 2나 Qwen3-8B를 자체 데이터로 리랭커와 함께 A/B 하는 것이 정답에 가깝다. '임베딩 한 번 정하고 끝'이 아니라 리랭커를 별도 레버로 두는 2단 검색 구조를 기본값으로 깔아두면 모델 교체 비용 없이 품질을 끌어올릴 수 있다.

Milvus Blog / ZeroEntropy / Qwen원문

NewsAI 개발중급·2026년 3월 9일

MCP 2026 로드맵, 원격 서버·에이전트 통신·엔터프라이즈로 무게중심 이동

Model Context Protocol(MCP) 메인테이너가 2026년 로드맵을 공개했다. 네 가지 우선순위는 (1) 전송 계층 확장성 — 원격 HTTP 전송을 개선해 수평 확장을 가능케 하고 .well-known 메타데이터로 서버 역량을 탐색, (2) 에이전트 통신 — 장시간 작업을 다루는 Tasks 프리미티브에 재시도·만료 정책을 추가, (3) 거버넌스 성숙 — Working Group 중심으로 SEP(스펙 개선 제안) 검토를 위임, (4) 엔터프라이즈 준비 — 감사 로그·SSO 인증·게이트웨이·설정 이식성이다. 핵심은 로컬 stdio 중심에서 평범한 HTTP 인프라 위에서 스케일하는 상태 비저장(stateless) 원격 서버로 무게중심이 옮겨간다는 점이다. 한국 개발자라면 사내 MCP 서버를 round-robin 로드밸런서 뒤에 둘 수 있는지, Tasks 확장으로 장시간 잡을 어떻게 모델링할지 미리 검토할 가치가 있다.

MCP가 개인 데스크톱 통합을 넘어 멀티테넌트 프로덕션 표준으로 진화하면서, 사내 도구를 에이전트에 연결하는 아키텍처 결정이 달라진다.

Model Context Protocol Blog원문

NewsAI 개발고급·2025년 12월 15일

추론 엔진 vLLM·SGLang·TensorRT-LLM, 무엇을 언제 쓸까

자체 모델을 서빙할 때 어떤 추론 엔진을 고르느냐가 비용·지연·처리량을 모델 아키텍처보다 더 크게 좌우한다. vLLM은 빠른 기동과 폭넓은 모델 호환성이 강점이라 합리적인 기본값이다. SGLang은 RadixAttention(접두사 공유 KV 캐시 재사용), 커널 퓨전, 구조적 생성에 강해 공통 시스템 프롬프트나 RAG 접두사를 공유하는 워크로드, 구조화 출력에서 큰 이득을 낸다. TensorRT-LLM은 NVIDIA GPU에 깊게 최적화돼 최대 처리량을 노리지만 빌드·운영 복잡도가 높다. 실무 원칙은 단순하다 — 워크로드가 긴 공유 접두사를 자주 쓰면 SGLang을, 다양한 모델을 빠르게 띄워야 하면 vLLM을, 고정 모델로 극한 처리량이 필요하면 TensorRT-LLM을 검토한다. 어떤 경우든 자사 트래픽 패턴(입력/출력 길이 분포, 동시성)으로 직접 벤치마크해야 한다.

GPU 비용이 서비스 손익의 큰 축인 상황에서, 엔진 선택과 튜닝만으로 동일 하드웨어의 처리량을 배수로 끌어올릴 수 있다.

Yotta Labs원문

NewsAI 개발고급·2026년 4월 21일

vLLM vs SGLang, 그리고 prefill/decode 분리: LLM 서빙의 표준 아키텍처가 바뀐다

대규모 LLM 추론에서 prefill(입력 프롬프트 전체 처리)과 decode(토큰 1개씩 생성)를 같은 인스턴스에 두지 않고 물리적으로 분리하는 'disaggregated serving'이 2026년 사실상 표준 패턴으로 올라섰다. 이유는 두 단계의 병목이 다르기 때문이다. prefill은 compute-bound라 큰 배치로 묶을수록 유리하고, decode는 memory-bandwidth-bound이면서 지연에 민감하다. 한 인스턴스에 섞으면 서로의 SLA를 깎아먹는다. vLLM은 prefill·decode를 각각 별도 인스턴스로 띄우고 --kv-transfer-config로 KV 캐시 전송 커넥터(NIXL, LMCache, 공유메모리)를 지정한다. SGLang은 라우터의 --disaggregation-mode로 prefill 워커·decode 워커·라우터를 구성하고 Mooncake/NIXL 백엔드를 지원하며, GB200 NVL72 클러스터에서 디코딩 처리량 2.7배를 보고했다. Meta·LinkedIn·Mistral·HuggingFace가 이미 vLLM 기반 분리 서빙을 프로덕션에서 돌리고 있고, LMSYS는 H100 96장(prefill 3노드+decode 9노드)으로 DeepSeek-R1 분리 서빙을 시연했다.

이 아키텍처는 '추론 처리량 2배'가 마케팅 문구가 아니라 하드웨어 활용의 구조적 개선이라는 점에서 중요하다. 한 대 GPU 자체 서빙 단계를 넘어 여러 장으로 스케일하는 순간, prefill/decode를 안 나누면 비싼 GPU를 절반만 쓰는 셈이다. 다만 KV 캐시를 인스턴스 간 전송하는 네트워크(NIXL 같은 RDMA 백엔드)가 새 병목이자 운영 복잡도가 되므로, 자체 LLM을 운영하려는 팀은 vLLM/SGLang 중 KV 전송 커넥터 생태계를 먼저 점검해야 한다.

vLLM Docs / SGLang / Spheron원문

이 브리핑에 대한 Q&A

이 브리핑에 질문하기

이 브리핑에서 궁금한 점이 있다면 먼저 질문을 남겨보세요.

첫 댓글을 남겨보세요.

중요한 AI 소식만, 메일로 받아보세요

매일 쏟아지는 소식 중 꼭 봐야 할 것만 골라 실무 가이드와 함께 보냅니다.

핵심 뉴스 5 · 추천 가이드 3 · 인기 Q&A