#로컬LLM #DGXSpark #speculative_decoding #Muse_Glimmer #DeepSeek_V4_Flash #benchmark #llama_cpp

내 컴퓨터 안에서만 돌아가는 LLM으로 코딩과 agent 작업이 정말 되는지, 된다면 장비를 한 대 더 사야 하는지. 저희도 그게 궁금해서 이틀 동안 직접 측정했습니다. 여기서 agent라고 부르는 것은 사람이 시킨 일을 AI가 스스로 여러 단계로 쪼개서, 터미널에 명령을 내리고 그 출력을 읽어 다음 명령을 정해 가며 답에 도달하는 방식을 말합니다. 요즘 코딩 도구들이 대부분 이 방식으로 움직입니다.

시험 대상은 새로 나온 모델 두 개에 저희가 쓰고 있던 두 개를 더해 모두 네 개이고, 장비는 DGX Spark 한 대입니다. 같은 고민을 하고 계신다면 아래 숫자를 그대로 가져다 쓰셔도 됩니다. 대신 저희가 어떤 조건에서 쟀는지도 함께 적어 두었으니, 조건이 다르다면 숫자도 다르게 읽으셔야 합니다.

✅ 결론부터

이틀 동안 정한 것은 세 가지입니다.

첫째, agent와 코딩에 상시로 띄워 둘 모델로 Muse-Glimmer-30B를 쓰기로 했습니다. 규모만 보면 이번에 시험한 넷 중 가장 큰 DeepSeek-V4-Flash가 유력한 후보였고 코딩 과제 성적도 나쁘지 않았지만, 뒤에서 말씀드릴 장비 사정과 실제 agent 성적 두 가지가 그쪽을 막았습니다. Muse를 고른 대가는 속도입니다. 지금까지 쓰던 Qwen3.6-35B-A3B는 코딩 과제에서 초당 87~92개의 token을 뽑아내는데, Muse는 초당 25~30개로 Qwen의 3분의 1 수준입니다. 여기서 token은 모델이 글을 만들어 낼 때 한 번에 내놓는 최소 단위입니다. 단어보다 잘게 쪼개질 때도 있고 여러 글자가 하나로 묶일 때도 있어서 언어와 모델마다 달라지지만, 초당 몇 개를 뽑아내느냐가 곧 체감 속도라고 보시면 됩니다. 그런데도 Muse를 고른 이유는, AI가 시스템 안에서 무언가를 알아내려고 터미널에 명령을 직접 내리고 그 출력을 읽어 다음 명령을 정하는 과제에서 거부당하거나 쓸데없이 반복한 명령이 가장 적었기 때문입니다. 같은 여덟 번의 기회를 주었을 때 Qwen은 열세 개의 명령을 내려 그중 여섯 개를 버렸고, Muse는 여덟 개를 내려 하나도 버리지 않았습니다.

둘째, DeepSeek-V4-Flash는 들이지 않기로 했습니다. 성능이 나빠서가 아니라 memory가 모자라서입니다. 이 모델은 원래 크기 그대로 쓰면 저희 장비에 아예 올라가지 않기 때문에, 정밀도를 낮춰 용량을 줄인 버전, 이른바 quantize한 모델을 씁니다. 그렇게 3-bit까지 줄인 버전 하나가 약 97 GiB를 차지합니다. 저희 장비에서 실제로 쓸 수 있는 memory가 121.6 GiB이니, 이 모델을 올리는 순간 나머지 세 모델은 전부 내려가야 합니다. 즉 이것은 하나를 더하는 일이 아니라 셋을 내리고 하나로 바꾸는 일입니다.

셋째, DGX Spark를 한 대 더 사지 않기로 했습니다. 두 대를 케이블로 묶으면 405B 규모의 모델까지 올릴 수 있다는 것은 NVIDIA 문서에 적힌 사실이고, 저희도 그 계산으로 시작했습니다. 다만 이틀 동안 측정해 보니 저희 작업에서 막히는 곳은 모델의 크기가 아니었습니다. 자세한 이야기는 10장에 적었습니다.

