R9700에서 35B MoE 모델을 돌려본 기록 - 백엔드, 동시성, MTP를 하나씩 재봤습니다

Vulkan이 이겼고, 동시 슬롯은 4개가 무릎이었고, MTP는 단일 요청에서만 도움이 됐습니다

R9700 구매 후기(새 창)에서 "결과가 나오면 따로 정리하겠다"고 약속했습니다. 이 글이 그 약속입니다.

R9700에서 35B MoE 모델(Qwen3.6-35B-A3B, 활성 파라미터 약 3B)을 돌렸을 때 어떤 설정이 가장 빨랐는지를 재봤습니다. 지금은 메인 카드가 아니라 백업 경로 전용이라, 속도만 검증했고 결과의 품질은 아직 재지 않았습니다.

먼저, 무엇을 무엇과 비교하는지

같은 R9700이라도 모델이 다르면 숫자가 완전히 달라집니다. 앞선 속도 비교 글(새 창)의 R9700 56 t/s는 남이 27B dense 모델로 잰 값입니다. 이 글의 값은 전부 35B MoE 기준이라 서로 직접 비교하면 안 됩니다.

또 하나, 종목당 시간은 처리량 기준으로 통일했습니다. 벽시계 시간을 종목 수로 나눈 값입니다. 이 기준을 흐트러뜨리는 함정 이야기는 아래에서 합니다.

워크로드와 샘플링

종목 하나를 분석하는 데 LLM 호출이 17~18번 일어나는 멀티 에이전트 파이프라인입니다. 튜닝용 픽스처로 쓴 6종목 재생은 105호출, 프롬프트 합계 664,557 토큰이었습니다(호출당 평균 약 6.3k).

프롬프트 길이는 125B 모델 서빙 글(새 창)에서 공개한 프로덕션 통계와 같은 파이프라인이라 평균 약 8.3k, 최대 약 22k 토큰입니다. 입력과 출력 토큰 비율이 대략 6.6:1이라 prefill 비중이 큽니다. 생성은 호출당 4,096 토큰으로 제한했습니다.

샘플링은 temperature 0.7, top_p 0.8, top_k 20, presence_penalty 1.5입니다. 이 프로파일은 원래 샘플링을 지정하지 않고 돌렸고, 09-04의 1차 스윕이 그랬습니다. 09-24 재튜닝은 위 값을 명시해서 돌렸습니다.

"미지정이라 출력이 짧게 나왔던 게 아닐까" 의심해서 두 경우를 비교했는데, 호출당 생성 길이가 1,458 토큰 대 1,436 토큰으로 사실상 같았습니다. 그 가설은 기각했습니다.

세팅

모델은 GGUF Q4_K_M(약 22GB)이고, KV 캐시는 q8_0, flash attention을 켰고, 배치는 -b 4096 -ub 2048입니다. 서빙은 llama.cpp이고 백엔드는 Vulkan과 HIP(ROCm)을 둘 다 빌드해서 비교했습니다.

ROCm은 새로 올리지 않고 우분투 패키지 7.1.x를 그대로 썼습니다. Vulkan이 1순위 후보라 ROCm 업그레이드는 필요 없다고 판단했기 때문입니다.

카드는 전력캡을 210W로 걸었습니다. 팬 소음 때문이고, 5090 옆에서 같은 머신을 공유합니다.

백엔드는 Vulkan이 이겼다

같은 조건(동시 슬롯 3개, MTP 끔)에서 Vulkan은 종목당 188.5초, HIP은 256.5초였습니다. HIP이 1.36배 느렸습니다. 공개된 벤치마크는 "HIP은 prefill, Vulkan은 decode가 강하다"는 방향인데, 제 실제 워크로드(긴 프롬프트를 여러 번 넣는 방식)에서는 전 구간에서 Vulkan이 앞섰습니다.

그 대조는 심지어 Vulkan 쪽 소스가 7주 더 낡은 빌드였는데도 나온 결과입니다. 최신 빌드로 다시 재봐도 방향은 같았고, HIP은 모든 동시성에서 1.3~1.4배 느렸습니다.

동시 슬롯은 4개가 무릎이었다

동시에 처리하는 요청 수(np)를 바꿔가며 합산 decode 처리량을 재봤습니다. 최신 Vulkan 빌드 기준입니다.

4개에서 꺾입니다. 6개와 8개는 처리량 이득이 0이거나 오히려 줄었고, 종목 하나가 끝나는 지연만 슬롯 수에 거의 비례해서 늘었습니다.

실제 프로덕션 입력을 얼려서 재생한 실험에서는 슬롯 4개가 12종목 기준 종목당 172.4초, 100종목 환산 약 4.79시간이었습니다. 슬롯 8개는 177.6초로 이득이 없었고, 거기에 컨텍스트만 두 배로 잡아먹었습니다.

MTP는 단일 요청에서만 도움이 됐다

MTP(투기적 디코딩)는 이 카드에서도 양면이었습니다. 슬롯 1개일 때 초당 133토큰 정도로 잘 나왔습니다. 그런데 동시 슬롯이 2개 이상이 되면 무효이거나 손해였습니다.

동시 슬롯 3개에서 MTP를 켜면 종목당 188.5초가 297.0초로 1.58배 느려졌습니다. 투기 토큰 수용률은 백엔드나 동시성과 상관없이 늘 50% 안팎이었습니다.

이유는 추정입니다. 활성 파라미터가 작은 MoE에서는 동시 요청마다 검증해야 할 토큰이 서로 다른 전문가를 불러서, 검증 배치가 요청 수에 비례해 비싸지는 것으로 보입니다.

두 번 정정한 것

첫째, 슬롯 3개가 최선이라던 결론을 4개로 고쳤습니다. 처음 스윕에서는 슬롯 4개 실험이 끝까지 완주하지 못해서, 완주한 값 중 가장 좋은 3개를 최선이라고 적었습니다. 잠정치를 결론처럼 적은 겁니다.

둘째, 자문에서 나온 "HIP에서는 MTP 수용률이 77~95%"라는 전제가 오독이었습니다. 원 보고는 27B dense 모델에서 동시 요청이 붕괴한다는 내용이었는데, 그걸 반대로 읽은 것이었습니다. 그 전제로 "HIP과 MTP와 슬롯 8개" 조합이라는 발상이 나왔는데, 실측하니 무효였고 오독은 나중에 정정했습니다.

측정에서 크게 헷갈린 것들

종목당 초가 두 종류였습니다. 하나는 처리량 기준(벽시계÷종목 수)이고, 다른 하나는 슬롯 지연 기준(각 슬롯이 종목 하나를 끝낸 시간)입니다. 후자는 전자의 동시 슬롯 수배입니다.

188.5초와 504초를 나란히 놓고 "새 빌드가 퇴행했다"고 오해할 뻔했습니다. 같은 기준으로 맞추면 새 빌드가 오히려 11% 빨랐습니다. prefill이 초당 2,476토큰에서 2,884토큰으로 올랐고 decode는 그대로였습니다.

출력 폭주가 시간을 흔들었습니다. 생성 상한에 걸리는 호출이 한 종목을 두 배 느리게 만들어서 반복 간 변동이 11% 정도 났습니다. 그래서 벽시계만 보지 않고 합산 decode와 prefill 처리량을 같이 봤습니다.

포트가 겹쳐서 표본이 오염됐습니다. 슬롯 6개 실험의 클라이언트 하나가 같은 포트의 슬롯 8개 서버에 아홉 번째 클라이언트로 붙었습니다. 모델 별칭이 달라도 서버가 거부하지 않아서, 그 표본은 버렸습니다.

슬롯 8개에서 순간 속도가 0.6에서 114까지 요동쳤습니다. 버그가 아니라 긴 프롬프트 슬롯의 청크가 배치를 점유하는 구조적 동작이었습니다. 그래서 순간값이 아닌 종목당 초로만 판정했습니다.

품질은 재지 않았다

이 조합(R9700에서 35B MoE)의 결과 품질은 0건 측정입니다. 지금 채택한 건 속도 설정뿐입니다.

9월 28일부터 이 백업 경로가 메인 경로(5090의 27B dense)와 매일 밤 같은 100종목을 동시에 채점합니다. 두 경로의 전방 수익률 상관(forward RankIC)을 나란히 쌓아서 4~6주 뒤에 비교하는 사전등록 실험입니다. 단일 런의 등급은 재현성 노이즈가 크기 때문에, 종목당 여러 번 뽑은 평균 점수를 씁니다.

이 모델의 자기 재현성은 앞선 글(새 창)에서 같은 종목을 세 번 돌린 결과(QWK 평균 0.12, 등급 일치 56~61%)로 이미 공개했습니다. 속도가 빠르다는 것과 신호가 믿을 만하다는 것은 별개의 문제입니다.

5090과 비교하면

같은 모델을 5090에서 vLLM으로 돌릴 때보다 R9700이 약 6.8배 느립니다. 카드 성격이 다르니 놀랄 일은 아닙니다. 그래서 R9700은 메인이 아니라 백업 경로로 두었습니다.

시도하지 않았거나 못 한 것

• Q5_K_M 이상의 양자화는 실측이 없습니다. 문헌 판단만 했습니다
• -b 16384 배치와 슬롯 4개 외의 -ub 스윕은 안 돌렸습니다
• vLLM과 SGLang의 ROCm 빌드는 이 카드에서 검증 안 된 부분이 많아 처음부터 제외했습니다
• MTP를 슬롯 2개 이상에서 Vulkan으로 다시 재보는 것은 제안만 됐고 실행하지 않았습니다

정리하면

지금 백업 경로의 설정은 Vulkan, 슬롯 4개, MTP 끔입니다. 종목당 약 172초, 100종목 기준 약 4.8시간이고, 이 값은 12종목 재생 실험에서 나온 잠정치입니다.

속도는 재봤지만 이 조합의 결과 품질은 아직 한 번도 재보지 못했습니다. 그건 다음 단계에서 메인 경로와 나란히 쌓아서 비교합니다. 27B 모델을 5090 한 장에서 튜닝한 과정은 별도 글(새 창)에 정리했습니다.

5090과 R9700을 한 카드씩 나눠 125B 모델을 함께 서빙해본 이야기는 지난 postmortem(새 창)에 있습니다.