# \#inference-framework **URL:** https://discuss.pytorch.kr/tag/inference-framework/5005.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 기술 보고서는 텍스트 외에 음성, 이미지, 영상, 로봇 행동까지 출력하는 생성 모델을 하나의 서빙 런타임에서 운영하기 위한 시스템 구조와 측정 결과를 정리한 문서입니다. 음성으로 대화하는 비서 하나를 서비스한다고 생각해 봅시다. 사용자의 말을 이해해 답을 텍스트로 만드는 모델, 그 답을 음성 코덱으로 바꾸는… --- ## [LLM 추론 엔진 이해하기: Nano-vLLM 내부 살펴보기 - 2부 (Understanding LLM Inference Engines: Inside Nano-vLLM (Part 2))](https://discuss.pytorch.kr/t/llm-nano-vllm-2-understanding-llm-inference-engines-inside-nano-vllm-part-2/9126)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [3월 3, 2026, 9:30오후 UTC](https://discuss.pytorch.kr/t/llm-nano-vllm-2-understanding-llm-inference-engines-inside-nano-vllm-part-2/9126 "2026-03-03T21:30:40Z")
Enterprise-grade Private Model-as-a-Service Platform, Neutree의 허락 하에 번역하였습니다. Neutree는 Enterprise Cloud Infra 기업 Arcfra에서 제공하고 있으며, 오픈소스로 공개되어 있습니다. Neutree의 원문 블로그는 아래 링크에서 확인 가능합니다. Neutree 소개 글은 여기에서 보실 수 있습니다. LLM 추론 엔진 이해하기: Nano-vLLM 내부 살펴보기 - 1부 글은 여기에서 보실 수 있습니다. LLM 추론 엔진 이해하기: Nano-vLLM 내부 살펴보기 (2부) Understanding LLM Inference Engines: Inside Nano-vLLM (Part 2) 모델 내부 구조, KV Cache, 그리고 텐서 병렬화 / Model Internals, KV Cache, and Tensor Parallelism 이전 글(1부)에서는 Nano-vLLM의 엔지니어링 아키텍처를 살펴봤습니다. 요청이 시스템을 어떻게 흐르는지, Scheduler가 시퀀스를 어떻게 배치(batch)로 묶는지, Block Manager가 KV cache 할당을 어떻게 추적하는지를 다뤘습니다. 의도적으로 모델 연산 자체는 블랙박스로 남겨두었는데, 이제 그 상자를 열어볼 차례입니다. In Part 1, we explored the engineering architecture of Nano-vLLM: how requests flow through the system, how the Scheduler batches sequences, and how the Block Manager tracks KV cache allocations. We deliberately treated the model computation as a black box. Now it's time to open that box. 이번 글에서는 모델 자체를 깊이 파헤칩니다. 토큰이 어떻게 벡터가 되는지, … --- ## [LLM 추론 엔진 이해하기: Nano-vLLM 내부 살펴보기 - 1부 (Understanding LLM Inference Engines: Inside Nano-vLLM (Part 1))](https://discuss.pytorch.kr/t/llm-nano-vllm-1-understanding-llm-inference-engines-inside-nano-vllm-part-1/9117)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [3월 3, 2026, 3:30오전 UTC](https://discuss.pytorch.kr/t/llm-nano-vllm-1-understanding-llm-inference-engines-inside-nano-vllm-part-1/9117 "2026-03-03T03:30:33Z")
Enterprise-grade Private Model-as-a-Service Platform, Neutree 블로그를 허락 하에 번역하였습니다. Neutree는 Enterprise Cloud Infra 기업 Arcfra에서 제공하고 있으며, 오픈소스로 공개되어 있습니다. Neutree의 원문 블로그는 아래 링크에서 확인 가능합니다. Neutree 소개 글은 여기에서 보실 수 있습니다. LLM 추론 엔진 이해하기: Nano-vLLM 내부 살펴보기 (1부) Understanding LLM Inference Engines: Inside Nano-vLLM (Part 1) 아키텍처, 스케줄링, 그리고 프롬프트에서 토큰까지 / Architecture, Scheduling, and the Path from Prompt to Token LLM을 프로덕션에 배포할 때 추론 엔진은 핵심 인프라가 됩니다. OpenAI, Claude, DeepSeek 등 우리가 사용하는 모든 LLM API는 이런 추론 엔진 위에서 동작합니다. 대부분의 개발자는 고수준 API를 통해 LLM과 상호작용하지만, 그 내부—프롬프트(Prompt)가 어떻게 처리되고, 요청이 어떻게 함께 처리(Batch)되며, GPU 리소스가 어떻게 관리되는지—를 이해하면 시스템 설계를 결정하는데 큰 도움이 됩니다. When deploying large language models in production, the inference engine becomes a critical piece of infrastructure. Every LLM API you use — OpenAI, Claude, DeepSeek — is sitting on top of an inference engine like this. While most developers interact with LLMs through high-level APIs, understanding what happens beneath the surface—… --- ## [mlx-vlm: M5와 같은 Apple Silicon에 최적화된 MLX 기반 시각-언어 모델(VLM) 추론 및 파인튜닝 도구](https://discuss.pytorch.kr/t/mlx-vlm-m5-apple-silicon-mlx-vlm/8963)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [2월 10, 2026, 9:30오후 UTC](https://discuss.pytorch.kr/t/mlx-vlm-m5-apple-silicon-mlx-vlm/8963 "2026-02-10T21:30:57Z")
mlx-vlm 소개 mlx-vlm은 Apple의 자체 실리콘(Apple Silicon) 칩셋에 최적화된 머신러닝 프레임워크인 MLX를 기반으로 구축된, Vision Language Model(VLM) 및 Omni Model 전용 툴킷입니다. 오늘날의 AI 트렌드는 단순히 텍스트만을 처리하는 LLM(Large Language Model)을 넘어, 이미지와 오디오, 비디오까지 동시에 이해하고 처리하는 멀티모달(Multi-modal) 모델로 진화하고 있습니다. 하지만 이러한 멀티모달 모델들은 방대한 연산량과 메모리를 요구하기 때문에, 고성능 NVIDIA GPU가 없는 로컬 환경, 특히 Mac 사용자들에게는 접근 장벽이 높았습니다. 이러한 배경에서 등장한 mlx-vlm은 Mac 개발자들이 로컬 환경에서 최신 고성능 모델을 효율적으로 구동할 수 있도록 돕습니다. 이 라이브러리는 단순히 모델을 실행하는 추론(Inference) 기능뿐만 아니라, 사용자의 데이터셋을 이용해 모델을 재학습시키는 파인튜닝(Fine-tuning) 기능까지 포괄적으로 제공합니다. 특히 Apple Silicon의 통합 메모리 구조를 활용하여 4-bit 또는 8-bit 양자화된 모델을 구동함으로써, 제한된 하드웨어 자원 내에서도 놀라운 속도와 성능을 보여줍니다. 개발자는 복잡한 환경 설정 없이도 이 패키지를 통해 이미지 분석, 문서 OCR, 비디오 캡셔닝, 오디오 이해와 같은 작업을 자신의 Mac에서 즉시 수행할 수 있습니다. mlx-vlm의 주요 특징 Apple Silicon에 최적화된 멀티모달 환경 mlx-vlm의 가장 큰 특징은 Apple이 직접 개발한 MLX 프레임워크 위에서 동작한다는 점입니다. 이는 기존의 PyTorch 기반 모델들을 Apple의 하드웨어 가속기(Metal)에 맞춰 변환하고 최적화하는 과정을 자동화해 줍니다. 사용자는 Hugging Face Hub에 업로드된 mlx-community 버전의 모델들을 별도의 복잡한 변환 과정 없이 바로 다운로드하여 사용할 수 있습니다… --- ## [vLLM팀, 실시간 음성 상호작용 등, 옴니모달(Omni-Modality) 모델 서빙을 위한 vLLM-Omni 공개](https://discuss.pytorch.kr/t/vllm-omni-modality-vllm-omni/8472)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [12월 22, 2025, 3:30오전 UTC](https://discuss.pytorch.kr/t/vllm-omni-modality-vllm-omni/8472 "2025-12-22T03:30:54Z")
vLLM-Omni 소개 vLLM 팀은 텍스트 중심의 AI 서빙을 넘어, 음성 및 영상과 같은 멀티모달 데이터를 실시간으로 처리할 수 있는 새로운 프레임워크인 vLLM-Omni를 공개했습니다. 최근 AI 분야의 트렌드는 단순한 텍스트 채팅을 넘어, 보고 듣고 말하는 '옴니-모달(Omni-Modality)' 에이전트로 진화하고 있습니다. 하지만 기존의 오픈소스 서빙 엔진들은 주로 텍스트 기반의 자기회귀(Autoregressive, AR) 작업에만 최적화되어 있어, 이러한 복합적인 데이터를 실시간으로 처리하는 데 한계가 있었습니다. vLLM-Omni는 이러한 격차를 해소하기 위해 설계되었습니다. 이 시스템은 텍스트뿐만 아니라 오디오와 이미지 입출력을 지원하며, 특히 실시간 음성 상호작용(Speech-to-Speech) 에 최적화된 엔드투엔드(End-to-End) 파이프라인을 제공합니다. 개발자들은 이를 통해 복잡한 별도의 음성 인식/합성 모델을 연결할 필요 없이, 단일 LLM 프로세스 내에서 사람과 대화하는 듯한 빠른 응답 속도의 AI 서비스를 구축할 수 있습니다. 즉, 기존의 vLLM이 텍스트 생성에 집중했다면, vLLM-Omni는 OmniStage라는 새로운 추상화 계층을 도입하여 비디오 생성이나 실시간 음성 대화와 같은 복잡한 멀티모달 워크플로우를 단일 파이프라인 안에서 매끄럽게 처리합니다. 기존에 멀티모달(특히 음성) 기능을 구현하기 위해서는 여러 개의 독립된 모델을 순차적으로 연결하는 캐스케이드(Cascade) 방식을 주로 사용했습니다. vLLM-Omni는 이 구조를 근본적으로 혁신했습니다. 이를 기존의 방식과 비교해보면 다음과 같습니다: 특징 기존 캐스케이드 방식 (Traditional Cascade) vLLM-Omni (End-to-End) 구조 ASR(음성인식) → LLM(텍스트 생성) → TTS(음성합성) 순차 실행 단일 모델이 입력 오디오를 이해하고 오디오 토큰을 직접 생성 지연 시간 (Latency) 각 단계의… --- ## [Mini-SGLang: SGLang의 핵심을 담은 경량화 고성능 LLM 추론 프레임워크](https://discuss.pytorch.kr/t/mini-sglang-sglang-llm/8443)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [12월 18, 2025, 9:30오전 UTC](https://discuss.pytorch.kr/t/mini-sglang-sglang-llm/8443 "2025-12-18T09:30:29Z")
Mini-SGLang 소개 Mini-SGLang은 최신 대규모 언어 모델(LLM) 서빙 시스템의 복잡성을 해소하고 그 원리를 명확히 보여주기 위해 설계된 SGLang의 경량화 버전입니다. 약 5,000줄의 간결한 Python 코드베이스로 구성되어 있어 연구자와 개발자가 LLM 추론 엔진의 내부 동작을 쉽게 이해하고 수정할 수 있는 투명한 레퍼런스를 제공합니다. LLM 서빙 기술은 KV 캐시 관리, 스케줄링, 병렬 처리 등 복잡한 엔지니어링의 집약체입니다. Mini-SGLang은 이러한 복잡함을 걷어내면서도 SGLang이 자랑하는 고성능 추론 능력의 핵심을 유지합니다. 단순히 교육용에 그치지 않고, 최신 최적화 기술들이 적용된 실제로 작동하는 고성능 추론 엔진으로서의 역할도 충분히 수행합니다. 이 프로젝트는 고성능 추론 프레임워크인 SGLang의 "핵심 기술"을 누구나 쉽게 접근하고 분석할 수 있도록 하는 데 목적이 있습니다. 복잡한 프로덕션 레벨의 코드를 파헤치지 않고도, Radix Attention이나 Chunked Prefill과 같은 고급 서빙 기술이 실제로 어떻게 구현되는지 학습할 수 있는 최적의 도구입니다. SGLang과의 비교 SGLang과 Mini-SGLang은 동일한 핵심 철학을 공유하지만, 그 지향점에서 차이가 있습니다. 먼저 SGLang은 대규모 프로덕션 환경을 위해 설계되었습니다. 수백 개의 GPU를 아우르는 분산 처리, 다양한 모델 아키텍처 지원, 복잡한 기능(비전 모델 등)을 모두 포함하며, 전 세계적으로 400,000개 이상의 GPU에서 사용되는 업계 표준급 엔진입니다. 이에 비해 Mini-SGLang은 코드의 가독성과 교육적 가치에 중점을 둡니다. 복잡한 의존성을 제거하고 핵심 로직(약 5,000라인)에 집중하여, 개발자가 하루 만에 전체 구조를 파악할 수 있도록 설계되었습니다. 하지만 성능을 희생하지 않았으며, 단일 노드나 소규모 클러스터 환경에서는 SGLang에 버금가는 처리량을 제공합니다. Mini-SGLang의 … --- ## [TileRT: LLM의 연산을 Tile 단위 작업으로 분해하여 실행하는 초저지연(Ultra-Low Latency) 런타임](https://discuss.pytorch.kr/t/tilert-llm-tile-ultra-low-latency/8295)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [11월 26, 2025, 3:30오전 UTC](https://discuss.pytorch.kr/t/tilert-llm-tile-ultra-low-latency/8295 "2025-11-26T03:30:31Z")
TileRT 소개 TileRT는 대규모 언어 모델(LLM)의 추론 속도를 극대화하기 위해 설계된 실험적인 런타임 프로젝트입니다. 현재 대부분의 LLM 추론 시스템은 처리량(Throughput)을 높이는 데 집중하고 있습니다. 즉, 많은 사용자의 요청을 동시에 처리하기 위해 '배치(Batch)' 처리를 최적화하는 방식입니다. 하지만 이러한 방식은 고빈도 매매(HFT), 실시간 의사결정, 인터랙티브 AI, 장기 실행 에이전트(Long-running Agents)와 같이 단일 요청에 대한 \*\*즉각적인 응답 속도(Latency)\*\*가 중요한 시나리오에서는 최적의 성능을 내지 못하는 경우가 많습니다. TileRT는 이러한 기존 시스템의 한계를 극복하고, 초저지연(Ultra-Low-Latency) 환경을 구축하는 것을 목표로 합니다. 수천억 개의 파라미터를 가진 거대 모델이라 할지라도 밀리초(ms) 단위의 토큰 생성 속도(TPOT)를 달성하여, 사용자가 지연을 거의 느끼지 못하는 수준의 반응성을 제공하고자 합니다. 이 프로젝트는 컴파일러 기반의 접근 방식을 사용하여 LLM 연산자를 세밀한 '타일(Tile)' 단위의 작업으로 분해합니다. 이를 통해 컴퓨팅, I/O, 통신 작업을 고도로 중첩(Overlap)시켜 하드웨어의 유휴 시간(Idle time)을 최소화하고 GPU와 같은 가속기의 성능을 극한까지 끌어올립니다. 현재 tile-ai 조직에서 개발 중이며, 향후 TileLang 및 TileScale과 같은 관련 기술들과 통합될 예정입니다. vLLM 및 SGLang과의 비교 TileRT는 기존의 대표적인 LLM 서빙 프레임워크들과 설계 철학에서 큰 차이를 보입니다. 예를 들어, vLLM이나 SGLang과 같은 시스템은 주로 높은 처리량(High Throughput) 을 달성하는 것을 목표로 설계되었습니다. Continuous Batching이나 PagedAttention과 같은 기술을 사용하여 메모리 효율성을 높이고, 한 번에 많은 요청을 처리하여 GPU 활용… --- ## [FlashTensors: 단일 GPU 환경에서 다수의 모델을 빠르게 바꿔가며 운용할 수 있도록 하는 추론 엔진](https://discuss.pytorch.kr/t/flashtensors-gpu/8169)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [11월 10, 2025, 9:30오후 UTC](https://discuss.pytorch.kr/t/flashtensors-gpu/8169 "2025-11-10T21:30:20Z")
FlashTensors 소개 FlashTensors는 대규모 AI 모델을 초고속으로 로드하고, 단일 GPU 환경에서도 수십~수백 개 모델을 유연하게 핫스왑하며 운용할 수 있도록 설계된 고성능 추론 엔진입니다. 특히 모델을 SSD에서 GPU 메모리로 로딩하는 데 있어서 기존 로더보다 최대 10배 빠른 속도를 자랑하며, TTFT(Time to First Token)도 2초 미만으로 단축시킵니다. 현대 AI 환경에서는 수많은 모델을 빠르게 교체하며 서비스해야 하는 경우가 많습니다. 그러나 기존의 safetensors나 torch.load() 기반 모델 로더는 이 과정에서 병목을 유발하며, 사용자 경험에 영향을 줄 수 있습니다. FlashTensors는 이러한 문제점을 해결하기 위해 모델을 불러오는 속도를 빠르게 하는 설계를 채택하였으며, 로컬에서 여러 모델을 동시에 다뤄야 하는 에이전트 기반 워크플로우나 로봇 등의 경량 환경에도 적합합니다. 이러한 기술은 특히 개인화 AI, 서버리스 추론, 로컬 배포, 로보틱스 등 다양한 도메인에서 활용될 수 있습니다. 단일 GPU에서 수십 개 모델을 동시에 핸들링하며 핫스왑이 가능하다는 점은 기존 인프라 비용을 줄이고, 개발 유연성을 극대화하는 데 핵심적인 역할을 합니다. 특히, FlashTensors는 safetensors 대비 모델 로딩 속도에서 약 4~6배 정도 빠르며, 특히 대규모 모델에서 그 효과가 극대화됩니다. 예를 들어, Qwen 3-32B 모델은 safetensors로 로딩 시 약 24초가 걸리지만, FlashTensors를 사용하면 4초 수준으로 단축됩니다. 또한 coldstart 시간도 일관되게 5초 미만으로 유지됩니다. 모델 FlashTensors (초) safetensors (초) 속도 배율 Qwen3-0.6B 2.74 11.68 ~4.3배 Qwen3-4B 2.26 8.54 ~3.8배 Qwen3-8B 2.57 9.08 ~3.5배 Qwen3-14B 3.02 12.91 ~… --- ## [HAIF(Hyperswarm-RPC AI Inference Framework): MSA 구조로 AI 추론 작업을 분산처리하도록 설계된 프레임워크](https://discuss.pytorch.kr/t/haif-hyperswarm-rpc-ai-inference-framework-msa-ai/7953)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [10월 14, 2025, 3:30오전 UTC](https://discuss.pytorch.kr/t/haif-hyperswarm-rpc-ai-inference-framework-msa-ai/7953 "2025-10-14T03:30:57Z")
HAIF 소개 HAIF(Hyperswarm-RPC AI Inference Framework)는 AI 추론(AI Inference) 작업을 마이크로서비스 형태로 분산 처리할 수 있도록 설계된 프로덕션 수준의 프레임워크입니다. 이 프로젝트는 단순한 모델 서버가 아니라, 게이트웨이(Gateway), 오케스트레이터(Orchestrator), 레지스트리(Registry), 워커(Worker), 그리고 관측성(Observability) 구성 요소를 완비한 엔드투엔드(end-to-end) AI 추론 플랫폼을 제공합니다. HAIF의 핵심 아이디어는 AI 모델 실행을 단일 서버에 한정하지 않고, 여러 개의 서비스로 분리해 효율적인 스케줄링, 부하 분산, 그리고 안정적인 모니터링을 가능하게 하는 것입니다. 이 프레임워크는 Hyperswarm RPC 프로토콜을 기반으로 서비스 간 통신을 수행하며, 모든 구성 요소는 Docker Compose 환경에서 손쉽게 실행할 수 있습니다. HAIF를 통해 AI 모델을 대규모 서비스로 배포하려는 개발자들이 겪는 모델 간 동적 로드 밸런싱, 추론 성능 모니터링, 장애 복구 자동화 등의 어려움을 체계적으로 해결해준다는 점입니다. 단순한 “모델 서버”를 넘어, 실제 운영 환경에서 재현 가능한 아키텍처를 제공하기 때문에 연구뿐 아니라 상용 서비스에도 활용할 수 있습니다. 또한 HAIF는 Prometheus, Grafana, Loki, Jaeger 등 관측성(Observability) 도구를 완벽하게 통합하여, 서비스 메트릭, 로그, 트레이스 등을 한눈에 확인할 수 있는 환경을 제공합니다. 즉, 모델 추론 시스템의 성능 및 신뢰성을 정량적으로 모니터링할 수 있는 “AI 인프라 운영 플랫폼”이라 할 수 있습니다. 기존의 대표적인 AI 서빙 프레임워크로는 TensorFlow Serving , TorchServe , 그리고 OpenAI Triton Inference Server 등이 있습니다. 이들 대부분은 단일 서비스 기반의 REST/g… --- ## [Tokasaurus: 고처리량 LLM 배치 추론을 위한 최적화 엔진 (feat. Stanford Scaling Intelligence Lab)](https://discuss.pytorch.kr/t/tokasaurus-llm-feat-stanford-scaling-intelligence-lab/7078)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [6월 9, 2025, 9:30오전 UTC](https://discuss.pytorch.kr/t/tokasaurus-llm-feat-stanford-scaling-intelligence-lab/7078 "2025-06-09T09:30:31Z")
Tokasaurus 소개 Stanford Scaling Intelligence Lab에서 공개한 Tokasaurus는 최근 다양한 AI 모델 추론 엔진 중에서도 특히 고처리량(throughput)에 초점을 맞춘 혁신적인 프로젝트입니다. 일반적인 챗봇 서비스보다는 수천 개의 요청을 동시에 처리해야 하는 배치 중심 워크로드(batch inference)에 특화되어 있으며, 기존의 대표적인 추론 엔진인 vLLM이나 SGLang보다 2~3배 향상된 처리 성능을 기록한 바 있습니다. 특히, 샘플링 중심 파이프라인을 구축 중이거나, 합성 데이터 생성, LLM 평가 자동화 등에서 성능 병목을 해결하는데 유용합니다. Tokasaurus는 오픈소스로 공개된 PyTorch 기반의 LLM 추론 엔진으로, 핵심 목적은 높은 처리량을 요구하는 대규모 배치 작업을 효율적으로 수행하는 것입니다. 이 엔진은 OpenAI API와 완전히 호환되는 REST 인터페이스를 제공하며, LLaMA-3 및 Qwen-2 계열 모델 등 다양한 사전 학습 모델을 손쉽게 실행할 수 있도록 구성되어 있습니다. 특히 기존 vLLM이나 SGLang과 같은 인기 추론 프레임워크들과 비교했을 때, Tokasaurus는 실행 효율성, 자원 활용도, 처리량 최적화 측면에서 뚜렷한 차별성을 보입니다. 이 프로젝트가 특히 주목받는 이유는 실행 중 자동으로 입력 시퀀스 간 prefix를 공유하여 attention 계산을 최적화하는 ‘Hydragen’ 기술과, torch.compile 및 CUDA Graphs를 활용한 엔드 투 엔드(End-to-End) 컴파일 기반 추론 최적화 덕분입니다. 여기에 더해, GPU 하드웨어 구성에 따라 적절한 병렬 전략을 선택 적용할 수 있도록 설계되었기 때문에, 다양한 하드웨어 환경에서도 최적의 성능을 달성할 수 있는 유연성을 제공합니다. Tokasaurus 구조 및 내부 디자인 Tokasaurus는 크게 세 가지 핵심 컴포넌트로 구성됩니다. 먼저, OpenAI API 규격…