Xinference: OpenAI API 그대로 두고 LLM·음성·이미지까지 한 번에 묶는 오픈소스 추론 플랫폼

AI 애플리케이션을 만들다 보면 금방 이런 순간이 옵니다.
텍스트는 OpenAI 스타일 API로 붙였는데, 임베딩은 또 다른 서버를 써야 하고, 음성 인식은 별도 엔드포인트, 이미지 생성은 또 다른 스택으로 따로 관리해야 합니다. 모델은 늘어나는데 운영 포인트도 같이 늘어납니다.

Xinference는 이 복잡함을 아주 현실적인 방식으로 풀어냅니다.
핵심은 단순합니다. 여러 종류의 오픈소스 모델을 하나의 통합 추론 플랫폼으로 묶고, OpenAI 호환 API까지 제공해서 기존 애플리케이션 코드의 변경 비용을 낮추는 것입니다. 게다가 로컬 노트북, 온프레미스, 클라우드, Kubernetes 클러스터까지 같은 제품 철학으로 가져갑니다. 지금 GitHub 기준으로 9.1k stars를 기록하고 있고, 최신 릴리스는 2026년 3월 13일 공개된 v2.3.0입니다. (GitHub)

 

GitHub - xorbitsai/inference: Swap GPT for any LLM by changing a single line of code. Xinference lets you run open-source, speec

 

---

프로젝트 소개

Xinference는 Xorbits AI가 만드는 오픈소스 추론 플랫폼입니다. 공식 문서와 저장소 설명을 보면 이 프로젝트는 LLM, embedding, image, audio, rerank, video를 포함한 다양한 AI 모델을 운영하고 통합하는 플랫폼으로 소개됩니다. 단순히 “모델 하나 띄우는 서버”가 아니라, 모델 등록·실행·종료·라우팅·관측까지 포함한 실전형 serving layer에 더 가깝습니다. (inference.readthedocs.io)

기술 스택 관점에서 보면 중심은 Python입니다. GitHub 언어 비율상 Python이 약 89.8%, JavaScript가 약 9.9%이고, 내부 구조 문서에 따르면 REST API는 FastAPI, CLI는 Click, 분산 실행과 자원 관리는 Xoscar actor 프레임워크 위에서 구성됩니다. 즉, “API 서버 + CLI + Web UI + actor 기반 실행 계층”이 결합된 구조라고 보면 이해가 쉽습니다. (GitHub)

또 하나 중요한 포인트는 백엔드 추론 엔진을 직접 추상화한다는 점입니다. 공식 문서에는 transformers, llama.cpp, vLLM, SGLang, MLX 같은 백엔드가 명시되어 있습니다. 이 말은 곧 Xinference가 모델 종류뿐 아니라 추론 엔진 선택까지 운영 계층에서 통합하려는 프로젝트라는 뜻입니다. (inference.readthedocs.io)

---

왜 이 프로젝트가 등장했을까

오픈소스 모델 생태계는 빠르게 발전했지만, 실제 서비스에 붙이는 순간 문제가 생깁니다.

첫째, 모델별 인터페이스가 제각각입니다.
어떤 모델은 transformers 스타일, 어떤 모델은 vLLM, 어떤 모델은 llama.cpp 기반으로 다뤄야 합니다. 개발자는 비즈니스 로직보다 “이 모델은 어떤 엔진으로 어떻게 띄워야 하지?”에 시간을 씁니다. Xinference는 이 문제를 “통합된 API 계층”으로 해결하려고 합니다. (inference.readthedocs.io)

둘째, 모달리티가 늘수록 운영 복잡도가 폭증합니다.
텍스트 생성만 할 때와 달리, embedding, rerank, image, audio까지 들어오면 모델 서버가 쪼개지고 SDK도 달라집니다. Xinference는 문서 첫 화면부터 LLM, Embedding, Image, Audio, Rerank, Video를 나란히 보여주며, 하나의 플랫폼에서 이들을 운영하는 방향을 분명하게 드러냅니다. (inference.readthedocs.io)