하나 더 말씀드릴 것이 있습니다. 이 글을 쓰면서 제일 오래 매달린 것은 모델 순위가 아니었습니다. 저희가 만든 측정 도구 자체가 거짓말을 하고 있던 지점이었습니다. 표를 다 만들어 놓고 나서야 두 군데에서 조건이 다른 값을 나란히 세워 두고 있었다는 것을 알았고, 그것을 바로잡자 글이 향하는 방향이 통째로 바뀌었습니다. 5장과 6장이 그 기록입니다. 순위표만 보러 오셨더라도 그 두 장은 읽어 보시길 권합니다. 남의 benchmark 숫자를 인용하실 때 무엇을 의심해야 하는지에 대한 이야기이기도 합니다.

🧩 측정 대상과 환경

장비는 DGX Spark 한 대입니다. NVIDIA가 만든 소형 AI 장비로, GB10 Grace Blackwell이라는 칩에 128 GB의 통합 memory를 얹었습니다. 통합 memory라는 말은 CPU와 GPU가 memory를 나눠 갖지 않고 같은 공간을 함께 쓴다는 뜻입니다. 덕분에 일반 그래픽카드처럼 “GPU memory 용량이 모자라 모델을 못 올린다”는 제약이 훨씬 완화되지만, 대신 운영체제와 모델이 같은 공간을 나눠 쓰게 됩니다. 128 GB 가운데 실제로 쓸 수 있는 용량은 121.6 GiB입니다.

모델을 돌리는 inference engine으로는 llama.cpp를 썼습니다. 측정에 앞서 이 프로그램을 최신 버전으로 새로 빌드해야 했는데, 뒤에 나오는 draft-dflash 기능이 저희가 쓰던 예전 버전에는 아예 없었기 때문입니다. 정확히는 없어서 느렸던 것이 아니라, 그 기능을 요구하는 모델이 아예 뜨지도 않았습니다.

모델	구조	파라미터	context	측정한 GPU memory
Gemma4-26B-A4B	MoE	25.2B	256K/slot × 2	28,145 MiB
Gemma4-E4B	MoE	7.46B	131K/slot × 2	10,980 MiB
Qwen3.6-35B-A3B	MoE (활성 약 3B)	35B	524K × 1	31,382 MiB
Muse-Glimmer-30B	dense	29.6B + vision encoder 1.8B	131K × 1	20,906 MiB
DeepSeek-V4-Flash	MoE (활성 13B)	284B	1M	3-bit로 줄였을 때 약 97 GiB

표를 읽으실 때 두 가지만 알아 두시면 나머지가 따라옵니다. 하나는 MoE와 dense의 차이입니다. MoE는 모델 안에 전문가 여러 명을 두고 글자 하나를 만들 때마다 그중 몇 명만 깨우는 방식이고, dense는 매번 전원을 깨우는 방식입니다. 그래서 표의 Qwen은 전체 35B이지만 실제로 한 번에 일하는 것은 3B 남짓이라 빠르고, Muse는 29.6B 전부가 매번 일합니다. 작은 모델이 반드시 빠른 것은 아니라는 이야기가 여기서 나옵니다. 다른 하나는 context로, 모델이 한 번의 대화에서 기억할 수 있는 분량입니다. 표의 524K는 약 52만 token까지 담아 둘 수 있다는 뜻이고, slot은 그 기억 공간을 몇 벌 두었는지를 가리킵니다.

표의 memory 값은 카탈로그에서 옮겨 적은 것이 아닙니다. 네 개 모델 server를 한꺼번에 띄우고 대화 기록을 모두 비운 상태에서 장비가 보고하는 값을 직접 읽었습니다. 넷을 더하면 91,413 MiB, 약 89.3 GiB입니다.

이번에 새로 시험한 두 모델을 간단히 소개해 두겠습니다. Muse-Glimmer-30B는 Meta가 8월에 공개한 모델로, 모델 카드에 “distilled from Muse Spark and purpose-built for autonomous agentic tasks”라고 적혀 있습니다. 더 큰 모델을 압축해 만들었고 처음부터 agent 용도를 겨냥했다는 뜻입니다. 앞서 말씀드린 대로 구조가 dense이고, 글뿐 아니라 이미지도 읽을 수 있습니다. DeepSeek-V4-Flash는 총 284B에 한 번에 13B만 활성화되는 MoE이고, context가 100만 token으로 이번 넷 중 가장 깁니다.

