Qwen3.8-27B VRAM 가이드: RTX 5090, GPU 두 장과 262K 설정

RTX 5090 한 장으로 Qwen3.8-27B를 시작한다면 4비트 가중치, 32K 컨텍스트, 동시 요청 1개를 먼저 검증하는 것이 현실적입니다. vLLM에는 단일 5090에서 Inferact NVFP4 모델과 FP8 KV 캐시를 사용하는 32,768토큰 실행 예가 있습니다. 다만 이 예는 특정 모델과 실행 버전의 구성입니다. 같은 옵션으로 262K까지 늘려도 된다는 뜻은 아닙니다. vLLM 실행 가이드

Qwen3.8-27B의 기본 최대 컨텍스트는 262,144토큰입니다. 흔히 쓰는 262K와 256K 표기는 여기서 같은 길이를 가리킵니다. 이 한도에는 입력과 생성할 답변이 함께 들어갑니다. 모델이 이 길이를 지원한다는 사실과 내 GPU가 이를 처리할 수 있다는 사실은 따로 확인해야 합니다. 공식 모델 카드

아래 수치는 2026년 9월 6일 확인한 추론용 자료입니다. 공개 파일 크기, 모델 설정에서 계산한 캐시 크기, 각 실행 가이드가 보고한 결과를 구분하며 학습 메모리에는 적용하지 않습니다. 설정 예는 이를 바탕으로 조정한 출발점이며, 특정 GPU에서 직접 측정한 성능표가 아닙니다.

파일이 들어갈 공간보다 실행 중 남는 공간이 중요합니다

데스크톱 RTX 5090은 32GB GDDR7을 탑재하며 NVLink를 지원하지 않습니다. 노트북용 모델과 혼동하지 말고, 실제 장비에서 총 VRAM과 사용 가능한 VRAM을 먼저 확인합니다. 디스플레이를 연결한 카드라면 다른 프로그램도 같은 메모리를 사용합니다. NVIDIA RTX 5090 사양

bash
nvidia-smi --query-gpu=index,name,memory.total,memory.used,memory.free --format=csv

nvidia-smi가 MiB로 표시하는 수치는 1,024로 나누면 GiB가 됩니다. 파일 배포 페이지의 GB는 보통 10억 바이트 기준이므로, 숫자만 직접 비교하면 오차가 생깁니다. 아래 표에서는 GB와 GiB를 함께 적었습니다.

BF16 값은 공식 인덱스의 텐서 바이트 합계이고, FP8은 공식 저장소의 safetensors 파일 합계입니다. GGUF는 Unsloth의 확인된 리비전 기준입니다. 이 값들은 실행 중 VRAM 측정치가 아닙니다. 다른 배포자의 같은 Q4 이름을 가진 파일에 그대로 적용해서도 안 됩니다.

실행 시 필요한 최대 메모리는 대략 다음 항목의 합으로 판단합니다.

text
GPU에 실제 적재한 가중치
+ 전체 어텐션의 KV 캐시
+ 선형 어텐션의 상태 저장 공간
+ 연산 중간 결과·실행 버퍼·CUDA 그래프
+ 사용 시 이미지 처리·MTP 추가 공간

Qwen3.8-27B는 두 종류의 어텐션을 섞어 사용합니다. 따라서 일반적인 64층 Transformer 계산식을 그대로 적용하면 캐시를 잘못 추정합니다. 반대로 선형 어텐션을 사용한다고 해서 상태 저장 공간이 사라지는 것도 아닙니다. SGLang은 GDN 상태 슬롯 하나를 FP32에서 153.9MB, BF16에서 78.4MB로 보고하며, 예약 슬롯 수와 실행 방식에 따라 총량이 달라집니다. SGLang 메모리 설명

262K에서 커지는 것은 가중치가 아니라 KV 캐시입니다

가중치 파일을 4비트로 줄여도 KV 캐시가 자동으로 4비트가 되지는 않습니다. 가중치 양자화와 캐시 정밀도는 별도의 설정입니다.

공식 설정 파일에 따르면 전체 64개 층 중 16개가 전체 어텐션을 사용합니다. 이 부분은 KV 헤드 4개, 헤드 차원 256입니다. 한 요청에서 토큰 하나를 저장하는 F16/BF16 KV 데이터는 다음과 같이 계산됩니다.

