# MiniMax M3.1 Flash 용량: 252GB, 허깅페이스 버전별 GB와 필요 메모리

> MiniMax M3.1 Flash는 전체 428B·활성 23B, 공식 가중치 252.4GB로 가볍지 않습니다. 256GB 장비는 3비트 GGUF·MLX까지, 그 아래는 API가 현실적입니다.

- URL: https://blog.laozhang.ai/ko/posts/minimax-m3-1-flash-size
- Published: 2026-10-25
- Updated: 2026-10-25
- Author: LaoZhang AI Team (https://blog.laozhang.ai/ko/about)
- Topic: 개발 도구·에이전트
- Tags: MiniMax M3.1 Flash, 허깅페이스, 로컬 LLM, 양자화, GGUF, vLLM

---
MiniMax M3.1 Flash(미니맥스 M3.1 플래시)는 이름과 달리 작은 모델이 아닙니다. 공식 모델 카드 기준으로 전체 파라미터는 약 428B(4,280억 개), 토큰마다 계산에 쓰이는 활성 파라미터는 약 23B이고, 2026년 10월 23일 가중치가 공개된 Hugging Face 공식 저장소 `MiniMaxAI/MiniMax-M3.1-Flash`를 통째로 받으면 252.4GB입니다. 파라미터 수는 이전 모델인 MiniMax M3와 같습니다. "Flash"는 전문가 가중치를 처음부터 4비트로 학습시켜(양자화 인식 학습, QAT) 다운로드를 M3의 854.2GB에서 약 3.4분의 1로 줄였다는 뜻이고, Hugging Face 페이지에 보이는 "220B params"도 4비트 값을 묶어 저장한 데서 생긴 표시일 뿐입니다.

그래서 무엇을 받을지는 장비 메모리가 정합니다. H100·H200 8장이나 Blackwell(B200·B300) 4장짜리 GPU 서버라면 공식 저장소를 vLLM 0.33.0 이상으로 띄우면 됩니다. Mac Studio 512GB라면 `mlx-community/MiniMax-M3.1-Flash-Text-4bit`, Mac Studio 256GB나 DGX Spark 두 대 같은 256GB급 장비라면 `unsloth/MiniMax-M3.1-Flash-GGUF`의 UD-Q3_K_XL이나 MLX 3비트가 상한이고, GGUF는 llama.cpp b11861 이상 빌드에서만 출력이 정상입니다. 메모리가 128GB 이하이거나 GPU가 한 장뿐이라면 로컬 구동보다 MiniMax API(100만 토큰당 입력 $0.15, 출력 $0.60)를 쓰는 편이 현실적입니다.

아래 용량은 2026년 10월 25일 기준으로 Hugging Face API에서 각 저장소의 파일 크기를 합산한 값이고, 파라미터 수는 공식 `config.json`으로 다시 계산했으며, 장비별로 들어가는지도 그 숫자로 계산했습니다. 가중치를 내려받아 직접 실행하지는 않았으므로 속도와 품질에 관한 내용은 vLLM·SGLang 문서와 커뮤니티 보고에서 왔고, 출처는 해당 문단에 적었습니다.

## MiniMax M3.1 Flash 용량: 428B 파라미터, 공식 다운로드 252.4GB

공식 저장소는 2026년 10월 25일 기준 파일 72개, 합계 252,446,157,295바이트로 252.4GB(235.1GiB)입니다. 이 가운데 본 가중치인 `model-*.safetensors` 48개가 250.1GB이고, 추측 디코딩(speculative decoding)에 쓰는 드래프트 모델이 든 `dspark/` 폴더가 2.3GB, 나머지는 토크나이저와 설정 파일입니다. Hugging Face는 10진 GB(10^9바이트)로 표시하므로 메모리와 비교할 때는 1.074로 나눈 GiB 값을 써야 합니다.

공식 체크포인트는 이미 대부분 4비트입니다. `config.json`의 양자화 설정을 보면 라우팅 전문가 128개는 NVFP4(4비트), 어텐션과 밀집 층은 MXFP8(8비트)이고, 임베딩·출력 헤드·비전 타워·라우터만 BF16으로 남아 있습니다. [MiniMax M3.1 Flash 공식 모델 카드](https://huggingface.co/MiniMaxAI/MiniMax-M3.1-Flash)도 라우팅 MoE 전문가와 어텐션 경로를 학습 중에 양자화해 메모리 사용량을 줄였다고 설명합니다. MiniMax가 M3.1 Flash의 BF16 원본을 따로 공개하지는 않았기 때문에, "BF16으로 받으면 몇 GB"라는 계산은 이 모델에는 해당하지 않습니다.

같은 날 Hugging Face API로 본 MiniMax M3 공식 저장소는 BF16 파라미터 427.0B, 용량 854.2GB입니다. M3.1 Flash를 `config.json`으로 다시 세면 라우팅 전문가만 413.1B(MoE 층 57개 × 전문가 128개 × 행렬 3개 × 6,144 × 3,072)이고, 공유 전문가·어텐션·임베딩을 더한 텍스트 부분이 약 425.9B, 토큰당 활성 파라미터는 23B 안팎입니다. 규모는 M3와 같고 저장 정밀도만 다르므로 "새 경량 모델"이라는 소개는 다운로드 크기와 API 단가에는 맞아도 모델 크기에는 맞지 않습니다. 활성 23B 역시 토큰당 연산량을 뜻할 뿐이고, 메모리에는 428B 전체가 올라가야 합니다.

## Hugging Face가 220B로 표시하는 이유: 4비트 두 개를 1바이트에 저장

Hugging Face 모델 페이지의 "220B params"는 파일 속 텐서 원소 수를 자료형별로 더한 값이라, 4비트 가중치 두 개를 1바이트(U8)에 묶어 둔 부분을 실제의 절반으로 셉니다. 2026년 10월 25일 Hugging Face API가 돌려준 공식 저장소의 메타데이터는 U8 206,561,083,392개, F8_E4M3 10,560,208,896개, BF16 3,323,222,528개, F32 46,339,200개, 합계 220,490,854,016개였습니다. U8 텐서의 이름이 `experts.N.w1/w2/w3.weight_packed`이고 `config.json`의 MoE 형식도 `nvfp4-pack-quantized`이므로, U8 부분은 묶어서 저장한 NVFP4 전문가 가중치입니다.

```text
U8 206.56B × 2 = 413.1B   ← config.json으로 다시 센 라우팅 전문가 수와 같음
413.1B + F8 10.56B + BF16 3.32B + F32 0.05B = 427.1B
```

보정한 427.1B는 모델 카드의 "약 428B"와 맞습니다. 공식 파일을 그대로 복제한 `unsloth/MiniMax-M3.1-Flash`에도 같은 220B가 표시되므로, 이 숫자를 보고 축소판이나 별개 모델로 판단하면 안 됩니다. Hugging Face가 이 표시의 계산 방식을 문서로 밝히지는 않았지만, U8 개수의 두 배가 전문가 수 재계산과 일치한다는 점이 원인을 보여 줍니다.

## 허깅페이스에서 받을 수 있는 MiniMax M3.1 Flash 버전별 용량

2026년 10월 25일 Hugging Face에서 "MiniMax-M3.1-Flash"로 검색되는 저장소는 49개지만, 실제로 고를 갈래는 공식 체크포인트, 칩 제조사용 변환본, Mac용 MLX, llama.cpp용 GGUF 네 가지입니다. 아래 용량은 같은 날 각 저장소의 `.safetensors`·`.gguf` 파일 크기를 더한 값이고, 드래프트 모델 폴더는 따로 적었습니다.

| 저장소(양자화) | 형식 | 용량 GB (GiB) | 실행 환경·엔진 |
|---|---|---|---|
| `MiniMaxAI/MiniMax-M3.1-Flash` (공식) | NVFP4 전문가 + MXFP8, safetensors | 250.1 (232.9) + dspark 2.3 | vLLM·SGLang, NVIDIA Blackwell·Hopper, AMD MI355X |
| `amd/MiniMax-M3.1-Flash-Quark-MXFP4` | MXFP4, safetensors | 237.2 (220.9) + dspark 2.3 | AMD Instinct, SGLang |
| `FlagRelease/MiniMax-M3.1-Flash-W8A8-nvidia-FlagOS-Express` | W8A8(8비트) | 430.9 (401.3) + dspark 2.3 | FlagOS용 vLLM 플러그인(vLLM-plugin-FL) |
| `mlx-community/MiniMax-M3.1-Flash-Text-4bit` | MLX 4비트, 텍스트 전용 | 248.4 (231.3) | Apple Silicon, MLX |
| `mlx-community/MiniMax-M3.1-Flash-Text-3bit` | MLX 3비트, 텍스트 전용 | 186.5 (173.7) | Apple Silicon, MLX |
| `unsloth/MiniMax-M3.1-Flash-GGUF` UD-Q8_K_XL | GGUF | 259.1 (241.3) | llama.cpp |
| 같은 저장소 UD-Q4_K_XL | GGUF | 249.4 (232.3) | llama.cpp |
| 같은 저장소 UD-Q3_K_XL | GGUF | 194.0 (180.6) | llama.cpp |
| 같은 저장소 UD-IQ3_S | GGUF | 175.5 (163.4) | llama.cpp |
| 같은 저장소 UD-IQ3_XXS | GGUF | 160.0 (149.1) | llama.cpp |
| 같은 저장소 UD-Q2_K_XL | GGUF | 143.9 (134.0) | llama.cpp |
| 같은 저장소 UD-IQ2_XXS | GGUF | 134.9 (125.7) | llama.cpp |
| 같은 저장소 UD-IQ1_M | GGUF | 129.4 (120.5) | llama.cpp |
| `primitive-ai/MiniMax-M3.1-Flash-pruned-272B-NVFP4` | 전문가를 잘라 낸 커뮤니티판, NVFP4 | 162.9 (151.7) + dspark 2.3 | 품질 검증 자료 없음 |

표에서 가장 흔히 착각하는 부분은 GGUF UD-Q4_K_XL(249.4GB)이 공식 저장소와 거의 같은 크기라는 점입니다. 공식 전문가 가중치가 이미 4비트이기 때문에 GGUF 4비트로 바꿔도 줄어드는 몫이 없고, 메모리를 아끼려고 GGUF를 받는다면 3비트 이하를 봐야 의미가 있습니다. Unsloth GGUF 저장소의 README는 "# Work in progress"로 시작하고 10월 25일에도 수정되고 있었으므로, 양자화 종류와 크기는 바뀔 수 있습니다. 이미지 입력용 비전 프로젝터 `mmproj-F32.gguf`(3.5GB)는 본 파일과 별도입니다.

![MiniMax M3.1 Flash 버전별 다운로드 용량 막대그래프: 공식 250.1GB와 GGUF UD-Q4_K_XL 249.4GB가 거의 같고, 3비트 이하부터 용량이 줄어듦](https://blog.laozhang.ai/posts/ko/minimax-m3-1-flash-size/img/version-sizes.webp)

`dspark/` 폴더의 2.3GB 드래프트 모델은 vLLM이나 SGLang에서 DSpark 추측 디코딩을 켤 때만 쓰이고 기본 추론에는 필요 없습니다. FlagOS W8A8 저장소는 BAAI가 주도하는 FlagOS가 원래의 QAT NVFP4 가중치를 8비트로 변환한 것으로, Huawei Ascend·Hygon·Moore Threads·Kunlunxin 등 9개 칩 제조사용 빌드가 같은 이름 계열로 올라와 있습니다. 8비트라서 공식판보다 약 1.7배 크므로, NVIDIA GPU에서 FlagOS 스택을 쓰지 않는다면 고를 이유가 적습니다. 검색 결과에는 다운로드 수가 많은 제3자 GGUF도 여럿 있지만 품질을 비교한 자료는 없고, 이름에 uncensored나 abliterated가 붙은 저장소는 안전 장치를 제거한 개조본이라 권하지 않습니다.

## 내 장비에 MiniMax M3.1 Flash가 들어가나: 메모리별 버전과 엔진

판단 기준은 가중치 파일(GiB)이 장비 메모리의 80% 이하인가입니다. 나머지 20%를 KV 캐시, 활성값, 런타임과 운영체제 몫으로 남긴다는 가정이며, MiniMax나 vLLM이 제시한 수치가 아니라 2026년 10월 25일 적합 계산에 쓴 기준입니다. 메모리는 표기 용량(예: 256GB)을 GiB로 보고 계산했습니다. 또한 "용량이 들어간다"와 "엔진이 지원한다"는 별개입니다. 공식 NVFP4 체크포인트는 CUDA·ROCm용 vLLM과 SGLang에서 돌아가므로, Mac에서는 메모리가 충분해도 공식 파일을 그대로 실행할 수 없습니다.

![장비 메모리별 MiniMax M3.1 Flash 선택: 128GB 이하는 API, 256GB는 3비트 MLX·GGUF, 512GB Mac은 4비트, GPU 서버는 공식 체크포인트와 vLLM·SGLang](https://blog.laozhang.ai/posts/ko/minimax-m3-1-flash-size/img/memory-fit.webp)

| 장비(메모리) | 여유를 두고 들어가는 버전 | 엔진 | 주의할 점 |
|---|---|---|---|
| RTX 5090 1장 (32GB) | 없음 | — | 시스템 RAM으로 넘겨야만 가능 |
| RTX 5090 1장 + RAM 128GB (합계 160GB) | UD-IQ2_XXS, UD-IQ1_M (합계의 80%인 128GiB 이하) | llama.cpp, CPU 오프로드 | 커뮤니티 1건: Q2_K 146GiB로 디코드 초당 5.12토큰 |
| RTX 5090 4장 또는 DGX Spark 1대 (128GB) | 없음 (UD-IQ1_M 120.5GiB와 UD-IQ2_XXS 125.7GiB가 가중치만 겨우 들어감, 남는 공간 7.5GiB·2.3GiB) | llama.cpp | 컨텍스트에 쓸 여유가 거의 없음 |
| Mac Studio 256GB, DGX Spark 2대 (256GB) | MLX 3비트, UD-Q3_K_XL, UD-IQ3_S, UD-IQ3_XXS, UD-Q2_K_XL | Mac은 MLX·llama.cpp, Spark는 llama.cpp | 공식판·4비트판은 가중치만 들어가고 여유 없음, Spark 2대는 분산 실행 필요 |
| Mac Studio 512GB | MLX 4비트, GGUF UD-Q4_K_XL·UD-Q8_K_XL | MLX, llama.cpp | 공식 체크포인트는 용량이 들어가도 Mac에서 실행 불가 |
| H200 4장 (564GB) | 공식 | vLLM | 용량은 충분하지만 vLLM의 Hopper 구성은 8장 TP8 |
| H100·H200 8장 (640GB 이상) | 공식 | vLLM TP8 | FP8 KV 캐시, Marlin 커널, DSpark 미지원 |
| B200 4장 (768GB), B300 4장 (1,152GB) | 공식 | vLLM TP4, SGLang은 B300 4장(B200은 8장 TP8) | NVFP4를 FP4 텐서 코어로 직접 실행, DSpark 사용 가능 |
| AMD MI355X 4장 | 공식 또는 AMD MXFP4 | vLLM(ROCm 7.2 이상) TP4, SGLang | vLLM은 로드할 때 전문가를 MXFP8로 다시 양자화 |
| Ascend 등 중국계 가속기 | FlagOS W8A8 | vLLM-plugin-FL | dspark 포함 403.4GiB라 504GiB 이상 필요 |

GPU 한 장과 넉넉한 시스템 RAM으로 버티는 구성은 돌아가기는 하지만 느립니다. llama.cpp 이슈 #31063을 올린 사용자는 RTX 5090 32GB와 RAM 128GB에서 직접 다시 양자화한 146GiB짜리 Q2_K(60개 층 전체)를 CPU와 GPU에 나눠 올렸고, 스케일 버그를 고친 뒤에는 답변이 정상적으로 나왔으며 속도는 프리필 초당 3.59토큰, 디코드 초당 5.12토큰이었다고 적었습니다. 커뮤니티 사례 한 건이고 Unsloth 파일이 아닌 자체 변환본이라 그대로 기대치로 삼기는 어렵지만, 이 등급의 장비에서는 대화형 코딩보다 느긋한 배치 작업에 가깝다는 감은 줍니다. 146GiB는 위 80% 기준(128GiB)을 넘는 크기여서 긴 컨텍스트를 붙일 여유도 적습니다. IQ1·IQ2급 저비트 양자화는 코딩 작업에서 실패 원인이 되기 쉬우므로 [로컬 coding agent가 실패할 때: 양자화, 컨텍스트, Harness를 분리 진단](https://blog.laozhang.ai/ko/posts/local-coding-agent-fails-quantization-context-harness)의 기준으로 결과를 따로 점검하는 편이 안전합니다. 32GB GPU 한 장에서 무언가를 돌려야 한다면 이 모델보다 한 장에 맞는 모델을 고르는 쪽이 맞고, 그 예는 [Qwen3.8-27B VRAM 가이드: RTX 5090, GPU 두 장과 262K 설정](https://blog.laozhang.ai/ko/posts/qwen3-8-27b-vram-guide)에 있습니다.

위 표는 가중치만 계산한 것이고, 긴 컨텍스트의 KV 캐시는 따로 더해집니다. 모델 카드는 최대 100만 토큰 컨텍스트를 지원한다고 하면서도 실제로 쓸 수 있는 길이와 처리량은 GPU 메모리와 서빙 설정에 달려 있다고 적고 있고, vLLM의 Hopper 예시도 최대 길이를 262,144토큰으로 제한합니다. DGX Spark 4대를 vLLM TP4로 묶어 공식판을 서빙했다는 커뮤니티 보고(kie.ai, 10월 23일 무렵)도 있지만, 설정과 속도가 공개된 재현 자료는 아닙니다.

## GPU 서버에서 공식 체크포인트 띄우기: vLLM과 SGLang

공식 체크포인트를 그대로 쓰려면 vLLM 0.33.0 이상이나 SGLang이 필요하고, GPU 세대에 따라 장수와 플래그가 달라집니다. [vLLM의 MiniMax-M3.1-Flash 레시피](https://recipes.vllm.ai/MiniMaxAI/MiniMax-M3.1-Flash)(2026년 10월 23일 갱신)는 Blackwell(GB200·GB300·B200·B300)과 AMD MI355X를 TP4로, Hopper(H100·H200)를 노드 한 대의 8장 전체를 쓰는 TP8로 안내합니다. Hopper에는 FP4 텐서 코어가 없어서 KV 캐시와 인덱서 캐시를 FP8로 두고 NVFP4 전문가를 Marlin MoE 커널로 돌리며, DSpark 추측 디코딩도 켜지지 않습니다.

사내 GPU 서버가 H100·H200 8장 노드라면 레시피의 Hopper 명령이 출발점입니다. 첫 실행 때 252.4GB를 받아야 하므로 디스크 공간과 회선을 먼저 확인합니다.

```bash
vllm serve MiniMaxAI/MiniMax-M3.1-Flash \
  --tensor-parallel-size 8 \
  --reasoning-parser minimax_m3 \
  --block-size 128 \
  --kv-cache-dtype fp8 \
  --attention-config '{"indexer_kv_dtype": "fp8"}' \
  --compilation-config '{"cudagraph_mode": "FULL_AND_PIECEWISE"}' \
  --max-model-len 262144 \
  --max-num-seqs 80 \
  --limit-mm-per-prompt '{"video": 0}' \
  --gpu-memory-utilization 0.9 \
  --no-enable-log-requests \
  --disable-hybrid-kv-cache-manager \
  --moe-backend marlin \
  --enable-auto-tool-choice \
  --tool-call-parser minimax_m3
```

`--block-size 128`은 모든 GPU에서 필수입니다. 모델 전 층에 들어간 MiniMax 희소 어텐션(MSA)의 캐시 구조 때문입니다. `--limit-mm-per-prompt '{"video": 0}'`은 영상 입력만 끄고 이미지 입력은 그대로 두는 설정이고, `--max-model-len 262144`는 요청당 컨텍스트를 262,144토큰으로 제한합니다. Blackwell에서는 `-tp 4`에 `--kv-cache-dtype nvfp4`를 쓰고, `--speculative-config`에 `"method":"dspark"`를 넣으면 체크포인트의 `dspark/` 폴더를 자동으로 읽어 추측 디코딩이 켜집니다. 레시피는 데이터 병렬 구성에서 JIT 빌드와 CUDA 그래프 캡처 때문에 첫 기동이 10분을 넘길 수 있다고 적고 있으니, 오래 멈춘 것처럼 보여도 바로 중단하지 않는 편이 좋습니다.

[SGLang의 MiniMax M3.1 쿡북](https://docs.sglang.io/cookbook/autoregressive/MiniMax/MiniMax-M3.1)은 B300 4장 TP4(저지연)와 B200 8장 TP8(고처리량), AMD MI350X·MI355X TP4 구성을 제공하고 Hopper 구성은 없습니다. 2026년 10월 25일 기준 M3.1 Flash 지원은 아직 SGLang 정식 릴리스에 들어가지 않아서, 쿡북은 지원 PR에서 직접 설치하거나 개발용 이미지 `lmsysorg/sglang:dev-minimax-m31-flash`를 쓰라고 안내합니다. Blackwell에서는 MSA 커널을 따로 설치해야 하며, 일부 커널을 실행 중에 컴파일하므로 장비에 CUDA 툴킷(nvcc) 13.4 이상이 있어야 합니다. PyTorch 휠에 들어 있는 CUDA 버전은 여기에 해당하지 않습니다. 같은 문서의 자체 벤치마크는 B300 4장에서 1K 컨텍스트 기준 초당 1,028토큰(MonoKernel 경로)을 보고하는데, 이는 SGLang 측 측정값입니다.

## llama.cpp와 Mac에서 돌리려면: GGUF는 b11861 이상, Mac은 MLX

MiniMax M3.1 Flash GGUF를 llama.cpp로 돌리려면 b11861 이상 빌드가 필요합니다. 그 이전 빌드는 NVFP4 전문가마다 붙은 스케일 값을 계산에 넣지 않아 의미 없는 토큰만 쏟아 냈고([llama.cpp 이슈 #31063](https://github.com/ggml-org/llama.cpp/issues/31063)), 이를 고친 [llama.cpp PR #31097](https://github.com/ggml-org/llama.cpp/pull/31097)이 2026년 10월 24일 병합되어 같은 날 나온 b11861 릴리스에 처음 들어갔습니다. 10월 25일 기준 최신 릴리스는 b11871입니다. 받은 GGUF가 엉뚱한 글자를 내놓는다면 파일을 다시 받기 전에 llama.cpp 버전부터 확인하세요.

Unsloth GGUF는 양자화마다 폴더가 나뉘어 있으므로, 120~260GB를 통째로 받지 말고 필요한 폴더 하나만 받습니다. 256GB급 장비에서 여유를 남기려면 아래처럼 UD-IQ3_XXS(149.1GiB)나 UD-Q3_K_XL(180.6GiB) 폴더를 지정하면 됩니다.

```bash
hf download unsloth/MiniMax-M3.1-Flash-GGUF \
  --include "UD-IQ3_XXS/*" \
  --local-dir ./MiniMax-M3.1-Flash-GGUF
```

Unsloth 문서에는 2026년 10월 25일 기준 M3.1 Flash 전용 안내가 없고 MiniMax M3용 안내만 있습니다. M3 안내는 GGUF가 실험 단계이고 텍스트 전용이며, llama.cpp가 MSA를 지원하지 않아 밀집 어텐션으로 대신 계산한다고 설명하고, UD-IQ1_M에 RAM 133GB 이상, 권장 양자화로 UD-IQ3_XXS를 제시합니다. M3.1 Flash GGUF도 같은 제약을 받는지는 공개 문서에 나와 있지 않고, 저장소에 비전 프로젝터 파일이 있다는 점만 다릅니다.

Mac에서는 공식 NVFP4 체크포인트를 쓸 수 없고 MLX 변환본이나 GGUF만 선택지입니다. `mlx-community`의 Text-4bit(231.3GiB)는 Mac Studio 512GB, Text-3bit(173.7GiB)는 256GB에서 여유가 남으며, 이름 그대로 텍스트 전용 변환본이라 이미지·영상 입력은 쓸 수 없습니다. Ollama의 `minimax-m3.1-flash:cloud`는 이름에 붙은 `:cloud`대로 클라우드에서 돌아가는 호스팅 모델이므로, 로컬 구동 수단으로 오해하지 않아야 합니다.

## MiniMax M3.1 Flash 라이선스: 무료 다운로드, 상업적 사용은 통지 필요

MiniMax M3.1 Flash 가중치는 누구나 무료로 받을 수 있지만, OSI 기준의 오픈소스가 아니라 [MiniMax Community License](https://huggingface.co/MiniMaxAI/MiniMax-M3.1-Flash/blob/main/LICENSE)로 배포되는 오픈 웨이트(가중치 공개) 모델입니다. 비상업적 사용은 조건 없이 허용됩니다. 상업적으로 쓰려면 관련 웹사이트·UI·제품 문서 등에 "Built with MiniMax M3.1-Flash"를 눈에 띄게 표시해야 하고, 연 매출이 2,000만 달러(US$20M) 이하라면 api@minimax.io로 제목 "M3.1-Flash licensing — notice"인 통지 메일을 한 번 보내야 합니다. 연 매출이 2,000만 달러를 넘으면 사전에 서면 허가를 받아야 합니다.

라이선스가 말하는 상업적 사용에는 이 모델을 쓰는 유료 서비스 제공, 모델 API의 상업적 사용, 미세 조정 등으로 수정한 파생 모델의 상업적 배포가 모두 들어갑니다. 사내 서비스에 붙이는 경우도 영리 목적이라면 통지 대상이 될 수 있으므로 배포 전에 표시 문구와 메일 발송을 끝내 두는 편이 안전합니다. 별첨에는 군사 목적, 미성년자에게 해를 끼치는 용도 같은 금지 사항이 따로 정리되어 있습니다.

## 로컬보다 MiniMax API가 나은 조건

장비 메모리가 256GB에 못 미치거나, 공식 가중치 그대로의 품질과 이미지·영상 입력, 긴 컨텍스트가 필요한데 Blackwell·Hopper 서버가 없다면 API가 맞습니다. 모델 카드도 공개한 성능은 공식 가중치 기준이며 제3자 양자화는 결과가 다를 수 있다고 밝히고 있어서, 3비트 이하 로컬판은 API와 같은 답을 낸다고 기대하기 어렵습니다. [MiniMax API 요금 페이지](https://platform.minimax.io/docs/guides/pricing)는 2026년 10월 25일 기준 MiniMax-M3.1-Flash를 100만 토큰당 입력 $0.15, 출력 $0.60, 캐시 읽기 $0.015로 표시하고, 컨텍스트 길이별 구간은 없습니다.

예를 들어 한 달에 입력 1억 토큰과 출력 2,000만 토큰을 쓰면 100 × $0.15 + 20 × $0.60 = $27입니다. 다만 추론(thinking)을 끌 수 없고 effort를 지정하지 않으면 최고 단계로 동작한다는 제3자 보고(kie.ai, DataLearner)가 있으므로, 출력 토큰은 답변 길이보다 넉넉하게 잡아야 합니다. 반대로 데이터를 외부로 보낼 수 없거나 이미 H100 8장급 노드가 놀고 있다면 로컬 서빙이 의미가 있고, 그 판단 기준은 [로컬 LLM 코딩 에이전트: Claude/Codex보다 나은 순간](https://blog.laozhang.ai/ko/posts/cloud-vs-local-coding-agent-cost-routing)에 정리되어 있습니다. MiniMax 자체 API 외에 Together AI와 OpenRouter에서도 이 모델을 호스팅하고 있다는 보고가 있습니다.

## 참고 자료

이 글이 링크한 외부 페이지를 본문에 나온 순서대로 정리했습니다. 마지막 업데이트: 2026-10-25.

- [MiniMax M3.1 Flash 공식 모델 카드](https://huggingface.co/MiniMaxAI/MiniMax-M3.1-Flash) (huggingface.co)
- [vLLM의 MiniMax-M3.1-Flash 레시피](https://recipes.vllm.ai/MiniMaxAI/MiniMax-M3.1-Flash) (recipes.vllm.ai)
- [SGLang의 MiniMax M3.1 쿡북](https://docs.sglang.io/cookbook/autoregressive/MiniMax/MiniMax-M3.1) (docs.sglang.io)
- [llama.cpp 이슈 #31063](https://github.com/ggml-org/llama.cpp/issues/31063) (github.com)
- [llama.cpp PR #31097](https://github.com/ggml-org/llama.cpp/pull/31097) (github.com)
- [MiniMax Community License](https://huggingface.co/MiniMaxAI/MiniMax-M3.1-Flash/blob/main/LICENSE) (huggingface.co)
- [MiniMax API 요금 페이지](https://platform.minimax.io/docs/guides/pricing) (platform.minimax.io)