2주 전에는 [Qwen3.8-Flash-Next를 EXL3와 TabbyAPI를 사용해 40GB 이상의 RAM으로 구동하는 것]에 대해 작성했습니다. 그 이후 워크스테이션의 RAM이 128 GB로 업그레이드되었고, 이로 인해 가장 빠른 설정 자체가 바뀌었습니다. 본 가이드는 현재 매일 사용하는 설정을 다룹니다: Strata가 Unsloth의 5-bit UD-Q5_K_XL GGUF 형식으로 같은 125B 모델을 512K 컨텍스트에서 약 초당 79 토큰(tokens per second)으로 서비스합니다. 이 모든 것은 RTX 5090 한 장비로 구동됩니다.

아래의 모든 수치는 2026년 10월 15일, 저희 자체 기계에서 측정된 것입니다. 다른 사람에게서 온 수치라면 출처를 명시했습니다.

EXL3 가이드 이후 무엇이 바뀌었는가

EXL3 가이드는 터보더프(turboderp)의 3.05 bpw 양자화(quant)를 사용했는데, 이는 64 GB RAM으로는 더 큰 것을 담을 공간이 없었기 때문입니다. 128 GB가 되면서 두 가지 경로가 열렸습니다:

• TabbyAPI는 4.05 bpw EXL3 양자화와 고정된 CPU expert arena를 사용했습니다. 서버 로그에 따르면, VRAM 여유 공간 3 GB로 디코딩 시 초당 약 68 토큰(tokens per second)이었고, 254K 토큰에서 프리필(prefill) 시 초당 약 1,780 토큰이었습니다.
• Strata는 Unsloth의 UD-Q5_K_XL을 사용했습니다. 이는 8비트 다운 프로젝션(down projections)을 가진 5-bit 양자화입니다. 같은 모델이지만, expert당 더 많은 비트를 사용하며, 이 단일 모델 패밀리를 위해 구축된 런타임입니다.

같은 기계에서 Strata는 튜닝 전에는 TabbyAPI와 비슷한 속도로 디코딩했고, 보정(calibration) 후에는 더 빨랐으며, 긴 프롬프트는 약 1.8~2.4배 빠르게 읽었고, 512K 컨텍스트에서 구동되었습니다. 이것이 현재 저희의 기본 설정입니다.

기계 사양

• GPU: RTX 5090, VRAM 32 GB. 데스크톱도 구동하는 장비입니다. 나중에 중요합니다.
• CPU: Ryzen 9 9950X3D (16 코어, 32 스레드, AVX-512).
• RAM: 4x32 GB로 구성된 DDR5 128 GB, 5,600 MT/s로 작동합니다. 'pitfalls'에서 왜 6,000이 아닌지에 대해 더 설명하겠습니다.
• 디스크: 158 GB 다운로드 공간을 확보한 NVMe 드라이브 하나.
• OS: Arch Linux (Omarchy), NVIDIA driver 615.78, CUDA 13.4.
• Strata는 커밋 296b59d 버전입니다.

왜 Strata인가

Strata는 Qwen3.8-Flash-Next 및 그 변형 모델을 위한 C++/CUDA 엔진과 Python 서버입니다. 이 시스템은 모델을 세 가지 계층(tier)으로 읽습니다: 대화에 가장 많이 사용되는 전문가(experts)들은 VRAM에, 다음 전문가들은 RAM에, 그리고 들어가지 않는 것은 SSD에서 가져옵니다. 실행하는 동안 전문가들을 계층 간에 이동시키고, 모델 자체의 MTP 레이어(layer)를 사용하여 토큰을 초안 작성하며, OpenAI 및 Anthropic과 호환되는 API와 실시간 모니터가 있는 작은 웹 UI를 제공합니다.

이 프로젝트의 설치 문서는 코딩 에이전트가 따라 할 수 있도록 작성되었습니다(docs/AI_SETUP.md). 하지만 여전히 직접 읽어보시는 것을 권장합니다: 해당 문서에 추천된 크기는 32-96 GB 게이밍 PC를 대상으로 하며, 더 큰 Unsloth 양자화(quants)는 별도의 설정군입니다.

RAM 용량으로 양자화를 선택하세요. 비트 수로가 아닙니다