🧪 공개 benchmark 대신 우리 버그로 시험을 만든 이유

공개 benchmark 점수라면 이미 모델 카드에 다 적혀 있습니다. 그런데 그 점수는 “이 모델이 세상의 여러 시험에서 몇 점을 받았는가”를 알려 줄 뿐, 저희가 알고 싶었던 “우리 일에 쓸 만한가”에는 답하지 않습니다. 게다가 널리 쓰이는 시험지일수록 학습 과정에서 이미 본 문제일 가능성이 높아집니다. 그래서 시험 문제를 저희가 실제로 겪고 고친 버그로 새로 만들었습니다.

시험은 세 종류입니다.

첫째는 코딩 3과제입니다. 결함이 들어 있는 실제 코드를 주고 원인을 찾게 하고(find_bug), 고칠 코드를 직접 쓰게 하고(write_fix), 그렇게 판단한 근거를 설명하게 했습니다(reason). 셋으로 나눈 이유는, 원인을 찾는 능력과 고쳐 쓰는 능력과 설명하는 능력이 모델마다 다르기 때문입니다.

둘째는 terminal agent 과제입니다. 어떤 포트를 어떤 프로그램이 붙잡고 있는지를 실제 장비에서 알아내게 했습니다. 모델이 종이 위에 답을 쓰는 것이 아니라 실제로 명령을 내리고 그 결과를 봅니다.

셋째는 일반 과제로, 분류와 추론과 한국어 처리입니다.

이렇게 만들면 채점자가 정답을 이미 알고 있다는 장점이 생깁니다. 대신 문제 수가 적어집니다. 저희가 겪은 버그만 쓸 수 있으니 문제를 무한정 늘릴 수가 없습니다. 그 한계는 감추지 않고 11장에 그대로 적어 두었습니다.

📊 코딩 3과제 측정 — 그리고 표가 거짓말할 뻔한 지점

먼저 숫자부터 보시겠습니다. 모든 행이 같은 질문, 같은 temperature(모델이 얼마나 과감하게 답을 고르는지를 정하는 값입니다), 같은 생성 상한에서 나온 값입니다.

모델	과제	걸린 시간(초)	생성 token	tok/s
Qwen3.6-35B-A3B	find_bug	11.5	1,002	87.0
	write_fix	14.9	1,277	85.8
	reason	18.8	1,726	92.0
DeepSeek-V4-Flash (3-bit)	find_bug	15.8	440	27.9
	write_fix	12.7	411	32.3
	reason	33.8	1,092	32.3
DeepSeek-V4-Flash (2-bit)	find_bug	15.7	511	32.5
	write_fix	10.8	392	36.4
	reason	21.9	766	34.9
Muse-Glimmer-30B	find_bug	74.3	2,000 (상한)	26.9
	write_fix	65.7	2,000 (상한)	30.4
	reason	79.7	2,000 (상한)	25.1

이 표를 그대로 읽으면 Muse-Glimmer가 Qwen보다 여섯 배쯤 느린 모델로 보입니다. Qwen은 한 문제에 11.5초에서 18.8초를 쓰는데 Muse는 65.7초에서 79.7초를 쓰니, 그렇게 읽는 것이 자연스럽습니다. 그런데 그렇게 읽으시면 틀립니다.

생성 token 열을 다시 보시겠습니다. Muse-Glimmer만 세 과제가 전부 정확히 2,000입니다. 세 번 다 우연히 같은 분량으로 끝났을 리는 없습니다. 저희 측정 script가 답변을 2,000 token에서 끊도록 되어 있었고, Qwen과 DeepSeek은 그 아래에서 할 말을 마쳤지만 Muse-Glimmer는 세 번 모두 말을 맺기도 전에 잘려 나갔던 것입니다. 그러니까 저 66~80초는 “Muse가 답 하나를 만드는 데 걸린 시간”이 아니라 “저희가 허락한 2,000 token을 채우는 데 걸린 시간”이었습니다.

상한을 풀고 같은 세 문제를 다시 돌렸더니 이 모델이 실제로 쓴 분량은 2,744 / 4,046 / 3,358 token이었습니다. Qwen이 같은 문제에 1,002 / 1,277 / 1,726 token을 썼으니, Muse는 두세 배를 씁니다. 느린 것도 사실이지만, 길게 쓰는 것이기도 했습니다.

