Qwen3.8 27B 모델을 16GB VRAM에서 구동한 경험 및 가이드
요약
본 글은 Qwen3.8 27B 모델을 16GB VRAM 환경에서 구동하는 실질적인 가이드와 경험을 공유합니다. MTP나 일반 양자화 대신 ISTA-DASLab의 GSQ-RCO 양자화를 사용하고, 특정 llama fork를 활용하여 대용량 컨텍스트(최대 131k)에서도 안정적으로 추론이 가능함을 보여줍니다.
핵심 포인트
- Qwen3.8 27B 모델을 16GB VRAM에서 구동하는 것이 가능합니다.
- ISTA-DASLab의 GSQ-RCO 양자화가 가장 좋은 성능과 효율성을 제공합니다.
- 특정 llama fork를 사용하면 대용량 컨텍스트(예: 131k)에서도 추론이 가능합니다.
- 싱글 채널 RAM보다는 듀얼 채널 구성이 더 나은 성능을 기대할 수 있습니다.
휴가라 시간이 많지 않지만, qwen3.8 27b 모델이 16Gb VRAM으로 실제로 작동할 수 있는지 궁금해하고 어려움을 겪는 사람들을 많이 봤습니다. 간단히 말해서: 네, 할 수 있습니다. 더 길게 설명하자면: 전체 모델을 사용하는 것은 아니며, MTP를 사용하거나 더 큰 컨텍스트에서는 자신만의 llama fork를 구축해야 합니다. Qwen3.8 27b GSQ-RCO-IQ3_S는 안정적인 결과를 제공하며, 16GB에 적합하고 최대 262k 컨텍스트를 달성하는 데 필요한 kv-streaming-magic을 위한 충분한 VRAM이 남습니다. 기적 같은 결과는 기대하지 마세요. 저에게는 빈 컨텍스트에서 30tps로 시작하여, 단일 DDR5 스틱과 5060Ti로 131k 컨텍스트에서는 최대 10tps까지 떨어졌습니다. 하지만 최대 131k 컨텍스트에서도 초기에 추적을 잃지 않고 백그라운드에서 작업을 처리할 수 있습니다. 전체 답변 (그리고 제가 작동하게 만든 방법): fp16도, Q6 양자화(quant)조차 아니며, 16GB에 매우 좋은 옵션은 ISTA-DASLab의 GSQ-RCO 양자화입니다: https://huggingface.co/ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF 저는 이전에 ridge-quant를 사용해봤는데 어느 정도는 작동했지만, gsq-rco가 훨씬 앞서 있습니다. IQ3_S 버전을 받으세요. 저는 이를 Q8 버전(H200에 접근할 수 있는 좋은 친구가 호스팅함)과 나란히 돌려보았고, 홈랩 개발 중에는 추론 속도 외에는 구별할 수 없었습니다. gsq-rco를 사용하여 kv streaming fork를 구축하는 데 도움을 받으세요: https://github.com/RaymondHuang210129/llama.cpp-adaptive-kv-streaming 주의할 점은, 이 포크(fork)를 사용하면 MTP를 사용할 수 없다는 것입니다. 저에게는 MTP가 추가로 ~5tps의 성능 향상을 가져왔지만, VRAM 측면에서 그 비용이 노력할 가치가 아니었습니다.
Ryzen 9600x, 32GB (싱글 채널) 및 5060Ti 16GB로 구동했을 때, 다양한 크기의 KV-window에 대해 다음과 같은 수치를 얻었습니다 (이 수치는 qwen 덕분에 포착할 수 있었고, 이 게시물에서 AI가 생성한 유일한 부분입니다): 결과 (측정치) pp t/s ≈ 콜드 프롬프트 처리 속도; dec t/s = 프로브의 ~53개 생성 토큰에 대한 디코딩: 토큰 pp @ 임의 풀 디코 t/s 512 디코 t/s 1536 디코 t/s 2048 14 644 878–892 28.0 28.5 27.9 35 186 803–807 23.9 25.2 25.2 54 976 736 15.9 20.6 21.3 69 429 695 12.4 18.7 19.1 94 464 630–635 8.7 12.6 15.5 프리필(Prefill)은 토큰 수에만 영향을 받으며, 프롬프트가 커질수록 꾸준히 감소합니다. 디코딩(Decoding)은 설정된 KV-window를 초과할 때까지는 느리게 감소하다가, 그 이후에는 더 빠르고 선형적으로 떨어집니다. 기억하세요: 저는 싱글 채널 RAM을 사용했기 때문에 듀얼 채널이 더 좋을 수 있습니다. 거의 131k 및 1536M window에서 약 9tps를 얻었으므로 이것이 하한선입니다. ~13.5GB의 모델 사용량으로는 3G kv-window를 확보하는 것이 불가능합니다. 이론적으로는 128MB까지 낮출 수 있지만, 그러면 처음부터 느립니다. 저는 1.5G가 상당히 좋다고 생각했습니다. 다른 GPU 작업에 충분한 VRAM을 남겨두면서도 여전히 ~30k 컨텍스트를 순수하게 VRAM만으로 서비스할 수 있게 해주기 때문입니다. 이 기능을 제대로 작동시키기 위한 몇 가지 제안: 모델은 기본 llama에서 로드되므로 이를 활용하세요. q8 kv 캐시를 사용하면 시스템이 필요로 하는 VRAM 양에 따라 32k에서 68k 컨텍스트 사이를 달성할 수 있습니다 (헤드리스 환경에서는 최대 68k까지 얻었지만, 데스크톱의 경우 신뢰성 있게 48k 정도만 얻을 수도 있습니다). 이것만으로도 컴파일 및 kvstreaming 포크 설정을 지원하기에 충분해야 합니다. pi(pi.dev)와 같은 하네스(harness)로 이를 연결하고 포크를 컴파일하게 하세요. 저에게는 그것이 쉽게 가능했습니다. 채팅 모드에서도 명령어만 가져와 콘솔 출력을 복사 붙여넣기 하는 것만으로도 잘 작동합니다. 무엇을 하고 있는지 약간 이해하는 것이 도움이 되지만, 자신만의 리눅스 커널을 컴파일할 필요가 있는 마스터 프로그래머일 필요는 없습니다.
모델을 낮은 컨텍스트(기본 llama)로 실행하려면, models-preset-ini 파일에 다음과 같은 내용을 제안합니다: [qwen38-gsq-rco] model = /models-src/linked/qwen38-gsq-rco.gguf mmproj = /models-src/linked/qwen38-gsq-rco-mmproj.gguf ctx-size = 49152 cache-type-k = q8_0 cache-type-v = q8_0 llama를 다음 설정으로 시작하세요 (ini 파일 경로가 올바르게 구성되었다고 가정): --models-preset /models-src/models-preset.ini --models-max 1 --host 0.0.0.0 --port 8080 --n-gpu-layers 999 --jinja --flash-attn on --no-mmproj-offload 이렇게 하면 전체 모델을 kv와 함께 GPU에 로드하고 비전 부분은 시스템 RAM에 유지됩니다 (이미지 분석 속도만 느려질 뿐, 다른 것은 아닙니다). 새로운 llama-kv-streaming image를 사용하면 원하는 크기의 "kv-window"를 설정할 수 있습니다. 저는 KV에 1536M의 VRAM을 할당하여 총 VRAM 사용량이 13.5GB(헤드리스 모드 기준)인 상태로 실행했습니다. 131k의 컨텍스트를 처리했는데, 더 많은 것도 가능하지만 a) 시스템 메모리를 소모하고 b) 사용되는 컨텍스트가 커질수록 속도가 느려집니다. 131k는 대부분의 작업에 완전히 사용 가능한 수준입니다. 제 kv-streaming llama 컨테이너용 dockerfile의 시작 매개변수는 다음과 같습니다: command: > --model /models-src/linked/qwen38-gsq-rco.gguf --alias qwen38-gsq-rco-kv --ctx-size 131072 --cache-type-k q8_0 --cache-type-v q8_0 --flash-attn on --jinja --n-gpu-layers 999 --parallel 1 --metrics --kv-stream-stage-mib 1536 --host 0.0.0.0 --port 8080 --mmproj /models-src/linked/qwen38-gsq-rco-mmproj.gguf --no-mmproj-offload 그리고 모델을 사용할 때의 nvidia-smi는 다음과 같습니다: Tue Oct 6 23:29:08 2026 +-----------------------------------------------------------------------------------------+ | NVIDIA-SMI 580.173.02 Driver Version: 580.173.02 CUDA Version: 13.0 | +-----------------------------------------+------------------------+----------------------+ | GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. | | | | MIG M.
| |=========================================+========================+======================| | 0 NVIDIA GeForce RTX 5060 Ti Off | 00000000:01:00.0 Off | N/A | | 33% 60C P1 172W / 180W | 13660MiB / 16311MiB | 100% Default | | | | N/A | +-----------------------------------------+------------------------+----------------------+ +-----------------------------------------------------------------------------------------+ | 프로세스: | | GPU GI CI PID 유형 프로세스 이름 GPU 메모리 | | ID ID 사용량 | |=========================================================================================| | 0 N/A N/A 4167261 C /app/llama-server 13644MiB | +-----------------------------------------------------------------------------------------+ 주의할 점은 전체 KV 캐시(Key-Value Cache)가 여기에 저장되어야 하므로 상당한 양의 시스템 RAM이 필요하다는 것입니다. 그리고 이 데이터는 요청 시 VRAM 윈도우로 복사됩니다. 요약하자면(TL;DR): 크기에 비해 매우 견고한 성능을 제공하는 Qwen3.8 27B GSQ-RCO IQ3_S를 사용하세요. 이를 40k 이상의 컨텍스트와 함께 사용하여 llama 포크 세트를 컴파일하십시오. kv-streaming llama를 설정하고 원하는 컨텍스트 크기를 설정하되, 기적을 기대하지 마십시오. 컨텍스트의 한계에 도달하면 느릴 수 있습니다. 제출자: /u/randomgenericbot [링크] [댓글]
AI 자동 생성 콘텐츠
본 콘텐츠는 Reddit AI Engineering의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기