Lucebox: 추측 디코딩과 전용 커널로 소비자용 GPU의 LLM 추론을 끌어올리는 서버

Lucebox 소개

책상 위 RTX 3090 한 장으로 27B 모델을 돌려 보면, 답이 한 글자씩 떨어지는 속도에서 곧 한계를 느끼게 됩니다. 카드가 낡아서라기보다 그 위에서 도는 소프트웨어가 특정 칩에 맞춰져 있지 않기 때문입니다. 범용 추론 런타임은 어떤 하드웨어에서도 무난히 돌아가도록 만들어져 있고, 그 무난함의 대가로 각 칩이 낼 수 있는 최고치를 남겨 둡니다. Lucebox 는 그 남는 성능을 회수하는 쪽을 택한 로컬 LLM 추론 서버입니다.

방법은 하나가 아니라 여럿입니다. 초안 모델이 여러 토큰을 미리 써 두고 본 모델이 한 번에 검증하는 추측 디코딩(speculative decoding), 긴 프롬프트를 압축해 첫 응답까지 걸리는 시간을 줄이는 추측 프리필(speculative prefill), 모델의 전체 레이어를 하나의 CUDA 디스패치로 묶는 메가커널(megakernel), VRAM에 다 들어가지 않는 MoE 전문가를 선별해 올리는 전문가 오프로드가 각각 별도의 구성요소로 들어 있습니다. 프로젝트는 이 방식들이 "각 최적화는 특정 모델 계열과 하드웨어를 겨냥한다" 는 전제 위에 서 있다고 밝히고 있습니다. 하나의 만능 경로가 아니라 조합이라는 뜻입니다.

서버 본체는 C++17로 작성되어 있고 CUDA 12 이상 또는 ROCm 6 이상에서 빌드되며, OpenAI 호환 HTTP API를 8000번 포트로 엽니다. 라이선스는 Apache 2.0이고, RTX 3090을 기준 장비로 삼아 모든 대표 수치를 측정했습니다. 이 글에서는 Lucebox가 어떤 최적화를 어떻게 나눠 담았는지, 어떤 모델과 GPU에서 검증됐는지, 설치와 실행은 어떤 모습인지를 정리합니다.

범용 런타임의 한계와 Lucebox의 접근

프로젝트는 "왜 이것을 만들었는가" 섹션에서 문제를 직접 서술합니다. 대부분의 장비는 일반 데스크톱 CPU에 기성 GPU를 꽂고 기성 런타임을 올릴 뿐, 그 아래 실리콘에 맞춰 커널을 손보지 않습니다. 추측 디코딩이나 융합 커널, 보정된 MoE 오프로드처럼 3~10배를 끌어낼 수 있는 기법들이 이미 있지만, 대개 데이터센터 GPU의 BF16 가중치에 묶여 있어 소비자용 카드는 그 혜택에서 밀려나 있다는 것이 저자들의 진단입니다.

그래서 Lucebox의 접근은 "모든 모델을 조금씩 빠르게"가 아니라 특정 조합을 깊게 파는 쪽 입니다. 대표 수치가 전부 RTX 3090 기준이고, 최적화마다 대상 모델 계열이 정해져 있으며, 벤치마크도 최적화 디렉토리별로 따로 관리됩니다. 아래 표는 이 차이를 정리한 것입니다.

항목 범용 추론 런타임 Lucebox
목표 넓은 하드웨어·모델 호환 특정 모델 계열과 GPU 조합의 최대 처리량
최적화 단위 런타임 전체 최적화별 독립 구성요소, 각자 설정과 벤치마크 보유
대표 장비 특정하지 않음 RTX 3090(Ampere sm_86)을 기준으로 모든 대표 수치 측정
성능 비교 기준 저장소에 포함된 llama.cpp 대비, KV 양자화 조건을 맞춰 측정

수치를 읽을 때는 조건을 함께 봐야 합니다. 저장소가 제시하는 속도 향상은 모두 저장소에 함께 담긴 llama.cpp를 -fa 1 옵션과 동일한 KV 양자화 조건에서 돌린 결과와 비교한 값이고, 프리필과 디코딩을 모두 측정한 경우에는 두 값의 기하평균으로 계산했다고 밝히고 있습니다. 제3자가 검증한 수치가 아니라 개발팀이 자체 측정한 값이라는 점도 감안할 필요가 있습니다.

Lucebox의 최적화 구성요소