같은 측정을 한 번 더 돌렸을 때 Muse-Glimmer의 처리량은 26.7 tok/s에서 26.9 tok/s로 거의 그대로 나왔습니다. 반면 걸린 시간과 생성 token 수는 다시 나오지 않았습니다. 답변 길이가 실행마다 달라지기 때문입니다. 어떤 값이 다시 나오고 어떤 값이 안 나오는지를 미리 나눠 두시면, 나중에 판단하실 때 훨씬 편합니다. 재현되는 값으로는 모델을 비교할 수 있고, 재현되지 않는 값으로는 한 번의 경험을 이야기할 수 있을 뿐입니다.

🔧 terminal agent 측정 — 속도보다 쓸데없는 명령 수에서 차이가 났습니다

두 번째 시험은 종이 위 문제가 아닙니다. 모델이 shell 명령을 하나 고르면 그 명령이 실제 장비에서 실행되고, 모델은 진짜 출력을 돌려받습니다. 그것을 읽고 다음 명령을 정하는 일을 여덟 번 반복할 수 있게 했습니다. 과제는 특정 포트를 어떤 프로그램이 붙잡고 있는지 알아내는 것이고, 정답은 채점자가 이미 알고 있습니다.

안전을 위해 실행할 수 있는 명령을 읽기 전용 allowlist로 제한했습니다. 시스템을 바꾸는 명령은 아예 실행되지 않고, allowlist에 없는 명령을 고르면 거부됩니다. 중요한 것은 거부되었다는 사실이 모델에게 그대로 전달된다는 점입니다. 그러니 거부 횟수는 안전이 잘 지켜졌는지를 보여 주는 값이 아니라, 막혔을 때 이 모델이 어떻게 행동하는지를 보여 주는 값입니다. 좋은 agent는 막히면 다른 길을 찾고, 그렇지 못한 agent는 막힌 명령을 조금 바꿔 또 칩니다.

모델	내린 명령 수	거부된 명령	총 걸린 시간(초)
Qwen3.6-35B-A3B	13	6	8.9
DeepSeek-V4-Flash (3-bit)	13	6	30.9
DeepSeek-V4-Flash (3-bit, 재실행)	18	6	51.7
DeepSeek-V4-Flash (2-bit)	15	6	42.1
Muse-Glimmer-30B (1차)	10	2	44.0
Muse-Glimmer-30B (2차)	8	0	37.1

여기서도 표를 만들다가 하나를 바로잡았습니다. 결과 파일의 항목 이름이 turns_used여서 저는 그것을 “몇 번 만에 끝냈는가”로 읽었습니다. 그런데 코드를 열어 보니 이 값은 turn 수가 아니라 모델이 내린 명령의 개수였습니다. 실제 turn 수는 모든 실행에서 8로 똑같았습니다. 어느 모델도 여덟 번 안에 답에 도달해 일찍 끝내지 못했다는 뜻이고, 그렇다면 모두가 똑같이 여덟 번을 다 쓰고 그 안에 무엇을 남겼는가만이 차이로 남습니다.

그 차이는 꽤 선명합니다. Muse-Glimmer를 뺀 모든 모델이 이 allowlist에 여섯 번씩 걸렸습니다. quant 버전을 바꿔도, 다시 돌려도 여섯 번이었습니다. 반면 Muse-Glimmer는 한 번은 두 번 걸렸고, 다른 한 번은 아예 걸리지 않았습니다. 같은 여덟 번의 기회에서 Qwen은 열세 개의 명령을 던져 여섯 개를 버렸고, Muse는 여덟 개를 던져 하나도 버리지 않았습니다.

Muse-Glimmer만 두 번 돌린 이유를 밝혀 두겠습니다. agent 과제는 한 번 돌려 보고 결론 내리기에는 실행마다 결과가 꽤 달라집니다. 실제로 두 실행이 명령 수로는 2개, 시간으로는 7초만큼 달랐습니다. 두 결과를 모두 표에 실은 것은 그 차이를 감추고 싶지 않았기 때문입니다.

