TensorSharp에서 MiniMax-M3.1-Flash 지원 첫날 사용 후기: GGUF, 비전, 도구 호출, DSpark 및 8× A40

저는 TensorSharp의 개발자입니다. 저는 이 모델이 오픈 웨이트(open-weight)로 공개된 첫날에 MiniMax-M3.1-Flash 지원을 추가했으며, 로컬에서 모델을 실행하려는 모든 분들과 공유하고 싶은 작동 현황과 초기 벤치마크 결과가 있습니다. 가장 큰 성능 차이는 긴 프롬프트에서 나타났습니다: 테스트한 llama.cpp 브랜치에서는 64K executor prefill이 262 tok/s였던 것에 비해 2,567 tok/s에 도달했으며, 서버의 첫 토큰까지 걸리는 시간(server time to first token)은 293.4초에서 40.0초로 감소했습니다.

지원 기능: 현재 구현에는 다음이 포함됩니다:

• MiniMax Sparse Attention을 전용 CUDA 커널과 함께 사용하는 GGUF 추론 (inference).
• OpenAI와 호환되는 API를 통해 제공되는 텍스트 및 이미지 입력.
• JSON/스키마 응답, 도구 호출(tool calling), 다중 턴 KV-캐시 재사용(multi-turn KV-cache reuse).
• 다중 GPU 레이어 분할(Multi-GPU layer splitting) 및 텐서 병렬 처리(tensor parallelism).
• DSpark 추측 디코딩(speculative decoding).
• 라우팅된 MoE 전문가(MoE experts)를 위한 CPU 오프로드(CPU offload).

저는 채팅, 긴 프롬프트 검색(long-prompt retrieval), 구조화된 출력(structured output), 단일 및 병렬 도구 호출, 에이전트형 도구 루프(agentic tool loop), 이미지 처리, 그리고 동시 요청(concurrent requests)을 테스트했습니다.

하드웨어 및 비교 설정: 이 측정값들은 8× NVIDIA A40 GPU를 사용했으며, 두 엔진 모두 동일한 Unsloth MiniMax-M3.1-Flash UD-Q4_K_XL GGUF 파일을 사용했습니다. 모델 파일 자체의 크기는 런타임 할당과 KV 캐시를 제외하고 총 232.3 GiB에 달하므로, 이는 상당한 다중 GPU 구성입니다. 아래 CPU 오프로드 결과 역시 이 8개 GPU 머신을 사용했습니다.

기준선(baseline)의 경우, PR #320과 관련된 Unsloth의 llama.cpp minimax-m31 브랜치 at ef8f94cc를 사용했습니다. 제가 테스트를 실행했을 때 상위 버전의 llama.cpp는 이 모델을 로드할 수 없었습니다. 주요 비교는 두 엔진 모두에서 레이어 분할(layer splitting)과 F16 KV 캐시, 그리고 추측 디코딩 없이 진행되었습니다. 각 엔진은 GPU를 독점적으로 사용하여 개별 실행되었습니다. llama-server는 sparse-attention 경로가 활성화되도록 flash attention 및 --no-kv-unified 옵션을 사용했습니다.

초기 결과 측정
TensorSharp llama.cpp 지원 브랜치 | 실행기 프리필(prefill), 8K 토큰: 1,699 tok/s | 1,312 tok/s
실행기 프리필(prefill), 32K 토큰: 2,449 tok/s | 681 tok/s
실행기 프리필(prefill), 64K 토큰: 2,567 tok/s | 262 tok/s
실행기 디코드(decode) at 64K 컨텍스트: 22.9 tok/s | 15.4 tok/s
서버 시간 (첫 토큰까지), 64K 프롬프트: 40.0초 | 293.4초
이는 각각 8K, 32K, 64K에서 1.3배, 3.6배, 9.8배의 프리필 처리량(prefill throughput)을 의미합니다. 디코드 개선 폭은 더 작습니다. 64K 컨텍스트에서 실행기 디코드는 1.49배 향상되었습니다. 짧은 채팅 서버 요청의 경우, 디코드는 거의 동일했습니다: 26.3 대 26.0 tok/s. 컨텍스트가 커질수록 격차가 더 크게 벌어지는 이유는 무엇일까요?