가장 자주 쓰이는 경로는 27B급 모델을 겨냥한 DFlash입니다. 초안 모델이 만든 토큰들을 트리 형태로 한 번에 검증하는 DDTree 방식을 함께 쓰며, KV 캐시를 TQ3_0으로 양자화해 24GB 카드 한 장에서 256K 컨텍스트를 확보합니다.

작은 모델에는 접근이 아예 다릅니다. 메가커널은 Qwen3.5 0.8B의 24개 레이어 전체를 하나의 상주 CUDA 디스패치로 융합해, 레이어마다 커널을 실행하고 결과를 주고받는 비용을 없앱니다. 저장소의 측정값으로는 220W로 제한한 RTX 3090에서 디코딩 413 tok/s, 프리필 21,347 tok/s이고, 같은 카드에서 350W로 돌린 llama.cpp BF16의 267 tok/s·11,247 tok/s와 비교됩니다. 전력 조건이 서로 다르다는 점은 표에 그대로 적혀 있습니다.

나머지 세 가지는 각자 다른 병목을 겨냥합니다. PFlash는 긴 프롬프트를 점수화해 일부만 남기는 프리필 압축으로, 기본 설정은 32,000토큰을 넘는 프롬프트에 대해 원본 토큰의 5%만 남기고 컨텍스트 길이에 따라 비율을 조절합니다. Spark는 MoE 모델의 전문가 가중치가 VRAM에 다 들어가지 않을 때 자주 쓰이는 전문가와 그렇지 않은 전문가를 나눠 배치하고, 실제 트래픽을 보며 그 배치를 스스로 조정합니다. KVFlash는 KV 캐시를 고정 크기 GPU 슬롯 풀로 관리하고 오래된 64토큰 단위 조각을 호스트 메모리로 내려, 컨텍스트가 길어져도 디코딩 속도와 VRAM 사용량이 함께 늘어나지 않게 합니다.

Lucebox가 검증한 모델과 GPU

모델별 속도 향상은 README 표에 정리되어 있습니다. Qwen3.6 27B에 PFlash를 적용하면 약 5.6배, DDTree를 쓰면 4.84배, Laguna XS 2.1 33B는 256K 컨텍스트에서 PFlash로 8.2배가 나옵니다. Gemma 4 31B는 3.2배, 26B-A4B는 1.31배로 편차가 큰데, 이 편차 자체가 "최적화가 모델 계열별로 다르게 붙는다"는 설계를 보여 줍니다. 초안 모델들은 Hugging Face의 Lucebox 계정에 GGUF 형식으로 공개되어 있습니다.

하드웨어는 상태를 구분해 표기합니다. RTX 3090이 기준 장비이고, RTX 5090은 205 tok/s에 4.84배, RTX 2080 Ti는 DFlash로 53 tok/s, DGX Spark의 GB10은 메가커널 NVFP4 경로가 확인됐습니다. AMD 쪽은 HIP 백엔드로 Radeon RX 7900 XTX 50 tok/s, Ryzen AI MAX+ 395(Strix Halo) 37 tok/s, Radeon AI PRO R9700 55 tok/s가 기록되어 있습니다. RTX 4090은 커뮤니티가 제출한 벤치마크, Jetson AGX Thor와 V100·P40은 "빌드는 되지만 측정되지 않음" 으로 남아 있어, 무엇이 검증됐고 무엇이 아닌지가 구분되어 있습니다.

Lucebox 설치 및 실행

가장 빠른 경로는 GHCR에 올라온 사전 빌드 이미지입니다. CUDA 툴킷이나 빌드 과정 없이 GGUF 가중치만 마운트하면 됩니다.

docker pull ghcr.io/luce-org/lucebox-hub:cuda12   # NVIDIA
docker pull ghcr.io/luce-org/lucebox-hub:rocm     # AMD

docker run --rm --gpus all -p 8000:8080 \
  -v "$PWD/server/models:/opt/lucebox-hub/server/models" \
  ghcr.io/luce-org/lucebox-hub:cuda12

직접 빌드한다면 CMake 3.18 이상이 필요하고, server/ 는 필요한 ggml 소스를 저장소 안에 포함하고 있어 PyTorch 없이도 빌드됩니다. PyTorch 2.0 이상이 필요한 것은 메가커널 구성요소뿐입니다.

git clone --recurse-submodules https://github.com/Luce-Org/lucebox-hub && cd lucebox-hub
cmake -B server/build -S server -DCMAKE_BUILD_TYPE=Release
cmake --build server/build --target dflash_server -j

