MiniMax M3 API: 가격, 100만 토큰 컨텍스트 및 프로덕션 활용

MiniMax M3 API는 6월 1일에 공개됐다. 그 주부터 테스트를 시작했다. 뭔가를 기록으로 남기려면 최소 2주는 필요하다 — 그 전까지는 데모에 감탄만 하는 단계다.

이건 모델 리뷰가 아니라 작업 노트다. 벤치마크는 넘쳐난다. 내가 관심 가진 건 더 좁다: minimax m3 모델이 실제 프로덕션에서 어디에 맞는지, 1M 컨텍스트 비용이 실제로 얼마인지, 그리고 직접 API냐 애그리게이터냐 — 어느 걸 언제 쓸지.

먼저 몇 가지 짚고 넘어간다.

헤드라인 수치 대부분(SWE-Bench Pro 59.0%, 9배/15배 이상의 속도 향상, BrowseComp 83.5)은 벤더 발표 수치다. 유리한 조건에서의 상한선으로 받아들여야 한다. 내 코드베이스에서의 하한선이 아니다.

1M 컨텍스트는 실재한다. 요금은 두 단계로 나뉜다. 이게 사람들이 생각하는 것보다 훨씬 중요하다.

오픈 웨이트는 출시 10일쯤 후에 Hugging Face에 올라왔다. “웨이트 공개 예정”이라고 쓴 출시 기사를 봤다면, 이미 낡은 정보다.

MiniMax M3란 무엇인가 (개발자 관점)

API 가용성 및 접근 경로

세 가지 방법이 있다. MiniMax 오픈 플랫폼을 통한 직접 접근. OpenRouter, Fireworks 등 애그리게이터를 통한 접근. 또는 Hugging Face에서 셀프 호스팅.

처음 두 가지를 테스트해봤다. 셀프 호스팅은 GPU를 충분히 가진 사람에게 맡긴다 — minimax m3 파라미터 수는 총 ~428B이고 토큰당 ~23B가 활성화되는 MoE 구조라, 소비자용 GPU 하나로 돌릴 수 있는 게 아니다.

테스트한 두 경로는 문서에서 드러나지 않는 방식으로 차이가 있었다. 직접 접근이 토큰당 비용이 낮다. 애그리게이터는 여러 모델에 걸친 단일 청구 체계를 제공한다. 어느 쪽이 중요한지는 대부분의 팀이 아직 답하지 못한 질문에 달려 있다 — 나중에 다시 다루겠다. 사람들이 여기서 막히는 걸 자주 본다.

512K 보장 최소값을 가진 1M 컨텍스트

이 문장은 꼼꼼히 읽을 가치가 있다. MiniMax M3 API는 최대 1M 토큰의 컨텍스트를 지원한다. 계획할 때 기준으로 삼을 숫자는 512K — 보장된 최솟값이다. 1M 상한은 조건부다.

~480K 규모로 테스트를 돌렸다(레포 + 설계 문서 + 긴 스레드를 이어 붙인 것). 세 번 돌렸는데 일관된 결과가 나왔고, 레이턴시는 예상 범위 내였다.

~700K로 늘렸다(프로젝트의 전체 이슈 히스토리를 추가). 레이턴시 편차가 눈에 띄게 넓어졌다. 그리고 청구 구간이 바뀌었다.

실제로 정리하면: 512K가 신뢰할 수 있는 작업 기준값이다. 윈도우의 상위 절반은 존재하지만, 여유 용량이 아니라 예산 항목이다.

아키텍처는 MSA(MiniMax Sparse Attention)이고 출시 포스트에 문서화되어 있다. 비용 계획에서 중요한 세부사항은 1M 컨텍스트에서의 토큰당 연산이 M2 대비 약 1/20로 떨어진다는 점이다. 이 비율 없이는 장문 컨텍스트 구간이 경제적으로 불가능했을 것이다.

M3가 만들어진 용도

코딩 및 에이전틱 워크로드

minimax m3 모델은 장기 코딩과 에이전트 작업을 위해 포지셔닝되어 있다. 2주간 사용해본 결과, 그 포지셔닝은 솔직하다고 본다.

단일 턴 Q&A는 괜찮다. 인상적이지는 않지만 괜찮다. 달라지는 건 긴 세션에서다 — 레포를 읽고, 계획하고, 실행하고, 반복하고, 중간에 뭔가 망가졌을 때 복구하는 과정. MiniMax 자체 데모는 M3를 12시간, 18개 커밋으로 돌려 ICLR 논문을 재현한다. 아키텍처가 맞춰져 있는 워크로드가 바로 그것이다.

관련 minimax m3 벤치마크 수치 — 모두 벤더 발표 — 는 SWE-Bench Pro 59.0%, Terminal Bench 2.1 66.0%, MCP Atlas 74.2%다. VentureBeat 커버리지는 이를 GPT-5.5 및 Gemini 3.1 Pro와 비교한다. “앞선다”는 표현은 30% 정도 낮춰 잡는 게 좋다. 수치 자체는 실제다. 조건은 MiniMax의 실험실과 MiniMax의 스캐폴딩이었다.

