M5 Ultra 256GB에서 1조 파라미터 Mistral Large 4 UD-IQ1_S, 128K 위치 생성 초당 15토큰
M5 Ultra 256GB에서 1조 파라미터 Mistral Large 4를 Unsloth UD-IQ1_S(233GB)로 GPU에 모두 올려 128K까지 쟀습니다. 128K 생성 15.3 tok/s, 128K 지점 첫 토큰까지 약 4분이었고 DSpark는 코드에서만 빨랐습니다.
Mistral Large 4는 전체 파라미터가 약 1조(1,049B)인 MoE 모델입니다. 라우팅 전문가 128개 중 4개와 공유 전문가 1개를 써서 토큰마다 약 51B가 계산에 들어갑니다. Unsloth가 이를 1비트급 혼합 양자화 UD-IQ1_S(분할 6개, 합계 233.0GB, 평균 약 1.78bpw)로 줄여 "256GB Mac Studio에 들어간다"고 내놓았습니다. Mac Studio M5 Ultra(GPU 80코어, 통합 메모리 256GB)에서 실제로 전부 GPU에 올려 공통 벤치마크로 쟀습니다.
작업은 DeepSeek V4.1 llama.cpp 글과 같습니다. 소설과 코드 원문을 32K토큰씩 이어 붙여 128K까지 가며, 단계마다 새로 넣은 약 32K의 처리와 이어지는 256토큰 생성을 원문마다 3회 쟀습니다. HTTP /completion에 토큰 ID를 보냈고, 단계마다 재사용한 캐시 토큰 수가 기준(33,023, 66,047, 99,071)과 정확히 같은 원래 방식 그대로의 결과입니다. 코드 1회차는 스트리밍 중 토큰 ID가 빠져 무효로 하고 한 번 더 쟀습니다(아래 측정 환경).
이 모델을 잰 다른 기계는 없습니다. M4 Max와 Ryzen AI Max+ 395는 메모리가 128GB라 이 파일을 다 올릴 수 없습니다.
128K 위치 요청 한 번
128K까지 쌓인 문맥에 새 입력 약 32K를 넣고 256토큰을 받는 한 번의 요청입니다. 같은 기계와 같은 엔진·설정으로 잰 DeepSeek V4.1 Flash를 참고로 함께 둡니다. 모델이 달라 같은 일의 엔진 비교는 아닙니다.
| 모델 · 가중치 | 첫 토큰까지 (초) | 128K 생성 (tok/s) | 합계 (초) | 회수 |
|---|---|---|---|---|
| Mistral Large 4, UD-IQ1_S (이 글) | 244.78 / 247.20 | 15.37 / 15.33 | 261.4 / 263.9 | 3회 평균 |
| DeepSeek V4.1 Flash 1017, UD-Q2_K_XL (참고) | 64.25 / 61.39 | 41.53 / 41.32 | 70.4 / 67.6 | 3회 평균 |
값은 소설 / 코드 순서이고, 합계는 첫 토큰까지의 시간에 256토큰 생성 시간을 더한 것입니다. 128K 지점에서 새 32K를 넣으면 첫 토큰까지 4분 남짓이 걸립니다. 같은 엔진의 DeepSeek V4.1 Flash보다 한 번의 요청이 약 3.7~3.9배 깁니다.
사용 설정
| 항목 | 값 |
|---|---|
| 기계 | Mac Studio, M5 Ultra (CPU 12+24코어, GPU 80코어), 256GB, macOS 27.0.1 |
| 엔진 | Unsloth 배포 llama.cpp b11985-mix-c116c32 (build 11985, commit 6f4cc4d72), Metal. 모델 카드가 이 빌드를 쓰라고 함 |
| 모델 | Unsloth Mistral-Large-4-1T-A52B-GGUF의 UD-IQ1_S (HF revision 1eb4373d). 분할 6개의 SHA256을 HF 값과 모두 대조 |
| 메모리 배치 | 엔진 기본(mmap), 전부 Metal 버퍼. 적재 후 서버 메모리 225.5GiB, wired 239.7GiB |
| KV | f16(엔진 기본), MLA 캐시 |
| batch / ubatch | 2048 / 2048 |
| Flash Attention | on |
| 문맥 | 135,168 고정, 슬롯 1개, context shift 끔 |
| speculative | 대표는 off. DSpark 드래프터 결과는 아래에 따로 적음 |
| 생성 | greedy, 256토큰, 원문 이어쓰기 |
| 반복 | 회차마다 새 서버 프로세스, 짧은 인사로 워밍업. 로딩(첫 적재 49초, 이후 9.2초)은 통계에서 뺌 |
| 전원·메모리 | 잠자기 방지, 저전력 모드 끔, GPU wired 한도 245,760MiB |
모델은 72층이고, 어텐션은 MLA(KV 헤드 1개)와 DeepSeek 계열의 희소 어텐션 indexer(top_k 2048)를 씁니다. 지원 문맥은 1,048,576토큰이지만 측정은 135,168로 했습니다.
설정 고르기
대표 설정은 몇 가지를 한 번씩 재 보고 골랐습니다. 모두 1회 측정이라 대표 통계에 넣지 않았습니다.
| 엔진 | 설정 | 원문 | 32K prefill / 생성 | 128K prefill / 생성 |
|---|---|---|---|---|
| Unsloth b11985-mix | ubatch 2048 (선택) | 소설 | 184.05 / 18.40 | 135.54 / 15.35 |
| Unsloth b11985-mix | ubatch 2048 | 코드 | 179.44 / 18.39 | 135.91 / 15.32 |
| 업스트림 b12008 | ubatch 2048 | 소설 | 179.81 / 18.38 | 135.85 / 15.34 |
단위는 tok/s입니다. ubatch는 따로 4K 입력 처리 속도로 골랐습니다. 1024는 5%, 4096은 2% 느렸습니다. DeepSeek V4.1에서는 Unsloth 빌드가 업스트림보다 생성이 17~20% 빨랐는데, 이 모델에서는 차이가 없었습니다.
결과
소설
| 문맥 | 추가 prefill (tok/s) | 추가 prefill (초) | 생성 (tok/s) |
|---|---|---|---|
| 32K | 178.98 | 183.16 | 18.41 |
| 64K | 154.10 | 212.68 | 17.30 |
| 96K | 142.97 | 229.21 | 15.29 |
| 128K | 133.88 | 244.77 | 15.37 |
코드
| 문맥 | 추가 prefill (tok/s) | 추가 prefill (초) | 생성 (tok/s) |
|---|---|---|---|
| 32K | 177.53 | 184.64 | 18.39 |
| 64K | 155.01 | 211.41 | 17.25 |
| 96K | 141.57 | 231.51 | 15.24 |
| 128K | 132.62 | 247.19 | 15.33 |
3회 평균입니다(코드는 2·3·4회차). 표준편차는 prefill이 0.80~4.56, 생성이 0.01~0.02 tok/s였습니다. 첫 토큰까지 걸린 시간은 단계마다 추가 prefill 시간과 0.01초 안에서 같았습니다.
생성은 32K 18.4에서 128K 15.4 tok/s로 줄었습니다. 문맥이 32K씩 늘 때 추가 prefill 시간은 15~30초씩 늘었습니다(소설 183초에서 245초).
prefill이 느린 이유
첫 32K의 처리 속도는 약 180 tok/s로, 같은 기계와 엔진의 DeepSeek V4.1 Flash UD-Q2_K_XL(666~706)의 약 4분의 1입니다. 서버 로그를 보면 2048토큰 배치마다 약 11초로 일정해서, 문맥 길이보다 배치 계산 자체가 시간의 대부분이었습니다.
토큰마다 계산에 쓰는 파라미터가 Mistral Large 4는 51.08B, DeepSeek V4.1 Flash는 16.13B로 3.2배입니다(GGUF 헤더로 센 값). 파라미터당 2 FLOP으로 어림하면 llama.cpp가 내는 실효 계산은 두 모델 모두 초당 약 22~23조 번으로 같습니다. 이 모델만의 결함이라기보다 토큰당 일이 많은 것이고, 남는 차이는 긴 문맥 어텐션과 indexer 몫으로 봅니다. 커널 단위로 나눠 재지는 않았습니다.
같은 기계에서 mlx-serve는 DeepSeek V4.1 Flash의 32K를 초당 3,500~4,000토큰으로 처리했습니다(mlx-serve 글, 같은 어림으로 초당 약 120조 번). 이 기계의 한계는 llama.cpp의 양자화 MoE 경로 쪽입니다. 다만 Mistral Large 4의 MLX판은 가장 작은 2비트판도 338GB라 256GB에 들어가지 않습니다. llama.cpp 소스를 보면 IQ1_S도 M5의 tensor API 행렬 곱 경로를 타므로, 그 경로를 못 써서 느리다는 설명은 맞지 않습니다.
DSpark 드래프터를 켜면
Unsloth가 함께 낸 DSpark 드래프터(Q8_0, 2.25GB)를 DeepSeek V4.1 때와 같은 값(--spec-type draft-dspark --spec-draft-n-max 3)으로 켜고 소설과 코드를 한 번씩 쟀습니다.
| 원문 | 32K prefill / 생성 | 128K prefill / 생성 |
|---|---|---|
| 소설 | 174.19 / 12.38 | 134.22 / 13.26 |
| 코드 | 179.81 / 34.17 | 135.29 / 28.66 |
코드는 128K에서 1.87배 빨라지고 소설은 0.86배로 느려졌습니다. 서버 로그의 드래프트 수락률은 코드 67~89%, 소설 13~22%였습니다. 소설에서는 틀린 추측을 검증하는 비용이 이득보다 컸습니다. 드래프터가 2.25GB 더 올라가면서 메모리 여유가 1%까지 떨어지고 swap이 590MB에서 990MB로 늘었습니다. 대표는 소설과 코드에 같은 설정을 써야 해서 드래프터를 끈 쪽으로 했습니다. 코드 위주라면 켜는 편이 빠르지만 메모리가 거의 남지 않습니다.
공개 자료와 비교
Unsloth는 속도 수치를 내지 않았습니다. 밝힌 것은 크기 233GB, 원본 대비 오차(KLD) 0.1263, 첫 후보 일치율 90.6%, 1비트 필요 메모리 256~270GB, 256GB Mac Studio에 들어간다는 것입니다. 이 측정에서 적재 후 시스템 여유가 3~4%였으니 겨우 들어간다는 쪽에 가깝습니다.
Hugging Face 블로그는 llama.cpp로 M3 Ultra 512GB와 Q2_K에서 prefill 약 90, 생성 15 tok/s를 적었습니다. 프롬프트 길이는 적혀 있지 않습니다. 이 측정의 32K prefill 177~179, 생성 18.4 tok/s는 그 약 2배와 1.2배인데, 양자화와 칩이 모두 달라 참고로만 둡니다.
관찰
- 같은 설정, greedy인데 회차마다 출력이 달랐습니다. 소설과 코드 모두 32K부터 해시가 갈렸고, 코드 32K는 두 갈래로 나뉘었습니다. 같은 기계의 다른 llama.cpp 결과도 같은 양상이었고 원인은 확인하지 않았습니다. 생성 속도 편차는 0.03 tok/s 이내였습니다.
- 짧은 확인에서 "17×23은 얼마인가요? 숫자만 답하세요."에 391로 답했습니다. 기본으로 생각 과정 463자를 따로 냈고, 짧은 문맥 생성은 21.7~22.1 tok/s였습니다.
측정 환경
측정은 10월 31일 오후에 했습니다. 모델을 올린 뒤 메모리 여유는 3~4%였고, swap은 측정 내내 990MB로 그대로였습니다. 같은 SSD의 다운로드와 같은 기계의 다른 추론 서버는 측정 동안 멈췄습니다.
코드 1회차는 96K 단계에서 무효가 됐습니다. 서버는 256토큰을 생성했는데 스트리밍으로 받은 토큰 ID는 254개였습니다. 출력에 3바이트 UTF-8 문자 하나가 토큰 세 개로 나뉘어 나왔고, llama-server가 문자가 완성될 때까지 보류한 앞 토큰 두 개의 ID를 보내지 않았습니다. 그 회차의 네 단계를 모두 평균에서 빼고, 같은 조건으로 4회차를 한 번 더 재서 코드 3회를 채웠습니다. 재측정은 이 한 번뿐입니다. 토큰 ID 스트림으로 출력을 검증하는 측정이라면 이 경로를 알고 있어야 합니다.
범위
출력 정확도와 한국어 장문 품질은 재지 않았습니다. DSpark는 1회씩만 쟀고, 다른 양자화 파일은 재지 않았습니다.