text
2(K와 V) × 16개 층 × 4개 KV 헤드 × 256 × 2바이트
= 토큰당 65,536바이트 = 64KiB

이 표는 요청 1개의 전체 어텐션 KV 데이터만 계산한 값입니다. K와 V를 모두 같은 형식으로 저장한다고 가정했습니다. FP8과 q8_0는 같은 형식이 아닙니다. llama.cpp의 q8_0는 값 32개마다 34바이트, q4_0는 18바이트를 사용하므로, 단순히 2분의 1이나 4분의 1로 나눈 값보다 큽니다. llama.cpp 블록 형식 정의

실제 할당에는 패딩, 상태 저장, 관리 공간이 추가됩니다. 여러 요청을 동시에 처리하면 저장해야 하는 토큰의 합도 커집니다. 캐시 공유가 실제로 일어나는지 확인하지 않은 상태에서, 동일한 문서를 넣었다는 이유만으로 메모리가 재사용된다고 가정하면 안 됩니다.

Q4 모델을 32GB에 넣었는데 왜 262K에서 실패할까요?

UD-Q4_K_M의 파일 크기 15.334GiB를 가중치 공간의 근삿값으로 놓으면 차이가 분명해집니다.

• F16 캐시: 15.334 + 16 = 31.334GiB
• q8_0 캐시: 15.334 + 8.5 = 23.834GiB
• q4_0 캐시: 15.334 + 4.5 = 19.834GiB

첫 번째 구성은 나머지 실행 공간을 더하기도 전에 32GB 카드의 여유를 거의 소진합니다. 두 번째와 세 번째는 검토할 여지가 있지만, 합계만 보고 실행 성공을 확정할 수는 없습니다. 캐시 양자화를 지원하는 엔진과 커널이 필요하고, 긴 문서에서 답변 품질도 확인해야 합니다.

답변에 8,192토큰을 남기려면 262,144토큰 한도에서 입력으로 쓸 수 있는 상한은 253,952토큰입니다. 여기에는 시스템 지시문, 대화 이력, 템플릿 등도 들어가므로, 문서 본문 자체는 더 짧아야 합니다. 글자 수나 파일 용량 대신 실제 적용한 채팅 템플릿과 토크나이저 기준으로 셉니다.

RTX 5090 한 장에서는 32K 기준선을 먼저 만듭니다

GGUF를 사용한다면 처음부터 이미지 입력이나 여러 동시 요청을 넣지 않고, 텍스트 요청 하나로 시작합니다. 아래는 llama.cpp 서버의 문서화된 옵션을 조합한 예입니다. /path/to/model.gguf는 준비한 Qwen3.8-27B UD-Q4_K_M 파일 경로로 바꿉니다.

bash
llama-server --help

CUDA_VISIBLE_DEVICES=0 llama-server \
  --model /path/to/model.gguf \
  --n-gpu-layers 99 \
  --ctx-size 32768 \
  --parallel 1 \
  --flash-attn on \
  --cache-type-k q8_0 \
  --cache-type-v q8_0

--n-gpu-layers 99는 가능한 모든 모델 층을 GPU에 올리려는 설정입니다. 실제 적재 결과는 시작 로그로 확인합니다. 설치된 버전이 모델 구조와 캐시 옵션을 지원하는지도 먼저 확인해야 합니다. 인식하지 못하는 옵션을 지우고 실행만 통과시키면 의도한 메모리 구성이 달라질 수 있습니다. llama-server 옵션 문서

이 설정에서 확인할 것은 세 가지입니다. 시작 로그에 표시된 GPU 적재 층 수와 캐시 형식, 요청 전후의 VRAM 변화, 짧은 입력과 충분히 긴 입력에서의 정상 출력입니다. 메모리가 남고 답변이 정상이라면 컨텍스트를 65,536, 131,072 순으로 늘립니다. 각 단계에서 입력 처리 중 최대 사용량과 첫 답변까지 걸린 시간도 기록해야 합니다.

vLLM의 NVFP4 경로를 택한다면 GGUF 옵션을 옮겨 쓰지 않습니다. 단일 RTX 5090 실행 예는 Inferact NVFP4 체크포인트에 다음 설정을 사용합니다.