컨텍스트 2,048 포지션(position)을 넘어서면, MiniMax Sparse Attention은 KV 그룹당 16개의 128 토큰 블록을 선택합니다. TensorSharp는 이 블록들을 선택하여 그 위에서 블록-희소 CUDA 어텐션(block-sparse CUDA attention)을 실행합니다. 테스트된 llama.cpp 브랜치는 밀집 마스크(dense mask)를 사용하여 선택하고 캐시 위에서 밀집 플래시 어텐션(dense flash attention)을 실행합니다. 이러한 구현 차이는 컨텍스트가 커질수록 훨씬 더 중요해집니다. TensorSharp는 또한 프롬프트 처리를 8개의 GPU에 걸쳐 파이프라인 처리합니다.

다른 구성
텐서 병렬성(Tensor parallelism): TensorSharp의 --tp 8은 짧은 채팅 서버 디코드에서 약 41 tok/s에 도달했으며, 이는 레이어 분할 모드(layer-split mode)에서의 26.3 tok/s 대비 향상된 수치입니다. 에이전트적 도구 루프(agentic tool loop)는 18.1초에서 11.7초로 감소했습니다. 테스트된 llama.cpp 브랜치는 이 모델에 대해 텐서 분할을 거부하므로, 이는 별도의 기능 결과입니다. TP 또한 이 하드웨어에서는 더 느린 프리필과 더 작은 사용 가능한 컨텍스트를 가졌습니다.

DSpark: 동일한 드래프터(drafter)를 사용했을 때 평균 32.3 대 25.8 tok/s였습니다. TensorSharp는 약한 초안(drafts)의 비싼 검증을 피하기 위해 신뢰도 게이팅(confidence gating)을 사용했습니다. 기준 정책과 일치하도록 게이트를 비활성화했을 때, 결과는 더 가까워졌습니다: 26.6 대 25.8 tok/s.

CPU 전문가 오프로드(expert offload): --n-cpu-moe 24 설정 시, 약 79.7 GiB의 라우팅된 전문 지식 가중치(routed-expert weights)가 호스트 메모리에 유지되었습니다. 짧은 채팅 디코드는 17.9 대 13.8 tok/s에 도달했습니다.

여전히 개선이 필요한 부분: 짧은 채팅의 첫 토큰까지 걸리는 시간은 약간 더 나빴습니다: 0.41초 대 0.39초.

메인 실행에서 동시 요청 처리량(Concurrent-request throughput)은 개선되었지만, 요청당 첫 토큰 지연 시간(per-request first-token latency)은 약 4% 더 길었습니다. 이는 단일 호스트와 하나의 양자화(quantization)를 기준으로 한 초기 결과입니다. 대부분의 측정값은 세 번 반복(three repeats)을 사용합니다. llama.cpp 64K 실행기 사전 채우기(prefill) 결과는 한 번의 실행인 반면, 64K 서버 결과는 엔진당 세 번의 반복을 사용했습니다. 검증에는 토크나이저/템플릿 매칭, 합성 로짓 비교(synthetic-logit comparisons), 기능적 테스트 케이스(functional fixtures)가 포함되었습니다. 이미지 읽기 오류가 있었고, 일부 생성 테스트에서는 토큰 제한에 도달했습니다. 비전 커버리지는 작으며, 네이티브 비디오 시간적 패치(native video temporal patches)는 구현되지 않았습니다. 측정된 TensorSharp 빌드는 커밋되지 않은 개발 작업 트리였으며, 원시 실행 기록은 공개 보고서에 포함되어 있지 않습니다. GitHub의 TensorSharp 링크, Unsloth MiniMax-M3.1-Flash GGUF 전체 벤치마크 보고서, 구성 및 방법론을 참고하십시오.

만약 M3.1 Flash를 로컬에서 테스트하고 계시다면, 사용하신 하드웨어, 양자화 방식, 그리고 사전 채우기(prefill)/디코딩 결과를 알려주시면 감사하겠습니다. 추가적인 기준선 설정이나 유용한 워크로드에 대한 제안도 환영합니다.

이 게시물의 영어 문구 초안 작성 및 편집에는 LLM을 사용했습니다. 제출자: /u/fuzhongkai [링크] [댓글]