GLM 5.3 flash (Maya-S24) 모델을 X79 UD3 메인보드 2개에 클러스터링하여 8x RTX 3060에서 42 tok/s 달성
요약
본 글은 GLM-5.3-Flash 모델을 두 개의 분리된 X79 워크스테이션에 레이어 분할(two-box layer split) 방식으로 클러스터링하여 구동하는 방법을 제시합니다. Box A가 초기 레이어를, Box B가 후반부 레이어와 헤드를 담당하며, 은닉 상태만 1 GbE 링크를 통해 전송됩니다. 이 아키텍처는 단일 GPU 박스 대비 높은 성능을 달성했으며, 디코딩 시 38~42 tok/s의 속도를 기록했습니다.
핵심 포인트
- 모델 레이어를 두 개의 물리적 박스로 분할하여 구동하는 방식을 구현함.
- X79 보드와 RTX 3060 8개 GPU를 사용했으며, NVLink나 P2P 없이 일반 네트워크로 연결됨.
- 은닉 상태(hidden state)만 전송하며, 토큰당 약 25 KB의 데이터가 링크를 가로지름.
- 디코딩 속도는 38~42 tok/s를 달성했으며, 프롬프트 읽기는 ~1,100 tok/s 기록.
이전 게시글의 후속 내용입니다. 결론적으로, 이미 작은 4-GPU 박스 두 개를 가지고 있기 때문에 큰 DDR3 워크스테이션 보드는 돈값을 하지 못한다는 것을 알게 되었습니다. 그래서 저는 이 두 개의 박스가 하나처럼 작동하도록 만들었습니다. 요약하자면: Project Maya에 두 박스를 연결하는 레이어 분할(two-box layer split)을 추가했습니다. Box A는 레이어 0–23을 실행하고, Box B는 레이어 24–44와 헤드(head)를 실행합니다. 오직 은닉 상태(hidden state)만 네트워크를 가로지르며, 토큰당 약 25 KB입니다. GLM-5.3-Flash (Maya-S24) 모델은 두 개의 오래된 X79 박스에 분산된 8× RTX 3060에서 디코딩 시 38–42 tok/s, 30K 컨텍스트에서 프롬프트 읽기 시 약 1,100 tok/s, 에이전트 한 번의 턴(agent turn)당 6–7초를 기록합니다. 이 성능은 단일 8-GPU 박스에서 달성한 코딩 에이전트 벤치마크 점수 48/48과 동일합니다.
코드: https://github.com/0xluk/project-maya/pull/1 (Maya v1.1.50 기반의 two-box-split 브랜치; 사용법은 docs/TWO-BOX-SPLIT.md 참고)
설정: X79 보드(Ivy/Sandy Bridge, DDR3, PCIe 3.0) 두 개를 준비하고, 각각에 4× RTX 3060 12 GB를 장착했습니다. NVLink나 P2P는 사용하지 않은, 전용 마이닝 리그입니다. RAM은 Box A에 20 GB, Box B에 32 GB가 있습니다 (자세한 내용은 아래 참조). 두 박스 사이에는 일반 스위치로 연결된 1 GbE 링크를 사용했습니다.
Project Maya v1.1.50 + 제가 패치한 내용, Maya-S24 양자화(quant), 128K 컨텍스트, MTP 추측 디코딩(speculative decoding) 활성화 상태입니다. GPU는 130 W로 제한했습니다. 또한, PSU가 언락된 부하를 좋아하지 않아 한 박스는 클럭을 1500 MHz로 고정했습니다.
작동 방식 (간단 요약): Box A(앞쪽)는 OpenAI/Anthropic과 호환되는 API, 토크나이저(tokenizer), 임베딩(embedding), 그리고 레이어 0–23을 자체의 4개 GPU에서 실행합니다. Box B(뒤쪽)는 레이어 24–44, MTP 초안 블록(draft block), 출력 헤드(output head), 그리고 샘플러(sampler)를 자체의 4개 GPU에서 실행합니다. 생성되는 토큰당 잔여값(residual, 4×4096 값)이 링크를 한 번 가로지릅니다. fp32 → bf16 → 무손실 패킹은 약 25 KB이며, 1 GbE 상에서 약 0.3 ms가 소요됩니다. Box B는 토큰 ID를 샘플링하여 전송하고, MTP 추측 디코딩은 이 링크를 통해 파이프라인 처리됩니다. 프롬프트는 512-토큰 조각으로 잘려져 모든 8개 GPU를 한 번에 통과합니다. 각 조각은 자체 스레드에서 링크를 한 번 가로지릅니다 (~12 MB).
보안: 이 링크에는 양방향 IP allowlist와 HMAC-SHA256 도전 응답(challenge-response)이 적용되어 있으며, API 키가 필요합니다.
패치 크기: 약 1,900줄이며, 그중 약 1,100줄은 링크 자체에 관한 내용입니다.
--role 없이 엔진은 변경되지 않았습니다. 결과 (1개의 대화) 지표: 두 개의 박스(본 시스템) | 하나의 박스, 8× 3060 (임대, 동일 양자화): 디코드(Decode), 짧게는 38–42 tok/s, 42–45 tok/s. 약 30K 컨텍스트에서의 디코드: 33–37 tok/s (측정 안 됨). 프롬프트(Prompt), 30K 토큰: ~1,100 tok/s, ~1,050 tok/s. 에이전트 턴(~긴 대화에서 2.4K개의 새 토큰): 6–7초, 5.0–5.3초.
코딩 에이전트 벤치마크 (실제 레포지토리 작업 5개, 숨겨진 테스트 48개): | 설정 | 점수 | 시간 |
| :--- | :--- | :--- |
| 두 개의 박스, Qwen Code | 48/48 | 22.9분 |
| 두 개의 박스, DeepSeek Harness | 48/48 | 17.8분 |
| 8× 3060 하나의 박스, Maya-S, Qwen Code | 48/48 | 21.3분 |
| Qwen3.8-Flash-Next on 2× 3060 (Strata), Qwen Code | 48/48 | 23.2분 |
두 에이전트 모두 구문 오류가 있는 도구 호출은 없었습니다. 원샷(One-shot) 하드 스위트 (10개 작업, 각 요청당 하나, 도구 없음, 사고 및 추론 포함 32K 출력 제한): 6/10 전체 통과, 테스트의 67%를 달성했습니다. 비교 대상: Opus 5.5는 9/10을 기록했으며, 같은 양자화(quant)로 8-GPU 박스에서는 7/10, Flash-Next는 6/10이었습니다. 통과한 작업: json_patch, fixbug_calc, event_scheduler, csv_rfc4180, c_utf8, singleflight_cache. 실패한 4개 중 3개는 잘못된 코드가 아닌 예산(budget) 문제였습니다: regex_engine, lisp_interp 및 c_bigint의 경우 모델이 32K 토큰에 도달했을 때 여전히 사고하고 있었기 때문에 아예 코드가 출력되지 않았습니다. 실제 실패 지점은 c_json_canon이었으며, 31개 테스트 중 22개가 통과했고 유니코드 이스케이프 처리(Unicode escape handling)에서 누락이 발생했습니다. 다음 단계: 컨텍스트가 허용하는 64K 제한으로 세 가지 제한된 작업을 재실행할 것입니다.
진짜 병목 현상은 네트워크가 아니라 RAM이었습니다. 박스당 16GB의 경우, VRAM에 맞지 않아 떨어진 전문가(experts)들이 모든 프롬프트 청크마다 저렴한 SATA SSD에서 로드되었고, 그 결과 30K 프롬프트에서 턴(turn) 시간이 31초, tok/s는 173을 기록했습니다. 20GB + 32GB로 늘리자 SSD 읽기 작업이 없어지면서 턴 시간은 6–7초, tok/s는 1,100을 달성했습니다. 네트워크 비용은 디코드의 약 1~2%, 턴(turn)의 약 3%를 차지합니다.
버그가 아닌 정확도 관련 우려 사항이었습니다. 단일 프로세스 참조와 비교했을 때, 분할된 시스템은 KL 다이버전스가 ~1.6e-2 및 top-1 정확도가 ~95%를 보였으며, 저는 이 분할 버그를 찾는 데 상당한 시간을 할애했습니다. 결국 한 대의 머신에서 단일 프로세스로 실행하더라도 RAM 티어 크기나 프롬프트 청크 크기를 변경하는 것만으로 동일한 양(KL 1.1–2.5e-2)만큼 이동한다는 것을 알게 되었습니다.}
상위 8개 전문가 선택(top-8 expert choice)에서의 근접한 동점은 반올림 노이즈에 따라 변동됩니다. 분할 지점은 그 오차 범위 내에 있습니다. 하드웨어 문제: 새로운 PSU는 최대 4×130 W가 풀려나갔을 때 전원이 꺼졌으며, 이로 인해 해당 장치는 클럭 잠금(clock-locked) 상태를 유지합니다. 두 개의 GPU는 전원 손실 재부팅 후 PCIe x8/x16 대신 PCIe x4에서 작동하는 경우가 있었습니다. 저는 성능 저하된 링크에서는 엔진을 시작하지 않는 부팅 확인 기능(boot check)을 추가했습니다. 중요했던 튜닝: 모든 8개 GPU가 중첩되도록 512 토큰 프롬프트 조각을 사용한 결과, 각 턴당 약 1초의 시간이 소요되었습니다. 마지막 GPU에는 헤드와 MTP 블록이 함께 실려 있어 레이어 수가 적습니다. 전체 KV 캐시를 VRAM에 유지했습니다. 도움이 되지 않은 것: 더 큰 프롬프트 청크는 20 GB 용량 장치를 SSD 읽기 작업으로 밀어냈습니다. 제가 건너뛴 것: 10 GbE NIC입니다. 이는 PCIe 2.0 x1 슬롯에 위치할 것이며, 어차피 링크가 병목 현상을 일으키지 않습니다. 다음 계획: 하나의 케이스에 x1 라이저를 사용하여 5번째 3060을 추가할 것입니다. 그러면 모든 전문가(experts)가 VRAM에 들어갈 수 있게 되어, 턴당 시간이 약 5초로 늘어날 것으로 예상됩니다. 현재 Maya 릴리스에 기반하여 재구축하고 있습니다. 질문에 기꺼이 답하겠습니다. 만약 24 GB 카드를 가진 두 개의 케이스를 가지고 계신 분이 있다면, 그 수치를 보고 싶습니다. submitted by /u/alexlucaci [link] [comments]
AI 자동 생성 콘텐츠
본 콘텐츠는 Reddit AI Engineering의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기