CELL AI DEVLOG

B300 GPU에서 SGLang으로 Qwen3.5를 서빙하면서 어텐션 백엔드 설정을 이것저것 해봤습니다.환경GPU: NVIDIA B300 (SM103, Blackwell 계열)모델: Qwen3.5-4B (head_dim=256)프레임워크: SGLang (CUDA 12.9+)1차 시도 — FA4 + trtllm_mha--prefill-attention-backend fa4 \--attention-backend trtllm_mha에러:AssertionError: (head_dim, head_dim_v)=(256, 256) is not supported on SM100/SM110.head_dim must be between 8 and 128FA4는 head_dim 128까지만 지원해요. Qwen3.5는 256..

SGLang으로 서버 띄울 때 이 파라미터를 보게 돼요.python -m sglang.launch_server \ --model-path Qwen/Qwen3.5-9B-Instruct \ --attention-backend ??? # 뭘 써야 하지?옵션이 여러 개예요.tritonflashinferfa3 (flashattention3)trtllm_mhatrtllm_mlafa4 (최신)각각이 뭔지, 언제 써야 하는지 정리할게요.백엔드가 뭔가Attention 계산을 어떤 커널(저수준 GPU 코드)로 처리할지 결정하는 거예요.SGLang 서버 ↓Attention Backend 선택 ↓┌──────────────────────────────────────┐│ Triton │ FlashInfer..

