가이드
LLM 게이트웨이와 프록시 운영
연재 「LLM API 운영」의 글 세 편이다. 첫 글은 서비스 코드가 프로바이더를 직접 부르지 않을 때 LLM 게이트웨이가 무엇을 맡는지를 본다. 둘째는 LiteLLM 프록시를 띄워, Admin UI가 보여주는 것과 Grafana와 Langfuse가 있어야 보이는 것을 적는다. 셋째는 프롬프트 캐시와 응답 캐시를 가르고, 캐시가 언제 이득인지 따진다.
번호가 읽는 순서다. 날짜는 그 글이 발행된 날이다.
1
LLM API 게이트웨이 - OpenRouter, LiteLLM, Cloudflare 비교
OpenAI, Anthropic, Gemini API를 서비스 코드에서 직접 부르면 형식 차이, 장애 대응, 키와 비용 관리가 서비스마다 반복된다. 게이트웨이가 그 반복을 한 계층으로 모을 때 무엇을 내주는지 짚고, OpenRouter, LiteLLM, Cloudflare AI Gateway를 지연, fallback, 응답 캐시, 팀별 예산으로 비교한다. 비교는 공식 문서와 공개된 측정을 기준으로 했다. 첫 토큰까지는 Cloudflare가 26~37ms, OpenRouter가 200ms 남짓 더 걸렸다.
2
LiteLLM 프록시 모니터링 - Admin UI로 충분한 것과 Grafana, Langfuse가 있어야 보이는 것
Postgres를 붙인 LiteLLM 프록시는 누가 얼마나 썼는지를 보여준다. 실패율, 지연, fallback이 실제로 일어나는지는 Prometheus와 Grafana가 있어야 시계열과 알림으로 보인다. 요청 본문, 세션, 트레이스, 점수는 Langfuse 같은 트레이싱 도구가 있어야 보인다. 같은 mock 트래픽을 14분간 흘리고 각 화면이 무엇을 보여주는지 적었다.
3
AI 캐시가 제값을 하려면
AI API의 캐시 히트는 저장해 둔 답을 돌려주는 응답 캐시가 아니다. 입력 앞부분을 계산해 둔 KV를 다시 쓴다. 어떤 요청이 적중하는지, 쓰기 비용을 감안하면 적중률이 얼마여야 본전인지 따지고, Claude Code 실측과 슬랙 챗봇 운영 로그로 에이전트와 챗봇을 비교한다. 에이전트 세션은 입력의 97.6%가 캐시 읽기였다.