Apache 2.0 오픈소스
Mistral Small 4 써봤습니다 — 작다는 말이 절반만 맞습니다
2026년 3월 16일, Mistral AI가 Small 4를 공개했습니다. 전체 파라미터 119B인데 이름은 “Small”입니다. 이게 말이 되는 건지, 실제로 쓸 수 있는 건지, 공식 문서와 실사용 피드백을 같이 놓고 따져봤습니다. 결론부터 말씀드리면, 빠른 건 맞는데 조건이 있습니다.
119B인데 왜 “Small”인지 납득이 되는 이유
Mistral Small 4의 전체 파라미터는 119B입니다. 숫자만 보면 절대 작지 않습니다. 그런데 Mistral이 이 모델을 “Small”이라고 부르는 건 어느 정도 논리가 있습니다. MoE(Mixture-of-Experts) 구조로 설계됐기 때문입니다. 128개의 전문가(expert) 레이어 중 토큰당 4개만 활성화되고, 실제 추론에 쓰이는 파라미터는 6.5B입니다. 임베딩·출력 레이어까지 포함해도 8B 수준입니다.
실행 속도 관점에서 보면 24B 밀집 모델과 비슷한 처리 속도를 낼 수 있습니다. 공식 벤치마크에서 Small 3 대비 지연 최적화 환경에서 40% 응답 시간 단축, 처리량 최적화 환경에서 초당 요청 3배를 달성했다고 Mistral이 밝혔습니다. (출처: Mistral 공식 블로그, 2026.03.16) 속도만 보면 “Small”이라는 이름이 억지는 아닙니다.
💡 공식 발표문과 실제 VRAM 요구 사항을 같이 놓고 보니 이런 차이가 보였습니다.
119B는 저장 용량 이야기고, 6.5B는 실행 비용 이야기입니다. 두 숫자가 같은 의미가 아닙니다.
다만 여기에 함정이 있습니다. 119B를 메모리에 올리려면 결국 전체 웨이트를 들고 있어야 합니다. BF16 기준으로 약 238GB가 필요합니다. “실행 속도가 6.5B처럼 빠르다”는 말이 “6.5B만큼 메모리가 적게 든다”는 뜻은 아닙니다.
4개 모델이 1개로 합쳐졌습니다 — 실제로 무슨 뜻인가
Mistral은 이번 Small 4가 기존에 따로 운영하던 4개 모델 라인을 하나로 통합한 첫 번째 모델이라고 발표했습니다. Magistral(추론), Pixtral(멀티모달), Devstral(에이전트 코딩), Mistral Small(일반 대화)이 하나의 모델로 합쳐졌습니다. (출처: mistral.ai/news/mistral-small-4, 2026.03.16)
실무에서 이게 왜 중요한지 잠깐 생각해보면 이렇습니다. 지금까지는 코딩 작업엔 Devstral, 이미지 분석엔 Pixtral, 복잡한 추론엔 Magistral로 API를 분리 연결해야 했습니다. Small 4부터는 하나의 API 엔드포인트에서 요청마다 동작을 바꿀 수 있습니다. 인프라 관리 복잡도가 줄어드는 건 맞습니다.
💡 “4개가 1개로”라는 말이 마케팅처럼 들릴 수 있는데, Hugging Face 모델 카드에 실제로 각 전임 모델과의 동작 동등성이 기술돼 있습니다. reasoning_effort=”none”은 Mistral Small 3.2와 동등, reasoning_effort=”high”는 Magistral Small과 동등한 출력을 낸다고 명시했습니다. (출처: HuggingFace mistralai/Mistral-Small-4-119B-2603, 2026.03.16)
텍스트와 이미지를 동시에 받아서 텍스트로 출력하는 멀티모달 구조도 포함돼 있습니다. 컨텍스트 윈도우는 256k 토큰으로, 긴 문서 분석이나 코드베이스 전체를 한 번에 넣는 에이전트 워크플로우에서 의미 있는 수치입니다.
reasoning_effort 파라미터, 생각보다 제약이 많습니다
Mistral Small 4의 핵심 기능 중 하나가 추론 강도를 요청마다 조절할 수 있다는 reasoning_effort 파라미터입니다. 그런데 막상 모델 카드를 보면 지원 값이 딱 두 가지뿐입니다. none과 high입니다. (출처: HuggingFace mistralai/Mistral-Small-4-119B-2603, 2026.03.16)
GPT-OSS처럼 low, medium, high 등 세밀하게 조절이 가능할 거라고 기대했다면 다른 결과를 만납니다. 독립 분석가 Nicolas Serrano가 공개한 채팅 템플릿 분석에서도 “실질적으로 Qwen3.5의 enable_thinking 스위치와 구조가 같다”는 결론이 나왔습니다. (출처: The Kaitchup 뉴스레터, 2026.03.21)
⚠️ 주의: reasoning_effort=”none”으로 설정하면 Small 3.2와 동등한 출력을 냅니다. 119B 모델을 올려서 24B 수준 성능을 쓰는 셈입니다. 추론을 끈 상태에서는 오히려 Small 3.2 대비 성능 향상이 거의 없습니다.
추론 모드를 끈 상태에서 Mistral Small 4 instruct와 Small 3.2를 비교한 Reddit 커뮤니티 벤치마크에서도 Small 4 instruct의 GPQA Diamond 점수가 59.1점으로, reasoning 모드 71.2점보다 12점 이상 낮게 나왔습니다. (출처: r/LocalLLaMA DistanceSolar1449, 2026.03.16) 이 12점 차이가 실제로 어느 사용 맥락에서 체감되는지를 먼저 따져봐야 합니다.
벤치마크 숫자가 보여주는 것과 감추는 것
Mistral 공식 발표에서 핵심으로 내세우는 수치가 하나 있습니다. AA LCR 벤치마크에서 Mistral Small 4가 0.72점을 기록하는데, 출력 길이가 1.6K 문자라는 점입니다. 비교 대상인 Qwen 모델들은 비슷한 점수를 내기 위해 5.8K~6.1K 문자, 즉 3.5~4배 더 긴 출력이 필요했습니다. LiveCodeBench에서도 GPT-OSS 120B보다 성능은 높으면서 출력은 20% 적었습니다. (출처: mistral.ai/news/mistral-small-4, 2026.03.16)
이 수치가 실제로 의미하는 건 “토큰당 효율”이 좋다는 겁니다. 같은 결론을 내기 위해 덜 씁니다. 추론 비용은 출력 토큰 수에 비례하기 때문에, 이 차이가 대규모 프로덕션 환경에서는 직접적인 비용 절감으로 이어집니다.
| 모델 | 파라미터 | GPQA Diamond | MMLU Pro | LiveCodeBench |
|---|---|---|---|---|
| Mistral Small 4 (추론) | 119B / 6.5B active | 71.2 | 78.0 | 63.6 |
| Mistral Small 4 (일반) | 119B / 6.5B active | 59.1 | 73.5 | — |
| Qwen3.5-35B-A3B | 35B / 3B active | 84.2 | 85.3 | 74.6 |
출처: r/LocalLLaMA DistanceSolar1449 커뮤니티 집계 (2026.03.16) / 모든 수치는 공개 벤치마크 기준
표를 보면 솔직히 좀 의아합니다. Qwen3.5-35B-A3B는 전체 파라미터가 35B이고 활성 파라미터는 3B에 불과한데, 모든 벤치마크에서 Small 4를 앞섭니다. GPQA Diamond 기준으로 84.2 vs 71.2, 무려 13점 차입니다. 이 차이를 “출력 효율”이라는 Mistral의 논점으로 덮기는 쉽지 않습니다.
로컬 구동 조건 — 이 GPU 없으면 포기하는 게 낫습니다
가장 많은 질문이 나올 부분입니다. RTX 4090이나 맥 스튜디오로 돌릴 수 있냐는 거죠. 직접 계산해보겠습니다. BF16 기준 전체 웨이트는 약 238GB입니다. Q4 양자화 시 약 60~70GB 수준으로 줄어듭니다. 공식 문서에서 권장하는 최소 하드웨어는 NVIDIA HGX H100 4대, HGX H200 2대, 또는 DGX B200 1대입니다. (출처: build.nvidia.com/mistralai/mistral-small-4-119b-2603, 2026.03.16) H100 단가를 생각하면 일반 개인이 접근할 수 있는 환경이 아닙니다.
KV 캐시는 MLA 아키텍처 덕분에 상대적으로 가볍습니다. 256k 컨텍스트 기준 BF16에서 약 5.49GiB, FP8에서 2.75GiB입니다. 이 수치는 Qwen3.5-122B 대비 6% 가볍지만, Nemotron 3 Super 대비로는 2.8배 무겁습니다. (출처: The Kaitchup 뉴스레터 KV cache 분석, 2026.03.21) KV 캐시 부담은 작은 편이지만, 모델 자체를 올리는 비용이 문제입니다.
💡 llama.cpp용 GGUF 파일은 Unsloth가 Hugging Face에 올려뒀습니다. 이론상으로는 대용량 시스템 RAM을 가진 환경에서 CPU 추론이 가능하나, 92GB DDR5 기준 초당 10~20 토큰 수준으로 체감 속도는 매우 느립니다. (Reddit r/LocalLLaMA, 2026.03.16)
vLLM은 현재 지원 중이나, 공식 문서에는 “tool calling과 reasoning parsing 수정 사항이 아직 메인 브랜치에 병합되지 않았다”고 명시돼 있습니다. Mistral 측이 커스텀 Docker 이미지를 제공하고 있고, 2~3주 내 메인에 통합될 예정이라고 했습니다. 지금 당장 프로덕션에 올리기엔 이 부분이 걸립니다.
그래서 언제 쓰면 유리한지
벤치마크만 보면 Qwen3.5에 밀리는 게 맞습니다. 그런데 Mistral 모델이 강점을 보이는 영역이 따로 있습니다. 유럽어 포함 다국어 지원, 시스템 프롬프트 준수도, 그리고 상대적으로 관대한 콘텐츠 필터입니다. Reddit 커뮤니티에서도 Mistral 모델을 쓰는 주된 이유로 이 세 가지가 반복해서 언급됩니다. 순수 벤치마크가 아닌 실제 서비스 요구사항에서 중요한 속성입니다.
또 하나의 실질적인 이점은 유럽 데이터 주권 이슈입니다. EU AI Act 적용 대상 기업이나 중국산 모델 사용을 제한받는 조직에서는 Apache 2.0 라이선스의 유럽 기원 모델이라는 점이 실질적인 선택 기준이 됩니다. 벤치마크 점수보다 이 조건이 우선인 상황이 분명 존재합니다.
💡 Mistral AI가 NVIDIA Nemotron Coalition 창립 멤버로 합류했다는 점도 이번 발표에 포함됐습니다. (출처: mistral.ai/news/mistral-small-4, 2026.03.16) NVIDIA 인프라 위에서 최적화된 NIM 컨테이너로 바로 배포 가능하다는 뜻이고, 엔터프라이즈 환경에서의 지원 접근성이 달라집니다.
파인튜닝도 고려할 수 있는 부분입니다. Apache 2.0 라이선스라 상업적 사용과 수정이 자유롭고, Axolotl을 통한 파인튜닝 예제도 공식 제공됩니다. 도메인 특화 모델을 만들 계획이라면 가장 유연한 선택지 중 하나입니다.
Q&A 5가지
Q1. Mistral Small 4를 RTX 4090 하나로 돌릴 수 있나요?
현실적으로 어렵습니다. RTX 4090의 VRAM은 24GB입니다. Q4 양자화 기준으로도 60~70GB가 필요하기 때문에 단독으로는 불가능합니다. 다만 대용량 시스템 RAM(128GB 이상)이 있다면 CPU 오프로딩으로 구동 자체는 가능하나, 속도가 실용 수준이 아닙니다. API로 사용하는 게 현재로선 가장 현실적입니다.
Q2. reasoning_effort를 medium으로 설정할 수 있나요?
현재는 불가능합니다. 공식 모델 카드와 채팅 템플릿을 분석한 결과, none과 high 두 값만 지원됩니다. GPT-OSS처럼 세밀한 조절은 지원하지 않으며, Qwen3.5의 enable_thinking 방식과 구조적으로 같습니다. Mistral이 추후 업데이트에서 이 부분을 확장할지는 아직 공개된 내용이 없습니다.
Q3. 한국어 성능은 어떤가요?
Hugging Face 모델 카드에 한국어가 공식 지원 언어 목록에 포함돼 있습니다. 그러나 한국어 특화 벤치마크 결과는 공식 발표문에 포함되지 않았습니다. 한국어 성능에 대한 공식 수치를 Mistral이 별도로 공개하지 않은 상황입니다.
Q4. Small 4가 Qwen3.5-122B보다 뭐가 더 낫나요?
두 가지 측면에서 Small 4가 앞섭니다. 첫째, 같은 성능을 내는 데 필요한 출력 토큰 수가 적습니다. AA LCR에서 Small 4는 1.6K 문자, Qwen은 5.8~6.1K 문자가 필요했습니다. (출처: mistral.ai/news/mistral-small-4) 둘째, KV 캐시가 약 6% 가볍습니다. 단, 순수 정확도 벤치마크에서는 Qwen3.5-122B가 대부분 앞섭니다.
Q5. vLLM로 지금 바로 배포 가능한가요?
배포는 가능하나 완전하지 않습니다. 2026년 3월 16일 기준으로 tool calling 및 reasoning parsing 수정 사항이 vLLM 메인 브랜치에 아직 병합되지 않았습니다. Mistral이 제공하는 커스텀 Docker 이미지(mistralllm/vllm-ms4:latest)를 사용해야 하며, 메인 브랜치 통합은 1~2주 내 예정이라고 명시돼 있습니다.
마치며
Mistral Small 4를 한 줄로 요약하면 이렇습니다. “4개 모델을 1개로 통합한 건 실용적인 결정이고, 출력 효율도 진짜입니다. 다만 벤치마크 정확도에서 Qwen3.5 계열에 밀리고, 로컬 구동 문턱은 여전히 높습니다.”
개인적으로 가장 흥미로웠던 부분은 KV 캐시 구조입니다. MLA 아키텍처로 256k 컨텍스트에서 BF16 기준 5.49GiB만 쓴다는 건 긴 문서 처리 비용을 실질적으로 낮춰줍니다. 그 반면에 reasoning_effort가 none/high 이분법만 지원한다는 건 아쉬운 부분입니다. 같은 급 모델들과 비교했을 때 이 유연성 부재가 실무에서 가장 먼저 걸리는 지점이 될 것 같습니다.
EU 데이터 주권이나 Apache 2.0 파인튜닝 자유도가 중요한 조직이라면 지금도 충분히 검토할 이유가 있습니다. 순수 성능 경쟁만 놓고 보면 3월 현재 Qwen3.5-35B-A3B가 파라미터 대비 더 좋은 선택입니다.
본 포스팅 참고 자료
- ① Mistral AI 공식 발표 — Introducing Mistral Small 4
https://mistral.ai/news/mistral-small-4 - ② Hugging Face 공식 모델 카드 — mistralai/Mistral-Small-4-119B-2603
https://huggingface.co/mistralai/Mistral-Small-4-119B-2603 - ③ NVIDIA NIM 모델 카드 — mistral-small-4-119b-2603
https://build.nvidia.com/mistralai/mistral-small-4-119b-2603/modelcard - ④ The Kaitchup 뉴스레터 — Mistral Small 4 KV 캐시 분석 (2026.03.21)
https://kaitchup.substack.com/p/mistral-small-4-a-good-alternative - ⑤ Reddit r/LocalLLaMA — 커뮤니티 벤치마크 비교 (2026.03.16)
https://www.reddit.com/r/LocalLLaMA/comments/1rvlfbh/
본 포스팅은 2026년 3월 22일 기준으로 작성됐습니다. Mistral Small 4 (버전 119B-2603) 공식 문서 및 공개 커뮤니티 자료를 바탕으로 합니다. 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. 특히 vLLM 통합, reasoning_effort 파라미터 지원 범위, 벤치마크 수치는 이후 업데이트에 따라 달라질 수 있으니 최신 공식 문서를 직접 확인하세요.
댓글 남기기