나눗셈 한 번으로 모델 후보 절반을 걸렀다
DGX Spark의 메모리 대역폭을 실측하니 231GB/s. 활성 파라미터로 나누면 디코드 상한이 나오고, dense 모델은 계산만으로 전부 탈락했다
DGX Spark는 로컬 LLM을 돌리려고 산 장비다. 지금 올려 둔 모델보다 나은 게 있는지 계속 검색시키다 보니 후보 목록만 길어졌고, 그 사이 값에 비해 성능이 너무 안 좋다는 불만도 같이 쌓였다. 그래서 모델을 더 고르기 전에 왜 느린지부터 재기로 했다.
하려던 것
돌아온 날부터 “지금 쓰는 Gemma 4 26B-A4B보다 나은 모델이 있나”를 계속 검색시켰다. 후보 목록이 길어졌다. 27B, 33B, 35B, 122B. 이름만 보면 다 좋아 보였다.
그 사이 실망도 쌓였다. 8월 18일 밤에 그대로 던졌다.
이 장비가 사실 엄청 비싼 가격인 것에 비해 LLM 올려서 보여주는 퍼포먼스가 너무 안 좋긴 하다.
Claude Code의 답은 위로가 아니라 숫자였다. 불만이 정당하다는 걸 계산으로 보여줬다.
어떻게 시켰나
느린 이유를 재라고 했다. 메모리 대역폭 실측이 먼저 나왔다. 231GB/s. 스펙 273GB/s의 85%다. GB10은 Blackwell 연산 유닛에 노트북급 메모리가 붙은 구조다. 살 때 본 숫자는 1 PFLOP이었고 쓸 때 걸리는 숫자는 231GB/s였다.
LLM 디코드는 토큰 하나를 만들 때마다 활성 파라미터 전부를 메모리에서 한 번 읽는다. 그래서 상한이 나눗셈 하나로 나온다.
디코드 상한(t/s) = 231GB/s ÷ (활성 파라미터 수 × 파라미터당 바이트)어디서 막혔나
이 계산을 이제야 했다는 게 문제였다. 예전에 31B dense 모델을 올렸을 때 7t/s 언저리에서 벽을 봤다. 그때는 설정 문제라고 생각하고 넘어갔다.
dense 27B를 BF16으로 올리면 토큰당 54GB를 읽는다. 상한은 4.2t/s다. 어떤 설정을 해도 이 위로 못 올라간다. 지금 쓰는 Gemma 4 26B-A4B는 이름의 A4B가 활성 4B라는 뜻이다. 토큰당 8GB만 읽어서 상한이 29t/s다. 같은 26B급인데 상한이 일곱 배 차이 난다.
이 계산 하나로 후보 목록이 반으로 줄었다. 규칙은 단순하다. 이름에 A4B, A3B 같은 활성 파라미터 표기가 없으면 후보에서 뺀다. Qwen3.8-27B, EXAONE-4.5-33B, Muse-Glimmer-30B 같은 dense 모델은 벤치마크 점수를 보기도 전에 탈락했다. Kimi-K3(2.78T), GLM-5.2(753B) 같은 것은 4비트로 눌러도 90GB를 넘어 메모리에 안 들어간다. 살아남는 건 활성 파라미터 10B 이하의 MoE뿐이다.
어떻게 풀었나
같은 나눗셈이 이 장비의 강점도 보여줬다. 프리필은 대역폭이 아니라 연산이 병목이라 Blackwell 쪽 숫자가 먹힌다. 실측 약 1,900tok/s. 116,489토큰짜리 문서를 64.9초에 삼켰다. 이 가격대에서 11만 토큰을 1분에 읽는 장비는 흔치 않다.
그래서 이 장비가 잘하는 일의 모양이 정해졌다. 입력이 길고 출력이 짧은 일이다. 공시 요약처럼 입력과 출력 비율이 15:1인 문서 작업은 강점 구간이고, 자유 서술을 길게 뽑는 채팅은 약점 구간이다.
디코드 상한을 넘는 길은 하나뿐이다. 투기 디코딩은 메모리를 한 번 읽고 토큰 여러 개를 검증하기 때문에 나눗셈의 분자를 늘리는 효과가 난다. 전날 MTP를 켜서 실워크로드가 두 배 넘게 빨라진 이유가 이 계산으로 설명됐다.
배운 점
- 모델 고르기 전에 나눗셈부터 한다. 대역폭 ÷ (활성 파라미터 × 바이트). 이 상한을 못 넘는 모델은 벤치마크를 볼 필요가 없다.
- 파라미터 수가 아니라 활성 파라미터 수를 본다. 이름에 A4B, A3B가 붙은 MoE만 이 장비에서 의미 있는 속도가 나온다.
- 스펙표의 숫자와 쓸 때 걸리는 숫자는 다르다. 대역폭은 실측 85%였고, 연산 성능은 디코드에서 거의 쓰이지 않는다.
- 장비의 강점 구간에 일을 맞춘다. 프리필 1,900tok/s, 디코드 30t/s 안팎. 입력이 길고 출력이 짧은 일이 맞는다.
- “왜 느린가”를 재면 불만이 계산으로 바뀐다. 실망은 그대로 남지만 다음에 뭘 할지는 분명해진다.