vLLM, TensorRT-LLM, 또는 Hugging Face TGI와 같은 고성능 LLM 배포 프레임워크가 실제로 모델 서빙 (Model Serving)을 어떻게 최적화하는지 궁금해한 적이 있나요? 채팅창에 토큰이 스트리밍되는 것을 기다리는 동안, 내부 인프라는 프롬프트 사전 계산 (Prompt Pre-computation) 스케줄링, 페이지 메모리 세그먼트 (Paging Memory Segments) 관리, 추측적 토큰 체인 (Speculative Token Chains) 검증, 그리고 시스템 중단을 초래하는 병목 현상 (Bottleneck) 충돌 방지라는 정교한 균형 잡기 작업을 수행하고 있습니다.

LLM이 높은 동시 접속 부하 (High Concurrent Loads) 하에서 어떻게 배포되고, 최적화되며, 서빙되는지 가르쳐 주기 위해, 저는 인터랙티브한 팩토리 시뮬레이션 게임을 만들었습니다:

🏭 추론 파이프라인 타이쿤 (Inference Pipeline Tycoon)

전체 화면 모드로 플레이 (임베드 크기가 좁을 경우)

🛠️ 터미널 레벨 선택

인프라 아키텍트로서의 여정은 각각 고급 최적화 기술을 도입하는 세 가지의 뚜렷한 서빙 터미널로 나뉩니다:

• ⚡ 레벨 1: 프리필(Prefill) & 디코드(Decode) 기초 (쉬움): 입력 큐 (Input Queue)에서 프롬프트를 프리필 코어 (Prefill Core)로 라우팅하여 키-값 활성화 (Key-Value Activations)를 계산한 다음, 이를 디코드 코어 (Decode Core)에 연결하여 자기회귀적 (Autoregressive) 토큰 스트림을 생성합니다. 목표: 30.0 TPS.
• 🔋 레벨 2: KV-캐시 페이지 메모리 (중간): 제한된 VRAM 제약 조건 하에서 큰 컨텍스트 윈도우 (Context Windows)를 처리합니다. 메모리 할당을 압축하고 CUDA Out-of-Memory (OOM) 충돌을 방지하기 위해 가상 페이징 할당기 (Virtual Paging Allocators)를 연결해야 합니다. 목표: 제한된 3072 MB VRAM 카드에서 60.0 TPS.
• 🚀 레벨 3: 추측적 가속 (Speculative Speedup) (어려움): 자기회귀적 디코딩 (Autoregressive Decode)은 클라이언트 할당량을 맞추기에 너무 느립니다. 경량 초안 모델 (Draft Models)과 검증 게이트 (Validation Gates)를 배포하여 단계당 3개의 토큰을 병렬로 생성하고 검증해야 합니다. 목표: 120.0 TPS.

🧬 플레이 가능한 ML 개념 설명

이것은 단순한 퍼즐 게임이 아닙니다. 모든 구성 요소, 라우팅 방향, 메모리 규칙은 현대 머신러닝 (Machine Learning) 인프라의 실제 개념을 나타냅니다. 게임 내 메커니즘이 실제 운영 환경에서 대규모 언어 모델 (LLM)이 최적화되고 서빙되는 방식과 어떻게 직접적으로 매핑되는지는 다음과 같습니다:

1. 🎯 Prefill vs. Decode (순차적 파이프라인)

• 게임 내: 녹색 프롬프트 패킷(prompt packets)을 자홍색 활성화 벡터(activation vectors)로 처리하기 위해 **Prefill Core (PREF)**를 배치해야 하며, 그 후 자기회귀적 시퀀스 토큰 생성(autoregressive sequence token generation)을 시작하기 위해 이를 **Decode Core (DECO)**로 라우팅해야 합니다.
• 실제 대응 관계: LLM 서빙은 추론(inference)을 두 단계로 나눕니다:
  • Prefill (프리필): 사용자의 프롬프트 토큰을 병렬로 처리하여 초기 Key-Value (KV) 어텐션 행렬(attention matrices)을 생성합니다.
  • Decode (디코딩): 한 번에 하나의 토큰을 순차적으로 생성합니다. 새로 생성된 토큰을 가져와 히스토리에 추가하며, 토큰당 모델의 전체 순전파(forward pass)를 실행합니다.