속도만 보시면 Qwen이 8.9초로 압도적입니다. 다른 모델들이 30.9초에서 51.7초를 쓰는 동안 8.9초 만에 끝냈으니 서너 배에서 다섯 배 넘게 빠릅니다. 그렇지만 agent 작업은 명령을 한 번 시도할 때마다 시간이 소비되고, API를 쓰신다면 요금까지 추가됩니다. 그래서 거부당한 시도 횟수가 그대로 비용 낭비가 됩니다. 게다가 잘못 던진 명령은 시간만 쓰는 것이 아니라 모델이 기억할 수 있는 공간, 즉 앞에서 말씀드린 context를 차지하고, 되돌아온 오류 메시지가 다음 판단의 정확도를 떨어뜨립니다. 저희가 측정한 것은 여덟 번으로 끊은 짧은 과제 하나뿐이라 더 긴 작업에서 이 차이가 어떻게 벌어지는지는 확인하지 못했습니다만, 적어도 이 시험에서 차이가 난 것은 속도가 아니라 쓸데없이 반복한 명령의 수였습니다. 저희가 상시 slot을 느린 쪽에 내준 이유가 여기 있습니다.

🧾 차이가 안 난 시험도 싣습니다

세 번째 시험은 분류와 추론, 한국어 처리였습니다. 이 시험의 결과는 이렇습니다.

모델	분류 정답	분류 평균(초)	추론(초)	한국어(초)
Gemma4-26B-A4B	6 / 10	0.19	9.61	3.04
Qwen3.6-35B-A3B	6 / 10	0.22	16.19	1.24
Gemma4-E4B (7.46B)	6 / 10	0.24	7.39	1.03

세 모델이 정확히 같은 점수를 받았습니다. 파라미터가 7.46B밖에 안 되는 모델이 35B짜리와 동점입니다. 이 결과에서 나온 성능을 모델에 대한 평가로 가져가시면 안 됩니다. 이것은 시험 조건에 대한 결과입니다. 이 난이도의 분류 문제로는 이 급의 모델들 사이에 차이를 만들지 못한다는 뜻입니다. 따라서 이 정도 작업만 하신다면 큰 모델이 필요 없다는 것을 보여 주는 결과로 해설할 수 있습니다.

이미지를 읽는 능력도 마찬가지였습니다. 흰 배경에 빨간 숫자 하나와 색이 다른 도형 두 개를 그려 넣은 그림을 만들어 무엇이 보이는지 물었더니, 시험한 세 모델이 모두 숫자와 도형과 색을 정확히 맞혔습니다. 이것은 이미지 인식이 작동한다는 확인이지 품질 비교가 아닙니다. 도형과 큰 숫자는 셋 다 쉬운 문제라 차이가 드러나지 않습니다. 다만 하나는 확인했습니다. vision projector는 그림을 모델이 알아들을 수 있는 형태로 바꿔 주는 부분입니다. Muse-Glimmer만 이 부분이 quantize된 상태로 들어 있어서 혹시 손해를 보는지 궁금했는데, 적어도 이 과제에서는 차이가 없었습니다.

아무 차이도 안 나온 시험을 굳이 싣는 이유가 있습니다. 이런 결과를 빼고 나면 남은 표가 실제보다 정밀해 보이기 때문입니다. 보기 좋은 표를 얻으려고 차이가 안 난 시험을 지우는 순간, 읽는 분은 저희가 실제로 아는 것보다 더 많이 안다고 믿게 됩니다.

⚡ speculative decoding: 13에서 28로, 그런데 남의 측정은 정반대

이번 측정에서 설정 하나로 가장 큰 차이를 만든 것은 모델 선택이 아니라 speculative decoding이었습니다. 우리말로 옮기면 “미리 찍어 보기” 정도가 됩니다. 여기서 미리 찍는 쪽을 draft 모델이라고 부릅니다. 본 모델보다 훨씬 작고 빠른 모델로, 혼자 쓰면 품질이 모자라지만 먼저 찍어 보는 역할에는 충분합니다. 이 draft 모델이 다음에 올 글자 여러 개를 미리 찍어 두면, 크고 느린 본 모델은 그것을 처음부터 만드는 대신 맞는지만 한꺼번에 확인합니다. 맞으면 여러 글자를 한 번에 건지고 틀리면 그 지점부터 다시 만듭니다. llama.cpp에서는 --spec-type이라는 설정으로 방식을 고르고, 공식 문서에 draft-simple, draft-eagle3, draft-dflash, draft-dspark, draft-mtp 같은 이름이 나열되어 있습니다.

