[베타] Rust AI 게이트웨이

이것은 베타 기능이며 다루는 표면이 아직 늘어나고 있어요. Rust 코어는 선택(opt-in)이며 기본적으로 꺼져 있고, 실패하거나 아직 지원되지 않는 Rust 경로는 자동으로 기존 Python 경로로 대체되므로, 켜도 Python이 이미 처리하는 요청을 깨뜨릴 수 없어요. Anthropic /v1/messages 라우트용 모델별 rust: true 플래그는 v1.94.0 이상에서 사용 가능하며 v1.94.0-rc.1에서 처음 출시됐어요. anthropic·bedrock의 /chat/completions 지원은 더 새로워서 곧 출시될 릴리스에서 제공돼요. /chat/completions에서 자동 대체는 Rust 경로가 받아들이지 않는 요청을 다루며, 이는 프로바이더를 호출하기 전에 결정돼요. 프로바이더에 이미 도달한 후 실패한 호출은 Python 경로에서 재시도되는 대신 그 오류를 반환해요.

출처: 문서

본문

LiteLLM은 요청/응답 변환을 Rust 코어(litellm-rust 워크스페이스, LiteLLM wheel에 내장)로 포팅하고 있어요. 목표는 Python이 각 Rust 경로가 패리티 범위를 가질 때까지 인증, 구성, 라우팅, 로깅, 콜백, 지출 추적을 계속 소유하면서 요청당 CPU와 지연 시간을 낮추는 것이에요.

두 가지 채택 방법이 있어요.

모드 1: 기존 Python 서버에서 Rust 활성화 (저위험)

모드 1은 현재 배포를 유지해요. Python 프록시가 여전히 요청을 종료하고 인증·라우팅을 실행하며 콜백을 호출해요. 오직 아래 지원 라우트의 프로바이더 변환과 네트워크 호출만 Rust 코어를 통해 실행돼요. 모델별로 선택적이고 어떤 오류에도 Python으로 대체되므로 시작하기 권장되는 방법이에요.

모델의 litellm_params에 rust: true를 설정해요. 배포의 다른 모든 것은 그대로예요.

model_list:
  - model_name: claude-sonnet-5
    litellm_params:
      model: anthropic/claude-sonnet-5
      api_key: os.environ/ANTHROPIC_API_KEY
      rust: true            # run this deployment through the Rust core

  - model_name: azure-claude
    litellm_params:
      model: azure_ai/claude-sonnet-5
      api_base: os.environ/AZURE_AI_API_BASE
      api_key: os.environ/AZURE_AI_API_KEY
      rust: true

Rust 코어가 서빙한 응답은 x-litellm-rust: true 헤더를 담아 요청별로 경로를 확인할 수 있어요.

curl -i http://localhost:4000/v1/messages \
  -H "Authorization: Bearer ***" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-sonnet-5",
    "max_tokens": 128,
    "messages": [{"role": "user", "content": "hello from rust"}]
  }'

응답 헤더에서 x-litellm-rust: true를 찾아보세요. 헤더가 없으면 요청이 Python 경로로 서빙됐다는 뜻이에요(라우트/프로바이더가 아직 Rust에 없거나, Rust 오류가 자동 대체를 트리거했거나).

rust: true가 현재 다루는 것

Rust 코어는 점점 더 많은 라우트의 부분집합을 다루어요. 라우트나 프로바이더가 목록에 없으면 해당 배포는 rust: true가 설정돼 있어도 투명하게 Python 경로에 남아요.

라우트	Rust 경로의 프로바이더
/chat/completions	anthropic, bedrock (Converse)
Anthropic /v1/messages	anthropic, azure_ai
오디오 전사	bedrock
Responses API	—
WebSockets	openai

스트리밍은 Anthropic /v1/messages 라우트에서 지원되며, 에이전틱 완성 훅이 필요한 요청은 훅이 계속 실행되도록 Python 경로에 남아요.

/chat/completions에서 Rust 코어는 비스트리밍 텍스트 대화를 받아요. 모든 메시지가 콘텐츠가 문자열이거나 {"type": "text", "text": ...} 부분의 비어 있지 않은 목록인 system·user·assistant 메시지이고, 대화가 user 턴으로 시작하며, 설정된 샘플링 파라미터가 max_tokens, temperature, top_p, stop, 그리고 anthropic에서는 top_k뿐일 때 요청이 Rust에서 실행돼요. Bedrock은 Claude 모델의 Bedrock 기본 라우트인 Converse를 통해 서빙되며, Converse에 어시스턴트 프리필이 없으므로 대화가 user 턴으로 끝나는 것도 추가로 필요해요.

어느 경로가 요청을 서빙하는지는 프로바이더를 호출하기 전에 결정되므로, 그 부분집합 밖의 모든 것은 config 변경이나 오류 없이 Python으로 서빙돼요. 여기에는 stream: true, 도구 호출·도구 결과, 이미지·기타 비텍스트 콘텐츠 부분, 빈 콘텐츠 목록의 메시지, response_format·JSON 모드, 확장 사고, 프롬프트 캐싱, bedrock의 top_k, 1보다 큰 n, 그리고 Rust 경로가 인식하지 못하는 기타 파라미터가 포함돼요. 이 라우트에서 선택은 프로바이더 호출이 나간 뒤에 최종이며, 그 지점 이후의 실패는 Python에서 재시도되는 것이 아니라 오류로 돌아와요. 재시도하면 같은 프로바이더 호출을 두 번 실행해 두 번 청구되기 때문이에요.

어느 경로든 응답 본문은 같아요(토큰 수 포함). 그래서 헤더가 유일한 구분 수단이에요. Rust 서빙 응답은 x-litellm-rust: true를, Python 서빙 응답은 그런 헤더를 담지 않아요.

모드 2: 독립 Axum 서버 실행

모드 2는 Python 호스트를 Rust litellm-ai-gateway Axum 서버 바이너리로 교체해 라우팅과 네트워크 I/O를 전부 Rust에서 실행해요. 처리량에서 더 높은 상한이지만 현재 Python 호스트보다 다루는 라우트가 적고 아직 전체 프록시 기능 세트가 없어요.

Axum 서버용 사전 빌드 Docker 이미지는 아직 게시되지 않았어요. 이 섹션은 출시되면 이미지 참조와 배포 예시로 채워질 거예요. 그동안 server 기능과 함께 litellm-rust 워크스페이스에서 서버를 빌드할 수 있어요. 조기 시험을 원하면 커뮤니티 채널에서 연락하세요.

더 알아보기 (Learn more)

고성능 문서