• LLM에 미치는 영향: 디코딩은 메모리 대역폭(memory bandwidth)에 의해 제한되기 때문에(예측되는 매 토큰마다 수십억 개의 모델 가중치를 다시 불러와야 함), 프리필보다 훨씬 느립니다. 코어들을 멀리 배치하면 라우팅 지연(latency)이 추가됩니다. 코어들을 함께 모아두는 것은 처리량(throughput)을 극대화하기 위한 표준적인 하드웨어 공동 배치(co-location)를 의미합니다.

2. 🔋 KV-Cache Paging (vLLM Page Allocator)

• 게임 내: **Page Allocators (vLLM)**를 Prefill 및 Decode 코어 바로 옆에 배치하면 VRAM 캐시 점유율(cache footprint)을 자동으로 40% 압축할 수 있습니다.
• 실제 대응 관계: Key-Value 캐싱은 과거 토큰의 표현(representations)을 GPU VRAM에 저장하여 다시 계산할 필요가 없도록 합니다. 그러나 동적인 사용자 프롬프트 크기로 인해 심각한 메모리 파편화(memory fragmentation)가 발생하며, 이는 조기 할당 제한 및 CUDA Out of Memory 오류로 이어집니다.
• LLM에 미치는 영향: 최신 엔진들은 PagedAttention (vLLM에 의해 대중화됨)을 구현합니다. 가상 메모리 테이블을 할당하고 KV-캐시를 논리적 페이지(logical pages, 운영 체제의 페이징과 유사)로 분할함으로써, 엔진은 파편화와 캐시 낭비를 제거하여 GPU 서빙 용량을 최대 4배까지 증폭시킵니다.

3. 🚀 Speculative Decoding (Drafter & Validation Gates)

• In-Game: **Draft Model (DRAF)**을 Decode Core 옆에 배치하면 단계당 3개의 추측 토큰 (speculative tokens) 초안을 생성할 수 있습니다. 이 초안들은 출력 싱크(output sink)에 도달하기 전, 검증을 위해 **Validation Gate (VALI)**를 통과해야 합니다.
• 실제 사례 (The Real-World Counterpart): Speculative decoding (추측적 디코딩)은 거대하고 정확한 타겟 LLM과 매우 빠르게 작동하는 작고 가벼운 draft model (초안 모델)을 쌍으로 결합합니다. draft model은 $K$개의 토큰 시퀀스를 추측하여 생성합니다. 그러면 타겟 모델은 단 한 번의 forward pass (순전파)를 통해 $K$개의 토큰 모두를 병렬로 검증합니다.
• LLM에 미치는 영향: 타겟 모델이 하나의 토큰을 자기회귀적 (autoregressively)으로 생성하는 데 걸리는 시간과 동일한 시간 내에 여러 토큰을 검증할 수 있기 때문에, speculative decoding은 지연 시간 (latency)을 극적으로 줄여줍니다. 만약 초안이 일치하면 한 단계 만에 $K$개의 토큰을 얻게 되며, 일치하지 않으면 롤백(roll back) 후 다시 생성합니다.

🛠️ 내부 엔지니어링 여정 (The Under-the-Hood Engineering Journey)

Canvas 렌더링과 실시간 오디오 합성 기능을 갖춘 고처리량 (high-throughput) 시뮬레이션 게임을 구축하면서 몇 가지 흥미로운 웹 개발 과제들이 나타났습니다:

1. 고정 타임스텝 물리 (Fixed Timestep Physics: FPS와 TPS의 분리)

