# \#serving **URL:** https://discuss.pytorch.kr/tag/serving/9275.md [최신](https://discuss.pytorch.kr/latest.md) · [카테고리](https://discuss.pytorch.kr/categories.md) · [태그](https://discuss.pytorch.kr/tags.md) --- ## [vLLM-Omni 기술 보고서: 음성, 이미지, 영상, 로봇 행동 모델을 한 런타임에서 서빙하는 구조](https://discuss.pytorch.kr/t/vllm-omni/12128)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [10월 10, 2026, 10:30오전 UTC](https://discuss.pytorch.kr/t/vllm-omni/12128 "2026-10-10T10:30:31Z")
핵심 요약 vLLM-Omni 기술 보고서는 텍스트, 음성, 이미지, 영상, 로봇 행동을 출력하는 모델을 여러 스테이지(stage)의 파이프라인으로 봅니다. 그리고 오케스트레이터 하나가 요청 수락, 스테이지 진행, 스트리밍, 완료를 관리하는 구조를 설명합니다. 코드는 vLLM-Omni GitHub 저장소에 Apache-2.0 라이선스로 공개되어 있습니다. 대상 독자는 옴니 모델, TTS 모델, 확산 모델을 서로 다른 서버로 실행해 연결하고 있는 서빙 담당자입니다. 프로세스마다 파이프라인 하나를 올리되, 모든 모델을 같은 런타임과 OpenAI 호환 API, 로봇용 OpenPI 프로토콜로 노출하는 방법을 확인할 수 있습니다. 평가는 vLLM-Omni 팀의 멀티모달 nightly CI(H100)와 별도 H200 측정에서 나왔고, 대부분 vLLM-Omni의 기본 배포와 옵트인 프로필을 비교합니다. SGLang-Omni 같은 다른 프레임워크와의 비교는 이번 판에서 제외했습니다. Qwen3-Omni에서 스테이지 사이 청크 스트리밍(async\_chunk)을 끄면 동시 요청 32개에서 첫 토큰 지연이 508 ms에서 3{,}420 ms로 늘었습니다. Qwen3-TTS를 GPU 1장의 단일 스테이지로 합친 프로필은 GPU 2장의 기본 배포보다 처리량이 높았습니다. 가장 큰 차이는 CustomVoice 동시 요청 64개의 2.6\\times 였고, 음성 복제(Base)는 같은 조건에서 1.66\\times 였습니다. 반면 일부 옵트인 프로필은 시작 단계 오류, 요청 실패, 발화가 멈추지 않는 문제를 함께 보고했습니다. vLLM-Omni 기술 보고서 소개 vLLM-Omni 기술 보고서는 텍스트 외에 음성, 이미지, 영상, 로봇 행동까지 출력하는 생성 모델을 하나의 서빙 런타임에서 운영하기 위한 시스템 구조와 측정 결과를 정리한 문서입니다. 음성으로 대화하는 비서 하나를 서비스한다고 생각해 봅시다. 사용자의 말을 이해해 답을 텍스트로 만드는 모델, 그 답을 음성 코덱으로 바꾸는…