Muse-Glimmer-30B에 draft-dflash를 붙이자 초당 13개였던 생성 속도가 28개로 올랐습니다. 두 배가 넘습니다. 설정 한 줄로 이만큼 움직이는 경우는 흔치 않습니다. 같은 계열의 기법인 MTP를 Gemma4-E4B에 붙여 초당 81개를 얻었던 기록은 이 글에 남겨 두었습니다. 다만 그때는 Apple Silicon 장비였고 이번에는 DGX Spark이니, 같은 기법이라 해도 수치를 그대로 옮겨 읽으시면 안 됩니다.

그런데 같은 기법을 두고 정반대의 결과를 공개한 실측이 있습니다. thc1006(蔡秀吉)이라는 분이 RTX 3090 그래픽카드에서 speculative decoding 설정 19가지를 전부 돌려 보고 내린 결론은 어느 것도 기준보다 빠르지 않다였습니다. 남의 이야기로 넘길 수가 없었던 것은, 그가 시험한 모델이 Qwen3.6-35B-A3B, 그것도 저희가 지금 쓰고 있는 것과 같은 quant 버전이었기 때문입니다.

설정	tok/s	기준 대비
기준(speculative decoding 없음)	139.9	—
draft-min 48 / draft-max 64	85.6	−39%
DFlash (최선 설정, draft-max 8)	77.0	−44.6%
draft-min 2 / draft-max 32	65.0	−54%

이 표에는 저자의 재측정본 수치만 실었습니다. 그는 처음 공개한 표에서 일부 설정이 초당 120개 안팎으로 나왔다고 적었다가, 뒤이은 재측정에서 그 값이 “서로 다른 두 구간이 섞인 평균”이었다고 스스로 정정했습니다. 그렇다면 인용하는 쪽도 정정된 값만 쓰는 것이 맞습니다.

정리하면 같은 이름의 기법으로 저희는 두 배 넘게 빨라졌고 그는 절반 가까이 느려졌습니다. 그가 지목한 원인은 MoE의 전문가 saturation입니다. 앞에서 MoE는 글자마다 전문가 몇 명만 깨운다고 말씀드렸는데, 미리 찍어 둔 글자 하나하나가 저마다 다른 전문가를 부릅니다. 그러면 확인하는 단계에서 그 전문가들을 전부 memory 위로 끌어올려야 하고, 데이터를 옮기는 속도가 병목인 장비에서는 그 비용이 미리 찍어서 아낀 시간을 넘어선다는 설명입니다.

그는 이후 자기 주장의 적용 범위를 좁히는 정정도 함께 올렸습니다. 이 결과는 llama.cpp의 draft-spec 계열과 4-bit로 줄인 모델, 소비자용 Ampere 세대 그래픽카드에서만 해당하며, 다른 프로그램의 MTP 방식에서는 오히려 27.5% 개선이 나왔다는 내용입니다. 자기 결과가 어디까지만 통하는지를 스스로 좁혀서 밝히는 기록은 흔하지 않습니다. 그래서 인용할 값이 있다고 판단했습니다.

💾 memory가 판단을 대신했습니다

DeepSeek-V4-Flash는 이번에 시험한 모델 가운데 덩치가 가장 큽니다. 총 284B에 한 번에 13B가 활성화되는 MoE이고, 한 번의 대화에서 100만 token까지 기억합니다. 앞의 표에서 보셨듯 코딩 과제 성적도 나쁘지 않았습니다. 그래서 시험을 시작할 때만 해도 저희는 이 모델을 새 주력으로 삼게 될 것이라고 생각했습니다.

걸린 것은 크기였습니다. 앞서 말씀드린 대로 이 모델은 원래 크기 그대로는 저희 장비에 올라가지 않아서, 정밀도를 낮춰 quantize한 버전을 씁니다. 3-bit까지 줄인 버전 하나가 약 97 GiB를 차지합니다. 저희 장비에서 쓸 수 있는 memory가 121.6 GiB이니, 이 모델을 올리는 순간 나머지 세 모델은 전부 내려가야 합니다.

