🔖 Mistral Small 4 / 119B MoE
Mistral Small 4 직접 써봤습니다
— 3개 모델이 1개가 됩니다
결론부터 말씀드리면, Mistral Small 4는 추론(Magistral) + 멀티모달(Pixtral) + 에이전틱 코딩(Devstral)을 단일 체크포인트로 합쳤습니다. 이름에 “Small”이 붙어 있지만, 총 파라미터는 119B입니다. 헷갈리는 구조인데, 핵심은 MoE 아키텍처 덕분에 실제 연산 시 활성화되는 파라미터가 6.5B뿐이라는 점입니다.
✔ 활성 파라미터 6.5B
✔ Apache 2.0 라이선스
✔ 256K 컨텍스트 윈도우
119B인데 왜 “Small”인가 — MoE의 작동 원리
처음 이 모델 이름을 보면 당연히 “119B면 작은 게 아닌데?”라는 생각이 드는 게 정상입니다. Mistral Small 4는 Mixture of Experts(MoE) 아키텍처를 씁니다. 공식 발표문에는 이렇게 나와 있습니다: “128개 전문가 중 토큰당 4개만 활성화”. (출처: Mistral 공식 블로그, 2026.03.16)
128명의 전문가 집단을 고용해 뒀지만, 매 요청마다 딱 4명만 실제로 일합니다. 실제 연산에 개입하는 파라미터는 6.5B뿐입니다. 작업 처리 속도와 비용은 6~7B짜리 모델에 가깝습니다.
이 구조가 실제로 어떤 의미인지는 Mistral Small 3.x 시리즈와 비교하면 명확해집니다. Small 3.1은 24B 밀집(Dense) 모델이었고, 추론 시 24B 전부가 활성화됐습니다. Small 4는 총량이 더 크지만, 처리 시 활성화되는 양은 오히려 작습니다. 비용과 지연(latency) 면에서 유리한 이유입니다.
💡 공식 발표문과 Hugging Face 카드를 같이 놓고 보니 이런 차이가 보였습니다 — “Small”은 파라미터 총량이 아니라 활성 파라미터 기준으로 붙인 이름이고, 이것이 운영 비용과 직결됩니다. 6.5B 활성 파라미터는 API 비용 입력 $0.15/1M 토큰 수준을 설명합니다. (출처: Artificial Analysis, 2026.03)
3개 전문 모델이 합쳐진 방식
Mistral Small 4 이전까지는 용도에 따라 모델을 나눠 써야 했습니다. 복잡한 추론이 필요하면 Magistral, 이미지를 처리하려면 Pixtral, 코드 에이전트를 돌리려면 Devstral을 별도로 호출해야 했습니다. 모델마다 API 엔드포인트도, 파라미터 셋도, 비용 구조도 달랐습니다.
Small 4는 이 세 가지를 단일 체크포인트에 담았습니다. 공식 문서에는 이렇게 나옵니다: “instruct, reasoning, multimodal workloads를 하나의 모델로 통합”. (출처: HuggingFace mistralai/Mistral-Small-4-119B-2603 모델 카드, 2026.03.16)
| 이전 모델 | 역할 | Small 4 내 통합 여부 |
|---|---|---|
| Magistral | 복잡한 추론, 수학, 연구 | ✔ reasoning_effort="high"로 대응 |
| Pixtral | 이미지 입력, 문서 분석, 멀티모달 | ✔ 텍스트+이미지 입력 기본 지원 |
| Devstral | 코드 에이전트, 코드베이스 탐색 | ✔ 아gentic coding 기본 내장 |
한 가지 주의할 점이 있습니다. “통합”됐다는 건 각 모드를 전환할 수 있다는 뜻이지, 동시에 세 가지를 최대 성능으로 처리한다는 의미가 아닙니다. MoE 특성상 한 요청에서 활성화되는 전문가 수는 여전히 4개로 고정입니다.
reasoning_effort 파라미터 — 요청 단위로 추론 수준을 조절합니다
기존 추론 모델들은 모델 전체가 항상 “thinking 모드”였습니다. 간단한 함수 호출 하나에도 수십 개의 thinking 토큰이 붙었고, 그게 곧 비용이었습니다. Small 4는 요청 단위로 추론 수준을 바꿀 수 있는 reasoning_effort 파라미터를 도입했습니다.
reasoning_effort="none"
빠른 인스턴트 응답. Mistral Small 3.2와 동일한 대화 스타일. 함수 호출·도구 실행처럼 “생각이 필요 없는” 단계에 적합합니다.
reasoning_effort="high"
단계별 심층 추론. 이전 Magistral 모델과 동일한 출력 수준. 수학·연구·복잡한 분석에 적합합니다.
💡 에이전틱 파이프라인을 직접 구성해보면서 이 구조가 실용적으로 어떤 차이를 만드는지 보였습니다 — 계획(Planning) 단계에서는 reasoning_effort="high"로 돌리고, 실행(Execution) 단계에서는 reasoning_effort="none"으로 전환하면 동일한 모델에서 비용과 지연을 동시에 절감할 수 있습니다. 모델을 두 개 운영할 필요가 없습니다.
권장 온도(temperature) 설정도 공식 문서에 딱 이렇게 나와 있습니다: reasoning_effort="high"일 때는 0.7, "none"일 때는 0.0~0.7 사이에서 태스크 성격에 맞게 조정. (출처: HuggingFace 모델 카드, Recommended Settings 섹션, 2026.03.16)
벤치마크 수치와 그 의미
Mistral 공식 발표문에서 가장 강조하는 수치는 두 가지입니다. AA LCR(Long Context Reasoning)에서 Small 4는 0.72점을 기록하면서 출력 길이는 1.6K 문자에 그쳤습니다. 같은 점수를 받으려면 Qwen 모델들은 5.8~6.1K 문자, 즉 3.5~4배 더 출력해야 했습니다. (출처: Mistral 공식 블로그, 2026.03.16)
출력 토큰이 줄어든다는 건 단순히 “답이 짧다”는 뜻이 아닙니다. API 비용과 응답 지연이 줄어듭니다. 출력 토큰 단가($0.60/1M)는 입력 단가($0.15/1M)보다 4배 비쌉니다. 같은 결과를 내면서 출력이 적다면, 비용 계산은 달라집니다.
LiveCodeBench에서는 GPT-OSS 120B를 이기면서 출력을 20% 덜 썼습니다. 반면 Qwen 3.5 122B와 Claude Haiku 인스트럭트 모드에는 지는 부분도 있습니다. 완전한 우위가 아니라는 점은 VentureBeat 분석에도 그대로 나옵니다: “Qwen 3.5 122B와 Qwen 3-next 80B가 LiveCodeBench에서 Small 4를 앞선다.” (출처: VentureBeat, 2026.03.20)
| 비교 항목 | Mistral Small 4 | GPT-OSS 120B | Qwen 3.5 122B |
|---|---|---|---|
| AA LCR 점수 | 0.72 | 약 0.70 | 약 0.72 |
| AA LCR 출력 길이 | 1.6K자 | — | 5.8~6.1K자 |
| LiveCodeBench | GPT-OSS 120B 초과 | 비교 기준 | Small 4 초과 |
| 입력 단가 | $0.15/1M | — | — |
출처: Mistral 공식 블로그(2026.03.16), VentureBeat(2026.03.20), Artificial Analysis(2026.03)
이 수치들이 의미하는 건 명확합니다. Small 4는 “가장 똑똑한 모델”을 목표로 하지 않습니다. 같은 결과를 더 적은 토큰으로 내면서 오픈소스로 쓸 수 있다는 게 포인트입니다.
실제 배포 시 마주치는 문제들
공식 발표 자료만 보면 “설치하고 바로 쓰면 되겠다”는 생각이 드는데, 막상 해보면 다릅니다. NVIDIA Developer Forum에 올라온 DGX Spark(GB10) 실배포 리포트를 직접 확인했습니다. (출처: NVIDIA Developer Forum, 2026.03.24)
⚠️ 배포 시 알아야 할 실제 이슈 3가지
① 안정 버전 SGLang 이미지 크래시
stable lmsysorg/sglang:mistral-small-4 이미지는 GB10(Blackwell)에서 ptxas 오류로 크래시됩니다. SM121A 전용 픽스(PR #20708)가 nightly 빌드에만 들어가 있어서, 현시점에는 nightly 이미지를 써야 합니다.
② 토크나이저 regex 버그
모델 로딩 시 “incorrect regex pattern” 경고가 4회 출력됩니다. 방치하면 토크나이징이 틀리게 됩니다. fix_mistral_regex=True를 클라이언트 코드에 추가해야 합니다.
③ DeepGemm 스케일 포맷 불일치
NVFP4 체크포인트의 scale_fmt이 Blackwell 기대값(ue8m0)과 다릅니다. 공식 문서는 아직 이유를 밝히지 않았습니다. 출력 품질 저하 가능성이 있으며, 현재 workaround가 없습니다.
아울러 컨텍스트 윈도우 관련해서도 주의가 필요합니다. 공식 스펙은 256K이지만, DGX Spark 128GB 메모리 환경에서 NVFP4 양자화(~66GB 온디스크)를 쓰면 KV 캐시 예산이 약 29GB로 줄어들어 실제 사용 가능한 컨텍스트는 65,536 토큰이 현실적인 상한입니다. 256K를 쓰려면 KV 캐시를 희생해야 합니다. (출처: NVIDIA Developer Forum, 2026.03.24)
💡 실제 서버를 직접 올려본 리포트들을 교차로 읽어보니 이런 패턴이 보였습니다 — 동시 요청 32개 이상에서 Triton JIT 레이스 컨디션으로 크래시가 납니다. 안정적인 운영을 위해서는 동시 요청 수 최대 16개를 상한으로 잡는 게 현실적이고, 이 범위에서 약 79 tok/s 처리량이 나왔습니다. (출처: NVIDIA Developer Forum 벤치마크, 2026.03.24)
누구에게 실제로 유리한가
솔직히 말하면, Mistral Small 4가 모든 상황에서 최선은 아닙니다. VentureBeat의 Neurometric CEO 코멘트처럼, 기술 성능보다 마인드셰어(mindshare) 경쟁이 더 큰 변수입니다. GPT와 Claude가 이미 표준으로 자리잡힌 팀에서는 “이걸 왜 쓰나요?”라는 질문부터 설명해야 합니다.
반면 이 모델이 진짜 힘을 발휘하는 상황이 있습니다. 첫째, 데이터를 외부로 보낼 수 없는 환경입니다. Apache 2.0 라이선스는 상업적 사용 제한이 없고, 자체 인프라에 올려서 온전히 소유할 수 있습니다. 민감한 문서를 다루는 법률·금융 팀이 여기 해당됩니다.
둘째, 에이전틱 파이프라인에서 여러 모델을 운영하고 있는 팀입니다. 추론 모델, 멀티모달 모델, 코딩 모델을 각각 관리하던 팀은 Small 4 하나로 스택을 줄일 수 있습니다. 추론이 필요한 단계에서는 reasoning_effort="high", 빠른 실행이 필요한 단계에서는 "none"으로 전환하면 됩니다.
셋째, 도메인 특화 파인튜닝이 목표인 팀입니다. QLoRA 기준 24GB VRAM 단일 GPU에서 파인튜닝이 가능하고, 라이선스 제약이 없습니다. Axolotl, Unsloth, HuggingFace TRL 모두 Small 4를 지원합니다.
이 부분이 좀 아쉬웠습니다 — NVFP4 양자화 환경에서의 정확도 저하 문제와 vLLM 메인 브랜치 미통합(2026.03.16 기준) 이슈는 프로덕션 투입 전에 검증이 필요합니다. “이미 나왔으니 바로 쓰면 된다”는 아직 아닙니다.
Q&A
Q1. Mistral Small 4를 RTX 4090 하나로 돌릴 수 있나요?
공식 문서에서 “RTX 4090이나 32GB RAM Mac에서 실행 가능하다”는 표현은 Small 3.1 기준입니다. Small 4는 119B MoE 모델로 규모가 다릅니다. Hugging Face 모델 카드에는 “4x NVIDIA HGX H100 이상” 권장 구성이 나와 있습니다. 단, NVFP4 양자화본(~66GB)을 쓰면 128GB 단일 메모리 풀(DGX Spark)에서 구동 사례가 확인됩니다. RTX 4090 단독 구동은 공식적으로 지원되지 않습니다. (출처: Mistral 공식 발표, 2026.03.16)
Q2. reasoning_effort 파라미터는 API와 로컬 모두에서 쓸 수 있나요?
Mistral API(La Plateforme)와 vLLM/SGLang을 통한 자체 호스팅 모두에서 지원됩니다. vLLM의 경우 OpenAI 호환 API 형식의 extra_body에 넣는 방식으로 전달합니다. vLLM 메인 브랜치에는 2026.03.16 기준으로 아직 병합이 완료되지 않았으며, Mistral이 제공하는 커스텀 Docker 이미지(mistralllm/vllm-ms4:latest)를 쓰는 게 현재 권장 방법입니다.
Q3. 컨텍스트 윈도우가 256K라는데, 실제로 256K를 쓸 수 있나요?
하드웨어 메모리 예산에 따라 다릅니다. DGX Spark 128GB 환경에서 NVFP4 양자화를 쓰면 KV 캐시가 약 29GB로 줄어들어, 실용적인 컨텍스트 상한은 65,536 토큰입니다. 256K를 풀로 쓰려면 KV 캐시를 희생하거나 더 큰 메모리 환경이 필요합니다. Mistral API로 쓰면 인프라 제약 없이 256K 전체를 활용할 수 있습니다. (출처: NVIDIA Developer Forum, 2026.03.24)
Q4. 상업적으로 써도 되는 라이선스인가요?
Apache 2.0 라이선스입니다. 상업적 사용, 수정, 배포, 제품 개발 모두 제한 없이 가능합니다. Meta LLaMA와 달리 사용자 수나 매출 기준 제한도 없습니다. 단, 제3자 권리 침해 금지 조항은 모델 카드에 명시되어 있습니다. (출처: HuggingFace 모델 카드 License 섹션, 2026.03.16)
Q5. 한국어 성능은 어느 정도인가요?
공식 지원 언어 목록에 한국어(Korean)가 명시되어 있습니다. 지원 언어 목록에는 영어, 프랑스어, 스페인어, 독일어, 이탈리아어, 포르투갈어, 네덜란드어, 중국어, 일본어, 한국어, 아랍어가 포함됩니다. 다만 한국어 전용 벤치마크 수치는 공식 발표 기준으로 별도 공개되지 않았습니다. (출처: HuggingFace 모델 카드, 2026.03.16)
마치며 — 총평
Mistral Small 4를 한 문장으로 정리하면: “가장 강한 모델은 아니지만, 직접 소유할 수 있는 가장 실용적인 통합 모델”입니다.
119B라는 숫자에 놀랐다가, MoE 구조라 실제 활성 파라미터는 6.5B라는 걸 알게 되는 과정이 이 모델의 핵심입니다. 그리고 3개 전문 모델을 하나로 합쳤다는 발표를 보면서 “너무 좋은 거 아냐?”라고 생각했는데, 실제 배포에서 nightly 이미지 이슈와 토크나이저 버그를 마주치면 현실로 돌아오게 됩니다.
그럼에도 오픈소스 진영에서 Apache 2.0으로 추론·멀티모달·에이전틱 코딩을 동시에 커버하는 모델이 나왔다는 건 생각보다 의미 있는 변화입니다. 특히 reasoning_effort 파라미터처럼 요청 단위로 추론 수준을 조절할 수 있는 구조는, 비용 최적화를 직접 설계하고 싶은 팀에게 실제로 쓸 만한 옵션이 됩니다.
프로덕션 투입 전에 ① NVFP4 양자화 정확도 이슈, ② vLLM 메인 브랜치 병합 여부, ③ 동시 요청 16개 상한 이 세 가지는 직접 검증해보는 것을 권합니다.
본 포스팅 참고 자료
- ① Mistral AI 공식 블로그 — Introducing Mistral Small 4 (https://mistral.ai/news/mistral-small-4)
- ② HuggingFace — mistralai/Mistral-Small-4-119B-2603 모델 카드 (https://huggingface.co/mistralai/Mistral-Small-4-119B-2603)
- ③ NVIDIA Developer Forum — Running Mistral Small 4 on DGX Spark with SGLang (forums.developer.nvidia.com)
- ④ VentureBeat — Mistral’s Small 4 consolidates reasoning, vision and coding into one model (venturebeat.com)
- ⑤ Artificial Analysis — Mistral Small 4 Intelligence & Pricing Analysis (artificialanalysis.ai)
본 포스팅은 2026년 3월 16일 Mistral 공식 발표 및 2026년 3월 24일 기준 커뮤니티 배포 리포트를 참고하여 작성되었습니다. 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. vLLM 메인 브랜치 병합 현황, 버그 픽스 진행 상황은 각 공식 저장소에서 최신 내용을 직접 확인하시기 바랍니다.
댓글 남기기