수백 개의 활성화된 토큰 입자들을 동시에 렌더링할 때, Canvas 드로잉 오버헤드로 인해 구형 기기에서는 브라우저의 렌더링 속도가 15–20 FPS까지 떨어질 수 있습니다. 초기 초안에서는 이로 인해 클록 (clock) 속도가 느려져, 최적화된 파이프라인을 사용하더라도 처리량 (throughput)이 66 TPS로 제한되었습니다.

• 해결책: 우리는 Fixed Timestep Accumulator (60 ticks/sec)를 구현했습니다. 브라우저의 렌더링 프레임 속도가 뒤처지더라도, accumulator가 프레임당 여러 번의 시뮬레이션 틱 (simulation ticks)을 실행함으로써 따라잡게 하여, 처리량 (TPS) 지표가 실제 현실 시간 (wall-clock time)과 완전히 일치하도록 유지합니다.

2. Conduit Queue 전파 문제 해결 (Resolving Conduit Queue Propagation)

Conduits는 초기에는 틱(tick)당 타일 하나에서 패킷 하나를 처리했습니다. Speculative validation이 한 번에 3개의 토큰 배치를 해제할 때, conduits는 큐 정체(queue pile-ups)를 일으켰고, 이는 처리량(throughput)을 엄격한 한계치로 제한했습니다. conduit 전파 방식을 while 루프로 변경함으로써 wire tiles가 물리적 도체처럼 동작하여, 동일한 프레임 내에 도착한 모든 토큰을 전달할 수 있게 되었습니다.

💬 함께 논의해 봅시다:

• Level 3에서 달성한 가장 높은 처리량(throughput) 레이아웃은 무엇이었나요?
• vLLM Page Allocators와 Speculative Drafters를 OOM(Out of Memory) 없이 Level 3의 그리드에 깔끔하게 배치하는 데 성공하셨나요?
• 어떤 아키텍처 조합이 가장 효과적이라고 느끼셨나요?

UnitBuilds-CC / LLMs-are-Demented

LLM에 대해 배울 수 있는 교육용 크로스워드 게임

📟 게이팅 위기: Sparse MoE Router 시뮬레이터 🧠⚡

UnitBuilds CC Playgrounds Suite의 일부

환영합니다, 신경 공학자(neural engineer)님. 당신은 현재 실행 중인 Mixture of Experts (MoE) 거대 언어 모델(Large Language Model)의 게이팅 네트워크 (Gating Network, Router) 책임을 맡게 되었습니다.

당신의 임무는 들어오는 멀티모달 토큰 스트림([T] 텍스트 (Text), [M] 수학 (Math), [V] 비전 (Vision), [A] 오디오 (Audio), [C] 코드 (Code))을 실시간으로 특화된 피드포워드 네트워크 (Feed-Forward Network, FFN) 전문가(experts)들에게 라우팅하는 것입니다. 이것은 Top-2 Routing 네트워크이므로, 토큰이 축출 임계값(eviction threshold)에 도달하기 전에 반드시 정확히 두 명의 전문가에게 전달해야 합니다.

토큰을 잘못 라우팅하면 모델의 출력 품질이 퍼플렉시티 붕괴 (perplexity collapse) 상태로 저하됩니다. 만약 개별 전문가의 큐 제한을 초과하여 과부하를 주면, 시스템은 용량 저하 (Capacity Drops) (데이터 손실)를 겪게 됩니다.

🕹️ 게임 메커니즘 (플레이 방법)

• ⌨️ 단축키 라우팅: 숫자 1에서 8까지 (또는 단순화 모드에서는 1에서 4까지) 사용하여...

면책 조항 (Disclaimer): 이 프로젝트 전반에 걸쳐 AI가 사용되었으며, AI가 저와 공동 저자로 참여하는 것은 매우 자연스러운 일입니다. 따라서 지치지 않고 열심히 작업해 준 Foundry와 커버 이미지를 제작해 준 Gemini에게 특별한 감사를 전합니다.