대상 모델과 초안 모델을 받은 뒤 서버를 띄우면 OpenAI 호환 엔드포인트가 열립니다. 기본 구성은 Qwen3.6 27B Q4_K_M 대상 모델에 DFlash 초안 모델을 붙이고, DDTree 예산 22와 TQ3_0 KV 캐시를 사용합니다.

DFLASH27B_KV_TQ3=1 \
./server/build/dflash_server server/models/Qwen3.6-27B-Q4_K_M.gguf \
  --draft server/models/draft/dflash-draft-3.6-q4_k_m.gguf \
  --ddtree --ddtree-budget 22 --port 8000

요청을 보낼 때 temperature 를 0으로 두면 가장 빠릅니다. 탐욕적 디코딩(greedy decoding)에서 추측 디코딩의 초안 수용률이 가장 높아지기 때문이라고 설명하고 있습니다. DDTree 예산처럼 카드마다 다시 맞춰야 하는 값도 있는데, 3090에서 22, 5090에서 40이 기본이고 GB10에서는 다시 측정하라고 안내합니다.

Lucebox를 코딩 에이전트에 연결하기

harness/ 디렉토리에는 로컬 서버를 실제 클라이언트에 붙이는 실행 스크립트가 들어 있습니다. Claude Code, Codex, OpenCode, Hermes, Pi, OpenClaw, Open WebUI용 런처가 각각 준비되어 있고, 모두 네이티브 C++ HTTP 서버를 띄운 뒤 그 클라이언트를 연결하는 구조입니다. 서버를 고쳤을 때 이 클라이언트들이 여전히 붙는지 확인하는 회귀 테스트 역할도 겸합니다.

DFLASH_SERVER_BIN=server/build/dflash_server \
DFLASH_TARGET=server/models/Qwen3.6-27B-Q4_K_M.gguf \
DFLASH_DRAFT=server/models/draft/dflash-draft-3.6-q4_k_m.gguf \
MAX_CTX=32768 BUDGET=22 VERIFY_MODE=ddtree \
harness/clients/run_codex.sh

돌고 있는 서버에 대해 토큰 처리량과 첫 응답 지연을 재는 벤치마크 스크립트도 함께 들어 있어, 설정을 바꿔 가며 비교해 보기 좋습니다.

python3 harness/client_test_runner.py bench \
  --url http://127.0.0.1:8000 --suite he,agent --n-sample 3

Lucebox는 누구에게 유용한가

24GB 안팎의 소비자용 GPU가 있고 그 위에서 27B급 모델을 코딩 에이전트의 백엔드로 쓰고 싶다면 검토할 만합니다. 표에 올라 있는 모델과 카드 조합에 해당하면 도커 이미지만으로 시작할 수 있고, 클라이언트 런처까지 준비되어 있어 붙이는 과정도 짧습니다. 반대로 사용 중인 모델이 지원 목록에 없다면 얻는 것이 크게 줄어듭니다. 최적화가 모델 계열과 하드웨어에 맞춰 작성되어 있어, 목록 밖의 조합은 일반 경로로 동작하기 때문입니다.

여러 사용자를 동시에 받는 서비스용 서빙 스택을 찾고 있다면 방향이 다릅니다. 이 프로젝트가 다루는 문제는 한 대의 장비에서 한 사람이 쓰는 속도이고, 설정 항목 대부분도 단일 GPU 또는 같은 장비 안의 여러 GPU를 전제로 합니다. 플래그와 환경 변수의 수가 상당해서 기본값 밖으로 나가려면 문서를 꽤 읽어야 한다는 점, 그리고 성능 수치가 모두 개발팀 자체 측정이라는 점도 도입 전에 감안할 부분입니다.

Lucebox의 라이선스

Lucebox는 Apache 라이선스 2.0으로 공개되어 있어 개인 및 상업적 목적으로 자유롭게 사용할 수 있습니다.

:house: Lucebox 공식 홈페이지

:books: Lucebox 최적화 기법 소개 블로그

:hugs: Lucebox 초안 모델 다운로드

:github: Lucebox 프로젝트 GitHub 저장소

더 읽어보기




이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다. :hugs:

이 도구를 직접 설치해 사용해보셨다면, :pytorch:파이토치 한국 사용자 모임:south_korea: 회원들을 위해 경험이나 팁을 댓글로 남겨주세요! :folded_hands: