Mistral Large 4 자체 배포: 1T·52B와 실제 서버 조건 읽는 법

공개 가중치가 바꾸는 선택

Mistral은 10월 6일 Large 4의 API 공개 미리보기를 발표했고, 10월 29일에는 추가 학습한 모델의 가중치 공개를 발표했다. API를 쓸 수 있게 된 날짜와 내려받아 운영할 수 있게 된 날짜를 구분해야 한다. 이번 글은 10월 31일 확인한 공개 체크포인트와 배포 문서를 기준으로 한다. 초기 발표, 가중치 공개 발표

직접 배포의 이점은 팀이 모델 파일과 실행 환경, 업데이트 시점을 관리할 수 있다는 데 있다. 대신 서버 준비·요청 대기·장애 대응을 팀의 운영 문제로 받아들인다. 가중치를 소유하는 것과 원하는 응답 시간을 얻는 것은 별개의 결정이다.

가상의 개발팀이 “외부로 보내기 어려운 사내 코드를 검토하고, 문제 위치와 수정 이유를 남기는 서비스”를 만든다고 하자. 이 팀에 필요한 답은 모델 순위보다 구체적이다. 어떤 장비와 체크포인트를 시험할지, 얼마만큼의 코드를 넣을지, 여러 개발자가 동시에 요청하면 무엇을 제한할지 정해야 한다. 아래 서비스 사례는 설계 예시이며, 이 글에서 GPU 추론이나 코드 검토 성능을 측정하지 않았다.

1T를 보관하면서 일부를 계산하는 구조

공식 카드의 규모는 전체 약 1조 파라미터다. 토큰당 활성 파라미터는 49B이며 임베딩·출력층을 포함하면 52B다. 라우팅 대상 전문가 128개 중 토큰마다 4개를 선택하고, 공유 전문가 1개도 사용한다. 고정 커밋의 모델 카드

이런 MoE 구조에서 ‘활성’은 이번 입력의 계산 경로를 설명한다. 다음 토큰이 다른 전문가를 선택할 수 있으므로 사용하지 않은 전문가의 가중치가 모델에서 사라지는 것은 아니다. 모든 가중치를 GPU에 올리는 구성이라면 전체 적재량이 필요하다. 일부를 다른 장치에 두는 구성은 전송과 실행 지원까지 별도로 다룬다.

단위만 확인하는 가상 계산을 해 보자. 정확히 1조 개의 값을 모두 1바이트로 저장한다고 가정하면 원시 데이터는 1TB다. 520억 개만 세면 52GB가 된다. 약 19.2배 차이는 ‘활성 수’를 ‘보관할 수’로 바꾸었기 때문에 생긴다. 이 계산은 실제 파일 크기나 GPU 사용량이 아니다. 보조값, 서로 다른 자료형, 캐시와 실행 중 작업 공간을 포함하지 않는다.

실제 FP8 체크포인트의 설정도 모든 텐서를 한 가지 자료형으로 취급하지 않는다. quant_method는 fp8이지만 비전 인코더·출력층 등 변환 제외 목록이 있다. 따라서 전체 파라미터 수에 일정 바이트를 곱한 값은 거친 출발점이다. 공식 config.json

FP8·NVFP4를 장비와 함께 고른다

NVFP4 카드는 MoE 전문가의 NVFP4 양자화와 FP8 선형층을 설명하고, Blackwell 계열 GPU를 대상으로 명시한다. 공급자는 여러 평가에서 FP8과 유사한 결과를 제시한다. 이 설명을 우리 코드와 장비에서도 같은 품질·속도를 얻는다는 보증으로 사용할 수는 없다. NVFP4 카드

vLLM의 현재 레시피는 가중치 규모를 FP8 약 1.06TB, NVFP4 약 610GB로 안내한다. 검증 장비에는 NVFP4의 B200·GB300, FP8의 H200 등이 포함된다. H200 예시는 두 노드의 총 16개 GPU 구성이므로 ‘H200 지원’을 ‘한 대에서 같은 구성으로 실행’으로 읽으면 안 된다. 이 수치는 문서의 안내이며 테크독해의 다운로드·메모리 실측이 아니다. vLLM 레시피

현재 자원·목표	첫 비교 대상으로 삼을 것	다음 판단에 필요한 정보
Blackwell 서버가 있음	해당 장비의 NVFP4 구성	실제 적재·요청 메모리, 사내 코드의 오류 탐지 결과
H200 자원을 묶을 수 있음	공식 FP8 다중 노드 구성	노드 간 연결, 전체 GPU 수, 완료 지연
장비가 없고 업무 적합성부터 모름	반출 가능한 자체 제작 입력으로 기능 평가	검토 결과가 쓸 만한지, 이후 자체 배포로 옮길 비용

