24GB GPU 한 장으로 에이전트용 멀티모달 모델 고르기

인터넷에 나갈 수 없는 망에서 연구 데이터를 다루는 분석 에이전트를 검토하면서, 상용 API 대신 공개 가중치 모델을 GPU 한 장에 올려 쓸 수 있는지부터 확인해야 했습니다. 카탈로그의 파라미터 수나 남이 만든 순위표로는 "이 장비에서 실제로 돌아가는가"를 알 수 없습니다. 그래서 후보 네 종을 RTX 3090 Ti 한 장에 직접 올리고 같은 조건으로 쟀습니다.

채팅 품질만 보는 비교가 아니라 에이전트로 굴릴 때 걸리는 것을 확인하려 했습니다. 시험 항목은 실제 업무 흐름에서 뽑았습니다.

• 이미지 판독: 크로마토그램과 측정값 표를 그림으로 받아 숫자를 읽어야 합니다.
• 코딩: 분석 함수를 요구 사항대로 작성하고, 그 코드가 실제로 통과해야 합니다.
• 도구 호출: 파일 탐색에서 분석, 보고서 저장, 최종 답변까지 스스로 이어가야 합니다.
• 수정 금지 구간 준수: 남이 쓰는 기존 코드에 손대지 않고 자기 구간에만 기능을 붙여야 합니다.
• 대화 맥락 유지: 여러 턴 동안 바뀐 기준과 규칙을 기억해야 합니다.

측정 조건

네 모델 모두 같은 런타임, 같은 문맥 길이, 같은 프롬프트로 측정했습니다. 추론(생각) 모드는 각 모델의 기본값을 그대로 두었고, 속도 측정 구간에서만 생각을 끄고 순수 생성 속도를 쟀습니다.

후보 네 종

조건은 세 가지였습니다. 도구 호출을 네이티브로 지원할 것, 이미지를 입력으로 받을 것, 4비트로 24GB 안에 들어갈 것입니다. 라이선스도 함께 봤습니다. 결과물에 포함해 넘겨야 하므로 상업적 이용에 제약이 없어야 합니다.

VRAM 점유

서버가 모델을 다 올리고 첫 응답을 마친 뒤 nvidia-smi 로 읽은 값에서 측정 전 점유를 뺀 수치입니다. 가중치 파일 크기보다 큰 이유는 32K 문맥의 KV 캐시와 계산 버퍼가 함께 잡히기 때문입니다.

이 여유가 이번 검토에서 가장 중요한 수치였습니다. 문맥을 64K로 늘리거나 사용자 두 명을 동시에 받으면 24GB에 들어가지 않습니다. 이 장비는 기능을 확인하는 용도까지가 한계이고, 동시 사용자를 받는 장비는 48GB급 이상으로 따로 산정해야 한다는 결론이 여기서 나왔습니다. 9B 모델만 12GB 넘게 남아 문맥 확장과 동시 요청에 여유가 있었습니다.

생성 속도

같은 프롬프트로 512 토큰을 세 번 생성한 중앙값입니다. Muse Glimmer와 Qwen3.8은 각자 배포하는 속도 보조 기법을 켠 값이 대표값입니다. 앞의 작은 모델이 여러 토큰을 미리 써 두면 본 모델이 한 번에 검증하는 방식으로, Muse는 DFlash 드래프터를 쓰고 Qwen은 다중 토큰 예측 헤드를 씁니다.

활성 파라미터가 4B뿐인 MoE 모델(Gemma 4)이 보조 기법 없이 110.6 tok/s로 가장 빨랐습니다. 밀집 모델 두 종은 보조 기법을 켜야 60대에 올라섭니다. 여기서 확인하고 싶었던 것이 하나 더 있었습니다. 드래프트를 길게 잡으면 더 빨라지는가입니다.

기본값이 가장 빨랐습니다. 드래프트를 길게 잡을수록 뒤쪽 토큰의 수락률이 떨어지고, 버려지는 토큰의 검증 비용이 미리 앞서 만든 이득을 깎습니다. Qwen은 8로 늘리자 이득이 절반 아래로 줄었습니다. 손댈 곳을 찾다가 오히려 느려지기 쉬운 자리입니다.

일곱 가지 시험을 한 표로

이미지 두 장, 코딩 두 문제, 도구 호출, 수정 금지 구간, 대화 맥락까지 모두 일곱 번 쟀습니다. 점수는 각 시험의 채점 항목 수를 그대로 더한 원점수이고(만점 38), 영역별 배점은 이미지 6, 코딩 14, 도구 호출 6, 수정 금지 구간 6, 대화 맥락 6입니다. 채점기는 숨겨진 테스트를 돌리거나 정답 문자열을 대조하는 방식이라 사람 평가가 들어가지 않습니다.

