Mistral Large 4는 저희 Gauntlet 벤치마크에서 0.5462점을 기록하며 44개 모델 중 28위를 차지했습니다. 이 점수 하락분 중 약 3분의 1은 테이블을 거꾸로 읽은 저희의 확인 과정 때문이었습니다. 화면에 표시한 12개 금액 모두는 정확했습니다. 저는 느리고 비싼 모델에 대해 작성할 것으로 예상했지만, 저희 Forge 벤치마크에서는 그 부분이 여전히 유효합니다.
만약 코딩 에이전트를 사용하기 위해 비용을 지불한다면, 이 모델은 예산에 맞춰져 있습니다. Mistral은 Large 4를 10월 6일에 Public Preview로 출시했으며, 이는 1.05조 개의 파라미터와 520억 개의 활성 파라미터를 가지며 1M 토큰의 컨텍스트를 제공합니다. 이 모델은 첫 2주 동안 목록 가격의 절반으로 이용할 수 있습니다. 그들의 출시 게시물에 따르면, Large 4는 자체 Coding Agent Index에서 DeepSeek V4 Pro보다 앞서 나갑니다(49.8%). 이는 예산을 움직이는 종류의 주장이라서, 저희는 이 모델을 두 가지 에이전트 코딩 벤치마크 모두로 테스트했습니다. Gauntlet는 모델 호출 150회 내에 두 가지 서비스와 3D 뷰가 포함된 결제 콘솔을 에이전트가 구축하도록 요구하고, 이후 99개의 체크 항목으로 점수를 매깁니다. Forge 2.0는 작동하는 Jira Forge 앱의 v2 업그레이드를 모델 호출 300회 내에 요청하고, 세 개의 시드된(seeded) Jira 사이트를 대상으로 105개의 체크 항목으로 점수를 매깁니다.
Gauntlet 점수를 얻는 데 네 번의 시도가 필요했다. 첫 번째 시도는 10월 9일에 있었으며, OpenRouter에서 "Upstream idle timeout exceeded" 오류로 인해 49회 호출 후 종료되었다. 10월 18일에는 두 번째 시도가 Mistral 서버에 의해 종료되었다. 10월 19일 초에는 우리가 운영하는 오픈 소스 코딩 에이전트(직접 포크한 버전)인 goose의 버그로 인해 세 번째 시도가 종료되었고, 네 번째 시도는 그날 오후에 완료되었다. 이 모델의 Forge 2.0 쌍은 최소 $10.95를 기준으로 각각 0.1086과 0.3304를 기록했다. DeepSeek V4.1 Flash 1017는 동일한 Forge 작업에서 더 좋은 성능을 보였다. 이는 내가 DeepSeek 글에서 언급했던 10월 17일 스냅샷이며, 약 4분의 1 시간 만에 최소 $0.62를 기준으로 각각 0.2422와 0.6618을 기록했다.
Gauntlet에서는 낮은 점수가 주로 우리의 채점기(scorer) 문제였다. Forge에서는 코드 손실이 Mistral 자체의 문제였다. 또한, 우리의 하네스(harness)는 DeepSeek보다 더 작은 컨텍스트 창(context window)을 제공했다. 빌드 트리에는 각 손실이 어디서 발생했는지 보여준다. 이것은 우리가 설정한 환경에서 기록된 Gauntlet 실행 한 번과 Forge 쌍 하나이며, 이 모델의 공급업체는 미리보기 상태일 때 조용히 변경될 수 있다고 말한다.
Mistral Large 4 벤치마크 결과: Gauntlet 0.5462, Forge 2.0 중앙값 0.2195
Three-panel bar chart comparing Mistral Large 4 with DeepSeek V4.1 Flash 1017. Score: Gauntlet 0.5462 for Mistral, with a hatched extension to about 0.7048 without our false money critical (our arithmetic), against 0.6957; Forge 2.0 build 1 0.1086 against 0.2422; build 2 0.3304 against 0.6618. Minutes per build: 144, 118 and 106 for Mistral against 23, 28 and 30, with first app-code writes at 27, 49 and 55 minutes against 2, 5 and 5. OpenRouter bill: $4.93, at least $5.40 and $5.55 against $0.21, $0.30 and at least $0.32
| Mistral Large 4 | DeepSeek V4.1 Flash 1017 |
|---|
| Gauntlet 7.2 | 0.5462, 144 min, $4.93 | 0.6957, 23 min, $0.21 |
| ... | | |
| I checked these on the live boards on 21 October; if a run page says something else now, trust the run page. All six Mistral runs together cost at least $21.53, with three of the bills only lower bounds. | | |
Mistral Large 4 빌드에서 발견한 여섯 가지 사항
- Gauntlet에서 발생한 x0.6 "잘못된 금액(wrong money)"의 치명적인 오류는 저희 버그입니다. 저희의 금액 확인 기능은 화면에 표시된 금액을 가장 오래된 50개 결제 건과 비교하는데, Mistral의 표는 가장 최신 데이터부터 열립니다.
- Mistral의 금액 포맷터는 DeepSeek와 동일한 접근 방식인 통화별 소수점 테이블을 사용하여 정수 자릿수로 작동합니다.
- Forge build 1은 제가 보기엔 build 2에 비해 격차를 많이 잃었는데, 이는 스스로 쓰게 만든 스로틀링(throttle) 때문이었습니다. 이 빌드는 리스트 호출의 실제 비용보다 25배에서 34배 많은 금액을 청구했고, v1 마이그레이션이 실행되기 전에 매시간 자체 예정 작업을 일시 중지했습니다.
- 두 Forge 빌드 모두 관리자 페이지를 표시하지 못했으며, 브라우저 셀프 테스트도 수행하지 못했습니다.
- 10월 18일 시도는 37,853단어 분량의 생각으로 시작되어 18분 동안 실행되었으나, 65,536 토큰 출력 제한에 걸려 폐기되었습니다.
- Mistral의 API는 OpenRouter를 통해 저희가 2주 전에 수행한 테스트에서 다른 세 제공업체의 엔드포인트들이 응답했던 메시지 순서를 거부했습니다.
Gauntlet에서의 Mistral Large 4 성능: 0.5462, 자체 검사 없이 약 0.70
대부분의 Gauntlet 체크는 가중 평균에 더해지지만, 몇 가지는 매우 중요하며 이 중 하나라도 실패하면 전체 점수를 최대 x0.6까지 떨어뜨립니다. 결제 콘솔에서 잘못된 금액을 입력하는 것이 바로 그런 경우입니다. 이 금액 확인은 b_money_rendered라고 불립니다. 브라우저 프로브(probe)는 결제 테이블의 처음 12개 행에 있는 금액 셀을 읽습니다. 그런 다음 스코어러(scorer)는 해당 숫자가 저장된 금액과 일치하는지, 그리고 소수점이 통화와 일치하는지를 확인합니다. 왜냐하면 금액은 통화의 가장 작은 단위(센트 또는 쿠웨이트 디나르의 필스)로 정수로 저장되기 때문입니다. 정확한 셀은 EUR와 USD에 대해 두 자리 소수점을, 엔화에는 소수점 없음, 디나르에는 세 자리 소수점을 표시합니다. Mistral의 실행 결과는 이 부분에서 0.00을 기록했으며, 상세 내역은 "12개 셀 중 0.00 지수-정확; JPY/KWD 트랩 0.00"이었습니다. 이에 따라 승수(multiplier)가 전체 점수를 0.9104에서 0.5462로 떨어뜨렸습니다.
Mistral이 렌더링한 내용
프로브가 읽은 12개 셀의 내용은 다음과 같습니다: KWD 111.000, ¥594, ¥199, $4.47, ¥809, €224.00, KWD 82.400, €33.10, KWD 2.420, ¥1,060, $1,840.00, KWD 72.400. 저희 프로브는 또한 각 행의 ID를 기록하며, 이는 고정값(fixture)과 결합되어 pay_12287이 KWD 111000으로 저장되었으므로 111.000 디나르가 맞고, pay_12286은 JPY 594로 소수점이 필요 없습니다. 12개 모두 정확합니다. 프로브의 추가 12개 행도 마찬가지입니다.
web/app.js에 있는 포매터(formatter)는 (7행부터 25행, 원본의 Ì 이스케이프가 문자로 표시됨) 부동 소수점(float)을 건드리지 않습니다:
const CUR = {
EUR: { sym: '€', exp: 2 },
USD: { sym: '$', exp: 2 },
...
이것은 작성하기 전에 계획한 것입니다. 저희 시간(EEST)으로 오전 10시 58분, 진행된 지 27분이 되었을 때, Mistral은 계약의 예제와 두 개의 실제 결제를 사고 과정에서 확인했습니다: "129900 EUR → €1,299.00 ✓; JPY 8564 → ¥8,564 ✓; KWD 8263000 → KWD 8,263.000 ✓". 스코어러가 자체적으로 찍은 인스펙터(inspector) 스크린샷을 보면 디나르 결제가 KWD 8,263.000인 것을 볼 수 있으며, 인스펙터 체크(q_payment_context)도 통과했습니다.
The scorer's screenshot of Mistral Large 4's Meridian Payments Console: summary cards of €2,054,151.31, $1,959,829.14, ¥2,064,134 and KWD 1,957,586.370, a 3D tower being inspected, and the inspector row reading ID pay_01869, Currency KWD, Amount KWD 8,263.000, Status refunded, Version 1
검사(Check)가 0을 표시한 이유
여기 스코어러(score_sb7.py)의 라인 973 근처 코드가 있습니다:
first_page = c.pack.payments[:50]
by_cur: Dict[str, set] = {}
for row in first_page:
...
payments는 날짜 순서로 저장되어 있으므로 payments[:50]은 가장 오래된 50개(pay_00000부터 pay_00049)를 의미합니다. 셀이 렌더링되려면 그 자릿수가 이 50개 금액 중 하나와 일치해야 하므로, 이 검사는 테이블이 가장 오래된 것부터 열린다고 암묵적으로 가정합니다. Mistral은 최신순으로 여는 방식(sort: '-created_at', web/app.js:49)을 사용했습니다. 따라서 12개 셀 중 어느 것도 일치할 수 없었습니다. 심지어 우리의 프로브(probe)는
돈 관련 성능 비교
제가 비교한 다섯 가지 모델은 모두 통과했습니다: Claude Opus 5.5, Claude Sonnet 5.5, GPT-6.1 Sol (제공된 Jev Router의 최고 Forge 점수의 기반 모델), GPT-6.1 Sol Pro, 그리고 DeepSeek V4.1 Flash 1017입니다. 이들은 모두 sort: 'created_at'으로 테이블을 열고, 저희 자체 레퍼런스 앱도 마찬가지이므로, 저희의 출시 검증은 절대 내림차순 기본값을 만나지 않았습니다. 그 다섯 개의 테이블을 최신 50개 결제에 대해 평가하자 점수는 0.0점, Sol은 0.05점이었습니다.
DeepSeek의 포매터는 Mistral의 복사본과 유사합니다:
let digits = String(Math.abs(minor));
if (exponent > 0) digits = digits.padStart(exponent + 1, '0');
const whole = exponent > 0 ? digits.slice(0, digits.length - exponent) : digits;
