MLX 4비트 로컬 LLM 성능 측정법

터미널에 tokens-per-sec가 찍히는 순간, 로컬 LLM의 체감이 달라진다. “돌아가긴 한다”에서 “실제로 쓸 만하다”로 넘어가려면 속도와 메모리 피크를 같은 방식으로 재서 비교해야 한다. Hugging Face에는 MLX 포맷의 4비트(mxfp4) 모델이 올라와 있다. 일부 모델 카드는 어떤 커맨드로 실행했고 무엇을 기록했는지를 로그 형태로 남겨 둔다. 이 글은 그 모델 카드의 관측 방식을 기준점으로 삼아, Apple Silicon 로컬 환경에서 로딩/추론 파이프라인과 정밀도-성능 트레이드오프를 검증 가능한 형태로 정리한다.

예: 노트북에서 로컬 모델을 켠다. 같은 프롬프트로 한 번은 고정밀로, 한 번은 4비트로 돌린다. 둘 다 “빠르다”라고 말하기 전에, 출력 로그에서 속도와 피크 메모리를 같은 항목으로 적어 비교한다.

세 줄 요약

핵심 이슈: MLX 4비트(mxfp4) 모델은 로컬 추론의 메모리 요구를 낮출 수 있다. 다만 성능·품질 평가는 “같은 커맨드/같은 프롬프트”로 재현해야 비교가 성립한다.
왜 중요한가: 일부 Hugging Face 모델 카드는 tokens-per-sec(프롬프트/생성 분리)와 Peak memory를 함께 남긴다. 이러면 속도-메모리-품질 트레이드오프를 같은 축에서 비교하기 쉽다.
뭘 하면 되나: 모델 카드의 예시 실행을 그대로 돌린다. 로그의 Prompt tokens-per-sec, Generation tokens-per-sec, Peak memory를 표에 옮겨 적는다. 가능하다면 fp16 등 다른 정밀도도 같은 절차로 실행해 차이를 확인한다.

현황

Hugging Face의 한 MLX(mxfp4) 모델 카드 예시에는 실행 결과로 프롬프트 처리와 생성의 토큰 처리량이 분리돼 찍힌다. 동시에 **피크 메모리(“Peak memory”)**도 함께 찍힌다. 이 방식은 “대충 빠르다/가볍다” 같은 인상평보다, 같은 실행법을 따랐을 때 비슷한 형식의 결과를 남기려는 보고 방식에 가깝다.

해당 페이지의 로그 예시는 다음 항목을 함께 적어 둔다. Prompt: 29 tokens, 149.991 tokens-per-sec, Generation: 117 tokens, 57.075 tokens-per-sec, Peak memory: 42.672 GB. 여기서 핵심은 “숫자가 크다/작다”가 아니다. 프롬프트 구간과 생성 구간을 나눠 보고한다는 점이다. 로컬 추론에서는 프롬프트 길이(또는 KV 캐시 크기)에 따라 병목이 달라질 수 있다. 단일 평균값만 두면 비교가 흐려진다.

다만 이 방식이 Hugging Face 전체의 “공식 표준 템플릿”인지까지는 이번 자료만으로 확인되지 않는다. 확인되는 건 개별 모델 카드에서 verbose 출력 기반으로 tokens-per-sec와 Peak memory를 기록해 재현성을 높이려는 관행이다. 독자가 따라 하기에는 충분히 구체적이다. 플랫폼 차원의 규격으로 단정하기는 어렵다.

분석

mxfp4 같은 4비트 가중치는 로컬 LLM의 접근성을 높일 수 있다. 대신 사용자는 두 가지를 함께 본다. “이 4비트가 내 작업에서 품질을 얼마나 바꾸나?”와 “속도/메모리는 얼마나 달라지나?”다. 그래서 모델 카드가 남긴 Prompt tokens-per-sec / Generation tokens-per-sec / Peak memory 같은 로그는 과시용 지표라기보다 **비교의 기준선(baseline)**으로 쓸 수 있다. 같은 프롬프트, 같은 커맨드로 숫자를 남겨 두면, 다른 정밀도(fp16 등)나 다른 디코딩 설정을 얹었을 때 “무엇이 변했는지”를 설명하기 쉬워진다.