마지막 행은 API나 별도 시험 환경을 검토할 수 있다는 편집 제안이다. 비공개 코드를 보내도 된다는 허가가 아니다. 또 기능 평가가 좋더라도 자체 배포의 처리량과 운영 비용은 다시 측정해야 한다.

복사하기 전에 Configuration 한 줄을 대조한다

이번 조사에서 공식 레시피의 Markdown 응답을 장비 선택값별로 직접 요청했다. 문서 서버 응답을 확인한 것이며 아래 장비를 실행한 결과는 아니다.

요청한 선택값	반환된 구성의 핵심
hardware=b200, variant=default	B200 8개, 단일 노드 Tensor Parallel, NVFP4
hardware=h200, variant=fp8	H200 8개씩 2노드, Multi-Node Tensor Parallel, FP8
존재하지 않는 장비값	GB300 NVL4 4개, 기본 NVFP4 구성으로 대체

레시피는 알 수 없거나 호환되지 않는 선택값이 기본값으로 돌아갈 수 있으므로 Configuration을 확인하라고 명시한다. URL을 요청해 명령이 나왔다는 사실만으로 원하는 장비의 명령을 얻었다고 볼 수 없다. 직접 확인한 B200 응답, H200 응답

우리 팀의 배포 기록에는 요청한 장비명과 실제로 반환된 장비·노드 수·체크포인트·병렬화 방식을 함께 적는다. 장비명 오타나 잘못된 preset을 조기에 찾는 데 도움이 된다. 기본값으로 대체된 경우에는 명령을 실행하기 전에 선택을 바로잡는다.

버전 안내도 주의해서 읽을 부분이 있다. 확인한 Markdown 상단은 vLLM >= 0.34.0을 요구하지만, 같은 문서의 Prerequisites는 정식·nightly wheel에 아직 지원이 없으며 전용 mistral-large-4 이미지를 쓰도록 설명한다. 두 문구만으로 일반 패키지 설치가 충분하다고 결론 내리기 어렵다. 여기서는 설치 성공을 주장하지 않으며, 첫 시험에는 공식 모델 전용 이미지를 출발점으로 삼고 실제 이미지 digest와 엔진 버전을 기록하는 방법을 제안한다. 레시피 원문

가변 이미지 태그 하나만 남기면 이후 같은 명령으로 다른 빌드를 받을 수 있다. 모델도 저장소 이름만 기록하지 말고 revision을 묶어 둔다. 이 글이 대조한 기본 카드·설정의 revision은 f12dabdc…, NVFP4 카드는 bb6d00fe…이며 위 링크에 전체 커밋이 들어 있다.

사내 코드 검토를 세 입력으로 좁혀 시험한다

이제 하드웨어 표에서 업무로 돌아오자. 처음부터 저장소 전체를 넣기보다 같은 변경을 세 가지 입력으로 구성한다. 다음은 독자가 자체 제작 코드로 반복할 수 있는 미실행 평가 설계다.

가상 서비스에는 계정별 보고서 다운로드 기능이 있다. 요청의 보고서 ID만 조회하고 요청자의 계정 소유권을 확인하지 않는 변경을 만든다. 비교할 정상 버전에는 소유권 조건이 있다. 실행 시험은 격리된 예제에서만 수행하고, 실제 사용자 데이터는 넣지 않는다.

입력 묶음	포함할 것	검토 결과에서 확인할 것
A: 작은 변경	변경 함수, 호출부, 관련 테스트	권한 확인 누락 위치와 필요한 조건을 찾는가
B: 긴 문맥	A와 같은 근거, 주변 모듈·문서·무관한 코드	근거 위치가 멀어져도 결론과 코드 위치가 유지되는가
C: 정상 반례	소유권 검사가 이미 있는 정상 버전	같은 취약점이 있다고 무조건 지적하지 않는가

모델의 출력 계약은 ‘문제 있음/없음/판단 자료 부족’, 근거 파일과 위치, 필요한 추가 확인으로 정한다. B에 관련 타입이나 인증 문맥이 빠졌다면 판단 보류가 맞을 수 있다. 취약한 예제 하나를 맞히는 것만으로 도입하지 않고, 정상 반례와 정보 부족 입력까지 비교해야 과잉 경보와 근거 없는 확신을 구분할 수 있다. JSON 형식을 쓰더라도 내용의 타당성 검사는 남는다. 구조화 출력의 업무 검증에서 이 차이를 이어 볼 수 있다.

첫 비교에서는 모델 revision, 체크포인트, 추론 노력 수준, 출력 예산과 입력을 고정한다. 이후 한 항목씩 바꾼다. NVFP4에서 결과가 달라졌는데 문맥 길이·프롬프트·추론 수준도 함께 바뀌었다면 양자화가 원인인지 판단하기 어렵다. 같은 설정에서도 생성 결과가 달라질 수 있으므로 반복 횟수와 전체 결과를 보존한다.