Strata는 전문가들과 약 16 GB의 여유 공간이 RAM에 들어갈 경우 모든 전문가를 RAM에 유지합니다. 만약 그렇지 않다면, 답변을 하는 동안 나머지 부분을 SSD에서 읽어오게 되는데, 이는 상당한 디코드 속도 저하를 초래합니다. 따라서 규칙은 간단합니다: 여유 공간을 두고 RAM에 들어가는 가장 큰 양자화를 선택하세요.

Strata의 모델 테이블과 자체 품질 측정 기준(양자화가 Q8_0과 동일한 상위 토큰을 선택하는 빈도):

무엇이든 다운로드하기 전에, setup을 사용하여 PC를 점검하세요:

git clone https://github.com/Niko1221/Strata.git
cd Strata
./setup.sh --check

이 명령어는 GPU, 드라이버, RAM, CPU 및 여유 디스크 공간을 출력하며 어떤 크기가 적합한지 알려줍니다.

설치

이것은 저희가 실행한 설정 명령어입니다. 비대화형(non-interactive) 방식으로, 모델 파일들은 NVMe 드라이브에 있습니다:

./setup.sh --yes --family unsloth --model UD-Q5_K_XL \
  --context 262144 --vision no --gpu 0 \
  --data-dir ~/Models/strata --port 8081 \
...

각 플래그의 역할:

• --family unsloth --model UD-Q5_K_XL: Unsloth의 5비트 파일을 선택합니다.
• --context 262144: 모델이 학습된 컨텍스트 길이입니다. 나중에 늘릴 수 있습니다.
• --vram-reserve-mib 3072: 3 GB의 VRAM을 여유 공간으로 남겨둡니다. 저희 데스크톱은 같은 카드를 사용하는데, VRAM이 완전히 가득 차면 화면이 깜빡이기 시작했습니다.
• --port 8081: 포트 8080은 저희 GLM 설정에서 사용하고 있기 때문에 (나중에 설명하겠습니다). 기본값은 8080입니다.
• --no-start: 서버를 시작하지 않고 설치하므로, 아래에 설명된 방식으로 시작할 수 있습니다.

설정(Setup) 과정은 Strata 폴더 안에 JSON 설정 파일(strata-unsloth-ud-q5_k_xl.json)과 시작 스크립트(run-unsloth-ud-q5_k_xl.sh)를 작성합니다.

다운로드가 느릴 경우

Strata 자체 다운로더는 여기서 시간당 약 7 MB/s에 불과했고, 이는 158 GB를 다운로드하는 데 약 6시간이 걸리는 정도입니다. 더 빠른 방법은 다음과 같습니다: 설정(setup)을 중단하고, setup이 지정한 정확한 리비전으로 Hugging Face CLI를 사용하여 샤드(shards)를 가져와 모델 폴더에 넣고, 다시 setup을 실행합니다. 이 과정은 모든 파일을 SHA-256과 비교하여 이미 존재하는 파일은 건너뜁니다.

# Unsloth의 리포지토리에서 setup.py가 지정하는 리비전 확인
grep -n "unsloth/Qwen3.8-Flash-Next-GGUF" setup.py

...

만약 사용자의 setup.py가 출력하는 리비전과 다르다면, 그 리비전을 사용하십시오.

setup이 샤드 1이

in check_shards(), before: need = g.data_start + ...

if not g.tensors:
continue

git pull을 할 때마다 해당 수정 사항이 상위(upstream)에 적용되었는지 확인하여, 더 이상 필요하지 않은 패치를 유지하는 것을 방지하세요.

셸의 메모리 제한 외부에서 실행하기

Strata는 이 양자화(quant)를 사용하여 약 98 GB의 RAM을 고정합니다. 두 가지 리눅스 기본 설정이 그 정도 크기의 프로세스를 종료시키거나 심각하게 손상시킬 수 있습니다:

• 메모리 제한이 있는 systemd 범위 내의 셸 또는 도구 실행기(tool runner). 저희 에이전트의 터미널 범위는 memory.max가 4 GiB이며, 여기서 시작된 모델은 대부분 스왑(swap)으로 이동하게 됩니다.
• systemd-oomd. Omarchy는 사용자의 app.slice에 대해 이를 활성화하고, 메모리 압력이 50%를 초과한 후 20초가 지나면 cgroup을 종료시킵니다. 대부분의 RAM을 고정하는 모델은 부하 상태에서 정확히 그렇게 보입니다.