개발자에게 의미하는 바: 코딩 어시스턴트, 데스크톱 에이전트, 또는 멀티스텝 계획을 유지하는 무언가를 만들고 있다면 M3는 후보 목록에 들어간다. 짧은 프롬프트를 높은 동시성으로 처리하는 게 워크로드라면, 사용하지 않는 컨텍스트에 돈을 내는 셈이다.

네이티브 멀티모달 (이미지, 비디오) 입력

멀티모달은 네이티브다. 덧붙여진 게 아니다. 텍스트, 이미지, 비디오가 같은 컨텍스트로 들어간다. 출력은 텍스트다.

UI 스크린샷 + 30초 화면 녹화 + 관련 백엔드 코드 덩어리를 넣고 사용자가 실제로 뭘 하려는 건지 파악해달라고 했다. 답이 나왔다. 한 번에 된 건 아니었다 — 두 번째 턴에서 방향을 잡아줘야 했다. (첫 번째 추측은 합리적이었지만 틀렸다.) 내 기준으로는 동작하는 걸로 친다.

짚어두고 싶은 세부사항이 있다. 다른 테스트에서 실제로 당했던 부분이다: 이미지와 비디오 토큰은 텍스트와 같은 풀을 공유한다. 짧은 클립이 프롬프트 텍스트 하나 들어오기 전에 512K 윈도우의 상당 부분을 먹어버릴 수 있다. 15초짜리 720p 클립의 토큰 수를 확인해봤는데, 내 머릿속 예상보다 훨씬 많았다. 추산하기 전에 직접 측정해볼 것.

프로덕션 비용 및 한계

구체적인 백만 토큰당 수치는 여기 적지 않겠다. 공급자 요금은 변하고, minimax m3 가격 계산을 제대로 다루는 별도 글이 있다. 계획 단계에서 필요한 건 전체 구조다.

표준 vs 장문 컨텍스트 (>512K) 요금

MiniMax M3 API의 두 가지 구간:

≤512K 입력 토큰 — 표준 요금. 대부분의 채팅, 코딩, 에이전트 루프를 커버.
>512K 입력 토큰 — 높은 장문 컨텍스트 요금. 전체 레포 추론, 초장문 문서, 수 시간의 에이전트 세션을 위한 것.

이 분기가 설계 시 가장 중요하게 고려해야 할 단일 요소다. 100K–300K 구간에서 작동하는 시스템은 700K를 일상적으로 건드리는 것과 단가 경제학이 다르다. 내가 알게 된 방식은 대부분의 팀이 알게 되는 방식과 같다: 청구서를 보고.

내게 효과적이었던 방법: 기본 라우팅을 512K로 제한하고, 초과하려면 명시적인 플래그를 요구한다. 그러면 비용이 월말이 아니라 호출 지점에서 보인다.

모달리티 간 공유 토큰 풀

이미 언급했지만 별도로 다룰 가치가 있다. 멀티모달 별도 허용량은 없다. 이미지는 토큰이다. 프레임도 토큰이다. 텍스트와 같은 윈도우를 먹고, 텍스트와 같은 방식으로 512K를 넘는다.

매 턴마다 스크린샷을 끌어오는 에이전트 루프에서는, 대충 계산한 것보다 빠르게 쌓인다. 실제 세션의 토큰 수를 감사해봐라. 합성 벤치마크는 믿지 말 것.

직접 API vs 애그리게이션 레이어

팀들이 막히는 결정이다. 대부분 필요 이상으로 오래 막혀 있다.

각각이 맞는 상황

직접 연결이 맞을 때:

M3를 기본 모델로 확정했고 교체할 생각이 없을 때.
통합 표면보다 토큰당 비용이 더 중요할 때.
전체 1M이 필요할 때 (일부 애그리게이터는 더 낮게 제한한다 — Fireworks는 500K 제한으로 출시했고 단계적으로 올리는 중이다).
모델별 통합을 유지하는 게 불편하지 않을 때.

애그리게이터를 통할 때:

이미 프로덕션에서 여러 모델을 운영하거나, 그렇게 될 예정일 때.
요청 경로를 다시 만들지 않고 M3를 Claude Opus나 DeepSeek V4 등과 A/B 테스트하고 싶을 때.
통합 청구, 재시도, 폴백 라우팅, 옵저버빌리티가 중요할 때.
워크로드가 어떤 모델에 안착할지 아직 모를 때.

애그리게이션의 진짜 이유는 낮은 토큰당 비용이 아니다. 보통은 약간 더 높다. 이유는 모델 전환 자유도에 경제적 가치가 있기 때문이고, 그 가치는 제품이 여러 공급자에 걸쳐 생성을 건드릴수록 복리로 커진다. WaveSpeedAI가 그 레이어에 있고, OpenRouter와 Fireworks도 마찬가지다 — 각각 라우팅, 레이턴시, 커버리지에서 다른 트레이드오프를 택한다.