긴 문맥과 여러 사용자를 따로 늘린다

모델 카드의 최대 문맥은 약 1M 토큰이다. 그러나 현재 vLLM 가이드는 검증 범위를 256k까지로 밝히며 생성된 기본 명령도 max-model-len=262144로 제한한다. 모델이 나타내는 상한과 특정 서버 구성에서 확인한 범위가 다르다. 모델 카드, 실행 레시피

사례의 A·B·C를 먼저 요청 한 개씩 실행해 결과와 최고 메모리, 첫 응답과 최종 완료 시간을 기록한다. 다음에는 같은 길이의 입력으로 동시 요청을 늘린다. 마지막으로 짧은 요청과 긴 요청이 섞이는 상황을 비교한다. 긴 검토 한 건이 들어올 때 짧은 검토의 대기 시간이 얼마나 바뀌는지가 실제 개발자의 체감과 연결된다.

설정의 최대 동시 시퀀스 수는 허용 한도다. 그 수만큼 최대 길이 요청을 동시에 받아도 메모리와 응답 기준을 만족한다는 보증은 아니다. 시작에 성공했더라도 큐가 길어지거나 생성 도중 여유가 부족할 수 있다. 팀이 감당할 문맥·동시 요청 조합을 정하고, 넘는 요청은 대기·분할·거절 중 무엇으로 처리할지 명시한다.

또 Large 4는 MLA와 레이어 간 KV 공유를 사용하는 구조다. 일반 GQA용 단순 캐시 식을 그대로 넣어 정확한 수용량이라고 제시하지 않는다. 일반적인 추론 메모리 설명은 개념을 이해하는 데 쓰고, 실제 용량은 해당 엔진이 기록한 값과 부하 실행으로 확인한다. 지연은 요청의 임계 경로를 나누는 방법처럼 대기·입력 처리·생성을 분리해 남긴다.

공개 가중치의 사용 조건도 배포 형태와 연결된다

이 모델은 일반 MIT 그대로가 아닌 Mistral Ecosystem Open-Weight License를 사용한다. 조건 2는 라이선스 이용자 또는 계열사가 Model as a Service 사업을 운영할 경우 상업적 사용 전에 별도 상업 라이선스를 요구한다. 조건 3은 제3자에게 모델을 제공하지 않는 내부 사용과 Mistral 공식 제품을 통한 사용을 그 요구의 예외로 적는다. 고정 커밋의 LICENSE 전문

문서의 MaaS 정의는 제3자가 입력·매개변수·학습 데이터에 의미 있는 통제권을 갖는 방식의 모델 접근을 포함한다. 특정 기능에만 모델 능력이 들어간 최종 사용자 제품과 다른 호스팅 모델로 요청을 중계하는 경우는 정의의 제외 항목으로 제시한다. 저작권·허가 고지 보존 조건도 있다.

따라서 예시의 사내 검토 도구를 외부 고객용 범용 추론 API로 바꾸면 사용 조건을 다시 확인해야 한다. ‘상업적 사용 가능’이라는 카드의 짧은 문장만으로 모든 제공 형태를 승인받았다고 보면 안 된다. 이 글은 원문의 적용 지점을 안내하며 특정 사업의 계약상 해당 여부를 판정하지 않는다.

첫 도입의 산출물은 실행 명령과 평가 기록이다

자체 배포 검토 기록지 내려받기에는 요청한 레시피와 반환된 구성, 모델 revision과 이미지 digest, A·B·C 입력, 동시 요청별 관측을 적는 칸을 넣었다. 빈칸은 아직 측정하지 않았다는 뜻이며 이 글의 성능 결과가 아니다.

도입 판단은 세 가지로 나뉜다. 정상 반례를 포함해 업무 결과가 쓸 만하고 응답 기준을 만족하면 제한된 내부 사용을 검토한다. 결과는 유용하지만 긴 요청이 짧은 요청을 지연시키면 큐·입력 한도나 실행 자원 분리를 먼저 조정한다. 품질의 이득이 작고 운영 부담이 크면 기존 방식이나 더 작은 모델을 유지할 수 있다.

Mistral Large 4의 공개는 팀이 운영 주도권을 선택할 가능성을 넓혔다. 그 선택을 현실로 만드는 단위는 모델 이름 하나가 아니라 체크포인트·실행 환경·허용 입력·완료 기준의 묶음이다. 처음 시험할 때 이 묶음을 저장해 두면 이후 모델이나 엔진이 바뀌었을 때 무엇을 다시 비교할지 명확해진다.