“내 맥에서 이 모델이 돌아갈까?”

로컬 LLM을 검토할 때 가장 먼저 생기는 질문입니다. 하지만 Apple Silicon은 CPU와 GPU가 통합 메모리를 공유합니다. 시스템에 16GB가 있다고 해서 모델이 그 16GB를 전부 사용할 수 있다고 가정하면 안 됩니다.

이번 주제는 GeekNews의 AI Hardware Fit 소개에서 발견했습니다. 검증한 버전은 v7.11.0, commit은 ec95edf423ac8d63ec471beeecc66684755f7b2b입니다. 이후 데이터가 바뀌어도 같은 계산을 설명할 수 있도록 고정 revision의 실제 계산 엔진을 실행했습니다.

먼저 분명히 할 점: 실제 추론 테스트가 아니다

이번 확인에서는 모델 가중치를 다운로드하지 않았습니다. Gemma나 Llama를 실행하지 않았고, tokens/s나 응답 지연도 측정하지 않았습니다.

실행한 것은 v7.11.0에 포함된 estimateModel() 함수입니다. 따라서 아래 결과는 실제 구동 성공을 입증하는 벤치마크가 아니라, 다운로드 전에 명백히 맞지 않는 후보를 거르는 휴리스틱 사전 산정입니다.

프로젝트도 같은 한계를 밝힙니다. 브라우저는 실제 GPU 점유량과 드라이버 상태를 읽지 못하며 결과는 런타임, 모델 구현, KV cache 정밀도, 배치와 다른 프로세스의 점유량에 따라 달라질 수 있습니다. 자세한 범위는 공식 정확도와 한계 문서에서 확인할 수 있습니다.

가중치 크기만 계산하면 부족하다

AI Hardware Fit의 계산 방법론은 모델 메모리를 크게 세 부분으로 나눕니다.

필요 메모리 = 모델 가중치 + KV cache + 런타임 오버헤드

가중치는 파라미터 수와 양자화 크기를 반영합니다. KV cache는 컨텍스트 길이, 동시 요청 수, cache 정밀도에 따라 커집니다. 런타임 오버헤드는 llama.cpp·Ollama, vLLM, Transformers마다 다른 값을 사용합니다.

같은 Q4 양자화라도 1B와 70B가 전혀 다른 결과를 내는 이유입니다. 계산은 결정론적이지만 실측 모델은 아닙니다.

M1 16GB의 계산 예산을 10GB로 잡았다

실행 호스트는 Apple M1 8-core, 통합 메모리 16GB, arm64였습니다. 검증 스크립트는 Node.js 24.14.1에서 실행했습니다.

프로젝트에는 M1 16GB 전용 preset이 없습니다. 따라서 16GB를 곧바로 모델 예산으로 입력하지 않았습니다.

v7.11.0의 Apple preset 정책은 Metal의 recommendedMaxWorkingSetSize를 근거로 통합 메모리의 약 75%를 작업 예산으로 둡니다. 이 비율을 M1에 명시적으로 적용해 12GB를 잡고, 다시 2GB를 예약·안전 여유로 제외했습니다.

시스템 통합 메모리: 16GB
Apple working-set 가정: 12GB
예약 및 안전 여유: 2GB
모델 계산 가용량: 10GB
런타임: llama.cpp
양자화: Q4_K_M
컨텍스트: 8,192 tokens
동시 요청: 1

12GB는 M1에서 측정한 고정 VRAM 용량이 아닙니다. v7.11.0의 정책을 적용한 계산 가정입니다.

성공 사례: Gemma 3 1B는 2.067GB

고정 revision의 계산 엔진을 불러오는 임시 스크립트를 실행했습니다.

node /tmp/m1-fit-check.mjs

Gemma 3 1B IT의 핵심 결과는 다음과 같았습니다.

{
  "model": "Gemma 3 1B IT",
  "quant": "Q4_K_M",
  "contextTokens": 8192,
  "availableGb": 10,
  "requiredGb": 2.067,
  "weightsGb": 0.648,
  "kvGb": 0.18,
  "runtimeOverheadGb": 1.239,
  "pressure": 0.207,
  "grade": "S"
}

가중치만 보면 0.648GB지만 KV cache와 runtime overhead를 합친 필요량은 2.067GB였습니다. 10GB 예산에 대한 압력은 약 20.7%였고, 도구의 기준에서는 여유 범위인 S로 분류됐습니다.

이 결과를 “M1에서 Gemma 3 1B가 빠르게 실행됐다”로 바꿔 말하면 안 됩니다. 확인된 것은 메모리 계산뿐입니다.

실패 사례: Llama 3.1 70B는 61.882GB

같은 하드웨어 조건에서 모델만 Llama 3.1 70B Instruct로 바꿨습니다.

{
  "model": "Llama 3.1 70B Instruct",
  "quant": "Q4_K_M",
  "contextTokens": 8192,
  "availableGb": 10,
  "requiredGb": 61.882,
  "weightsGb": 45.36,
  "kvGb": 12.6,
  "runtimeOverheadGb": 3.922,
  "pressure": 6.188,
  "grade": "F"
}

컨텍스트 자체는 모델 제한 안에 있었습니다. 실패 원인은 메모리 예산 초과였습니다. 가중치만 45.36GB이고 KV cache가 12.6GB였습니다. 총 필요량은 10GB 예산의 약 6.19배로 F 판정을 받았습니다.

이 사례는 “Q4니까 작은 메모리에서도 되지 않을까?”라는 판단이 위험한 이유를 보여 줍니다. 파라미터 수와 컨텍스트가 크면 양자화 후에도 범위를 크게 벗어납니다.

어디까지 도입 판단에 쓸 수 있나

이 계산기는 모델을 내려받기 전에 불가능한 후보를 제거하는 첫 번째 filter로 유용합니다. 양자화, 컨텍스트, 동시 요청, 예약 메모리를 같은 기준에서 비교할 수 있고 계산식도 공개돼 있습니다.

반대로 등급을 실측 성능처럼 인용하면 안 됩니다. 특히 Apple Silicon에서는 macOS와 다른 프로세스가 같은 메모리를 사용합니다. 실제 결과는 GGUF 파일, llama.cpp 빌드, Metal 지원, KV cache 설정과 당시 점유량에 따라 달라집니다.

카탈로그의 모델·GPU 개수도 계속 변합니다. GeekNews 소개와 고정 revision 문서에서 집계 숫자가 달랐으므로 홍보성 개수를 핵심 근거로 사용하지 않았습니다.

안전한 순서는 명확합니다.

  1. 휴리스틱 계산으로 명백히 불가능한 후보를 제거합니다.
  2. 모델 파일과 런타임 버전을 고정합니다.
  3. 실제 업무 입력으로 peak memory와 응답 속도를 측정합니다.
  4. macOS와 다른 프로세스가 점유한 메모리를 포함해 장시간 안정성을 확인합니다.

결론

AI Hardware Fit v7.11.0은 16GB M1에서 로컬 LLM 후보를 고르는 사전 filter로 도입할 가치가 있습니다. 이번 조건에서 1B Q4는 2.067GB로 계산상 여유가 있었고, 70B Q4는 61.882GB로 명확히 탈락했습니다.

다만 계산기는 휴리스틱이며 이번 검증에서도 모델 추론을 실행하지 않았습니다. 최종 구매와 배포 판단은 반드시 실제 모델, 실제 런타임, 실제 입력으로 진행한 PoC 뒤에 내려야 합니다.