추론 플랫폼 Baseten이 10월 2일 엔지니어링 블로그에 글을 올렸다. Claude Code로 Fable 5를 구동해 AI 에이전트가 단일 모델만 서비스하는 추론 엔진을 처음부터 작성하게 했고, 테스트한 모든 트래픽 패턴에서 vLLM을 앞질렀다고 밝혔다.
이 엔진은 VibeQwen이라 불리며, 알리바바의 Qwen-3.6-35B-A3B를 전담으로 서비스한다. 저자 Shawn Rushefsky는 글에서 다음과 같이 적었다.
"the generated engine, called VibeQwen, outperformed vLLM across all tested traffic patterns, and by very large margins in some cases"
(생성된 엔진 VibeQwen은 테스트한 모든 트래픽 패턴에서 vLLM을 앞섰고, 일부 경우에는 그 격차가 매우 컸다)
수치는 어떻게 나왔나
테스트 하드웨어는 엔비디아 B200, 비교 대상은 vLLM 0.25.1, 부하 테스트 도구는 AIPerf를 사용했다. 결과는 다음과 같다.
- 싱글 스트림 디코딩 1792 TPS, vLLM은 943 TPS로 약 90% 더 빨랐다;
- 첫 토큰 지연은 28밀리초에서 12밀리초로, 약 2.3배 단축됐다;
- 32개 동시 요청 기준 처리량이 71% 더 높았다.
비용 측면에서 VibeQwen은 전후로 약 1주일이 걸렸고, 토큰 약 17억 개(대부분 캐시 히트)와 B200 기준 약 200시간을 소모해, 총 비용은 수천 달러 수준이었다.
같은 방식을 이미지 분할에도 한 번 적용해봤다. 두 번째 결과물은 Sammie라 불리며, Meta의 SAM 3.1을 서비스하고 H100에서 구동된다. 작업은 며칠 만에 끝났고, 비용은 수백 달러, 토큰 약 2억 개가 들었다. 32개 동시 요청 기준 처리량은 Meta 공식 레퍼런스 서버보다 50% 높아 초당 91장의 이미지를 처리했다.
에이전트는 실제로 무엇을 했나
Baseten은 자체 프레임워크인 MetaInfer를 완전한 서빙 스택으로 확장하고, 나머지를 에이전트가 채우도록 맡겼다. 에이전트는 기존 오픈소스 구현을 참고할 수 있었고, 수정할 때마다 AIPerf로 부하 테스트를 돌려 그 수치를 기준으로 다음 단계를 결정했다.
특히 구체적으로 명시된 제약이 하나 있다. 출력 정밀도에 영향을 줄 수 있는 변경은 에이전트가 반드시 멈추고 사람의 승인을 받아야 한다는 것이다. 수치상의 미세한 드리프트는 추론 엔진에서 가장 잡아내기 어려운 문제이며, 속도 향상이 정밀도를 희생한 결과라면 벤치마크 점수만으로는 드러나지 않는다. 이 제약은 바로 그런 상황을 막기 위한 것이다.
블로그 글 스스로도 한계를 명시했다. VibeQwen과 Sammie는 모두 아직 실험 단계이며, 프로덕션 트래픽을 처리해본 적은 없다. Sammie 쪽 비교는 더 거칠어서, 저자 역시 해당 수치가 "시사적인 증거" 정도에 그친다고 인정했다. 두 쪽의 아키텍처와 가속기가 서로 다르고, 대조 실험도 이루어지지 않았다.
중국 AI 팀에 주는 의미
VibeQwen의 대상은 오픈소스 Qwen 모델이며, 중국 내 상당수 운영 서비스도 마침 Qwen과 vLLM 또는 SGLang 조합으로 돌아간다. 그만큼 이 수치는 많은 팀의 일상 업무와 직접 맞닿아 있다.
두 방식의 경제성을 비교해볼 만하다. 범용 엔진은 수백 가지 모델 구조를 아울러야 해서, 단일 구조에 맞춘 과감한 최적화를 많이 넣을 수 없다. 전용 엔진은 단 하나의 모델만 보기 때문에 어텐션 커널, MoE 라우팅, 스케줄링 전략을 전부 35B-A3B 구조에 맞게 설계할 수 있다. 과거에는 전용 엔진을 만드는 데 팀 단위로 몇 달이 걸렸지만, Baseten은 이번에 그것을 1주일, 수천 달러로 압축했다. 대략 계산하면 추론 엔지니어 한 명의 한 달 인건비보다 싸다.
- 엔진이 모델에 종속된다. Qwen이 업그레이드되어 구조가 바뀌면 엔진은 대부분 다시 생성해야 한다.
- 테스트는 B200만 다뤘다. 중국에서 구할 수 있는 가속기 종류는 다양한데, 같은 과정이 다른 하드웨어에서도 재현되는지에 대한 데이터는 블로그에 없다.
- 프로덕션에서 중요한 롱테일 안정성, 메모리 파편화, 비정상 요청 처리는 부하 테스트로 다 검증되지 않을 수 있다.
그럼에도 "주요 모델마다 자동 생성된 전용 엔진을 둔다"는 방식이 검증 가능한 사례 하나를 확보한 셈이다. vLLM의 위치가 "운영 주력"에서 "기준선과 안전망"으로 밀려날지는, 이런 엔진을 실제로 프로덕션에 넣고 몇 달치 데이터를 공개하는 팀이 나오는지에 달려 있다.
참고 출처: Baseten 엔지니어링 블로그, CocoLoop; TPS, 첫 토큰 지연, 동시 처리량, 토큰 사용량, GPU 시간은 Baseten 블로그 기준으로 확인됐다.