한계도 있다. 첫째, tokens-per-sec만으로는 출력의 정확도나 유용성을 판단하기 어렵다. 둘째, 4비트의 품질 변화는 작업별로 다르게 나타날 수 있다(예: 환각에 민감한 작업, 긴 문맥 검색, 수학/논리 등). 셋째, 긴 문맥 능력은 “그냥 길게 넣어보기”만으로는 비교가 어렵다. 그래서 재현 가능한 평가 절차가 필요하다. 이 글에서 언급한 흐름은 다음처럼 나뉜다. 표준 과제는 EleutherAI lm-evaluation-harness 같은 절차로, 환각은 TruthfulQA 같은 진실성 벤치마크로, 긴 문맥은 NIAH(needle-in-a-haystack) 계열 절차로 따로 측정한다. NIAH는 긴 컨텍스트 “건초더미”에서 필요한 “바늘”을 찾아오게 만들어, 길이 증가에 따른 성능 변화를 수치로 비교하려는 방식이다.

실전 적용

핵심은 “모델 카드의 사용 예시를 그대로 재현”이다. 모델 카드가 제공한 커맨드(예: mlx_lm.generate)를 그대로 실행한다. 출력에 포함된 tokens-per-sec와 Peak memory를 복사해 기록한다. 이때 속도는 Prompt와 Generation을 분리해 적는다. 프롬프트 처리는 빠른데 생성이 느릴 수도 있고(또는 반대일 수도 있다). 이 차이는 디코딩 설정, 캐시, 정밀도 변경을 점검할 때 단서가 된다.

다음 단계는 품질 검증이다. 같은 모델의 다른 정밀도(예: fp16)가 있다면, 두 버전을 같은 프롬프트/같은 설정으로 돌려 결과를 비교한다. 그리고 “내가 걱정하는 품질”이 무엇인지에 따라 평가 절차를 나눈다. 정답률이 중요하면 표준 과제 평가로 간다. 환각이 문제면 TruthfulQA 같은 진실성 평가로 간다. 긴 문맥이 핵심이면 NIAH 계열 절차로 간다. 이렇게 하면 “4비트라서 별로” 같은 감상 대신, 어떤 축에서 차이가 났는지 정리할 수 있다.

오늘 바로 할 일 체크리스트 3개

모델 카드 예시를 그대로 실행하고, 로그의 Prompt tokens-per-sec / Generation tokens-per-sec / Peak memory를 원문 그대로 기록한다.
같은 프롬프트를 고정한 채, 정밀도만 바꿔 결과를 모은다. 속도·피크 메모리·출력 품질을 같은 표에서 비교한다.
긴 문맥·환각·정답률 중 리스크가 큰 축을 하나 고른다. 그 축에 맞는 공개 벤치마크 절차로 mxfp4 vs 고정밀을 검증한다.

FAQ

Q1. 모델 카드의 tokens-per-sec는 어떤 값을 보고해야 하나?
A1. 조사 결과로 확인되는 모델 카드 예시에서는 verbose 출력에 Prompt와 Generation의 tokens-per-sec가 분리돼 나온다. 같은 실행 커맨드와 같은 프롬프트로 돌린 뒤, 두 값을 분리해 기록하는 방식이 재현 가능한 보고로 쓰인다.

Q2. 메모리는 무엇을 기준으로 비교해야 하나?
A2. 같은 예시에서 메모리는 출력 로그의 Peak memory를 함께 기록한다. 예시에는 Peak memory: 42.672 GB처럼 단일 값으로 제시된다. 다만 이것이 모든 환경에서 동일한 정의/측정 규격인지(예: RSS, unified memory 포함 범위 등)는 추가 확인이 필요하다.

Q3. mxfp4가 정확도나 환각을 얼마나 바꾸는지 “공개 절차”로 확인하려면?
A3. 조사 결과 기준으로는 세 갈래로 나눈다. (1) 표준 과제 정답률은 EleutherAI lm-evaluation-harness로 재현 평가한다. (2) 환각 성향은 TruthfulQA 같은 진실성 벤치마크로 분리 측정한다. (3) 긴 문맥은 NIAH(needle-in-a-haystack) 계열(예: NoLiMa, Sequential-NIAH)로 컨텍스트를 늘려가며 정확도를 본다. 핵심은 mxfp4와 fp16을 같은 프롬프트/같은 설정으로 비교하는 것이다.

결론

MLX 4비트(mxfp4) 로컬 추론은 “가능”을 “측정 가능한 선택지”로 다루게 만든다. 먼저 모델 카드가 남긴 방식대로 tokens-per-sec(Prompt/Generation 분리)와 Peak memory를 찍어 둔다. 그다음 벤치마크로 품질 변화를 확인한다.

Aionda

MLX 4비트 로컬 LLM 성능 측정법

세 줄 요약

현황

분석

실전 적용

FAQ

결론

다음으로 읽기

참고 자료

업데이트 받기