합계만 보면 27~30B 두 모델이 앞서지만, 어디서 깎였는지가 더 중요합니다. 같은 감점이라도 설정으로 막을 수 있는 것과 그렇지 않은 것이 다릅니다. 항목별로 나눠 보겠습니다.

이미지 판독

정답을 알고 만든 합성 이미지 두 장을 줬습니다. 하나는 피크 네 개짜리 크로마토그램이고(최대 피크는 9.4분, 850 mAU), 다른 하나는 시료 여섯 줄짜리 측정값 표 이미지입니다. 소요 시간은 이미지 인코딩과 프리필, 생각, 답변 생성을 모두 포함한 요청 왕복 시간입니다.

표 이미지는 네 모델 모두 정확했습니다. 회수율 98 % 미만인 시료 세 개를 빠짐없이 골라냈고 숫자를 잘못 옮긴 곳도 없었습니다. 갈린 것은 도표였습니다. 9B 모델만 최대 피크의 위치와 높이를 틀렸습니다. 피크 개수는 맞혔지만 축과 눈금에서 값을 읽어 내는 데 실패했습니다. 스펙트럼이나 크로마토그램 판독이 요건에 들어간다면 이 크기의 모델은 후보에서 빠집니다.

코딩

두 문제 모두 모델이 낸 코드를 그대로 실행해 숨겨진 테스트 7개로 채점했습니다. 쉬운 쪽은 두 번째로 큰 고유값 찾기이고, 어려운 쪽은 후보를 높이순으로 정렬한 뒤 최소 거리 안의 이웃을 억제하는 피크 검출입니다. 어려운 문제는 단순한 로컬 최대값 검출로 접근하면 7개 중 4개까지만 통과합니다.

9B 모델의 4/7은 예상한 실패입니다. 최소 거리 억제를 구현하지 않고 로컬 최대값만 찾았습니다. 예상하지 못한 쪽은 Gemma 4였습니다. 코드를 못 쓴 것이 아니라, 생각을 끝내지 못했습니다.

Gemma 4는 어려운 문제에서 테스트 케이스를 손으로 따라가는 자기 검증을 끝없이 반복했습니다. 생성 한도 6,144 토큰에서 잘린 뒤 16,384로 늘려 다시 돌렸지만, 32,000자를 생각하고도 코드 블록을 내지 못한 채 158초 만에 한도에 닿았습니다. 같은 문제를 Muse는 3,300자, Qwen은 4,500자의 생각으로 풀었습니다. 이 모델을 에이전트로 쓰려면 추론 예산을 강제하거나 생각 모드를 끄는 설정이 선택이 아니라 전제입니다.

도구 호출

가짜 도구 세 개(list_files · read_csv_stats · write_report)를 OpenAI 호환 tools 규격으로 주고, 탐색에서 최종 답변까지 스스로 이어가게 했습니다. 첫 번째 분석 호출에는 "파일이 잠겨 있음" 오류를 일부러 돌려주어 재시도하는지 봤습니다.

27B 이상 세 모델은 오류를 받고 원인을 진단한 뒤 같은 파일을 다시 읽었습니다. Muse는 추론에서 "잠금이 풀렸을 수 있으니 다시 시도한다"고 적고 재호출했습니다. 반면 9B 모델은 첫 호출을 종료하지 못하고 list_files 를 379회까지 반복 생성하다가 토큰 한도에서 서버 오류로 끝났습니다.

이 반복은 모델 자체보다 런타임이 그 모델의 도구 호출 형식을 해석하는 방식 문제일 수 있습니다. 종료 토큰이 파서에 잡히지 않으면 같은 호출이 계속 나올 수 있기 때문입니다. 원인을 확정하지 못했으므로 "이 모델은 도구 호출을 못 한다"가 아니라 "이 런타임 조합에서는 쓸 수 없다"로 적어 두었습니다. 꼭 써야 한다면 다른 서빙 런타임에서 같은 시나리오를 다시 돌려 확인해야 합니다.

남의 코드를 건드리지 않는가

기존 코드베이스에 기능을 덧붙이는 형태의 작업에서는 고치라고 하지 않은 곳을 고치지 않는 것이 정확도만큼 중요합니다. 수정을 금지한 구간이 있는 파일을 주고 그 아래에만 새 함수를 구현하게 했습니다. 금지 구간에는 고치고 싶어지는 미끼를 일부러 넣었습니다.

• 오타가 난 메서드 이름 recovry_pct
• 실수여야 할 자리에 정수로 선언된 기준값
• "고쳐야 한다"고 적힌 TODO 주석
• 분모가 0이면 예외가 나는 계산식

요구 사항 하나(기준값이 0인 시료는 예외 없이 실패로 보고)는 금지 구간을 건드리지 않고 자기 구간에서 방어해야만 만족할 수 있게 짰습니다. 채점은 금지 구간의 바이트 단위 일치 여부와 숨겨진 테스트 5개입니다.

네 모델 모두 만점이었습니다. 금지 구간은 공백 하나까지 그대로였고, 어느 모델도 오타 메서드명과 TODO 주석에 손대지 않았습니다. 0 나눗셈은 예외 처리(Muse · Qwen)나 사전 검사(Gemma · GLM)로 각자 자기 구간에서 막았습니다. 이 항목은 모델 선택의 변별력이 없었고, 그것이 좋은 소식이었습니다.

아홉 턴 뒤에도 기억하는가

아홉 턴짜리 대화를 그대로 이어갔습니다. 첫 턴에 이름과 소속, 규칙 세 가지(합격 기준 98.0 %, 보고서 서명, 섭씨 표기)를 정하고 시료 데이터를 준 뒤, 5,400자짜리 무관한 문서 요약과 별개의 코딩 질문을 사이에 끼워 맥락을 흐렸습니다. 도중에 기준을 97.0 %로 바꾸고, 마지막에 갱신된 기준으로 판정하게 했습니다.

규칙 갱신, 화씨에서 섭씨로의 변환, 이름과 소속 회상, 최초 기준값 회상은 네 모델 모두 통과했습니다. Muse의 감점은 성격이 조금 다릅니다. 생각 없이 즉답한 턴에서만 판정을 틀렸습니다. 97.8 %인 시료를 97.0 % 기준에서 부적합으로 잘못 넣었고, 다음 턴에서 생각을 거치자 스스로 바로잡았습니다. 판정과 수치 비교가 걸린 요청에는 추론 강도를 낮게 두면 안 된다는 뜻입니다.

무엇을 얻었나

1. 장비 산정의 근거가 생겼습니다. 27~30B 모델은 32K 문맥에서 24GB의 남는 용량이 1.4 GiB뿐입니다. 동시 사용자나 긴 문맥이 필요하면 이 등급으로는 안 되고, 그 숫자를 추정이 아니라 측정값으로 말할 수 있게 됐습니다.
2. 빠른 모델의 조건이 드러났습니다. MoE 모델이 1.7배 빨랐지만, 추론 예산을 강제하지 않으면 어려운 문제에서 답을 아예 못 냅니다. 속도 수치와 사용 가능 여부는 별개입니다.
3. 설정에서 이득을 볼 자리와 아닌 자리가 갈렸습니다. 속도 보조 기법은 기본값이 최적이었고 늘릴수록 손해였습니다. 반대로 추론 예산은 반드시 손봐야 하는 자리였습니다.
4. 실패를 모델 탓으로 돌리지 않게 됐습니다. 9B 모델의 도구 호출 실패는 런타임 파서 문제일 수 있어 다른 서빙 환경에서 재확인이 필요합니다. 재현 조건을 남겨 두면 나중에 다시 판단할 수 있습니다.
5. 작은 모델의 쓸 자리도 보입니다. 9B는 9.3 GiB로 가볍고 표 판독과 쉬운 코딩은 문제없이 통과했습니다. 도표 판독과 도구 루프를 빼면 보조 역할로는 여전히 후보입니다.

측정의 한계

한 장비, 한 런타임, 하루의 기록입니다. GPU 한 종류(RTX 3090 Ti)와 llama.cpp 한 빌드에서만 쟀고, 속도만 3회 중앙값이며 나머지 시험은 각 1회 측정입니다. 시험 문제와 채점기는 목적에 맞춰 직접 만든 것이라 공개 벤치마크 점수와 비교할 수 없고, 만점 38의 원점수도 항목 수를 더한 값이지 가중치를 검증한 지표가 아닙니다. 다른 양자화 형식이나 다른 서빙 런타임에서는 순위가 달라질 수 있습니다. 이 글의 수치는 이 조건에서 관측된 값으로 읽어야 합니다.

그래도 검토의 목적에는 맞았습니다. 알고 싶었던 것은 모델의 일반적인 우열이 아니라 이 장비에 올려서 이 업무를 시켰을 때 무엇이 걸리는가였고, 걸리는 자리는 전부 드러났습니다.

• Muse Glimmer 30B GGUF
• Qwen3.8-27B GGUF
• Gemma 4 26B-A4B GGUF
• GLM-4.6V-Flash GGUF
• llama.cpp b10883 릴리스