AI 에이전트의 진짜 비용은 모델이 아니라, 당신이 보내는 모든 것이다.

Source: Dev.to

동일 백엔드에서 Lynkr를 LiteLLM과 벤치마킹했습니다. 도구 중심 워크로드에서 Lynkr가 더 저렴했습니다

Founder disclosure: 저는 Lynkr를 직접 만들었으니, 이 글은 중립적인 업계 보고서가 아니라 기술적인 벤치마크 정리임을 알려드립니다. 아래 수치는 두 게이트웨이 모두 같은 백엔드 제공자를 사용해 얻은 결과입니다.
AI 코딩 트래픽을 게이트웨이로 라우팅한다면, 단순히 제공자를 바꾸는 것만으로는 충분하지 않습니다. 진정한 비용 절감은 모델에 도달하는 토큰 자체를 줄이는 데서 옵니다.

저는 Lynkr와 LiteLLM을 같은 백엔드—로컬 Ollama, Moonshot, Azure OpenAI—에서 9가지 시나리오에 걸쳐 테스트했습니다. 에이전트형 코딩 작업에 해당하는 시나리오에서는 Lynkr가 세 가지 사전 작업을 수행하기 때문에 비용이 더 낮았습니다: 스마트 툴 선택, TOON 압축, 그리고 의미 기반 캐시.

Lynkr는 비용에 민감한 워크로드 부분에서 눈에 띄게 우수했습니다:

• 스마트 툴 선택: 입력 토큰 53% 감소, 비용 52% 절감
• TOON JSON 압축: 대형 툴 결과에서 청구 토큰 87.6% 감소, 비용 50% 절감
• 의미 캐시: 캐시 히트 시 171ms 응답 vs 반복 쿼리 경로에서 3,282ms
• 계층 라우팅: 모든 요청을 가장 저렴한 경로에 무작위로 보내는 대신, 어려운 프롬프트는 강력한 모델로 에스컬레이션

툴, 파일 읽기, grep 출력, 반복 컨텍스트가 토큰 청구에 큰 비중을 차지하는 Claude Code, Codex, Cursor와 같은 에이전트 워크플로우에서는 이러한 차이가 중요합니다.

• 동일한 벤치마크 입력, 동일한 제공자, 동일한 요청 형태
• 머신: macOS on Apple Silicon
• Lynkr: v9.3.2 on Node 20
• LiteLLM: v1.87.1 on Python 3.12
• 사용 백엔드: Ollama 로컬, Moonshot, Azure OpenAI
• 시나리오: 간단 프롬프트, 툴, 히스토리, 캐시, 라우팅을 포함한 총 9개

각 시나리오는 POST /v1/messages 로 두 게이트웨이에 동일한 HTTP 요청을 보냈습니다. 많은 코딩 요청이 읽기 전용이지만, 모델은 여전히 전체 툴 세트를 전달받습니다: write, edit, bash, git, 파일 작업 등 모든 툴.

Lynkr는 먼저 요청을 분류하고, 상위로 전달하기 전에 관련 없는 툴 스키마를 제거합니다. 따라서 읽기 전용 질문은 쓰기 가능한 툴을 포함하지 않아 비용이 절감됩니다.

벤치마크 설정: 모든 요청에 14개의 툴 정의가 첨부되었으며, 이는 Claude Code나 Cursor 스타일 세션에 꽤 현실적인 상황입니다.

• Lynkr: 959 청구 입력 토큰, $0.0044
• LiteLLM: 2,085 청구 입력 토큰, $0.0091

결과: 동일 모델·프롬프트 기준 입력 토큰 53% 감소, 비용 52% 절감. 이 최적화는 매번 하위 모델 호출 전에 발생하기 때문에 복합적인 비용 절감 효과를 냅니다.

툴 중심 워크플로는 구조화된 JSON 때문에 비용이 급증하는 경우가 많으며, 이는 사용자가 긴 프롬프트를 작성했기 때문이 아닙니다. Lynkr의 TOON 경로는 대형 JSON 페이로드를 제공자에 전달하기 전에 압축합니다. 일반 텍스트는 그대로 전달됩니다. 이 효과 덕분에 파일 읽기, grep 배열, 툴 트레이스 등 구조화된 출력이 요청을 압도하지 않게 됩니다.

벤치마크 설정: Bash 툴이 60개의 grep 결과를 JSON 배열로 반환, 최적화되지 않은 경우 약 3,400 토큰.