따라서 저희는 메모리 제한 없이 자체 슬라이스(slice)에서 서버를 시작합니다:

systemd-run --user --scope --collect --slice=llm.slice \
  --unit="strata-$(date +%s)" -p MemoryMax=infinity \
  ./run-unsloth-ud-q5_k_xl.sh

systemctl --user stop 'strata-*.scope'로 중지하세요. 광범위한 pkill -f: 이 패턴은 실행하는 셸도 일치시키기 때문에 피해야 합니다.

처음 시작할 때는 몇 분이 걸리며, RAM이 고정되는 동안 데스크톱이 잠시 멈출 수 있습니다. 그런 다음 작동 중인지 확인하세요:

curl -s http://127.0.0.1:8081/health
# {"status": "ok", "max_context": 524288, "model": "...", "loaded": true, ...}

...

기본 URL http://127.0.0.1:8081/v1을 사용하는 모든 OpenAI 호환 클라이언트와 모든 API 키 및 모든 모델 이름이 작동합니다. Anthropic 호환 클라이언트는 /v1/messages를 사용합니다. 127.0.0.1에 그대로 두세요. 네트워크로 열 경우, --api-key도 설정해야 합니다.

512K 컨텍스트로 이동하기

이 모델은 262,144 토큰으로 훈련되었습니다. Strata는 YaRN rope scaling을 통해 이를 확장할 수 있으며, 설정 스크립트가 방법을 자동으로 선택합니다:

./setup.sh --setup --context 524288

메모리 제한이 있는 셸에서 실행하는 경우 --no-start를 추가하고 서버를 별도로 시작하세요. 설정(Setup)은 엔진 인수에 --max-context 524288 --rope-scaling yarn --rope-scale 2를 추가합니다. 사용자 지정 채팅 템플릿을 사용하는 경우(아래 참조), config의 tokenizer 키가 여전히 해당 템플릿을 가리키는지 나중에 확인하세요. Strata 문서에서는 이를 실험적(experimental)이라고 부르며, 니들 테스트(needle tests)는 분리된 스케일링 방법들을 제대로 측정하지 못하지만, 실제 장문 질의응답(long-document Q&A)은 그렇게 한다고 언급합니다. 저희 기계에서 이 방법을 사용했을 때 520K 토큰에서 니들을 찾았으며, 디코딩 속도는 262K일 때와 동일하게 유지되었습니다. KV 캐시는 GPU에 32K 토큰이 상주하는 int8 방식이며, 따라서 추가적인 컨텍스트는 VRAM이 아닌 RAM을 소모합니다.

PC용 보정 (Calibrate for your PC)

Strata에는 사용자의 하드웨어에서 몇 가지 엔진 설정을 측정하고 3% 이상 빨라진 변경 사항만 유지하는 보정(calibration) 기능이 있습니다:

./setup.sh --calibrate --no-start

--no-start 없이 실행하면 나중에 서버가 시작됩니다. VRAM 예약 설정을 완료한 후, 그리고 서버와 동일하게(메모리 제한 없이 llm.slice에서) 실행하세요. 왜냐하면 전체 모델을 로드하기 때문입니다. Strata는 15~30분이 걸린다고 추정합니다. 저희는 같은 보정 함수(setup.py의 calibrate_config)를 작은 스크립트에서 호출했고, 약 11분 만에 끝났습니다. 저희 기계에서는 다음 설정을 선택했습니다:

--pcie-frac 0.35 --spec-min-p 0.70
--adapt-every 1 --adapt-swaps 160 --adapt-decay 0.97

--adapt-* 설정은 적응형 전문가 캐시(adaptive expert cache)를 구동합니다: 전문가가 RAM과 VRAM 사이를 얼마나 자주 스왑하는지, 한 단계당 몇 개를 스왑하는지, 그리고 오래된 사용 횟수가 얼마나 빨리 사라지는지를 결정합니다. --spec-min-p 0.70은 MTP drafter가 확신하지 못할 때 더 일찍 멈추게 합니다. CPU 워커(4~15개)의 개수는 차이를 만들지 않았습니다.

