GLM-5.3-Flash는 321B 규모의 mixture-of-experts 모델이며, 이 모델의 3.05 bpw EXL3 양자화(quant) 버전은 125 GB로, 워크스테이션의 OS를 위한 128 GB RAM에 담기에는 너무 큰 용량입니다. 그럼에도 불구하고 여기서는 로컬에서 실행할 수 있습니다: 128 GB RAM을 갖춘 RTX 5090 하나와 512K-token 컨텍스트로, 초당 약 25 토큰 속도입니다. 이 가이드는 Project Maya를 사용하여 어떻게 가능한지, 그리고 그 과정에서 측정된 내용들을 보여줍니다.
아래의 모든 수치는 2026년 10월 15일에 저희 자체 장비에서 측정되었습니다. 출처가 다른 숫자는 해당 출처를 명시했습니다.
이 글은 두 개의 기사 중 두 번째입니다. 첫 번째 기사는 [Qwen3.8-Flash-Next with Strata at 79 tokens per second](https://dev.to/seppegadeyne/run-qwen38-flash-next-at-79-toks-with-strata-and-a-5-bit-quant-on-128-gb-of-ram-4a81]에서 다루었으며, 그 이전에는 [Qwen3.8-Flash-Next with EXL3 and TabbyAPI on 40+ GB of RAM](https://dev.to/seppegadeyne/run-qwen38-flash-next-locally-with-exl3-and-tabbyapi-on-40-gb-of-ram-3m8d]에 대해 작성했습니다.
모델 소개
GLM-5.3-Flash는 zai-org에서 MIT 라이선스로 제공하는 open-weight 모델입니다. Maya의 README에 따르면, 이 모델은 321B 파라미터를 가지며 토큰당 약 18B가 활성화되고 최대 1M 토큰 컨텍스트를 지원합니다. 하이브리드 어텐션 디자인과 드래프팅을 위한 MTP 레이어를 가지고 있습니다.
활성 파라미터 18B는 Qwen3.8-Flash-Next model card가 나열하는 약 6B보다 세 배 더 많습니다. 이것이 아래 속도 차이의 대부분을 설명합니다: 토큰당 모델의 더 많은 부분이 CPU와 PCIe를 거쳐 이동해야 하기 때문입니다.
TabbyAPI를 사용하지 않는 이유
저는 먼저 turboderp의 GLM-5.3-Flash EXL3 quants로 TabbyAPI를 시도했습니다. ExLlamaV3는 CPU 전문가(expert)들을 RAM 아레나에 유지하며, 전문가용 SSD 계층이 없습니다. 따라서 전체 모델은 OS 옆의 VRAM과 RAM 모두에 적합해야 합니다. 128 GB에서는 가장 큰 양자화 버전으로 자체 보정된 2.60 bpw 개정이 작동했습니다:
| TabbyAPI, 262K context | Decode (tok/s, 서버 로그) | Prefill at 256K | 부하 시 사용 가능한 RAM |
|---|
| sc_2.10bpw | 32.4 | 1,063 tok/s | ~36 GB |
| sc_2.60bpw | 25.5 | 1,151 tok/s | ~19 GB, 기타 프로세스는 zram 사용 |
The 3.05 bpw 양자화(quant) (125 GB)는 그렇게 들어가지 않습니다. 일부 전문가(experts)를 SSD에 남겨둘 수 있는 런타임이 필요합니다.
Project Maya가 필요한 이유
Project Maya는 Strata의 포크 버전으로, 이 단일 모델을 위해 구축되었습니다. 이 엔진은 사용자의 대화에서 가장 많이 사용하는 전문가를 GPU에, 다음 순서의 전문가는 RAM에, 그리고 나머지는 NVMe 드라이브에 보관하며, 채팅하는 동안 이를 이동시킵니다. 하드웨어를 측정하고 스스로 조정하며, OpenAI 및 Anthropic과 호환되는 API를 노출하고, 실시간 모니터가 있는 대시보드를 갖추고 있습니다.
Maya는 자체 GGUF 양자화(Maya-S 96.5 GB, Maya-M 116 GB, Maya-L 156 GB)를 배포합니다. 또한 turboderp의 EXL3 양자화를 safetensors에서 제자리에 읽을 수도 있는데, 이는 README에 실험적이며 NVIDIA 전용으로 표시되어 있습니다. 저는 이미 TabbyAPI 테스트를 통해 신뢰했던 이 quant와, Maya가 TabbyAPI에서 더 작은 sc_2.60 quant만큼 빠르게 디코딩했기 때문에 EXL3 3.05 bpw 경로를 선택했습니다.
장비 사양
- GPU: RTX 5090 (VRAM 32 GB), 데스크톱 구동에도 사용됨.
- CPU: Ryzen 9 9950X3D (16 코어, 32 스레드).
- RAM: 128 GB DDR5 (4x32 GB, 5,600 MT/s).
- 디스크: NVMe 드라이브 1개.
- OS: Arch Linux (Omarchy), NVIDIA 드라이버 615.78, CUDA 13.4.
- Maya 1.1.11 (커밋
d187195, 2026년 10월 15일).
설치 방법
git clone https://github.com/mw00/project-maya.git
cd project-maya
./maya.sh --check
--check는 GPU, 드라이버, CUDA 툴킷, 컴파일러, RAM 및 CPU를 출력합니다. 그런 다음 비대화형으로 설정을 실행합니다:
./maya.sh --setup --plain --yes --gpu 0 \
--context 131072 --model EXL3-3.05bpw \
--models-dir ~/Models/maya --download-model \
...
Maya의 설정 문서와 우리가 본 내용을 바탕으로 다음과 같은 일이 발생합니다:
- PC를 확인하고 Python 패키지를
.venv에 설치합니다.
llama.cpp의 소스를 특정 커밋(pinned commit)에서 가져와 사용자의 GPU용 엔진을 컴파일합니다. Maya 문서에 따르면 이 과정은 한 번 할 때 10~30분이 걸린다고 합니다.- 재개 가능한(
resumable) curl 명령어를 먼저 출력하고, 모든 파일이 SHA-256 해시를 통해 검증하는 방식으로 125.3 GB의 양자화(quant) 모델(총 27개 파일)을 다운로드합니다.
- 모델 폴더에 엔진의 모델 파일을 인덱싱한
_pack_을 구축합니다. 이 과정에서 1.3 GB의 pack/ 폴더와 그 옆에 2 GB의 maya-exl3.gguf가 생성되었습니다.
- 엔진 설정 파일인
maya-exl3-3.05bpw.json과 실행 스크립트인 run-maya-exl3-3.05bpw.sh를 작성합니다.
중요한 플래그들:
--model EXL3-3.05bpw: Maya GGUF 대신 turboderp의 EXL3 양자화 모델을 선택합니다.--draft mtp: 모델 자체의 MTP 블록으로 초안(draft)을 작성합니다. 다른 옵션인 DFlash2 drafter도 있지만, 라이선스가 CC BY-NC-ND 4.0(비상업적 용도로만 사용 가능)이라 제외했습니다.--no-vision: 이미지 인코더를 건너뜁니다 (이 과정은 10~20분 소요되며 파일 크기는 1.1 GB입니다).--no-start: 시작하지 않고 설치만 하므로, 아래에 보이는 방식으로 나중에 시작할 수 있습니다.
첫 실행 전에 설정 수정하기
maya-exl3-3.05bpw.json의 args 배열 안에 두 가지 설정을 추가해야 합니다:
"args": [
"--glm-pack", "/home/you/Models/maya/EXL3-3.05bpw/pack",
"--max-context", "524288",
...
--vram-reserve-mib 3072: Maya의 전문가 풀(expert pool)이 남겨두는 VRAM 용량입니다. 기본값은 700 MiB입니다. 저희 데스크톱도 같은 카드를 사용하는데, VRAM이 가득 차면 화면 깜빡임 현상이 발생했기 때문에 모든 곳에 3 GB를 여유 공간으로 확보했습니다.--max-context 524288: GLM-5.3-Flash는 최대 100만 토큰까지 지원하므로, 이는 RoPE 스케일링(rope scaling)이 아니라 단순히 더 큰 제한치입니다. --kv-streaming on을 사용하면 추가 컨텍스트 비용이 VRAM이 아닌 RAM에 발생합니다 (Maya가 디스크에 저장한 세션 크기를 고려할 때 토큰당 약 13 KB 정도).
새로운 --setup 실행은 이 파일을 다시 작성합니다. Maya 문서에서는 설정(reserve 등)을 유지한다고 하지만, 만약을 대비해 백업본을 보관하는 것이 좋습니다.
셸 메모리 제한 외부에서 시작하기
Maya는 전문가(expert) 계층을 위해 대부분의 여유 RAM을 점유합니다. 이 장치에서는 약 4~5 GB가 남습니다. 이는 두 가지 Linux 기본 설정과 충돌합니다:
- 메모리 제한이 있는 systemd 범위 내의 셸입니다. 저희 에이전트의 터미널 범위는
memory.max가 4 GiB로 설정되어 있어, 여기서 시작된 큰 프로세스는 스왑(swap) 메모리로 이동하게 됩니다.
- Omarchy가 사용자의
app.slice에 활성화하는 systemd-oomd입니다. 이는 메모리 압력이 50%를 초과한 cgroup을 20초 후에 종료시키는데, 모델이 로드되는 동안 RAM을 고정(pinning)하는 작업이 정확히 이를 유발합니다.
따라서 저희는 메모리 제한 없이 별도의 슬라이스에서 시작합니다:
systemd-run --user --scope --collect --slice=llm.slice \
--unit="maya-$(date +%s)" -p MemoryMax=infinity \
./run-maya-exl3-3.05bpw.sh --plain
--plain 옵션은 출력을 Maya의 전체 화면 대시보드 대신 일반 텍스트로 유지하여 로깅하기가 더 쉽습니다. 중지하려면 systemctl --user stop 'maya-*.scope'를 사용하세요. 시작하는 데 몇 분이 걸립니다. 그 후 다음 명령을 실행합니다:
curl -s http://127.0.0.1:8080/v1/models
curl -s http://127.0.0.1:8080/v1/chat/completions \
...
대시보드는 http://127.0.0.1:8080/#monitor에서 확인할 수 있으며, 디코드(decode) 및 프리필(prefill) 속도, VRAM 히트율, 그리고 전문가(experts)가 어디에 위치하는지 보여줍니다. 서버는 127.0.0.1에 유지하세요. 만약 네트워크로 열 경우, --api-key와 함께 --host 0.0.0.0을 사용해야 합니다.
보정(Calibrate)
Maya의 보정은 CPU와 PCIe 링크 간의 작업 분배 방식과 사용할 CPU 스레드 수를 측정합니다:
./maya.sh --calibrate --no-start
이 명령어는 전체 모델을 로드하므로, Maya를 중지한 상태에서 서버 실행 시와 동일하게 (즉, llm.slice 내에, 메모리 제한 없이) 실행해야 합니다. GPU의 VRAM 사용량이 1 GiB를 초과하면 작동을 거부하는데, 이는 다른 엔진이 로드되는 것을 방지하기 위함입니다. 같은 카드에 데스크톱만 올려도 이미 약 2 GB가 소요되므로, 저희 장치에서는 시작조차 할 수 없었습니다. 저는 maya.py의 busy_gpus() 함수에서 해당 임계값을 1024 MiB에서 3072 MiB로 로컬 패치를 적용했습니다. 이는 로컬 수정 사항이므로, 업데이트 후 매번 확인하고 다른 무거운 작업이 카드에 없다는 것이 확실할 때만 사용하세요.
캘리브레이션은 약 10분이 소요되었습니다 (Maya는 10~15분 추정). 저희 장비에서의 전체 출력 결과는 다음과 같습니다:
the engine's own split (PCIe share 0.60): 23.7 tok/s
PCIe share 0.00: 21.1 tok/s
PCIe share 0.10: 24.6 tok/s
...
결과는 설정 파일의 환경 변수로 저장됩니다. 스윕(sweep) 과정에서 PCIe 공유율 0.10이 엔진 자체 분할보다 약 4% 높은 성능을 보였고 (24.6 대 23.7), 확인 실행에서는 25.7을 측정했습니다. CPU 스레드가 16개 미만으로 적으면 성능 저하가 매우 심합니다.
벤치마크(Benchmarks)
측정 방법: OpenAI 엔드포인트에 대한 클라이언트 측 스트리밍 벤치입니다. 설정당 8회 실행을 진행했으며, 약 400단어 분량의 네덜란드어 산문 프롬프트와 코딩 프롬프트(테스트가 포함된 이진 탐색)를 번갈아 사용했습니다. 디코딩은 그리디 디코딩(greedy decoding)을 사용했고, 출력 토큰 수는 512개였으며 중앙값(median)을 보고했습니다. 프리필(Prefill)은 주어진 프롬프트 길이에서 니들-인더-헤이스택 테스트(needle-in-a-haystack test)를 통해 측정되었습니다. 니들과 필러 텍스트는 길이에 따라 고정되며, Maya는 프롬프트 접두사(prompt prefixes)를 캐싱합니다 (디스크에도 저장되어 재시작 간에 유지됨). 따라서 후속 실행은 이전 실행의 영향을 받을 수 있으니 프리필 숫자는 근사치로 읽어주십시오. 이 외에는 장비에서 무거운 작업을 수행하지 않았습니다.
| Maya, EXL3 3.05 bpw | Decode (tok/s) | Dutch prose / code | Prefill | Needle | VRAM peak |
|---|
| 128K context | 26.3 | 30.4 / 21.9 | 2,165 tok/s at 126K | found | 31.4 GiB |
| ... | | | | | |
첫 두 행은 기본 예약 메모리(default reserve) 700 MiB로 실행되었으며, VRAM 피크가 31.8 GiB 카드 경계에 있음을 알 수 있습니다. 예약 메모리를 3 GB로 설정했을 때는 피크가 29.5 GiB 이하를 유지했습니다. 506K 토큰을 읽는 데 262초가 걸렸습니다. 512K에서 디코딩 속도는 262K와 동일하게 빨랐는데, 이는 KV 캐시(KV cache)가 RAM으로부터 스트리밍되기 때문입니다.
동일한 장비의 TabbyAPI와 비교했을 때: 더 작은 sc_2.60 양자화 모델(TabbyAPI 서버 로그 기준 25.5)과 비슷한 디코딩 속도를 보였으며, 더 큰 양자화 모델에서는 프리필 속도가 약 1.7배 빠르고 컨텍스트 길이는 두 배였습니다.
참고로, Maya의 README에는 Ryzen 9 7950X와 DDR5 96GB를 사용하는 RTX 5090에서 Maya 자체의 Maya-M quant을 사용했을 때 '30+ 토큰/초'가 나열되어 있습니다. 이는 다른 quant이며 다른 벤치마크이므로 수치를 일대일로 비교하지 마십시오.
품질 검사 (Quality check)
저희는 Qwen 설정을 위해 사용했던 다섯 가지 코딩 작업에 대해 숨겨진 테스트를 진행했습니다: 각 3회 시도, 사일로(sandboxed) 환경, 중간 수준의 추론 노력(reasoning effort medium), 그리고 각 서버의 기본 샘플링 방식(Maya 온도 1.0 및 top_p 0.95, Strata greedy, TabbyAPI 온도 0.7)을 사용했습니다.
| 모델 및 실행 시간 | 통과 | 테스트 케이스 | 작업당 초 | 디코드 (Decode) |
|---|
| Qwen3.8-Flash-Next UD-Q5_K_XL, Strata | 15 / 15 | 480 / 480 | 42 | 67 |
| ... | | | | |
유일하게 놓친 것은 인시던트 보고서(incident-report) 작업의 한 시도에서 발생한 잘못된 JSON 형식(후행 쉼표, trailing comma)이었습니다. 모든 코드 작업은 통과했습니다. 이 테스트들은 어떤 모델이 더 똑똑하다고 말하기에는 너무 쉽습니다. 하지만 이것들이 보여주는 것은 데스크톱 환경의 3비트 GLM으로도 작동하는 코드를 생성할 수 있다는 점이며, 느린 디코드(decode) 때문에 작업당 시간이 약 1.5배 걸린다는 것입니다.
우리가 직면했던 문제점 (Pitfalls we ran into)
다른 것을 옆에 놓을 수 없습니다. Maya는 RAM이 약 45GB 남을 때까지 고정하고 VRAM의 2930GB를 차지합니다. 따라서 다른 모델 실행 환경, 게임 또는 GPU 마이너를 그 옆에서 돌리지 마십시오. 모델을 전환한다는 것은 하나를 중지하고 다른 것을 시작하는 것을 의미합니다.
중지 후 VRAM이 돌아오기를 기다리세요. 실행 환경이 멈춘 후 VRAM이 복구되는 데는 몇 초가 걸립니다. 너무 일찍 다음 것을 시작하면 VRAM 검사에 실패하거나 더 작은 전문가 풀(expert pool)을 얻게 됩니다.
불안정한 RAM은 다운로드를 손상시킵니다. 저희의 6,000 MT/s EXPO 프로파일에 맞춰진 네 개의 DIMM이 안정적이지 않았습니다: 커널 oopses, 충돌 등이 발생했고 그 시간 동안 작성된 모델 다운로드 중 대부분이 손상되었습니다. 현재는 5,600 MT/s를 사용합니다. Maya는 자체적으로 SHA-256을 사용하여 다운로드를 확인하므로, 여러분이 직접 가져오는 모든 파일도 동일하게 수행하십시오.
새로운 프롬프트로 측정하세요. 반복되는 긴 프롬프트는 접두사 캐시(prefix cache)에 영향을 줍니다. 저희의 한 테스트에서는 정확히 그 이유 때문에
추론 노력 및 샘플링. 설정(Setup)에서는 서버 기본값으로 "reasoning_effort": "high"를 온도 1.0, top_p 0.95와 함께 작성했습니다. 25 토큰/초로 장시간 추론하는 것은 누적되므로, 대화형 작업 시에는 클라이언트에서 더 낮은 reasoning_effort 값을 보내는 것을 고려하십시오. Qwen 설정에서는 medium이 자체 벤치마크에서 가장 좋은 점수를 기록했으며, GLM의 경우 아직 측정하지 않았습니다.
어떤 설정을 언제 사용할 것인가
현재 이 한 대의 장비에서 대규모 모델을 실행하는 세 가지 방법이 있으며, 시작 및 중지 스크립트를 통해 전환합니다:
- Strata에서 Qwen3.8-Flash-Next UD-Q5_K_XL: 초당 약 79 토큰, 512K 컨텍스트로, 코딩 및 에이전트 작업에 대한 우리의 일일 기본 설정입니다.
- TabbyAPI에서 Qwen3.8-Flash-Next EXL3 4.05 bpw: 서버 로그 상으로는 초당 약 68 토큰이며, 262K 컨텍스트를 지원합니다.
- Maya에서 GLM-5.3-Flash EXL3 3.05 bpw: 초당 약 25 토큰으로, 두 번째로 크고 더 큰 모델이 문제에 접근해야 할 때 사용하는 512K 컨텍스트의 321B 모델입니다.