셋째, 오픈소스 모델 도입의 마이그레이션 비용이 큽니다.
기존 앱이 OpenAI SDK 기반으로 작성되어 있으면, 보통 서버와 클라이언트 둘 다 손봐야 합니다. Xinference는 OpenAI-compatible API를 제공해 base URL만 바꾸는 형태의 드롭인 대체를 지향합니다. 공식 문서에는 chat completions, completions, embeddings 지원 예시가 직접 나와 있고, Anthropic 호환 base URL도 별도로 제공합니다. (inference.readthedocs.io)

즉, Xinference가 등장한 배경은 아주 명확합니다.
“오픈소스 모델은 많아졌는데, 개발자 입장에서는 여전히 운영이 불편하다.”
이 불편함을 API, 실행 엔진, 배포, 운영 관점에서 한 번에 감싸는 것이 Xinference의 역할입니다. (GitHub)

---

Xinference의 핵심 가치 한 줄 요약

Xinference는 오픈소스 AI 모델을 서비스 가능한 형태로 표준화하는 운영 플랫폼입니다.
모델 자체보다 중요한 것은, 그 모델을 같은 방식으로 띄우고, 같은 방식으로 호출하고, 같은 방식으로 관측하게 만든다는 점입니다. (GitHub)

---

핵심 기능

1) OpenAI 호환 API

가장 실무적인 장점입니다. 이미 OpenAI Python SDK나 OpenAI 스타일 REST 호출을 쓰고 있다면, Xinference는 base URL만 바꿔 붙일 수 있는 구조를 제공합니다. 공식 예시도 OpenAI(base_url="http://127.0.0.1:9997/v1", api_key="not used actually") 형태입니다. (inference.readthedocs.io)

이 기능의 의미는 단순한 편의성이 아닙니다.
개발 조직 입장에서는 다음이 가능해집니다.

• 개발 환경에서는 로컬 Xinference
• 사내망에서는 온프레미스 Xinference
• 특정 팀은 상용 API
• 특정 팀은 오픈소스 모델

이런 구성을 애플리케이션 인터페이스를 크게 바꾸지 않고 가져갈 수 있습니다. (inference.readthedocs.io)

예시: 기존 OpenAI 코드 거의 그대로 사용

from openai import OpenAI

client = OpenAI(
    base_url="http://127.0.0.1:9997/v1",
    api_key="not-used"
)

resp = client.chat.completions.create(
    model="qwen2.5-instruct",
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user", "content": "Xinference가 왜 유용한지 설명해줘."}
    ]
)

print(resp.choices[0].message.content)

이 패턴이 강력한 이유는, 클라이언트 코드의 추상화 계층을 바꾸지 않아도 오픈소스 모델로 전환 실험을 할 수 있기 때문입니다. (inference.readthedocs.io)

---

2) 멀티모달 통합 운영

Xinference는 LLM만 다루는 제품이 아닙니다. 공식 문서와 저장소 설명에는 language, speech recognition, multimodal serving이 명시되어 있고, 문서 구조상 client API도 LLM, Embedding, Image, Audio, Rerank로 나뉘어 있습니다. 최근 릴리스 노트에도 image, audio, video, OCR-VL 관련 모델 추가가 계속 보입니다. (GitHub)

이게 왜 중요할까요?
RAG 시스템을 생각해보면 실제로 필요한 것은 텍스트 생성 모델 하나가 아닙니다.

• 문서 임베딩 모델
• reranker
• 최종 응답용 LLM
• 필요하면 OCR 또는 음성 인식
• 필요하면 이미지 이해/생성 모델

Xinference는 이 조합을 “서로 다른 제품 조립”이 아니라 한 플랫폼 내부의 모델 카탈로그와 실행 체계로 묶으려 합니다. 이 지점이 단순 inference server와 MLOps 성격의 플랫폼을 가르는 분기점입니다. (inference.readthedocs.io)

---

3) 다양한 추론 백엔드 지원