• Lynkr: 427 청구 입력 토큰, $0.009, 지연 12초
• LiteLLM: 3,458 청구 입력 토큰, $0.018, 지연 12초

결과: 토큰 87.6% 감소, 비용 50% 절감, 지연은 동일하게 유지되었습니다. 비용이 개선되면서 요청이 느려지는 트레이드오프가 아니라, 압축이 프로세스 내에서 이루어져 실시간 결과가 변하지 않았다는 점이 핵심입니다.

가장 저렴한 요청은 모델에 도달조차 하지 않는 경우입니다. Lynkr는 들어오는 프롬프트에 대한 임베딩을 계산하고, 의미적으로 유사한 요청이 다시 나타나면 캐시된 응답을 반환합니다. 벤치마크에서 두 번째 프롬프트는 첫 번째의 패러프레이즈에 불과했습니다:

• “Explain TCP vs UDP”

• “What is the difference between TCP and UDP?”

• Lynkr(콜드): 2,857 토큰, 1,891ms

• Lynkr(캐시 히트): 171ms에 캐시에서 제공

• LiteLLM(반복 경로): 54 토큰, 3,282ms

핵심은 토큰 회피뿐만 아니라 응답 시간이 1.9초에서 171ms로 약 11배 빨라졌다는 점입니다. 인터랙티브 툴링에서는 이 차이가 즉시 체감됩니다.

LiteLLM에도 라우팅 기능이 있지만, 이번 벤치마크에서는 비용 기반 라우팅을 사용했으며, 이는 게이트웨이가 먼저 가장 저렴한 옵션을 선택하도록 최적화합니다. 이는 간단한 질문에는 잘 작동하지만, 프롬프트가 실제로 더 강력한 모델을 필요로 할 때는 문제가 됩니다.

Lynkr는 토큰 크기, 추론 마커, 코드 복잡도, 위험 신호, 에이전트 특성 등 15가지 차원을 기준으로 요청을 점수화하고 자동으로 라우팅합니다.

벤치마크 예시

• 간단 프롬프트: “What does git stash do?”

  • Lynkr → minimax-m2.5 로 라우팅
  • LiteLLM → 로컬 Ollama 로 라우팅

• 복잡 프롬프트: “JWT vs cookies security analysis for a banking architecture”

  • Lynkr → moonshot-v1-auto 로 에스컬레이션
  • LiteLLM → 여전히 로컬 Ollama 로 전송

이는 “기본적으로 저렴함”과 “적절할 때만 저렴함”의 차이입니다.

많은 게이트웨이 비교는 “몇 개의 제공자와 통신할 수 있느냐”로 귀결되지만, 이제는 기본적인 수준이 되었습니다. 더 중요한 질문은 요청이 모델에 도달하기 전에 지출을 줄이기 위해 게이트웨이가 무엇을 하는가? 입니다. 여기서 Lynkr는 실제로 차별화됩니다.

Lynkr는 세 가지 비용 레버를 겹쳐 사용합니다:

1. 툴 가지치기 – 관련 없는 툴 스키마가 함께 전송되지 않도록 함
2. TOON 압축 – 대형 구조화 툴 출력이 프롬프트를 부풀리는 것을 방지
3. 의미 캐시 – 반복 혹은 유사 요청이 모델 호출을 다시 하지 않게 함

그 위에 계층 라우팅을 추가해 남은 요청을 작업에 맞는 모델로 보냅니다. 이 스택이 벤치마크 결과를 흥미롭게 만든 이유이며, “Lynkr도 라우팅을 할 수 있다”는 수준을 넘어, 라우팅이 일어나기 전 요청 자체의 크기와 형태를 바꾸는 것이 핵심입니다.

대형 JSON 툴 결과 테스트를 대표적인 툴 중심 시나리오로 사용했을 때:

• LiteLLM: 약 $818/월
• Lynkr: 약 $409/월

동일한 백엔드, 동일한 모델 클래스에서 Lynkr는 약 50% 저렴하게 나왔습니다. 코딩 에이전트를 위한 LLM 게이트웨이를 평가한다면, 제가 중시하는 차이는 “다른 제공자 어댑터가 있느냐”가 아니라 “제공자가 보는 토큰 수를 얼마나 줄이느냐”입니다.

Portkey는 스택의 다른 레이어에 강점이 있습니다. 관리형 관측성, 프롬프트 관리, 거버넌스가 뛰어나지만,