이 한 줄이 속도 비교보다 결정에 더 크게 영향을 줬습니다. 저희 작업에서 네 모델은 저마다 다른 일을 맡고 있습니다. 큰 모델은 어려운 추론을, 중간 모델은 코딩을, 작은 모델은 분류와 태깅을 맡습니다. 하나를 올리려고 셋을 내리는 것은 남는 하나가 셋의 역할을 전부 더 잘해 낼 때만 이득인데, 4B급 모델이 하던 단순 분류를 284B 모델에게 맡기는 것은 개선이 아니라 낭비입니다. 앞 장에서 7.46B 모델이 35B 모델과 동점을 받은 결과가 여기서 다시 쓰입니다.

memory를 아끼려고 KV cache의 K 부분을 8-bit로 quantize해 봤는데, 20,906 MiB에서 28,772 MiB로 오히려 늘었습니다. 왜 그런지는 저희도 파악하지 못했습니다. 혹시 같은 시도를 해 보실 분들은 참고하시기 바랍니다. flash attention과 함께 써야 이득이 난다는 설명은 있지만, 저희는 그것도 켤 수 없었습니다. 예전에 켰다가 특정 모델이 로딩 도중 멈춰 버린 적이 있어 이 장비에서는 닫아 두었습니다.

🧮 한 대 더 사면 무엇이 달라지나

두 대를 묶는 것은 실제로 되고, 공식적으로도 지원합니다. NVIDIA 하드웨어 문서에는 한 대에서 최대 200B, 두 대 구성에서는 405B까지 지원한다고 적혀 있습니다. 연결은 장비 뒤쪽의 QSFP 포트를 케이블로 직접 잇는 방식이라, 스위치 같은 장비를 사이에 둘 필요가 없습니다.

다만 대역폭은 광고 문구보다 낮게 잡으셔야 합니다. 포트가 두 개라서 합쳐 400G로 읽히기 쉽지만, 두 장비를 직접 이을 때 실제로 지원되는 속도는 200 Gb/s라는 지적이 있습니다. 두 대에 나눠 올린 모델은 계산 도중 계속 서로 데이터를 주고받아야 하므로, 이 값이 곧 두 대로 묶었을 때의 천장이 됩니다.

가격은 이렇습니다. 국내 가격 비교 site 기준으로 신품이 9,250,000원입니다. 중고 거래에서는 3월에 대당 590만원에 나온 사례가 확인되고, 저희가 처음 살 때는 520만원 수준이었습니다. 세 숫자를 나란히 놓으면 흐름이 보입니다. 이 장비의 값은 시간이 지나면서 내려간 것이 아니라 올라갔습니다. 저희가 쓴 지 반년 된 장비인데 그 사이에 신품 값이 오른 것이고, 전자제품에서 흔한 흐름은 아닙니다. 되팔 때 손해가 적다는 뜻이기도 하지만, 지금 사시는 분에게는 그만큼 비싸게 시작한다는 뜻이기도 합니다.

이 장비를 처음 들일지 검토하던 시점의 비교는 DGX Spark와 MacBook Pro M5 Max를 비교한 글에 정리해 두었습니다. 이번 글은 그 장비를 실제로 반년 굴려 본 뒤의 후속편에 해당합니다.

⚖️ 이 결론이 틀릴 수 있는 지점

위 결론에는 약한 곳이 여럿 있습니다. 저희가 아는 대로 순서대로 적겠습니다.

첫째, MoE 쪽 speculative decoding을 저희 장비에서 켜고 끄며 비교해 보지 않았습니다. 8장에서 인용한 공개 실측은 MoE에서 이 기능이 손해라고 말하지만, 저희가 직접 켜고 끄며 비교한 것은 dense 모델뿐입니다. 저희가 쓰는 MoE 모델은 계속 켠 채로만 돌았습니다. 그러니 “구조 차이가 원인”이라는 저희 해석은 가설이지, 저희 장비에서 확인한 사실이 아닙니다. 이 글에서 가장 흥미로운 대목이 동시에 가장 근거가 얇은 대목입니다.

둘째, 문제 수가 적습니다. 코딩 3문제와 agent 1문제로 모델을 줄 세웠습니다. 저희 작업에서 자주 나오는 형태를 골랐지만, 네 문제로 한 모델의 능력을 전부 말할 수는 없습니다.

셋째, 같은 시험을 여러 번 돌렸을 때 결과가 얼마나 달라지는지를 충분히 확인하지 못했습니다. agent 과제에서 같은 모델이 두 번의 실행에서 명령 수도 거부 수도 달랐습니다. 다른 모델들은 한 번씩만 돌렸으니, 그 값들도 다시 돌리면 비슷한 폭으로 달라질 수 있습니다. 표에 적힌 13이나 15는 정확한 값이라기보다 그 언저리라고 읽으시는 편이 안전합니다.

넷째, 시험 문제가 저희 일 쪽으로 치우쳐 있습니다. 저희가 만든 문제는 저희가 겪은 버그이고, 저희는 서버 운영과 도구 제작을 주로 합니다. 다른 종류의 일에서는 순위가 달라질 수 있습니다. 특히 지식 자체를 묻는 과제는 이번 시험에 아예 넣지 않았습니다.

다섯째, 그리고 가장 무거운 반론입니다. API를 쓰는 편이 더 싸다는 계산이 이미 여러 곳에 공개되어 있습니다. 장비를 직접 갖추는 쪽이 본전을 뽑으려면 그 장비가 놀지 않고 돌아가야 하고, 월 사용량이 일정 규모에 못 미치면 장비 값과 운영에 드는 인건비까지 더하면 API 쪽이 유리하다는 분석이 많습니다. 저희가 로컬을 쓰는 이유는 token 값을 아끼려는 것이 아니라 데이터를 밖으로 내보내지 않는 것과 24시간 계속 돌려 둘 수 있다는 것입니다. 그 두 가지가 필요 없는 환경이시라면, 이 글의 결론을 그대로 가져다 쓰시면 안 됩니다.

✅ 정리 — 상황별 권장 구성

상황	권장	근거
agent가 shell·도구를 직접 몰아야 함	dense 30B급(예: Muse-Glimmer)	같은 8 turn에서 쓸데없는 명령이 가장 적었음
많은 요청을 빠르게 처리해야 함	MoE 35B급(예: Qwen3.6-35B-A3B)	tok/s 87~92로 3배 이상 빠름
단순 분류·태깅 위주	7B급으로 충분	35B와 동점(6/10)
초대형 모델이 꼭 필요함	장비를 늘리기보다 API를 다시 검토	3-bit 97 GiB는 추가가 아니라 교체
speculative decoding 도입 검토	구조를 확인하고 직접 켜고 꺼볼 것	dense +115% / MoE 사례 −44.6%

이틀 동안 측정하며 저희가 가장 크게 배운 것은 모델이 아니라 측정 방법에 대한 것이었습니다. 생성 상한 하나 때문에 한 모델만 말이 잘려 있었는데 표에서는 그것이 “느린 모델”로 보였고, 항목 이름 하나 때문에 저는 turn 수와 명령 수를 뒤바꿔 읽을 뻔했습니다. 둘 다 글을 올리기 직전에 측정 script를 열어 보고서야 찾았습니다. 만약 그대로 냈다면 표의 숫자는 전부 진짜였을 텐데 결론은 반대로 나왔을 것입니다.

그래서 저희가 이 글에서 드릴 수 있는 가장 쓸모 있는 조언은 순위표가 아니라 이 한 줄일지도 모르겠습니다. 숫자를 인용하시기 전에, 그 숫자를 만든 도구를 먼저 읽어 보십시오. 남이 만든 도구든 내가 만든 도구든 마찬가지입니다.

📚 참고 자료

• Muse-Glimmer-30B GGUF 모델 카드
• DeepSeek-V4-Flash 모델 카드
• llama.cpp speculative decoding 공식 문서
• llama.cpp PR #22105 — DFlash 지원 추가
• thc1006, Qwen3.6-35B-A3B + RTX 3090 speculative decoding 전수 측정
• DGX Spark Hardware Overview (공식)
• DGX Spark ConnectX-7 Networking (공식)
• DGX Spark Cluster Bandwidth: What 400G Really Means
• DataCamp — DFlash speculative decoding 입문