로컬 LLM이 답을 내놓는 속도가 답답하면 보통 더 큰 VRAM이 장착된 그래픽카드를 떠올리게 돼. 그런데 모델을 실행하는 프로그램만 바꿔도 속도가 빨라진다는 주장이 나왔어. Magnitude라는 오픈소스 실행 엔진이야.
개발사는 11개 모델을 Ollama와 비교해 답변 생성 속도가 Mac M4 Pro에서 평균 2.19배, NVIDIA DGX Spark에서 2.17배 빨랐다고 발표했어.
그런데 독립 테스트에서는 같은 모델이 문장을 베껴 쓸 때 2.17배 빨랐다가, 새 이야기를 만들 때는 오히려 더 느려지기도 했어. 대체 어떤 차이일까?
모델을 바꾸는 대신 실행 방식을 바꾼다
LLM을 돌릴 때 사용하는 실행엔진은 Ollama, llama.cpp 등이 대표적이야. 이번에 화제가 되고 있는 Magnitude도 실행엔진이지.
모델을 학습시키는 프로그램이 아니라, 모델이 하드웨어에서 더 효율적으로 계산하도록 돕는 실행 환경이야.
Magnitude는 모델을 처음 내려받을 때 현재 컴퓨터에 맞는 계산 설정을 시험해. GPU가 어떤 크기의 작업을 처리할지, 계산을 어떻게 나눌지 여러 조합을 돌려보고 빠른 설정을 골라 저장하는 식이지.
개발사 설명으로는 이 튜닝에 최대 1분 정도가 걸려. 이게 속도를 끌어올리는 하나의 요소지.
만약 LM Studio같은 실행엔진을 사용해본 사용자라면 모델을 불러올 때마다 각각의 설정값을 어떻게 맞춰야 내 컴퓨터에서 최적일지 혼란스러울 때가 많았을 거야. 캐시 설정을 비롯해서 조정가능한 값들이 상당히 많거든.
이런 세팅을 Magnitude가 맞춤형으로 해준다고 생각하면 쉽겠네.
✦ 추측 디코딩은 이렇게 돌아가
작은 모델이 후보를 미리 만들고, 큰 모델이 검증해
속도를 끌어올리는 다른 요소는 ‘추측 디코딩’이야. 큰 모델이 다음 단어를 하나씩 계산하는 동안, 작은 모델이나 전용 초안 생성기가 다음에 나올 토큰 후보를 미리 제안해.
큰 모델이 그 후보들을 확인하고 맞는 것을 받아들이면 그만큼 속도가 빨라진다는 거지. 다음에 나올 토큰 후보를 제대로 예상했다면 그만큼 이득이 커지고, 빗나가면 효과가 줄어들어.
‘2배 빨라졌다’는 건 어느 단계일까
✦ 프리필과 디코드, 뭐가 달라
입력 문맥을 처리하는 단계와 답변을 만드는 단계
LLM은 사용자의 질문을 받으면, 그 질문과 그동안의 대화 기록을 읽고, 답변을 토큰단위로 만들기 시작해. 입력 문맥을 처리하는 단계는 프리필(prefill), 답변을 생성하는 단계는 디코드(decode)라고 불러.
답변이 한 글자씩 늦게 나타나는 느낌에 직접 영향을 주는 건 주로 디코드 속도야.
Magnitude는 가장 대표적 실행엔진인 Ollama와 벤치마크 비교평가를 했어.
벤치마크에서는 양쪽 엔진 모두 추측 디코딩을 사용했지만, Ollama는 각 모델에 딸려있는 초안 생성기를 쓰고, Magnitude는 자체적인 초안 생성기를 사용했어.
✦ Magnitude의 평균 속도 비교
11개 모델 비교, 프리필과 디코드
| 환경 | 프리필 | 디코드 |
|---|---|---|
| Mac M4 Pro 48GB | 1.32배 | 2.19배 |
| NVIDIA DGX Spark 128GB | 1.34배 | 2.17배 |
Magnitude가 공개한 11개 모델 비교에서 Magnitude가 기록한 평균 결과는 이랬어.
- Mac M4 Pro 48GB 환경에서의 처리속도: 프리필 1.32배, 디코드 2.19배 - NVIDIA DGX Spark 128GB 환경에서의 처리속도: 프리필 1.34배, 디코드 2.17배
그러니까 2배라는 수치는 답변을 생성하는 디코드 속도를 말하는 거야. 긴 질문을 읽는 '프리필' 속도까지 두 배가 된 건 아니지.
✦ 모델마다 결과는 달랐어
Mac·DGX Spark 디코드 속도, 초당 토큰
| 환경·모델 | Ollama | Magnitude | 배율 |
|---|---|---|---|
| Mac · Qwen 3.5 4B | 45.2 | 134 | 약 2.97배 |
| DGX Spark · Qwen 3.5 4B | 61.1 | 296 | 4.84배 |
| DGX Spark · Nemotron 3.5 | 94.9 | 72.2 | 약 24% 느림 |
개별 모델을 보면 차이가 더 커. Mac M4 Pro에서 Qwen 3.5 4B는 초당 45.2토큰에서 134토큰으로 올라 약 2.97배가 됐어.
NVIDIA DGX Spark에서는 같은 모델이 61.1에서 296토큰으로 올라 4.84배를 기록했지.
반면 DGX Spark에서 Nemotron 3.5는 초당 94.9토큰에서 72.2토큰으로 떨어져서, 오히려 Magnitude 쪽이 약 24% 느렸어.
왜 문장 복사에는 빠르고 새 글쓰기에는 느려질까
공식 벤치마크의 작업 방식도 알아둘 필요가 있어. 약 6만 4천 토큰 길이의 『모비 딕』 문장을 입력하고, 모델에게 마지막 부분을 반복해서 쓰도록 했어. 출력은 256토큰으로 제한했고, 두 엔진 모두 추측 디코딩을 켰지.
이건 긴 문맥을 읽은 뒤 정해진 문장을 다시 출력하는 속도를 비교한 실험이고, 답변의 품질이나 코딩 성공률을 평가한 건 아니야.
✦ 독립 재시험, 작업에 따라 결과가 뒤집혔어
Qwen3.6 35B-A3B, Ollama와 Magnitude 비교
| 작업 | Ollama | Magnitude | 배율 |
|---|---|---|---|
| 긴 문장 복사 | 87.2 | 188.9 | 약 2.17배 |
| 긴 문맥 뒤 새 이야기 | 63.4 | 50.4 | 약 0.79배 |
이런 복사 작업에서는 다음에 나올 문장이 이미 '입력' 안에 있으니 초안 생성기가 후보를 잘 맞힐 가능성이 높아. 당연하겠지?
실제로 독립 테스트를 진행한 Niklas Lenz는 NVIDIA DGX Spark에서 Qwen3.6 35B-A3B를 실행해 비슷한 복사 시험을 다시 했어.
Ollama는 초당 87.2토큰, Magnitude는 188.9토큰을 기록해 약 2.17배 차이가 났지.
그런데 같은 모델로 긴 문맥 뒤에 새로운 이야기를 쓰게 하자 결과가 뒤집혔어. Ollama는 초당 63.4토큰, Magnitude는 50.4토큰이었어. Magnitude의 속도는 Ollama의 약 0.79배, 다시 말해 약 21% 느렸지.
긴 문맥 없이 새 이야기를 만드는 시험에서도 Magnitude가 약간 느렸어.
✦ 초안 후보, 얼마나 맞혔을까
작업에 따라 초안 생성기의 적중률이 크게 갈렸어
왜 이런 차이가 생길까? 이미 눈치챘지? 복사처럼 다음 토큰을 잘 예측할 수 있는 작업에서는 초안 생성기의 예측 정확도가 높아져. 반대로 새 이야기를 써야 하면 다음에 올 표현이 훨씬 다양하니 초안이 더 자주 빗나갈 수 밖에 없겠지.
Lenz의 테스트에서 Magnitude 초안 생성기가 제시한 후보는 복사 작업에서 약 75%가 적중했지만, 새 이야기에서는 약 43%에 불과했어.
동일한 모델 파일을 Ollama에 넣어 다시 돌린 경우도 테스트도 있었는데, 그때는 복사 작업에서 Magnitude가 188.9 대 45.6토큰으로 훨씬 빨랐고, 새 이야기에서는 50.4 대 46.1토큰으로 비슷했어.
따라서 현재까지의 결과만 놓고 보면, 특정 작업에서는 Magnitude의 장점이 있는 건 확실해보여. 하지만 우리가 로컬LLM에게 기대하는 일반적인 작업에서 안정적으로 속도향상을 기대하기는 어렵다는 거야.
그럼 설치해 볼 가치는 있을까
✦ Magnitude, 어떻게 시작할까
설치부터 에이전트 연결까지
Magnitude는 macOS·Windows·Linux에서 사용할 수 있는 무료 오픈소스 도구야. 누구나 내려받아서 실행할 수 있고, Codex나 OpenCode 같은 에이전트와 연결하는 기능도 제공해.
만약 설치해보고 싶다면, 아래 링크를 참고하면 돼.
공식 웹사이트: https://magnitude.dev
공식 저장소: https://github.com/magnitudedev/magnitude
이런 툴을 다뤄본 적이 별로 없어서 잘 모르겠다면, 사용하는 AI 에이전트(코덱스, 클로드 코드 등)에게 위의 링크를 알려주고 magnitude를 내 환경에 설치해달라고 해봐. 금방 설치해줄 거야.
어쨌든 이번 결과를 보면 ‘실행 엔진만 바꾸면 무조건 2배 빨라짐’이라는 말은 다소 과장된 표현이야. 그래도 로컬LLM을 계속 써야하는 사람이라면, Magnitude를 사용해 볼 가치는 충분해.
사실 현재 상황에서는 그래픽카드를 바꾸는 것 외에는 로컬LLM의 속도를 끌어올릴 방안이 특별히 없잖아. 양자화를 하면 속도를 얻는 대신 품질을 잃고, 그래픽카드는 너무 비싸. 그런데 무료로 이런 실행환경이 제공되니, 좋은 기회지.
특히 주로 처리하는 작업이 이미 입력한 프롬프트나 대화내용에서 반복되는 내용이 많다면, 상당한 속도 향상을 얻을 수 있을지도 몰라. 한 번 시험해봐. 읏흥♡
이번 글은 여기서 마칠게. 또 만나자.
💬 댓글
아직 댓글이 없어. 첫 댓글을 남겨줄래?
댓글 쓰기