공식 문서 기준으로 Xinference는 transformers, llama.cpp, vLLM, SGLang, MLX를 지원합니다. 설치 문서에는 backend별 extra 설치 방식도 나뉘어 있고, xinference[all] 설치가 가능하지만 v1.8.1부터는 vLLM과 SGLang 간 의존성 충돌 때문에 SGLang이 all extra에서 빠졌다는 점도 명시되어 있습니다. (inference.readthedocs.io)

이 설계는 꽤 영리합니다.
왜냐하면 개발자는 “모델이 무엇인가?”만 보는 게 아니라, 실제 운영에서는 “어떤 엔진이 지금 내 하드웨어와 워크로드에 맞는가?”를 고민해야 하기 때문입니다.

대략 이렇게 이해하면 됩니다.

• transformers: 범용성 높고 가장 기본적인 선택
• vLLM: 고성능 LLM serving에 강함
• SGLang: 고성능 런타임과 KV cache 재사용에 강점
• llama.cpp: GGUF 기반 로컬/경량 환경에 유리
• MLX: Apple Silicon 환경에서 유용

Xinference는 이 선택을 개별 프로젝트마다 다시 설계하게 하지 않고, 같은 플랫폼 위에서 엔진을 갈아끼울 수 있게 만듭니다. (inference.readthedocs.io)

---

4) 로컬부터 클러스터까지 같은 운영 모델

공식 문서상 Xinference는 Linux, Windows, macOS에 pip 설치가 가능하고, Docker 이미지와 Kubernetes Helm 설치도 제공합니다. 또한 xinference-local, xinference-supervisor, xinference-worker 같은 실행 방식이 분리되어 있습니다. (inference.readthedocs.io)

이 구조는 서비스 성장 단계와 잘 맞습니다.

• 개인 개발자는 xinference-local
• GPU 서버 한 대면 Docker
• 조직 단위 운영이면 supervisor + worker
• 플랫폼 팀이면 Kubernetes + Helm

즉, Xinference는 “데모용 로컬 서버”에서 끝나는 도구가 아니라, 같은 개념을 배포 규모에 맞춰 확장할 수 있게 설계된 플랫폼입니다. (inference.readthedocs.io)

---

5) 운영 기능: replica, load balancing, metrics

문서의 Model Launching Instructions에는 replica 개념이 따로 설명되어 있고, 여러 GPU에 동일 모델 인스턴스를 분산해 자동으로 load balancing한다고 되어 있습니다. Metrics 문서에는 supervisor와 worker 각각의 exporter가 있고, 요청 수·응답 수·status code·token throughput·TTFT 같은 지표를 노출합니다. (inference.readthedocs.io)

이런 기능은 “예쁘다”가 아니라 운영에서 필수입니다.

• replica: 처리량 확보
• TTFT 측정: 체감 지연 확인
• token/s: 추론 효율 확인
• request/response/status: 장애 추적
• worker metrics: GPU/노드 단위 병목 확인

그래서 Xinference는 단순 모델 런처보다 한 단계 위에 있습니다. 서비스 운영자가 보고 싶은 지표를 기본적으로 염두에 둔 제품입니다. (inference.readthedocs.io)

---

6) 분산 추론과 대형 모델 대응

Distributed Inference 문서에 따르면 Xinference는 최소 2개 이상의 worker를 전제로 분산 추론을 지원하고, SGLang과 vLLM, 일부 MLX 분산 실행을 지원합니다. 특히 대형 모델이 단일 머신 GPU에 들어가지 않을 때 여러 worker에 걸쳐 실행하는 시나리오를 직접 설명합니다. vLLM 0.11.0 이상에서는 Xinference 1.17.1 이상과 함께 tensor_parallel_size 및 pipeline_parallel_size=1 설정이 필요하다는 버전 조건도 문서에 적혀 있습니다. (inference.readthedocs.io)

이건 실무적으로 아주 중요합니다.
“OpenAI 호환 API”만 보면 단순 대체재 같지만, 실제로는 대형 오픈소스 모델을 운영 가능한 형태로 스케일링하는 계층까지 제공하는 셈이기 때문입니다. (inference.readthedocs.io)

---