LLM이 긴 문서를 처리할 때 왜 느려질까요?GPT-3 컨텍스트: 2,048 토큰GPT-4 컨텍스트: 128,000 토큰Llama 3: 1,000,000 토큰2년 만에 500배 늘어났어요.이게 가능해진 핵심 기술이 FlashAttention이에요.Attention이 뭔가LLM은 텍스트를 읽을 때 모든 토큰이 다른 모든 토큰과 얼마나 관련있는지 계산해요.입력: "나는 사과를 먹었다"각 토큰이 다른 토큰과의 관계 점수 계산:"나는" ↔ "사과를": 0.3"나는" ↔ "먹었다": 0.8"사과를" ↔ "먹었다": 0.7...수식으로는 이래요.Attention(Q, K, V) = softmax(QK^T / √d_k) × VQ(Query): "지금 처리 중인 토큰"K(Key): "비교할 모든 토큰"V(Val..

LLM 서빙 서버를 직접 구축하면 처음에 이런 상황이 생겨요.# 단순하게 구현한 LLM 서버@app.post("/generate")async def generate(request): output = model.generate(request.prompt) return output요청 하나하나를 순서대로 처리해요. GPU 사용률 확인해보면 이래요.nvidia-smi:GPU 사용률: 15~30%GPU 자원의 70~85%를 낭비하고 있어요. Continuous Batching이 이걸 해결해요.LLM 추론의 두 단계이해하려면 LLM이 어떻게 토큰을 생성하는지 알아야 해요.Prefill 단계 (입력 처리):"안녕하세요, 오늘 날씨는" → 한번에 병렬 처리→ 계산 집약적 (compute-bound)→ 첫 ..

LLM이 토큰을 생성할 때마다 이전 토큰들의 중간 연산 결과를 저장해 두는 게 KV 캐시예요. 없으면 매 토큰마다 처음부터 다시 계산해야 해요.근데 이 KV 캐시를 어떻게 관리하느냐에 따라 성능이 완전히 달라져요. vLLM과 SGLang은 서로 다른 방식으로 이 문제를 풀어요.KV 캐시가 뭔가트랜스포머의 어텐션 레이어는 매 스텝마다 이전 토큰들의 Key/Value 벡터를 참조해요.1번째 토큰 생성: [토큰1] KV 계산2번째 토큰 생성: [토큰1, 토큰2] — 토큰1 KV 재계산하면 낭비!KV 캐시:1번째 토큰 생성: [토큰1] KV 계산 → 저장2번째 토큰 생성: 저장된 토큰1 KV 재사용 + 토큰2 KV만 계산→ 계산량 대폭 감소문제는 KV 캐시가 메모리를 많이 먹는다는 거예요.Llama-3.1-8B..

70B 파라미터 모델을 FP16으로 그냥 올리면 GPU 메모리가 140GB 필요해요. H100 두 개가 있어야 겨우 올라가요.양자화(Quantization)는 이 문제를 해결해요.FP16 (기본): 70B 모델 = 140GB VRAM → H100 2개 필요INT8: 70B 모델 = 70GB VRAM → H100 1개로 가능INT4 (4비트): 70B 모델 = 35GB VRAM → A100 1개로 가능근데 양자화 방식이 너무 많아요. FP8, AWQ, GPTQ, GGUF, BitsAndBytes, MXFP4... 뭐가 뭔지 헷갈려요.이번 글에서 각 방식이 어떻게 다르고 언제 써야 하는지 완전 정리해 드릴게요.양자화란 무엇인가LLM의 가중치는 수천억 개의 숫자예요. 기본적..

LLM 추론에는 두 단계가 있어요.Prefill (프리필):- 입력 프롬프트 전체를 처리- 연산 집약적 (Compute-bound)- KV 캐시 생성- 보통 수백~수천 토큰을 한 번에 처리Decode (디코드):- 토큰을 하나씩 생성- 메모리 집약적 (Memory-bound)- KV 캐시를 매 스텝마다 읽음- 요청당 수십~수백 번 반복전통적인 통합 엔진에서는 이 두 단계가 같은 GPU에서 경쟁해요. 그래서 두 가지 심각한 문제가 생겨요.문제 1: Prefill 방해(Prefill Interruption)기존 통합 엔진:[디코딩 중...토큰 생성 중...] ↑ 새 요청 들어옴! ↓[프리필 처리... (디코딩 멈춤)][디코딩 재개...][프리필 처리... (또 멈춤)]..

python -m sglang.launch_server --help이 명령어 치면 100개 넘는 파라미터가 쏟아져요. 뭐가 뭔지 몰라서 그냥 기본값으로 쓰는 경우가 많은데, 파라미터를 제대로 알면 성능이 2~3배 차이 나요.전체 파라미터를 카테고리별로 완전 정리해 드릴게요.1. 모델 및 토크나이저--model-path (필수)모델 가중치 경로예요. 로컬 폴더 또는 HuggingFace repo ID를 받아요.# HuggingFace에서 다운로드python -m sglang.launch_server \ --model-path meta-llama/Llama-3.1-8B-Instruct# 로컬 폴더python -m sglang.launch_server \ --model-path /data/models/ll..

2026년 현재 오픈소스 LLM 추론 엔진 중 실질적인 업계 표준은 SGLang이에요.xAI(Grok), NVIDIA, AMD, LinkedIn, Cursor, Oracle Cloud, Google Cloud, AWS가 프로덕션에 사용 중이고, 전 세계 40만 개 이상의 GPU에서 매일 수조 개의 토큰을 처리하고 있어요.근데 왜 vLLM을 놔두고 SGLang인가? 핵심은 하나예요."vLLM은 요청을 독립된 단위로 처리한다. SGLang은 요청을 프로그램으로 처리한다."이 철학 하나가 성능을 완전히 갈라요.SGLang이 빠른 이유 — 핵심 원리 3가지1. RadixAttention — KV 캐시 자동 재사용기존 추론 엔진의 문제를 먼저 이해해야 해요.일반 추론 엔진 (vLLM 포함):요청 A: [시스템 프..

오픈소스 LLM을 직접 서빙하려고 하면 이 두 개를 반드시 마주치게 됩니다."sglang이랑 vLLM 중에 뭐 써야 하지?"둘 다 LLM을 HTTP API로 서빙하는 프레임워크인데, 설계 철학과 강점이 달라요. 이번 글에서는 실전 관점에서 두 프레임워크를 비교해 드릴게요.먼저 둘 다 뭔지부터vLLM은 2023년 UC Berkeley에서 발표한 LLM 서빙 프레임워크예요. PagedAttention이라는 메모리 관리 기법을 처음 도입해서 GPU 메모리 효율을 획기적으로 높인 프레임워크입니다. OpenAI API와 호환되는 엔드포인트를 제공해서 기존 코드를 거의 수정 없이 연결할 수 있어요.sglang은 2024년 Stanford에서 발표한 프레임워크예요. RadixAttention이라는 KV 캐시 공유 기..