가이드가 보고한 소비자 GPU 테스트 버전은 0.26.1rc1.dev608+g99a10304d입니다. 페이지에 표시된 일반적인 최소 버전만 맞추기보다, 선택한 체크포인트와 정확한 실행 예의 버전을 함께 확인합니다. --enforce-eager는 이 사례의 해결책이며 모든 엔진에 공통으로 필요한 옵션은 아닙니다.

GPU 두 장은 합계와 카드별 적재량을 함께 봅니다

두 장의 메모리가 자동으로 하나의 큰 VRAM이 되지는 않습니다. 같은 컴퓨터에 장착한 뒤에도 실행 엔진에서 모델을 분배해야 합니다. RTX 5090에는 NVLink가 없으므로, 텐서 병렬화의 성능은 PCIe 연결과 시스템 구성의 영향을 받습니다. 카드 수가 두 배가 되었다고 속도도 두 배라고 계산하지 않습니다.

먼저 합계 계산으로 불가능한 조합을 걸러낼 수 있습니다.

이 계산은 모델 전체를 GPU에 적재하고, 요청 하나에 전체 길이의 캐시가 필요하다고 가정합니다. CPU 오프로딩을 쓰거나 캐시를 양자화하면 다른 계산이 됩니다.

llama.cpp에서 동일한 카드 두 장을 이용하는 시작 예는 다음과 같습니다. 우선 32K로 분배를 확인한 뒤 길이를 늘립니다.

bash
CUDA_VISIBLE_DEVICES=0,1 llama-server \
  --model /path/to/model.gguf \
  --n-gpu-layers 99 \
  --split-mode layer \
  --tensor-split 1,1 \
  --ctx-size 32768 \
  --parallel 1 \
  --flash-attn on \
  --cache-type-k q8_0 \
  --cache-type-v q8_0

layer 모드는 층과 KV 캐시를 분배합니다. 반면 row 모드는 중간 결과와 KV 캐시가 주 GPU에 배치되므로, 같은 메모리 배분으로 생각하면 안 됩니다. --tensor-split은 분배 비율이며, 실제 카드별 사용량을 같게 보장하는 값은 아닙니다. 용량이 다른 카드나 디스플레이를 연결한 카드가 섞였다면 각 카드의 가용 VRAM과 로그를 보며 비율을 조정합니다. llama-server 다중 GPU 옵션

vLLM은 두 RTX 5090의 TP2 구성도 보고합니다. 공식 FP8, Inferact NVFP4, Unsloth NVFP4의 GPU당 가중치 사용량은 각각 14.28GiB, 12.02GiB, 10.64GiB였고, 시작 시 표시된 KV 캐시 토큰 용량은 각각 377,456, 445,875, 920,517이었습니다. 이는 해당 환경의 시작 로그 수치입니다. 920,517토큰짜리 단일 입력을 검증했다거나, 모델의 기본 한도를 늘렸다는 의미가 아닙니다. vLLM 두 장 구성 결과

단일 5090의 262K 사례는 재현 조건까지 읽어야 합니다

MiaAI-Lab은 단일 RTX 5090에서 262,144토큰을 설정한 별도 구성을 공개했습니다. 이 사례는 RadixArk NVFP4, vllm==0.27.1에 #40914 수정 사항을 추가한 빌드, turboquant_4bit_nc 캐시를 사용합니다. KV 캐시 풀은 5.5GiB이고, 동시 요청 1개, 배치 토큰 512, MTP3 설정이 포함됩니다. MiaAI-Lab 원본 구성

따라서 “4비트 모델이면 5090에서 262K가 된다”로 줄여서 읽으면 재현에 필요한 조건이 사라집니다. 이 저장소는 기본 실행 경로에서 출력이 깨질 수 있고, MTP와 동시 요청을 조합하면 충돌할 수 있다고 설명합니다. 실험하려면 패치, 모델, 캐시 형식을 하나의 구성으로 확인해야 합니다. 공개된 생성 속도 숫자도 262K 입력 처리 전체의 지연을 보장하지 않습니다.

SGLang의 소비자 GPU 구성은 또 다른 범위입니다. 문서의 검증 조건은 입력 8,192토큰, 출력 1,024토큰, 동시 요청 1개입니다. 여기에 최대 컨텍스트 설정이 함께 나와 있더라도 모든 GPU·양자화 조합을 262K 입력으로 시험했다는 뜻은 아닙니다. SGLang 검증 조건