프로젝트 아키텍처 분석

Xinference 내부 구조를 보면 꽤 명확한 계층이 보입니다. 공식 내부 문서는 REST API는 FastAPI, CLI는 Click, 실행 코어는 Xoscar actor 프레임워크 기반이라고 설명합니다. supervisor와 worker도 actor 인스턴스이며, worker actor는 모델 launch, list, terminate 같은 동작을 수행합니다. 또한 모델 구현은 model/ 계층에 모여 있고, Web UI 코드도 별도 디렉터리로 분리되어 있습니다. (inference.readthedocs.io)

아키텍처를 개발자 관점으로 재구성하면 아래와 같습니다.

이 구조의 핵심은 API 계층과 모델 실행 계층을 분리했다는 점입니다.
클라이언트는 REST나 CLI로 요청하지만, 실제 실행은 supervisor가 worker에게 할당하고, worker가 해당 엔진을 통해 모델을 로드·실행합니다. 그래서 로컬 단일 서버와 멀티노드 클러스터가 같은 운영 모델을 공유할 수 있습니다. (inference.readthedocs.io)

이 구조가 주는 장점

첫 번째는 엔진 교체의 유연성입니다.
Worker가 추론 엔진을 감싸기 때문에, 동일한 상위 API 아래에서 vLLM이든 transformers든 바꿔 끼울 수 있습니다. (inference.readthedocs.io)

두 번째는 분산 배포의 자연스러움입니다.
Supervisor가 orchestration을 맡고 worker가 실제 리소스를 소비하므로, 노드가 늘어나도 구조가 깨지지 않습니다. (inference.readthedocs.io)

세 번째는 관측 가능성입니다.
Supervisor/Worker metrics가 분리되어 있어 “API 계층 문제인지, 실제 모델 처리 문제인지”를 나눠서 볼 수 있습니다. (inference.readthedocs.io)

---

실제로 어떻게 쓰는가

가장 간단한 시작은 로컬 실행입니다.

pip install "xinference[all]"
xinference-local

공식 문서에 따르면 Linux, Windows, macOS에서 pip 설치가 가능하고, 로컬 인스턴스는 xinference-local로 시작할 수 있습니다. 이후 Web UI, cURL, CLI, Python client로 접근할 수 있습니다. (inference.readthedocs.io)

모델 운영은 단순 호출만이 아니라 lifecycle 관리도 가능합니다. 문서에는 모델 registration 조회, 현재 실행 중인 모델 조회, 특정 모델 terminate 예시가 CLI/cURL/Python client 형태로 함께 제공됩니다. (inference.readthedocs.io)

xinference registrations -t LLM
xinference list
xinference terminate --model-uid "qwen2.5-instruct"

이 부분이 좋은 이유는, 서비스에서 필요한 운영 작업이 보통 “추론 호출” 하나로 끝나지 않기 때문입니다.
무슨 모델이 등록돼 있는지, 지금 무엇이 떠 있는지, 필요 없는 모델을 내려 자원을 회수할 수 있는지가 실제 운영 포인트입니다. Xinference는 이를 API 플랫폼의 기본 기능으로 넣어둡니다. (inference.readthedocs.io)

---

Xinference를 쓰면 좋은 팀

1) OpenAI 의존도를 낮추고 싶은 팀

기존 애플리케이션이 OpenAI SDK 중심이라면, Xinference는 가장 낮은 마찰로 오픈소스 모델 A/B 테스트를 붙일 수 있는 선택지입니다. base URL 전환 중심의 접근이 가능하기 때문입니다. (inference.readthedocs.io)

2) RAG 파이프라인을 운영하는 팀

LLM만이 아니라 embedding, rerank, image, audio를 함께 다뤄야 하는 경우 Xinference의 진가가 더 잘 드러납니다. 각각 다른 서버를 운영하는 대신, 하나의 추론 플랫폼 아래에서 관리할 수 있기 때문입니다. (inference.readthedocs.io)

3) GPU 서버를 점점 늘려가는 팀

