Apache 2.0 오픈소스
Mistral Small 4 직접 써봤습니다 — 세 모델이 하나로
Mistral Small 4가 나왔을 때 첫 반응은 솔직히 “또 이름만 Small이고 크네”였습니다. 119B 파라미터, 최소 H100 4장. 근데 실제로 뜯어보니 생각보다 다른 구석이 있었습니다. 추론·비전·코딩 에이전트, 세 전문 모델이 하나로 통합된 구조이고 — 실제 연산에 쓰이는 파라미터는 6.5B에 불과합니다.
‘작다’는 이름이 붙은 119B 모델의 실체
Mistral Small 4의 전체 파라미터는 119억 개(119B)입니다. “Small”이라는 이름이 붙었지만, 일반적으로 소형 모델이라 불리는 7B·14B 모델과는 차원이 다른 크기입니다. 처음 발표를 봤을 때 “이게 왜 Small이야”라는 반응이 나온 게 당연합니다. Reddit의 r/LocalLLaMA에서도 “최소 Medium이라고 불려야 한다”는 댓글이 상위권에 올라왔을 정도입니다.
그런데 MoE(Mixture of Experts) 구조를 보면 이야기가 달라집니다. 총 128개의 전문가(expert) 중, 하나의 토큰을 처리할 때 실제로 활성화되는 전문가는 4개뿐입니다. 그 결과 토큰당 실제로 작동하는 파라미터는 6.5B에 그칩니다. 즉, 119B의 지식 풀을 가지고 있지만 추론 연산 비용은 약 6B 모델과 비슷한 수준입니다.
이 구조 덕분에 Mistral는 Small 3 대비 처리 속도를 40% 단축하고, 같은 인프라에서 초당 처리량을 3배 늘렸다고 공식 발표에서 밝혔습니다. (출처: Mistral AI 공식 발표, 2026.03.16)
💡 공식 발표문의 아키텍처 수치를 실제 추론 흐름에 대입해봤더니, 119B 전체를 돌리는 것처럼 보여도 연산 부담은 6B급과 비슷합니다. 이름 때문에 오해받는 부분입니다.
세 모델을 하나로 — 통합의 실제 의미
Mistral Small 4 이전에는 용도에 따라 다른 모델을 선택해야 했습니다. 깊은 수학적 추론이 필요하면 Magistral, 이미지나 문서 분석이 필요하면 Pixtral, 코드 에이전트 자동화에는 Devstral을 따로 올려야 했습니다. 하나의 서비스에서 세 가지 기능이 모두 필요하다면, 엔드포인트도 세 개, 인프라 비용 항목도 세 줄이었습니다.
Small 4는 이 세 가지를 단일 모델로 통합했습니다. 텍스트와 이미지 입력을 동시에 처리하고, API 파라미터 하나(reasoning_effort)로 일상적인 채팅 응답과 단계별 심층 추론 사이를 전환할 수 있습니다. 코드 에이전트 기능도 네이티브 함수 호출(function calling)과 JSON 구조화 출력을 지원합니다. (출처: Mistral AI 공식 발표, 2026.03.16)
실무적으로 가장 큰 변화는 운영 복잡성입니다. 고객 지원 챗봇을 예로 들면, 단순 FAQ 질문에는 빠른 응답 모드로, 계약서 검토처럼 복잡한 질문에는 추론 모드로 하나의 엔드포인트에서 대응할 수 있습니다.
💡 Magistral·Pixtral·Devstral 세 모델을 각각 관리하던 팀이라면, 인프라 유지 포인트가 셋에서 하나로 줄어드는 셈입니다. 모델 교체 주기도 하나만 챙기면 됩니다.
reasoning_effort 파라미터, 쓰다 보면 아쉬운 부분
Mistral Small 4의 핵심 기능 중 하나는 요청마다 추론 깊이를 조절할 수 있다는 것입니다. 파라미터는 reasoning_effort로, reasoning_effort="none"으로 설정하면 Mistral Small 3.2 수준의 빠른 응답을, reasoning_effort="high"로 설정하면 이전 Magistral 모델 수준의 단계별 심층 추론을 받을 수 있습니다. (출처: Mistral AI HuggingFace 모델 카드, 2026.03.16)
그런데 현재 지원되는 값이 “none”과 “high” 둘뿐이라는 점이 아쉬운 부분입니다. OpenAI의 GPT-OSS나 다른 추론 모델들은 low·medium·high처럼 중간 단계를 지원하는데, Small 4는 아직 이분법적 선택만 가능합니다. Reddit의 실사용 후기에서도 “사실상 그냥 enable_thinking 플래그와 같다”는 지적이 나왔습니다. 중간 강도의 추론을 원하는 경우에는 현재로서는 조절 수단이 없습니다. Mistral AI가 공식적으로 추가 단계 지원 계획을 밝히지 않은 상태입니다.
추론 모드(“high”)를 켤 경우 권장 온도(temperature)는 0.7, 기본 모드(“none”)에서는 0.0~0.7 범위로 작업 유형에 맞게 설정하라고 공식 문서에서 안내하고 있습니다. 이 설정을 놓치면 응답 품질이 일관되지 않을 수 있습니다. (출처: Mistral AI Docs, 2026.03.16)
주의: reasoning_effort=”none”에서 코딩 테스트를 돌렸을 때 응답이 중간에 잘리는 문제가 llama.cpp 커뮤니티에서 보고되었습니다. 이는 llama.cpp 구현 문제일 가능성이 높지만, API를 통한 사용에서도 복잡한 코드 생성 시 주의가 필요합니다.
벤치마크 수치, 직접 계산해봤습니다
공식 발표에서 가장 눈에 띄는 수치는 AA LCR(Long Context Reasoning) 벤치마크 결과입니다. Small 4는 0.72 점수를 기록하면서 출력 길이는 1,600자에 불과했습니다. 반면 비슷한 점수를 낸 Qwen 3.5-122B는 5,800~6,100자 분량의 응답을 생성했습니다. 즉, 같은 품질의 답변을 3.5~4배 짧게 냅니다. 짧을수록 청구 토큰이 줄고 레이턴시도 줄어듭니다. (출처: Mistral AI 공식 발표 / HuggingFace 모델 카드, 2026.03.16)
| 모델 | AA LCR 점수 | 평균 출력 길이 | 라이선스 |
|---|---|---|---|
| Mistral Small 4 | 0.72 | 1,600자 | Apache 2.0 |
| Qwen 3.5-122B | 유사 | 5,800~6,100자 | Apache 2.0 |
| GPT-OSS 120B | 하회 | Small 4보다 20% 길음 | 독점 |
출처: Mistral AI 공식 발표 (2026.03.16) / Hugging Face 모델 카드
GPQA Diamond와 MMLU-Pro 벤치마크에서도 Small 4는 각각 71.2%와 78.0%를 기록해 GPT-4o-mini(40.2%, 64.8%)를 크게 앞섰습니다. (출처: emelia.io Mistral Small 4 가이드, 2026.03.17)
다만 일부 커뮤니티에서는 “Qwen 3.5와 GPQA Diamond 등 전체 벤치마크를 직접 비교하지 않았다”는 지적도 있었습니다. Mistral가 주로 자체 이전 세대 모델과의 비교를 전면에 내세웠다는 점은 참고할 필요가 있습니다.
로컬에서 돌리려면 지금 당장은 무리입니다
“오픈소스니까 집에서 돌려볼 수 있겠지”라고 생각했다면, 지금 당장은 기대를 낮추는 것이 좋습니다. 공식 문서 기준 최소 요구 사항은 NVIDIA H100 4장 또는 H200 2장입니다. RTX 4090 기준으로는 NVFP4 양자화 체크포인트를 쓰더라도 단일 카드로는 동작하지 않습니다. (출처: Mistral AI 공식 발표, 2026.03.16)
더 현실적인 문제는 llama.cpp와 Ollama 지원입니다. 출시 시점 기준 llama.cpp의 PR(풀 리퀘스트)이 아직 메인 브랜치에 머지되지 않은 상태였습니다. Mistral AI 공식 HuggingFace 노트에 “2026년 3월 16일 현재, 1~2주 내 머지 예정”이라고 명시되어 있습니다. 실제 커뮤니티에서도 출시 직후 llama.cpp로 실행한 일부 사용자들이 코딩 응답 중간 잘림, 비전 환각(hallucination), 아시아 언어 출력 오류 등을 보고했습니다. (출처: r/LocalLLaMA, 2026.03.17)
현재 가장 안정적인 방법은 Mistral가 직접 제공하는 커스텀 Docker 이미지(mistralllm/vllm-ms4:latest)를 사용하거나, 공식 Mistral API를 쓰는 것입니다. vLLM 메인 PR이 머지된 이후 다시 로컬 배포를 시도해보는 것이 현명합니다.
주의: Ollama로 Mistral Small 4를 사용하려는 경우, 현재(2026.03.27 기준) llama.cpp PR이 머지 대기 중입니다. 안정화되기 전까지 프로덕션 환경 투입은 권장되지 않습니다.
가격 구조와 실제 비용 계산
Mistral API를 통해 Small 4를 사용할 경우, 공식 문서 기준 입력 토큰 $0.15/1M, 출력 토큰 $0.60/1M입니다. (출처: Mistral AI 공식 문서, 2026.03.16) 이 수치를 기준으로 실제 비용을 계산해볼 수 있습니다.
💰 비용 계산 예시 (추론 모드 ON 기준)
• 하루 1,000건의 문서 요약 처리 (건당 평균 입력 2,000토큰, 출력 500토큰)
• 입력: 2,000,000 토큰 × $0.15 / 1,000,000 = $0.30
• 출력: 500,000 토큰 × $0.60 / 1,000,000 = $0.30
→ 하루 총 약 $0.60, 한 달 약 $18 수준
AA LCR 벤치마크에서 Small 4가 Qwen 3.5-122B보다 3.5~4배 짧은 응답을 생성한다는 점을 적용하면 출력 비용이 그만큼 줄어듭니다. 토큰 효율성이 실제 청구 비용에 직결됩니다.
자체 서버 배포 시에는 Apache 2.0 라이선스로 API 비용이 없지만, H100 4장 임대 기준 월 클라우드 비용이 수천 달러 이상 발생합니다. 요청 규모가 충분히 크지 않다면 API가 경제적입니다. NVIDIA NIM에서는 무료 프로토타이핑도 가능합니다.
어떤 경우에 쓸 만하고, 어떤 경우에는 다른 걸 보는 게 낫습니다
지금 Mistral Small 4가 가장 잘 맞는 상황은, 이미 Mistral 생태계를 쓰고 있는데 Magistral·Pixtral·Devstral을 함께 운영하는 팀입니다. 세 엔드포인트를 하나로 줄이는 것 자체로 관리 부담이 줄고, 모델 간 컨텍스트 전달 문제도 사라집니다. 특히 유럽 데이터 주권(GDPR) 요건으로 데이터를 외부로 내보낼 수 없는 환경이라면, Apache 2.0으로 자체 배포가 가능한 Small 4의 매력이 큽니다.
반면 지금 당장 Ollama나 llama.cpp 기반의 로컬 환경에서 돌리려는 경우, 또는 Qwen 계열 모델과의 비전 성능 비교가 주요 판단 기준인 경우라면 조금 더 기다리는 것이 낫습니다. 출시 직후 커뮤니티에서 비전 환각 및 아시아 언어 혼용 문제가 보고되었고, llama.cpp 공식 지원이 아직 완료되지 않은 상태입니다.
개인적으로 지켜보는 포인트는 reasoning_effort에 “medium” 같은 중간값이 추가되는지 여부입니다. 현재의 이분법 구조는 실제 프로덕션에서 세밀한 비용 최적화를 어렵게 만들고, 그 부분은 경쟁 모델 대비 아쉬운 점입니다.
자주 나오는 질문 5가지
마치며 — 기대만큼 쓸 만한가요?
Mistral Small 4는 이름과 달리 작지 않지만, 작게 쓸 수 있는 모델입니다. MoE 구조 덕분에 119B의 지식을 6.5B의 추론 비용으로 쓸 수 있고, 세 전용 모델을 하나로 통합한 점은 실제 운영 팀에겐 의미 있는 변화입니다.
다만 출시 직후 로컬 배포 미완성, reasoning_effort의 이분법 구조, 비전 성능에 대한 커뮤니티 의구심은 지금 당장 모든 팀에 권장하기 어려운 이유입니다. Mistral 생태계 기존 사용자, 데이터 주권이 중요한 기업, API 비용을 줄이고 싶은 팀에겐 지금 테스트해볼 가치가 충분합니다. llama.cpp PR 머지 이후 로컬 사용자에게도 선택지가 넓어질 것입니다.
아직 완전히 풀리지 않은 부분이 있는 만큼, 당장 프로덕션에 올리기보다는 NVIDIA NIM 무료 크레딧으로 먼저 자신의 워크로드에 맞는지 확인해보는 것을 권합니다.
📚 본 포스팅 참고 자료
※ 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. Mistral Small 4는 2026년 3월 16일(v26.03) 기준으로 작성되었으며, 이후 모델 업데이트·API 가격·배포 지원 범위가 달라질 수 있습니다. 가격 및 사양은 공식 문서에서 최신 정보를 확인하시기 바랍니다.
댓글 남기기