장비를 처음부터 다시 재기로 했다

sm_121이라는 고아 번호, 6:0으로 이기던 SGLang이 투기 디코딩을 켜자 뒤집힌 표, 공개 벤치 1등이 자체 라벨 데이터에서 진 결과. DGX Spark를 칩·엔진·모델 세 층에서 다시 잰 하루

DGX Spark에서 나흘 동안 설정만 바꿔 가며 튜닝했다. 그런데 4월에 정해 둔 엔진과 모델은 한 번도 의심하지 않은 채 그 위에서만 돌고 있었고, 테스트가 모델 간 차이를 가려낼 만큼 촘촘하지 않다는 지적이 나왔다. 그래서 칩, 엔진, 모델 세 층을 순서대로 다시 쟀다.

하려던 것

나흘 동안 설정을 바꾸며 튜닝했다. 그런데 엔진과 모델 자체는 한 번도 의심하지 않았다. 4월에 정한 vLLM과 Gemma 4 26B-A4B를 그대로 두고 그 위에서만 돌았다.

테스트를 좀 더 확실하게 해야 모델별 차이를 알아낼 수 있는 거 아니야?

이날은 칩, 엔진, 모델 세 층을 순서대로 다시 쟀다.

어떻게 시켰나

칩부터. GB10은 sm_121이다. B200은 sm_100, RTX 50 시리즈는 sm_120이고 커널이 서로 호환되지 않는다. 상류 프로젝트에 GB10 CI가 없다. vLLM에 올라간 GB10 지원 PR은 5개월째 머지되지 않았고 이유는 CI 비용과 시장 크기였다. TensorRT-LLM은 두 릴리스 후보 모두 실패했는데, 파 보니 GB10 문제가 아니라 Gemma 4와의 조합 문제였다. NVIDIA 플레이북에 Gemma가 한 번도 안 나온다. 실질적인 선택지는 vLLM과 SGLang 둘이다. 우리가 CI 역할을 해야 한다는 뜻이고, 검증 스크립트가 59개까지 불어난 이유가 그거다.

엔진. vLLM과 SGLang을 같은 조건(둘 다 투기 디코딩 없음)에서 비교했다.

어디서 막혔나

SGLang이 여섯 항목 전부 이겼다. 단일 23.5t/s 대 19.4t/s, 첫 토큰 0.09초 대 0.18초, 동시 1·2·4·8·16 전부. 표만 보면 갈아탈 이유가 충분했다.

그런데 출하할 구성이 아니었다. 둘 다 투기 디코딩을 켜고 다시 쟀다.

vLLM + MTPSGLang + MTP
단일 디코드42.8t/s40.0t/s
공시 처리량1,323건/h1,072건/h
수치 원문 실재율98.0%98.0%
에이전트 벤치24/2424/24

품질은 완전히 같고 처리량만 19% 차이로 뒤집혔다. SGLang은 곁가지 함정도 있었다. 없는 모델명에 200을 돌려준다. vLLM은 404다. 오타가 조용히 삼켜진다. vLLM에 남기로 하고 0.22.1rc에서 v0.27.1로 올렸다. 공시 처리량이 31% 늘어 1,733건/h가 됐다.

어떻게 풀었나

모델. 후보 중 살아남은 MoE 두 개를 같은 하네스로 쟀다. 판정 기준은 속도가 아니라 공시 요약 서비스에서 쌓아 둔 라벨 13,206건 대비 수치 충실도다.

Gemma 4 26B-A4BQwen3.5-122B-A10BQwen3.6-35B-A3B
단일 디코드39.4t/s13.9t/s41.0t/s
공시 처리량1,733건/h628건/h1,915건/h
수치 원문 실재율97.9%86.8%90.3%
sentiment 일치96%96%83%

Qwen3.6-35B-A3B는 공개 벤치에서 Gemma를 압도한다. MCPMark 37 대 14, OmniDocBench 89.9 대 74.4. 그런데 우리 데이터에서는 출력한 숫자의 10%가 원문에 없다. 띵킹을 켜면 정확해지는데 문서당 62.5초로 Gemma의 네 배다. 빠르면 부정확하고 정확하면 네 배 느리다.

122B는 품질 우위가 실재했다. 리스크 심사에서 “30% 포지션에 3% 손절은 조기 청산 확률이 높다”며 포지션 크기와 손절폭의 불일치를 잡았다. Gemma는 일반론이었다. 그런데 출력 수치의 13%가 원문에 없고 처리량은 3분의 1이다.

두 번 같은 방향이 나왔다. 일반 추론이 강한 모델이 근거 기반 추출에서는 오히려 뒤진다. 공개 벤치가 재는 축과 내가 쓸 축이 다르다. Gemma 4 26B-A4B 유지로 확정했다.

배운 점