처음엔 단일 서버에서 시작하더라도, 나중에 replica, distributed inference, Kubernetes까지 확장할 수 있는 길이 열려 있습니다. 이 확장 경로가 문서와 CLI 수준에서 이미 드러난다는 점이 강점입니다. (inference.readthedocs.io)

4) 멀티모달 서비스를 준비하는 팀

텍스트 챗봇 수준을 넘어 음성 인식, 이미지 이해/생성, 비디오까지 고려한다면, Xinference는 “모델별 전용 서버를 따로 도입할지” 고민을 줄여줍니다. (inference.readthedocs.io)

---

Xinference를 볼 때 주의할 점

장점이 분명한 만큼, 운영 관점에서는 몇 가지 현실도 같이 봐야 합니다.

첫째, 백엔드별 의존성 관리가 완전히 공짜는 아닙니다.
설치 문서에 vLLM과 SGLang 의존성 충돌 때문에 all extra에서 SGLang을 분리했다고 적혀 있는 것만 봐도, 멀티엔진 플랫폼의 숙명은 존재합니다. Xinference는 이 복잡함을 많이 감춰주지만, 완전히 없애지는 못합니다. (inference.readthedocs.io)

둘째, 대형 모델 운영은 여전히 인프라 지식이 필요합니다.
분산 추론 문서에 엔진별 버전 조건과 병렬 설정이 따로 있는 이유가 바로 이것입니다. 플랫폼이 복잡함을 줄여주더라도, GPU 수·메모리·병렬 전략 같은 문제는 여전히 중요합니다. (inference.readthedocs.io)

셋째, 기능이 넓은 만큼 제품 성격도 넓습니다.
단순 로컬 챗 서버를 원한다면 다소 무겁게 느껴질 수 있습니다. 반대로 운영 관점에서는 이 넓은 범위가 오히려 장점이 됩니다. 그래서 Xinference는 “가벼운 취미용 서버”보다는 실험에서 운영으로 넘어가려는 팀에게 더 잘 맞습니다. 이 평가는 공식 문서의 기능 범위와 배포 옵션을 바탕으로 한 해석입니다. (inference.readthedocs.io)

---

개인적으로 보는 Xinference의 진짜 포지션

Xinference를 단순히 “OpenAI 호환 API 서버”로만 보면 절반만 본 겁니다.
이 프로젝트의 진짜 가치는 오픈소스 모델 서빙의 표준 운영면을 통합한다는 점에 있습니다.

• API 표준화
• 엔진 추상화
• 모달리티 통합
• 로컬~클러스터 확장
• replica / metrics / distributed inference

이 다섯 가지를 한 제품 안에서 연결하고 있다는 점에서, Xinference는 inference server이면서 동시에 경량 MLOps platform에 가깝습니다. 이건 공식 기능 범위를 바탕으로 한 해석이지만, 저장소와 문서가 보여주는 방향성과 잘 맞습니다. (GitHub)

---

마무리

요즘 오픈소스 AI 인프라에서 중요한 건 “어떤 모델이 제일 좋으냐”만이 아닙니다.
그 모델을 얼마나 빨리 붙이고, 얼마나 쉽게 교체하고, 얼마나 일관되게 운영할 수 있느냐가 더 중요해졌습니다.

Xinference는 바로 그 지점을 겨냥합니다.
OpenAI 호환 API로 개발자 진입 장벽을 낮추고, vLLM·SGLang·transformers·llama.cpp·MLX 같은 다양한 실행 엔진을 흡수하고, 텍스트를 넘어 음성·이미지·비디오까지 한 플랫폼에서 운영하게 만듭니다. 로컬에서 시작해 클러스터까지 확장할 수 있다는 점도 실전적입니다. (inference.readthedocs.io)

한 줄로 정리하면 이렇습니다.

Xinference는 “오픈소스 모델을 서비스 가능한 API 제품으로 바꾸는 계층”이다.
그리고 그 점 때문에, 이 프로젝트는 단순한 추론 도구를 넘어 개발자 친화적인 AI 플랫폼으로 읽을 가치가 있습니다. (inference.readthedocs.io)