보정 기능은 자체 수치(여기서는 끝에서 초당 86.8 토큰)를 보고하지만, 이는 내부 측정값입니다. 저는 제가 통제할 수 있는 값을 원했기 때문에, 각 팔(arm) 사이에 재시작을 거쳐 기존 설정과 새 설정을 각각 두 번씩 A/B 테스트를 진행했습니다. 보정하기 전에 config를 백업하여 같은 작업을 할 수 있도록 하세요.

벤치마크 (Benchmarks)

측정 방법: OpenAI 엔드포인트를 대상으로 클라이언트 측 스트리밍 벤치 테스트를 수행했습니다. 각 조건(arm)당 8회 실행을 진행했으며, 약 400단어 분량의 네덜란드어 산문 프롬프트와 코딩 프롬프트(테스트가 포함된 이진 탐색 함수)를 번갈아 사용했습니다. 디코딩은 그리디 디코딩(greedy decoding), 출력 토큰 512개를 기준으로 했으며, 중앙값을 보고했습니다. 프리필(Prefill)은 주어진 프롬프트 길이에서 니들-인-어-헤이스택 테스트(needle-in-a-haystack test)를 통해 측정되었습니다. 니들과 채움 텍스트는 길이에 따라 고정되어 있으므로, 나중에 실행하는 경우 이전에 수행된 테스트의 부분적인 프리픽스 캐시 히트(partial prefix-cache hit)가 발생할 수 있습니다: 따라서 프리필 숫자는 근사치로 간주하십시오. 기기에서 무거운 작업은 달리 수행되지 않았습니다.

프리필 값은 보정(calibration) 전후로 약 260K 토큰에서 초당 3,196개에서 4,205개 토큰 사이였습니다. 4.05 bpw EXL3 양자화(quant)를 사용한 TabbyAPI의 경우, 동일한 3 GB 예약 메모리로 디코딩 시 서버 로그에 약 초당 68토큰이 보고되었고, 같은 니들 테스트에서 254K 토큰을 초당 약 1,780토큰으로 프리필했습니다. 서버 로그와 클라이언트 스트림 디코드 수치는 측정 방식이 다르므로, 이를 일대일로 비교하기보다는 유사한 수준으로 간주하십시오.

비교를 위해 Strata의 문서는 AMD Radeon AI PRO R9700 (32 GB)에서 동일한 양자화를 사용했을 때 스토리의 경우 초당 57~60토큰, 코드의 경우 초당 82토큰을 나열하고 있습니다. 이는 다른 카드와 다른 벤치마크이므로 일대일로 비교해서는 안 됩니다.

품질 검증 (Quality checks)

속도만으로는 충분하지 않습니다. 답변 내용이 정확해야 의미가 있기 때문입니다. 저희는 자체적으로 두 가지 검사를 수행했습니다.

숨겨진 테스트가 있는 코딩 작업. 다섯 가지 작업이 각각 세 번의 시도로 샌드박스에서 실행되었으며, 추론 난이도는 중간(medium) 수준입니다. Strata를 UD-Q5_K_XL로 사용했을 때 15개 중 15개(480개 중 480개 테스트 케이스)를 통과했습니다. TabbyAPI를 EXL3 4.05 bpw로 사용했을 때도 동일한 점수를 기록했습니다. 이 작업들은 두 양자화 모델을 분리하기에는 너무 쉬웠고, 두 모델 간의 차이는 점수가 아니라 속도와 컨텍스트에 있었습니다.

저희가 직접 수행한 테스트. 저희 업무에서 가져온 아홉 가지 작업을 자동 검사기가 갖춘 벤치마크를 구축했습니다. 여기에는 JavaScript로 작성된 Astro 도우미 2개, PHP 샌드박스에서 실행되는 WordPress PHP 스니펫 2개, JSON 형식의 SEO 메타 태그, LocalBusiness JSON-LD, Search Console 도구 호출, Search Console 빠른 개선 분석, 그리고 네덜란드어 블로그 소개글 작성이 포함되었습니다. 설정당 두 라운드를 진행했으며, 최대 점수는 108점입니다: