
Dual Nvidia RTX 3090에서 실행한 Z.ai의 Local GLM 4.7: 더 똑똑한 모델이 잘못된 선택이 될 때
요약
Nvidia RTX 3090 듀얼 구성 환경에서 Zhipu의 GLM 4.7 모델을 로컬로 실행하며 성능을 테스트한 결과입니다. MoE 구조와 메모리 최적화 기술에도 불구하고, GPU 간 낮은 인터커넥트 속도가 컨텍스트 길이에 따른 생성 속도에 미치는 영향을 분석합니다.
핵심 포인트
- GLM 4.7은 MoE 구조를 통해 효율적인 파라미터 활용을 목표로 함
- GPU 간 낮은 데이터 전송 속도(1.4GB/s)가 성능 병목의 주요 원인
- 컨텍스트 길이가 길어질수록 모델의 생성 속도 저하 양상이 다름
- 로컬 환경에서는 모델의 품질만큼이나 하드웨어 효율성이 중요함
집에서 모델을 실행하면 모델에 대해 던지는 질문 자체가 달라집니다. 호스팅된 콘솔(hosted console)에서는 타인이 실리콘(silicon) 비용을 지불하기 때문에 오직 품질만을 느끼게 됩니다. 하지만 직접 소유한 기기에서는 그 실리콘이 곧 청구서가 되므로, 모든 모델은 "좋은가"라는 질문보다 더 직설적인 질문, 즉 "당신이 점유하고 있는 그래픽 카드의 가치를 할 만큼의 효용이 있는가"라는 질문에 답해야 합니다. 이것이 제가 두 개의 Nvidia RTX 3090에서 Zhipu의 GLM 4.7이라는 특정 모델에 이 질문을 던졌을 때 일어난 일이며, 답변을 듣던 도중 상황이 반전되었습니다.
홈 랩(home lab)이 모델에 실제로 요구하는 것
저는 GPU를 대여하는 대신 소규모 GPU 스택을 계속 가동하고 있습니다. 따라서 모델은 단순히 분위기(vibes)만으로 승리할 수 없습니다. 유용한 토큰(token)당 비용이 옆에 이미 로드되어 있는 대안보다 저렴해야 합니다. GLM 4.7은 흥미로운 후보입니다. 이 모델은 전문가 혼합(Mixture-of-Experts, MoE) 구조로 설계되었으며, 서류상으로는 약 300억 개의 파라미터(parameters)를 갖지만 토큰당 실제로 작동하는 것은 약 30억 개뿐이며, Multi-head Latent Attention이라고 불리는 메모리 트릭으로 감싸져 있습니다. 이론적으로는 빠르면서도 가벼워야 하는 모델입니다. 지난번 훨씬 성능이 낮은 환경에서 테스트했을 때는 둘 다 아니었는데, 저는 런타임(runtime)이 단순히 latent-attention 연산을 수행하지 못하고 있다는 사실을 깨닫기 전에 모델을 잘못 탓했습니다. 그래서 이번에는 공정한 하드웨어와 공정한 상대에게 기회를 주었습니다.
두 명의 경쟁자, 그리고 카드 사이의 느린 연결
상대는 의도적으로 지루한 모델로 정했습니다. 동일한 크기 범주에 있는 평범한 밀집형(dense), 그룹 쿼리(grouped-query) 모델로, 유행을 타지는 않지만 결코 당신을 놀라게 하지도 않는 그런 종류의 모델입니다. 두 모델 모두 동일한 서버에서 실행되었으므로 인프라(plumbing) 측면에서 어느 한쪽이 유리한 점은 없었습니다. 하드웨어는 미드레인지 데스크톱에 장착된 각각 24GB, 총 48GB의 Nvidia RTX 3090 두 개였습니다. 화려한 인터커넥트(interconnect)는 없었습니다. 두 카드는 제가 약 1.4GB/s로 측정한 링크를 통해 데이터를 주고받는데, 이는 GPU 기준으로 볼 때 매우 느린 속도이며, 이 단조로운 수치 하나가 결국 결과의 절반을 좌우하게 되었습니다.
그래서 저는 이론적인 추측을 멈추고, 수천 토큰부터 12만 8천 토큰에 이르기까지 모든 컨텍스트 길이(context length)에서 두 모델의 속도를 직접 측정했습니다.
생성 속도에는 예측 가능한 임계점이 있습니다
시작부터 GLM 4.7은 매우 짜릿했습니다. 짧은 프롬프트(prompt)에서는 초당 90토큰에 육박하며, 밀집 모델(dense model)보다 두 배 이상 빠른 속도를 보여주었습니다. 하지만 컨텍스트(context)가 채워짐에 따라 속도가 빠지기 시작했습니다. 60대, 40대, 20대로 떨어지더니, 아주 깊은 컨텍스트 영역에서는 10대 중반까지 내려갔습니다. 반면, 밀집 모델은 거의 흥미로운 변화 없이, 잃을 것이 없는 기계처럼 고집스럽게 자신의 속도를 유지하며 일정한 경로를 지켰습니다. 두 곡선은 6만 4천 토큰 부근에서 만났습니다. 이 선 아래에서는 흥미로운 모델이 압도적으로 앞서 나갑니다. 하지만 이 선 위에서는, 아무도 언급하지 않는 그 모델이 조용히 더 빠릅니다.
데모에서는 절대 나타나지 않는 비용
모두가 생성 속도(generation speed)를 벤치마크합니다. 하지만 첫 번째 토큰이 나오기 전까지의 대기 시간, 즉 기계가 사용자의 프롬프트를 삼키는 데 소비하는 시간(프롬프트 인제스션, prompt ingestion)을 벤치마크하는 사람은 거의 없습니다. 긴 입력값의 경우, 이 시간이 실제로 체감되는 대기 시간의 대부분을 차지합니다.
| 컨텍스트 (context) | Zhipu GLM 4.7 | 밀집 모델 (dense model) |
|---|---|---|
| 4K | 2626 tok/s | 979 tok/s |
| ... |
이전과 동일한 실루엣입니다. GLM 4.7은 짧은 프롬프트를 대략 3배 더 빠르게 집어삼키지만, 프롬프트가 길어질수록 그 이점을 잃어버립니다. 그리고 가장 깊은 컨텍스트에 도달하면, 일반적인 모델이 GLM 4.7보다 텍스트를 더 빠르게 흡수합니다. 영리한 모델은 작업의 양쪽 구간 모두에서 단거리 선수(sprinter)와 같지만, 단거리 선수는 긴 경주의 후반부에서 당신이 원하는 유형이 아닙니다.
메모리가 이야기를 거꾸로 뒤집습니다
GLM 4.7을 계속 논의의 중심에 두게 만드는 반전이 여기에 있습니다. 긴 문맥 (long context)의 깊은 단계에서 속도를 희생하게 만드는 바로 그 잠재 어텐션 (latent-attention) 트릭이, 실행 메모리 (running memory)를 이례적으로 작게 유지해 줍니다. 덕분에 단일 24GB 그래픽 카드에서 두 번째 GPU로 넘어가기 전까지 눈에 띄게 더 많은 문맥을 수용할 수 있습니다.
따라서 두 이야기는 서로 반대 방향을 가리킵니다. 속도 측면에서는 밀집 모델 (dense model)이 장기전에서 승리합니다. 메모리 측면에서는 영리한 모델이 승리하며, 하나의 카드에 더 큰 문맥을 담아냅니다. 만약 당신의 문제가 "단일 3090에서 거대한 문서를 유지하는 것"이라면, GLM 4.7은 실질적이고 물리적인 해답을 제공합니다. 다만 그 대가로 생성 속도를 지불해야 할 뿐입니다. 압축된 캐시 (compressed cache)를 사용하여 메모리를 더 줄여보기도 했지만, 실질적인 여유 공간(headroom) 확보 없이 모든 단계에서 속도만 느려지는 역효과가 발생하여 그 아이디어는 포기했습니다.
두 번째 카드가 오히려 속도를 느리게 만들 수 있습니다
가장 직관에 어긋나는 부분은 두 개의 RTX 3090을 동시에 사용하려고 시도했을 때 나타났습니다. 본능적으로는 두 개의 카드가 하나보다 낫다고 생각하기 마련입니다. 하지만 짧은 문맥의 단일 대화에서는 오히려 카드 한 장을 사용하는 것이 압도적으로 승리했습니다. 모델을 두 카드에 분산시키면 모든 토큰 (token)이 1.4GB의 통로를 건널 때마다 통행료를 지불해야 하며, 짧은 프롬프트 (prompt)에서는 이 통행료가 추가 카드로 얻는 이득보다 더 크기 때문입니다.
수학적으로는 컨텍스트 (Context)가 충분히 길어져서 토큰당 작업량이 비용을 압도하는 시점에 비로소 변화가 일어납니다. 그 지점에 도달하면 두 카드로 분할하여 실행하는 것이 모델이 갈구하는 메모리 대역폭 (Memory Bandwidth)을 대략 두 배로 늘려주며, 두 카드의 조합이 앞서 나가기 시작합니다. 그리고 채팅을 멈추고 대중에게 서비스를 제공하기 시작하는 순간, 이것은 더 이상 경쟁의 문제가 아닙니다. 여러 스트림 (Streams)에 걸쳐 배치 (Batched) 처리했을 때, 두 카드는 합계 초당 약 500 토큰에 육박하는 처리량 (Throughput)을 밀어붙였으며, 이는 카드 한 장이 단독으로 처리하는 양보다 몇 배나 높은 수치입니다. 따라서 "내 하드웨어를 모두 사용하라"는 조언조차 결국 상황에 따라 다르다 (it-depends)는 결론으로 귀결되었습니다.
내가 실제로 간직하게 된 의사결정 트리
나는 거의 무례할 정도로 흥미롭지 않은 결론을 내리며 마무리를 지었습니다:
- 짧고 빠른 응답, 키보드 앞에 앉은 한 사람: Zhipu의 GLM 4.7을 단일 카드에서 실행하세요. 이것이 진정으로 더 빠릅니다.
- 긴 단일 사용자 컨텍스트: 지루한 밀집 모델 (Dense Model)을 여전히 단일 카드에서 실행하세요. 그것이 더 빠르고 단순합니다.
- 실제 트래픽 서비스: GLM 4.7을 두 개의 RTX 3090에 분할하여 처리량 (Throughput)을 확보하세요.
전체적인 챔피언은 없습니다. 오직 작업의 형태에 따른 정답만이 존재할 뿐이며, 중요한 기술은 당신이 실제로 어떤 작업을 수행하고 있는지에 대해 정직해지는 것입니다. 나는 빠른 모델과 신뢰할 수 있는 모델을 나란히 두고, 작업이 보상하는 쪽을 선택합니다. 이것이 바로 리더보드 (Leaderboards)가 구조적으로 당신에게 알려줄 수 없는 부분입니다.
저에게 이러한 벤치마킹 (Benchmarking)은 학술적인 영역이 아닙니다. 동일한 두 장의 그래픽 카드는 제가 ModelDirectory에서 구축하는 작은 도구들을 실행하는 데 사용되며, 그중 가장 무거운 작업들은 단일 카드에서 빠른 모델을 사용하는 것이 승리하는 바로 그 단기~중기 GPU 작업들입니다. 즉, 출력 가능한 모델에 실제 디테일을 추가하는 STL upscaler와 프롬프트로부터 텍스트를 입혀주는 STL texture generator가 그러합니다. 출력 방향 및 출력 가능성 체크 도구나 출력 비용 계산기와 같은 가벼운 유틸리티들은 GPU를 거의 가열하지도 않으며, 이미 제가 비용을 지불한 하드웨어에서 이 모든 것을 실행할 수 있다는 점이 '실행(run)이냐 대여(rent)냐'의 계산 결과가 계속해서 '실행'으로 귀결되는 이유의 전부입니다.
다음으로 제가 알고 싶은 것은, 64,000 토큰의 교차점 (Crossover)이 깔끔한 합성 데이터 (Synthetic data)가 아닌 실제 긴 워크로드 (Workloads)와 접촉했을 때도 유지되는지 여부입니다. 이를 위해서는 더 나은 테스트 장비 (Test rig)가 필요하며, 그것이 제가 다음에 향할 곳입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기