내 대략적인 기준을 말하자면: 단일 모델 코딩 에이전트 → 직접. 여러 공급자에 걸친 텍스트 + 이미지 + 비디오 혼합 → 애그리게이터. 확정적인 규칙은 아니다. 시작점이다.

한계 및 트레이드오프

오픈 웨이트, 기술 보고서, 그리고 아직 없는 것들

웨이트는 Hugging Face에 있다. 커뮤니티 GGUF 양자화도 올라와 있다. 알아둘 두 가지:

라이선스 조건이 완전히 정해지지 않았다. Apache 2.0이나 MIT라고 가정하지 말 것 — 로컬 배포 경로로 상업적 제품을 만들기 전에 확인할 것.

그리고 모든 추론 엔진이 MSA를 지원하는 건 아니다. 지원하지 않는 엔진은 밀집 어텐션으로 폴백하는데, 이는 속도 이점의 상당 부분을 포기하는 것이다. 셀프 호스팅이라면 벤치마크 전에 엔진 지원 여부를 확인할 것 — 그렇지 않으면 수치가 실제보다 나쁘게 나온다.

ARC-AGI 격차

출시 커버리지가 건너뛰는 경향이 있는 한 가지. M3의 코딩 및 에이전틱 수치는 ARC-AGI 같은 일반 추상 추론 벤치마크로 깔끔하게 이어지지 않는다. 이 모델은 광고하는 것에 맞춰져 있다 — 코딩, 도구 사용, 장기 에이전트, 멀티모달 그라운딩 — 추상적 퍼즐이 아니다.

이건 비판이 아니다. 모델의 형태다. 이를 알면 잘못된 베팅을 막을 수 있다.

FAQ

MiniMax M3 API는 이미 프로덕션 사용에 안정적인가?

그렇다. 2026년 6월 1일부터 공개됐다. 여러 애그리게이터가 실제 트래픽을 라우팅할 만큼 안정적이다. 출시 3개월 미만의 모델이 항상 그렇듯, 공급자가 튜닝하면서 간헐적인 동작 변화가 있을 수 있다 — 프롬프트를 고정하고, 평가 스위트를 유지하라.

MiniMax M3의 실제 보장 컨텍스트 길이는 512K인가 1M인가?

512K 보장, 1M 상한. 512K 이하는 일관되게 동작한다. 그 이상이면 더 높은 요금과 레이턴시 편차 확대 구간에 진입한다. 일부 애그리게이터는 출시 시점에 1M보다 낮게 제한한다. 512K 기준으로 계획할 것.

MiniMax M3는 이미지와 비디오 입력에 네이티브 멀티모달인가?

그렇다. 어댑터가 아니라 네이티브다. 텍스트, 이미지, 비디오는 같은 토큰 풀과 컨텍스트 윈도우를 공유한다. 출력은 텍스트만이다.

MiniMax M3의 오픈 웨이트는 이미 공개됐나?

그렇다. 출시 약 10일 후에 Hugging Face에 올라왔다. 총 파라미터 ~428B, 토큰당 활성화 ~23B (MoE). 소비자용 GPU 하나로는 돌아가지 않는다 — 멀티 GPU 또는 양자화 추론이 필요하다. 라이선스 조건 — 상업적 사용 전에 확인할 것.

MiniMax M3에 직접 접근해야 할까, 아니면 애그리게이터를 통해야 할까?

단일 모델에 확정하고 가장 낮은 토큰당 비용을 원한다면 직접. 여러 모델을 운영하거나 전환 가능성이 있다면 애그리게이터. 답은 워크로드에 달려 있다. 어느 쪽이 “더 좋다”는 게 아니다.

결론

MiniMax M3 API가 흥미로운 건 단일 축에서 1위라서가 아니라 조합 때문이다 — 프론티어급 코딩, 네이티브 멀티모달, 실제(비록 구간별) 1M 컨텍스트, 오픈 웨이트, 이 모든 게 하나의 모델에. 이 조합은 예전에는 공급자를 이어 붙여야 했던 통합 표면을 단일화한다.

프로덕션 도입 전에 할 것:

벤치마크가 아닌 실제 워크로드를 돌려봐라. 프롬프트가 512K 대비 어디에 위치하는지 측정하라. 출시 전에 라우팅 정책을 정하라. 직접이냐 애그리게이터냐는 스티커 가격이 아니라 운영할 모델 수에 따라 선택하라. 셀프 호스팅이라면, 엔진의 MSA 지원 여부를 먼저 확인하라.

2주는 길지 않다. 모델도, 요금도 계속 진화할 것이다. 이 글의 유통기한이 거기에 있다.

실제로 빌드하는 날의 문서를 기준으로 항상 검증하라.

이전 포스트: