Mistral Small 4, 세 모델 통합이라는데
이 조건에서만 맞습니다
“한 모델로 추론·비전·코딩 에이전트를 전부 커버한다”는 발표문이 나왔습니다. 그런데 공식 벤치마크를 직접 뜯어보니, 이 주장이 성립하는 조건이 따로 있었습니다.
reasoning_effort=”none” 상태에서는 수치가 다릅니다.
Mistral Small 4가 나온 맥락 — 왜 지금인가
Mistral Small 4는 2026년 3월 16일 프랑스 AI 스타트업 Mistral AI가 공개한 모델입니다(출처: mistral.ai 공식 발표, 2026.03.16). 발표 시점이 중요한데, 이 모델이 나온 배경에는 Mistral이 그동안 따로 관리해온 세 가지 모델 계보가 있습니다.
Mistral은 복잡한 추론을 위한 Magistral, 이미지·문서 분석을 위한 Pixtral, 코딩 에이전트를 위한 Devstral을 각각 별도 모델로 제공해왔습니다. 사용자는 작업 유형에 따라 모델을 바꿔야 했고, API 비용도 각각 따로 지불해야 했습니다. Small 4는 이 셋을 하나의 가중치 파일로 합쳤다는 게 핵심 주장입니다.
타이밍 측면에서도 눈에 띄는 부분이 있습니다. 3월 중순 시점은 Qwen 3.5 시리즈가 오픈소스 벤치마크 상위권을 장악한 지 얼마 되지 않은 때입니다. Mistral로서는 단순한 성능 개선이 아니라 “통합 모델”이라는 포지셔닝 차별화가 필요했고, 그 결과물이 Small 4입니다. 솔직히 말하면, 경쟁 압박이 상당히 녹아있는 출시입니다.
119B인데 왜 “Small”인지 — 숫자를 제대로 읽어야 합니다
이름에 “Small”이 붙어있는데 총 파라미터 수는 119B입니다. 이게 모순처럼 보이지만, MoE(Mixture of Experts) 구조를 이해하면 다른 각도로 읽힙니다. 공식 문서에 따르면 Small 4는 128개 전문가(expert) 중 토큰당 4개만 활성화합니다. 실제 추론에 관여하는 파라미터는 6.5B입니다(출처: HuggingFace 공식 모델 카드).
💡 공식 발표문과 실제 추론 흐름을 같이 놓고 보니 이런 차이가 보였습니다
“119B 모델”이라는 표현은 VRAM 점유량 관점에서는 사실입니다. 하지만 실제 추론 연산량은 6.5B 수준입니다. 즉, 같은 하드웨어에서 24B 밀집(Dense) 모델보다 더 빠른 토큰 생성 속도를 낼 수 있다는 뜻입니다. “작다”는 말의 기준이 파라미터 총량이 아니라 활성 연산량임을 Mistral이 선택한 기준입니다.
그런데 여기서 간과하기 쉬운 반대 측면이 있습니다. VRAM 또는 시스템 RAM은 119B 전체를 올려야 합니다. BF16 기준 약 238GB의 메모리가 필요하고, FP8 양자화 기준으로도 최소 120GB 수준입니다. Mistral 공식 문서는 최소 구성으로 4x NVIDIA HGX H100 또는 2x NVIDIA HGX H200을 요구합니다(출처: mistral.ai 공식 발표). 연산은 빠를 수 있지만, 올리는 데 필요한 메모리는 절약되지 않는다는 점이 핵심입니다.
| 구분 | Mistral Small 4 | Mistral Small 3.2 (24B) | Qwen 3.5 122B-A10B |
|---|---|---|---|
| 총 파라미터 | 119B | 24B | 122B |
| 활성 파라미터 | 6.5B | 24B | 10B |
| 컨텍스트 | 256K | 128K | 262K |
| 라이선스 | Apache 2.0 | Apache 2.0 | Apache 2.0 |
| API 입력 단가 | $0.15/1M | 약 $0.10/1M | 약 $0.38/1M |
출처: Mistral AI 공식 문서(docs.mistral.ai), HuggingFace 모델 카드. API 단가는 2026.03.22 기준. Mistral Small 3.2 단가는 Mistral AI API 기준 추정치.
reasoning_effort 파라미터 — 켜야 쓸 모델입니다
Small 4의 가장 독특한 기능 중 하나는 API 요청 단위로 추론 강도를 조절할 수 있다는 점입니다. 공식 문서에서 설명하는 파라미터는 두 가지 값만 지원합니다: reasoning_effort="none"과 reasoning_effort="high"입니다(출처: Mistral 공식 문서).
💡 발표 자료에 나온 수치와 실제 사용 맥락을 맞춰보니 이런 그림이 나왔습니다
reasoning_effort=”none” 상태에서 Small 4는 공식 내부 비교표 기준으로 Mistral Small 3.2와 유사한 수준입니다(출처: HuggingFace 모델 카드). 반면 커뮤니티 벤치마크에서는 Qwen 3.5 35B-A3B(GPQA Diamond 84.2, MMLU Pro 85.3)에 비해 Mistral Small 4(GPQA Diamond 71.2, MMLU Pro 78.0)가 전 항목에서 낮게 나왔습니다(출처: Reddit r/LocalLLaMA 스레드, 2026.03.16).
이 수치가 의미하는 건 명확합니다. 추론 모드를 끄면 훨씬 작은 Qwen 모델보다 성능이 낮습니다.
반면 reasoning_effort=”high”를 켜면 성격이 달라집니다. 공식 발표에서 Mistral은 이 모드에서 GPT-OSS 120B를 AIME 2025, AA LCR, LiveCodeBench 세 가지 벤치마크 모두에서 비슷하거나 초과한다고 주장합니다. 특히 AA LCR 기준 0.72 점수를 1.6K 문자로 달성한 반면, Qwen 시리즈는 같은 점수를 내기 위해 5.8~6.1K 문자를 생성했습니다. 출력 길이가 3.5~4배 차이 납니다(출처: mistral.ai/news/mistral-small-4).
출력 토큰 수는 곧 비용입니다. 추론 모드를 켰을 때 Small 4가 같은 점수를 내면서 토큰을 훨씬 적게 쓴다는 건, API 요금 체계에서 유의미한 차이로 이어집니다. $0.60/1M 출력 단가 기준, Qwen이 6.1K 토큰을 쓸 때 Small 4는 1.6K를 씁니다. 같은 작업 1,000회 기준으로 계산하면 출력 비용만 약 3.7배 차이입니다.
공식 벤치마크 수치, 직접 확인한 것과 빠진 것
Mistral이 공식 발표에서 내세운 수치 중 눈에 띄는 게 있습니다. LiveCodeBench에서 GPT-OSS 120B를 앞서면서 출력은 20% 적게 생성했다는 항목입니다(출처: mistral.ai/news/mistral-small-4). 이 수치 자체는 공식 문서에 명시된 것입니다. 추론 모드 ON 기준으로는 분명히 경쟁력 있는 위치입니다.
그런데 발표 자료에서 조용히 빠진 항목이 있습니다. Qwen 3.5 122B-A10B와의 직접 비교 수치입니다. Mistral은 자사 이전 모델(Magistral, Devstral, Small 3.2)과의 비교만 전면에 배치하고, Qwen 3.5 계열과의 수치 비교는 공식 발표문에 포함하지 않았습니다. 공식 문서에서 별도 설명을 밝히지 않은 부분입니다.
커뮤니티에서 직접 비교한 결과를 보면 그 이유가 어느 정도 보입니다. Reddit r/LocalLLaMA 스레드(2026.03.16)에서 공유된 표를 보면 아래와 같습니다:
| 모델 | GPQA Diamond | MMLU Pro | IFBench | LiveCodeBench |
|---|---|---|---|---|
| Mistral Small 4 (추론 ON) | 71.2 | 78.0 | 48.0 | 63.6 |
| Mistral Small 4 (추론 OFF) | 59.1 | 73.5 | 35.7 | — |
| Qwen 3.5 35B-A3B | 84.2 | 85.3 | 70.2 | 74.6 |
출처: Reddit r/LocalLLaMA 커뮤니티 비교(2026.03.16), HuggingFace 모델 카드. Qwen 3.5 35B-A3B 수치는 커뮤니티 측정값. 각 벤치마크 방법론·샷 수 등에 따라 결과가 달라질 수 있습니다.
추론 ON 상태에서도 Qwen 3.5 35B-A3B(총 35B, 활성 3B)에 모든 항목에서 낮습니다. 활성 파라미터가 절반도 안 되는 모델에게 전 항목 밀립니다. 이 수치가 가리키는 건 단순합니다. Small 4의 포지션은 “통합 편의성”과 “API 효율성”이지, 원시 성능 경쟁이 아닙니다.
로컬 실행 시 실제로 필요한 하드웨어 — 기대보다 높습니다
“이름이 Small이니까 가볍겠지”라고 생각하면 실망이 큽니다. 공식 문서에서 최소 사양으로 명시한 구성은 4x NVIDIA HGX H100, 2x NVIDIA HGX H200, 또는 1x NVIDIA DGX B200입니다(출처: mistral.ai 공식 발표). 소비자 GPU 한두 장으로 구동 가능한 수준이 아닙니다.
다만 로컬 실행을 위한 현실적 대안도 있습니다. GGUF 양자화 버전(Q4_K_M 기준 약 65~70GB)을 쓰면 대용량 시스템 RAM에서도 구동이 가능합니다. Reddit 커뮤니티에서는 Mac Studio M4 Max(128GB 유니파이드 메모리) 또는 192GB 이상의 CPU 시스템에서도 실행된다는 보고가 나왔습니다. 속도는 느리지만 “일단 돌아간다”는 수준입니다. 다만 이 시나리오에서 토큰 생성 속도는 API 대비 수 배 느릴 가능성이 높습니다.
⚠️ llama.cpp 빌드 이슈 — 아직 불안정합니다
출시 직후(2026.03.16 기준) llama.cpp 구현이 완전히 안정화되지 않은 상태였습니다. Mistral 공식 HuggingFace 카드에는 vLLM을 권장 배포 방식으로 명시하며, vLLM PR 머지 작업이 2026년 3월 16일 기준 “1~2주 내” 완료 예정이라고 적혀 있습니다(출처: HuggingFace 모델 카드). 이유는 공식적으로 별도 설명되지 않았지만, Mistral 4 아키텍처 파싱 처리가 기존 llama.cpp 코드베이스와 충돌하는 것으로 추정됩니다.
Mistral은 추가로 NVFP4 양자화 체크포인트(mistralai/Mistral-Small-4-119B-2603-NVFP4)와 Eagle 스펙큘레이티브 디코딩 헤드(약 392MB)도 함께 공개했습니다. Eagle 헤드를 붙이면 동일 하드웨어에서 토큰 생성 속도를 추가로 높일 수 있습니다. 이 부분은 기존 Mistral Small 계열에 없던 새로운 최적화 도구입니다.
이 모델이 유리한 조건, 불리한 조건
공식 수치와 커뮤니티 실사용 데이터를 교차해서 보면, Small 4가 진짜로 강점을 가지는 시나리오가 따로 보입니다.
✅ 이 조건에서는 유리합니다
- Mistral API를 통한 기업 배포 — 추론·비전·코딩을 단일 엔드포인트로 통합, 모델 전환 오버헤드 없음
- reasoning_effort=”high” + 긴 추론 체인 — 같은 점수를 출력 토큰 3~4배 적게 씀, 대량 처리 비용 절감
- EU 규제 환경의 기업 — Apache 2.0 + 프랑스 기반 모델, GDPR·데이터 주권 이슈 완화 가능성
- 문서 파싱 + 에이전트 워크플로 조합 — 이미지 입력과 도구 호출을 같은 요청에서 처리 가능
- 파인튜닝 후 전문 도메인 배포 — Apache 2.0 상업 이용 가능, Axolotl/NeMo 연동 공식 지원
❌ 이 조건에서는 불리합니다
- 추론 모드 OFF 상태의 일반 채팅·코딩 — Qwen 3.5 35B-A3B보다 낮은 벤치마크 수치
- 소비자 GPU(RTX 4090급 이하) 로컬 실행 — 최소 사양이 4x H100 수준, 현실적으로 어려움
- 빠른 단순 응답이 필요한 챗봇 — 추론 모드 ON 시 응답 시간 증가, 단순 작업에는 과투입
- 이미지 입력 정확도 우선 작업 — 커뮤니티 후기에서 비전 품질이 Gemma 3 27B보다 낮다는 평가 다수
- llama.cpp 기반 로컬 스택 — 2026.03 기준 구현 불안정, PR 머지 완료 후 재검토 필요
개인적으로 이 모델을 “Mistral의 GPT-4o 대항마”로 해석하는 시각은 조금 과하다고 봅니다. 오히려 “Magistral + Pixtral + Devstral을 세 개 운영하던 기업 고객이 하나로 줄이는 도구”에 가깝습니다. API 단가($0.15/$0.60)도 단순 채팅용이라기보다 배치 처리 또는 에이전트 파이프라인 맥락에서 셈이 맞습니다.
자주 묻는 질문
마치며
Mistral Small 4를 한 문장으로 정리하면 이렇습니다. “세 모델 통합”이라는 주장은 사실이지만, 그 가치가 온전히 발휘되는 건 reasoning_effort=”high” 상태와 API 배포 환경이 맞아떨어질 때입니다.
추론 모드를 끄면 훨씬 작은 Qwen 3.5 35B-A3B에게 벤치마크 전 항목을 내줍니다. 로컬 실행은 최소 4x H100이 기준이고, llama.cpp 빌드는 출시 직후 기준으로 불안정합니다. 비전 품질도 커뮤니티 평가에서 기대에 못 미쳤다는 의견이 많습니다.
반면 기업 입장에서 Mistral API 위에 추론·에이전트·문서 파싱 파이프라인을 하나로 구성한다면, 단일 모델로 세 가지 작업을 처리하면서 출력 토큰을 3~4배 절약하는 건 실제 운영 비용에서 의미 있는 숫자입니다. EU 데이터 규제 환경에서 Apache 2.0 기반 유럽 모델을 선호하는 조직이라면 선택지가 좁은 편이기도 합니다.
결론적으로, “통합 모델”이라는 마케팅 문구를 먼저 보기보다는 현재 워크플로에서 추론 모드를 상시 켜야 하는 작업이 얼마나 되는지를 먼저 따져보는 게 순서입니다. 그 조건이 맞으면 꽤 매력적인 선택지이고, 그렇지 않으면 지금 시점에서 서두를 이유가 없습니다.
📚 본 포스팅 참고 자료
- Mistral AI 공식 발표: mistral.ai/news/mistral-small-4 (2026.03.16)
- Mistral 공식 모델 문서: docs.mistral.ai/models/mistral-small-4-0-26-03
- HuggingFace 공식 모델 카드: huggingface.co/mistralai/Mistral-Small-4-119B-2603
- NVIDIA NIM 모델 카드: build.nvidia.com/mistralai/mistral-small-4-119b-2603
- Reddit r/LocalLLaMA 커뮤니티 비교 스레드 (2026.03.16): reddit.com/r/LocalLLaMA/comments/1rvlfbh
본 포스팅은 2026년 3월 22일 기준으로 작성되었습니다. Mistral Small 4(v26.03) 기준입니다.
본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. 벤치마크 수치는 측정 방법론 및 환경에 따라 달라질 수 있으며, 공식 최신 문서를 직접 확인하는 것을 권장합니다.
댓글 남기기