장비를 선택하는 단계라면 이러한 특수 구성을 기본 성공 조건으로 잡지 않는 편이 낫습니다. 먼저 필요한 문서 길이에서 안정적으로 실행되는 일반 구성을 확보하고, 메모리를 더 줄여야 할 때 특수 캐시와 MTP를 하나씩 검증합니다.

메모리 부족은 발생 시점에 따라 조정합니다

CPU 오프로딩은 GPU에 들어가지 않는 부분을 시스템 RAM으로 옮기는 선택지입니다. 실행을 가능하게 할 수 있지만 RAM 용량과 데이터 이동 비용도 함께 고려해야 합니다. 서버가 켜졌다는 사실만으로 모든 층이 GPU에서 실행된다고 판단하지 말고 로그를 확인합니다.

한국어로 공개된 24GB Mac의 Qwen3.8-27B 실행 기록은 ollama ps의 100% CPU 표시와 로드 로그를 보여 줍니다. 이는 그 Mac과 소프트웨어 구성의 관찰입니다. 통합 메모리와 NVIDIA 전용 VRAM은 같은 조건이 아니므로, 이를 근거로 모든 24GB GPU에서 실행할 수 없다고 결론 내릴 수는 없습니다.

이미지를 입력한다면 텍스트 기준 계산을 다시 잡아야 합니다. Unsloth GGUF의 별도 mmproj-F16.gguf 파일만 약 0.864GiB이고, 이미지 처리 중간 버퍼는 여기에 추가됩니다. 모델과 맞는 프로젝터를 사용하고 실제 이미지 해상도·개수로 확인합니다. MTP도 추가 상태와 연산 공간을 쓸 수 있으므로 텍스트 단일 요청의 여유를 그대로 적용하지 않습니다. Unsloth 프로젝터 파일

내 문서로 262K를 검증하는 순서

최대 길이 설정, 시작 로그의 캐시 용량, 긴 입력 수락, 쓸 만한 답변은 서로 다른 확인 항목입니다. 다음 순서로 검증하면 어디까지 성공했는지 분명해집니다.

1. 비교 가능한 구성을 남깁니다. GPU 모델과 장수, 시작 전 가용 VRAM, 엔진 버전, 모델 파일과 리비전, 실행 옵션을 기록합니다. 가중치 형식과 KV 캐시 형식을 따로 적습니다.
2. 입력과 답변 공간을 나눕니다. 실제 채팅 템플릿이 적용된 토큰 수를 계산합니다. 출력 예산을 남기고, 서버가 입력을 조용히 잘라내지 않았는지 응답과 로그에서 확인합니다.
3. 문서의 앞·중간·뒤에 확인 가능한 정보를 넣습니다. 예를 들어 서로 다른 프로젝트 코드와 납기일을 배치하고, 위치별 값을 찾는 질문과 두 위치의 정보를 함께 써야 하는 질문을 준비합니다. 원문에서 답을 확인할 수 있어야 합니다.
4. 입력 처리와 생성을 모두 완료합니다. 긴 요청을 보낸 동안 각 GPU의 최대 메모리를 관찰하고, 첫 토큰까지의 시간과 이후 생성 시간을 구분합니다. 서버가 시작되거나 요청을 접수한 것만으로 통과시키지 않습니다.
5. 정확성과 안정성을 비교합니다. 같은 문서와 질문을 유지한 채 캐시 정밀도만 바꾸거나 MTP만 켭니다. 오류, 누락, 반복이 늘면 절약한 메모리보다 작업 손실이 큰지 판단합니다.
6. 실제로 쓸 부하를 추가합니다. 단일 텍스트 요청을 통과한 뒤 이미지나 동시 요청을 추가합니다. 요청 수가 늘어난 조건은 별도로 기록하고 다시 확인합니다.

내 문서가 40K토큰이라면 262K 캐시부터 확보할 이유는 없습니다. 필요한 길이와 답변 여유에 맞춰 시작하고, 한 장의 가용 VRAM으로 부족할 때 캐시 정밀도, 가중치 형식, GPU 분배를 차례로 조정하면 됩니다. Qwen3.8-27B 자체가 작업에 맞는지부터 결정해야 한다면 Flash-Next와 27B의 로컬 실행 비교를 먼저 확인할 수 있습니다.