로컬 AI를 위한 8GB 맥 생존 가이드

laptop_mac macOS Sonoma Intermediate schedule 8 min read

by Alex Rivera • May 14, 2024

Step 1 8GB 통합 메모리 현실 점검

이 미신을 즉시 없애버리자: 8GB 통합 메모리가 대부분의 사람들이 주장하는 것처럼 로컬 AI에 있어 사형 선고가 아니다. 하지만 이는 무분별한 모델 선택에는 냉혹하고, 세밀한 정밀도에는 보상을 주는 환경이다. 왜 그런지 이해하려면 Apple Silicon의 메모리 아키텍처를 간략히 살펴볼 필요가 있다.

통합 메모리는 "단순한 RAM"이 아니다

인텔 시대의 기기에서는 CPU가 시스템 RAM을, GPU가 자체 전용 VRAM을 각각 보유하여 서로 리소스를 공유할 수 없는 두 개의 별개 메모리 풀이 존재했다. Apple Silicon의 통합 메모리 아키텍처(UMA)는 이 경계를 완전히 제거했다. CPU, GPU, Neural Engine 모두 동일한 물리적 메모리 풀을 사용한다. 이것이 바로 8GB Mac이 추론 작업에서 16GB DDR4 PC를 능가할 수 있는 이유다 — 모델이 컴퓨팅 리소스에 접근하기 위해 PCIe 버스를 가로지를 필요가 없기 때문이다.

┌─────────────────────────────────────────────┐
│           Unified Memory (8GB)              │
│                                             │
│   ┌─────────┐  ┌─────────┐  ┌───────────┐  │
│   │   CPU   │  │   GPU   │  │  Neural   │  │
│   │  Cores  │  │  Cores  │  │  Engine   │  │
│   └─────────┘  └─────────┘  └───────────┘  │
│        ↑            ↑             ↑         │
│        └────────────┴─────────────┘         │
│              Shared Memory Bus              │
└─────────────────────────────────────────────┘

이 제로 카피(zero-copy) 아키텍처는 메모리에 로드된 모델 가중치가 전체 메모리 대역폭으로 모든 컴퓨팅 유닛에서 즉시 접근 가능함을 의미한다 — M2 칩에서는 최대 100 GB/s에 달한다. 이는 16x PCIe Gen 4 슬롯을 통해 약 32 GB/s로 데이터를 이동시키는 중급형 외장 GPU와 비교해보면 확연한 차이다.

실제 메모리 예산 분석

여기서 솔직해질 필요가 있다. 8GB 전체가 AI 추론에 사용 가능한 것이 아니다. macOS 자체가 메모리 상주형 운영 체제이며, 그 나름의 요구 사항이 있다:

즉, 실질적인 추론 예산은 현실적으로 4~5.5GB이며, 8GB가 아니다. 모든 바이트가 중요하다. 이론적으로 메모리에 맞는 모델도 Slack, 브라우저, Spotify를 동시에 실행하면 시스템을 스왑 지옥으로 몰아넣을 수 있다.

모델 메모리 사용량 이해하기

모델의 메모리 요구 사항은 단순히 디스크상의 파일 크기가 아니다. 추론 중에는 다음 사항들을 고려해야 한다:

• 모델 가중치 — 가장 큰 구성 요소로, 파라미터 수와 양자화에 따라 크기가 달라짐
• KV 캐시 — 컨텍스트 윈도우 크기에 따라 증가하는 키-값 어텐션 캐시
• 런타임 오버헤드 — 프레임워크 버퍼, 연산 그래프, 활성화 메모리

가중치 메모리 추정을 위한 대략적인 공식:

Memory (GB) ≈ (Parameters × Bits_per_weight) / (8 × 1024³)

Example: 7B model at 4-bit quantization
= (7,000,000,000 × 4) / (8 × 1,073,741,824)
≈ 3.26 GB

이것이 Q4로 양자화된 7B 모델이 약 3.5–4.2GB를 차지하는 이유를 설명합니다 — 기술적으로는 8GB 하드웨어에서 실행 가능하지만, 더 긴 컨텍스트에서 KV 캐시를 위한 여유 공간이 사실상 전혀 없는 상태로 운영하게 됩니다.

7B 모델에 대한 솔직한 진실

8GB Mac에서의 7B 모델은 프로덕션 워크플로우에 편안하게 사용할 수 없습니다. 작동은 합니다. 하지만 "작동한다"와 "잘 작동한다"는 다른 문제입니다.

2048 토큰 컨텍스트 윈도우에서 7B Q4 모델은 사용 가능한 추론 예산 전체를 소비합니다. 4096 토큰으로 늘리면 반드시 스왑이 발생합니다. 경험은 부드러운 추론에서 끊기고 열 제한된 느린 작업으로 저하되며, 이는 메모리 압박 관리에 대한 훌륭한 교훈이 됩니다.

로컬 AI를 위해 8GB Mac을 진정으로 잘 활용하는 엔지니어와 파워 유저들은 다른 사고방식을 내면화했습니다: 더 작고, 더 빠르며, 목적에 맞는 모델이 크고 범용적인 모델을 항상 이깁니다. 다음 섹션에서 그 스택을 구축하는 방법을 정확히 보여드리겠습니다.

Step 2 스왑 메모리란 무엇이며 왜 피해야 하는가

Mac의 물리적 통합 메모리가 부족해지면, macOS는 충돌하지 않습니다 — 대신 훨씬 더 교묘한 일을 조용히 수행합니다: SSD를 오버플로우 메모리로 사용하기 시작합니다. 이 메커니즘을 스왑 메모리 (또는 가상 메모리 페이징)라고 하며, 안전망처럼 들리지만 로컬 AI 추론에 있어서는 전속력으로 달려드는 성능 절벽과 같습니다.

스왑의 작동 방식

macOS는 메모리 압축 및 스와핑이라는 기술을 사용합니다. OS는 먼저 더 많은 데이터를 RAM에 맞추기 위해 비활성 메모리 페이지를 압축하려 시도합니다. 그것으로도 충분하지 않으면, 페이징이 시작됩니다 — 메모리 내용을 SSD의 스왑 파일이라는 예약된 공간에 기록하고, 필요할 때 다시 읽어옵니다.

Physical Unified Memory (8GB)
        │
        ▼
┌───────────────────────┐
│  Active Data (in RAM) │  ← Lightning fast (400 GB/s bandwidth)
└───────────────────────┘
        │ overflow
        ▼
┌───────────────────────┐
│  Swap on SSD          │  ← ~3,000–7,000 MB/s (NVMe)
└───────────────────────┘

속도 차이가 문제입니다. Apple Silicon의 통합 메모리는 약 400 GB/s의 대역폭으로 작동합니다. Apple의 가장 빠른 NVMe SSD조차도 최고 약 7 GB/s 수준입니다 — 스왑으로 밀려나는 데이터에 대해 약 57배 느린 처리량입니다.

LLM 추론에 미치는 영향

대형 언어 모델은 일반적인 애플리케이션과 다릅니다. 추론 중에 모델 가중치는 각 토큰을 계산하기 위해 메모리를 통해 지속적으로 스트리밍되어야 합니다. 4비트 양자화된 7B 파라미터 모델은 약 4–5GB의 메모리를 차지합니다. macOS 시스템 프로세스, 브라우저, 그 외 백그라운드 앱들이 이미 실행 중인 상태에서는 8GB를 초과하는 데 매우 적은 요인만으로도 충분합니다.

모델 가중치가 스왑으로 넘어가는 순간, 모든 단일 토큰 생성은 SSD에서 데이터를 읽어와야 합니다. 결과는 우아한 속도 저하가 아닙니다 — 완전한 붕괴입니다:

숨겨진 SSD 마모 문제

순수 성능 외에도 스왑을 진지하게 고려해야 할 또 다른 이유가 있습니다: SSD 수명. 스왑에 대한 모든 쓰기 작업은 SSD의 NAND 플래시 저장소에 대한 쓰기 작업입니다. 스왑을 지속적으로 과도하게 사용하는 대규모 추론 작업을 실행하면 수개월, 수년에 걸쳐 드라이브 마모를 의미 있게 가속화할 수 있습니다.

Apple은 MacBook SSD를 교체하는 것을 쉽게(또는 저렴하게) 만들지 않습니다. SSD를 보호하는 것은 곧 하드웨어 투자를 보호하는 것입니다.

실시간으로 스왑 모니터링하는 방법

모델을 로드하기 전에, 메모리 압력을 확인하는 습관을 들이세요. Activity Monitor → Memory 탭을 열거나, 터미널에서 다음을 실행하세요:

# Check current swap usage
vm_stat | grep "Swapouts"

# Real-time memory pressure monitoring
sudo memory_pressure

빠른 스냅샷을 위해 이 한 줄 명령어를 사용할 수도 있습니다:

sysctl vm.swapusage

정상적인 출력은 다음과 같습니다:

vm.swapusage: total = 2048.00M  used = 0.00M  free = 2048.00M

모델을 실행하는 동안 used 값이 증가하고 있다면, 설정이 잘못된 것입니다. 이 가이드의 나머지 부분은 해당 수치를 0으로 유지하는 데 전념합니다.

황금 규칙: 모델이 간결한 macOS 환경과 함께 8GB 통합 메모리에 완전히 들어맞지 않는다면, 어떤 하드웨어 트릭으로도 극복할 수 없는 성능 패널티를 치르게 됩니다. 해결책은 항상 더 작게, 더 스마트하게, 또는 더 가볍게 가는 것이며 — 스왑이 그 차이를 흡수하도록 내버려 두는 것은 절대 안 됩니다.

Step 3 8GB Mac을 위한 최적의 소형 모델 (Gemma 2B, Phi-3, Qwen)

8GB 통합 메모리 시스템에 맞는 올바른 모델을 선택하는 것은 타협이 아닙니다 — 그것은 정밀한 선택의 문제입니다. 4B 파라미터 이하의 모델 환경은 크게 성숙했으며, 여러 유력 모델들이 여러분을 놀라게 할 진정으로 인상적인 추론, 코딩, 지시 수행 능력을 제공합니다. 핵심은 효율적으로 설계된 모델과 단순히 작을 뿐인 모델을 구별하는 것입니다.

다음은 엄격한 규칙입니다: 모델 가중치 + KV 캐시 + macOS 오버헤드가 8GB 안에 여유 있게 맞아야 합니다. 이는 일반적으로 디스크/RAM에서 1.5GB에서 4GB 사이에 해당하는 양자화된 모델을 목표로 하여, 시스템이 숨 쉴 여유 공간을 남겨야 함을 의미합니다.

한눈에 보는 유력 모델들

Gemma 2 2B — Google의 효율적인 주력 모델

Google의 Gemma 2 2B는 자신의 체급을 훨씬 뛰어넘는 성능을 발휘합니다. 슬라이딩 윈도우 어텐션 메커니즘과 로짓 소프트 캡핑을 사용하여 기존 2B급 모델보다 훨씬 뛰어난 일관성을 보여줍니다. 8GB Mac에서 안심하고 매일 사용할 수 있는 모델입니다.

# Pull and run Gemma 2 2B via Ollama
ollama pull gemma2:2b
ollama run gemma2:2b

장점: 뛰어난 요약 능력, 자연스러운 대화 흐름, 우수한 명령 수행 능력. 단점: 코딩 품질이 Phi-3에 비해 떨어지며, 2B 변형에서 제한된 컨텍스트 윈도우를 가집니다.

Phi-3 Mini — 추론 전문가

Microsoft의 Phi-3 Mini (3.8B)는 이 등급에서 가장 기술적으로 정교한 옵션입니다. 엄격하게 선별된 "교과서 수준"의 데이터셋으로 학습되어, 훨씬 더 큰 모델들과 견줄 수 있는 추론 및 코딩 벤치마크를 달성합니다. 코드 생성, 논리 문제 또는 구조화된 출력을 위해 로컬 AI를 사용한다면, Phi-3 Mini가 최선의 선택입니다.

# Run Phi-3 Mini with Ollama
ollama pull phi3:mini
ollama run phi3:mini

# Or target the 128K context variant explicitly
ollama pull phi3:3.8b-mini-instruct-4k-q4_K_M

Q4_K_M 양자화 기준으로, Phi-3 Mini는 약 2.4GB의 용량을 차지하여 8GB 시스템에 상당한 여유 공간을 남겨둡니다. 스왑을 유발하지 않고 4K–8K 컨텍스트 윈도우를 편안하게 실행할 수 있습니다.

장점: 4B 미만 모델 중 최고 수준의 추론 능력, 우수한 코드 출력, 구조화된 JSON 생성. 단점: 다소 장황한 경향이 있으며, 간단한 답변을 지나치게 자세히 설명하는 경우가 있습니다.

Qwen2.5 — 다국어 속도의 달인

Alibaba의 Qwen2.5 시리즈는 8GB Mac 사용자에게 두 가지 매력적인 옵션을 제공합니다: 순수한 속도를 위한 1.5B와 더 나은 품질을 위한 3B입니다. Qwen 아키텍처는 효율성을 위해 특별히 최적화되었으며, 다국어 학습 데이터 덕분에 비영어권 작업에서 독보적인 강점을 발휘합니다.

# Qwen2.5 1.5B — fastest option
ollama pull qwen2.5:1.5b
ollama run qwen2.5:1.5b

# Qwen2.5 3B — better quality, still comfortable on 8GB
ollama pull qwen2.5:3b
ollama run qwen2.5:3b

1.5B 변형은 자동화 파이프라인에서 특히 흥미롭습니다 — 눈에 띄는 지연 없이 로컬 분류기, 라우터 또는 경량 데이터 변환 도구로 사용할 수 있을 만큼 빠릅니다.

장점: 빠른 추론 속도, 강력한 다국어 지원, 에이전틱/도구 사용 패턴에 탁월함. 단점: 1.5B는 복잡한 추론 작업에서 세밀함이 떨어지며, 진지한 활용을 위해서는 3B가 최소 요건입니다.

실용적인 모델 선택 매트릭스

한 가지 모델만 선택하지 마세요 — 작업에 맞는 모델을 선택하세요:

• 코딩 및 디버깅 → phi3:mini
• 일반 Q&A 및 채팅 → gemma2:2b
• 자동화, 분류, 파이프라인 → qwen2.5:1.5b
• 균형 잡힌 일상적 사용 → qwen2.5:3b
• 다국어 작업 → qwen2.5:3b

여러 모델을 실행하는 것도 문제가 없습니다 — Ollama는 필요에 따라 모델을 로드하고 유휴 상태일 때 메모리에서 제거합니다. 두 모델을 동시에 실행하지 않는 한, 아무것도 재시작하지 않고도 이 모델들 사이를 자유롭게 전환할 수 있습니다.

결론은 이것입니다: 8GB는 현명하게 선택한다면 제한이 되지 않습니다. 이 모델들은 타협의 산물이 아닙니다 — 여러분이 실행하는 환경에 최적화된, 전혀 다른 종류의 도구입니다.

Step 4 양자화 설명: Q4_K_M이 당신의 최고의 친구인 이유

Hugging Face나 Ollama의 모델 라이브러리를 둘러보는 데 시간을 써봤다면, 당혹스러운 접미사들을 피할 수 없었을 것입니다: Q4_K_M, Q8_0, Q5_K_S, F16, IQ3_XS. 이것들은 임의로 붙인 명명 관례가 아닙니다 — 이것들은 동일한 모델의 근본적으로 다른 버전을 나타내며, 8GB 머신에서 잘못된 것을 선택하는 것은 쓸 수 있는 도구와 시스템이 멈춰버리는 것의 차이입니다.

양자화가 실제로 하는 일

신경망 모델은 핵심적으로, 모델이 어떻게 생각하는지를 정의하는 수십억 개의 부동소수점 숫자들로 이루어진 방대한 수치 가중치의 집합입니다. 기본 형식(F32 또는 F16)에서 이 가중치들은 완전하거나 절반의 정밀도로 저장되어 엄청난 양의 메모리를 소비합니다.

양자화는 이러한 가중치들의 수치 정밀도를 줄이는 과정으로, 약간의 정확도를 희생하는 대신 메모리 사용량과 추론 속도를 극적으로 감소시킵니다.

이렇게 생각해보세요: 3.14159265358979라는 숫자를 저장하는 대신, 양자화는 3.14 또는 심지어 3으로 저장할 수 있습니다. 모델은 약간의 세밀함을 잃지만, 추론 능력의 대부분은 유지합니다.

명명 규칙 해독하기

GGUF 양자화 명명 체계(llama.cpp와 Ollama에서 사용)는 구조화된 패턴을 따릅니다:

Q[bits]_[variant]_[size]
│        │         └── S = Small, M = Medium, L = Large (parameter mixture)
│        └──────────── K = K-quants (newer, smarter algorithm)
└───────────────────── Number of bits per weight

Q4_K_M이 최적점을 달성하는 이유

Q4_K_M에서 "K"가 중요합니다. K-퀀트는 더 스마트한 비균일 양자화 전략을 사용합니다 — 모든 가중치에 동일한 정밀도 감소를 적용하지 않습니다. 대신, 어떤 가중치가 모델 출력에 더 중요한지 파악하여 더 높은 충실도로 보존하고, 덜 중요한 가중치들은 공격적으로 양자화합니다.

Q4_K_M이 달성하는 결과는 놀랍습니다: 70억 개의 매개변수 모델을 약 4GB로 압축하여, 다음을 위한 4GB의 여유 공간을 남겨둡니다: - macOS 시스템 프로세스 (기본 ~2GB) - 활성 애플리케이션 컨텍스트 - KV 캐시 (추론 중 모델의 "작업 메모리") - 스왑 방지를 위한 오버헤드 버퍼

실용적인 수준에서, 벤치마크는 Q4_K_M이 표준 추론 벤치마크에서 완전 정밀도 모델 성능의 95-98%를 유지한다는 것을 일관되게 보여줍니다. 코딩 지원, 텍스트 생성, Q&A 등 대부분의 실제 작업에서는 차이를 느끼지 못할 것입니다.

Ollama로 실제 확인하기

Ollama로 모델을 불러올 때, 양자화 수준을 명시적으로 지정할 수 있습니다:

# Default pull (Ollama chooses, usually Q4_K_M)
ollama pull llama3.2:3b

# Explicit quantization targeting
ollama pull qwen2.5:7b-instruct-q4_K_M

# Check what you have loaded
ollama list

NAME                              ID              SIZE    MODIFIED
qwen2.5:7b-instruct-q4_K_M      a8b3c2d1e0f9    4.7 GB  2 hours ago
gemma2:2b-instruct-q4_K_M       f1e2d3c4b5a6    1.6 GB  1 day ago

llama.cpp를 통한 수동 GGUF 관리의 경우, 양자화 지정 방식도 동일하게 직관적입니다:

./llama-cli \
  -m ./models/mistral-7b-instruct-q4_K_M.gguf \
  -n 512 \
  --ctx-size 4096 \
  -ngl 99          # Offload all layers to GPU (Metal)

더 낮은 양자화를 선택할 때 (그리고 선택하지 말아야 할 때)

Q3_K_M 또는 IQ3_XS로 낮추는 것이 합리적인 시나리오가 있습니다 — 특히 더 크고 더 유능한 모델 (예: 130억 개의 매개변수 모델)을 실행하면서 어느 정도의 품질 저하를 감수하더라도 메모리에 맞춰 실행해야 할 때입니다. 더 똑똑한 모델을 적극적으로 양자화하더라도, 가볍게 양자화된 약한 모델보다 성능이 뛰어날 수 있습니다.

단, Q4 미만으로 내려가면 다음과 같은 현상이 나타나기 시작합니다: - 환각 발생률 증가 - 지시 따르기 동작 저하 - 불일관한 추론 체인 - 구조화된 출력 작업 (JSON, 코드)에서 눈에 띄게 저하된 성능

8GB 머신을 위한 황금 법칙: 항상 먼저 Q4_K_M을 선택하세요. 모델이 단순히 맞지 않는 경우에만 더 낮은 것을 선택하고, 4B 미만의 매개변수 모델을 충분한 메모리 여유 공간으로 실행하는 경우에만 더 높은 것 (Q6_K, Q8_0)을 선택하세요.

Step 5 macOS 백그라운드 작업 최적화

아무리 적극적으로 양자화된 모델도 macOS가 여러분이 의식적으로 실행하지 않은 프로세스에 통합 메모리 2-3GB를 조용히 할당하고 있다면 버벅거리고 스왑이 발생할 것입니다. Ollama나 LM Studio를 실행하기 전에, Mac을 일시적으로 필요한 전용 추론 머신처럼 다루세요.

RAM을 잡아먹는 원인 파악하기

macOS는 아름답고 독자적인 운영 체제로, 항상 iCloud 동기화, Spotlight 색인 생성, 그리고 수십 개의 메뉴 바 데몬이 병렬로 실행되기를 원한다고 가정합니다. 로컬 AI 작업에서는 모든 메가바이트가 중요합니다. 메모리 압박 상황을 가감 없이 파악하기 위해 먼저 이 명령어를 실행하세요:

# Real-time memory breakdown
sudo memory_pressure

RAM을 가장 많이 사용하는 프로세스를 상주 크기 순으로 확인

ps aux --sort=-%mem | head -20

현재 스왑 사용량 확인

sysctl vm.swapusage

`vm.swapusage`에 `0.00B used` 이외의 값이 표시된다면, 추론을 시작하기도 전에 이미 문제가 발생한 것입니다.

---

### 추론 전 사전 의식: 체크리스트

모델을 로드하기 전에 반드시 수행해야 할 사전 점검 체크리스트로 활용하세요:

| 작업 | 명령어 / 위치 | 확보되는 메모리 (약) |
|---|---|---|
| 사용하지 않는 앱 종료 | Cmd+Q (단순 닫기가 아닌 완전 종료) | 200MB–1.5GB |
| Spotlight 인덱싱 비활성화 | `sudo mdutil -a -i off` | 150–400MB |
| iCloud Drive 동기화 중지 | 시스템 설정 → Apple ID → iCloud | 100–300MB |
| 브라우저 탭 종료 | 최대 0–2개 탭만 열어두기 | 500MB–2GB |
| Time Machine 스냅샷 비활성화 | `sudo tmutil disablelocal` | 백그라운드 I/O |
| 메일 및 캘린더 앱 종료 | 수동 종료 | 100–250MB |

---

### 가장 큰 문제를 일으키는 프로세스를 프로그래밍 방식으로 비활성화하기

매 세션마다 이 작업을 수동으로 반복하지 마세요. 로컬 LLM 작업을 시작하기 전에 실행할 수 있는 셸 스크립트를 만들어두세요:

```bash
#!/bin/zsh
# ai-mode.sh — Free up memory before local LLM sessions

echo "🧠 Entering AI Mode..."

# Pause Spotlight indexing
sudo mdutil -a -i off

# Purge inactive memory (forces disk cache to flush)
sudo purge

# Stop unnecessary launch agents
launchctl unload -w ~/Library/LaunchAgents/com.google.keystone.agent.plist 2>/dev/null
launchctl unload -w /Library/LaunchAgents/com.adobe.AdobeCreativeCloud.plist 2>/dev/null

# Disable WindowServer-heavy features (optional, aggressive)
# defaults write com.apple.universalaccess reduceMotion -bool true

echo "✅ Done. Current swap usage:"
sysctl vm.swapusage

echo "✅ Available memory:"
memory_pressure | grep "System Memory Pressure"

실행 권한 부여: chmod +x ai-mode.sh 후, 매 추론 세션 전에 sudo ./ai-mode.sh로 실행하세요.

열 및 성능 상태 제어

Apple Silicon에서는 CPU와 GPU가 동일한 통합 메모리 풀을 공유하지만, 고성능 코어는 전력 소비가 훨씬 크고 열을 발생시켜 추론 도중 열 제한(thermal throttling)을 유발할 수 있습니다. 이는 불규칙한 토큰 생성 속도로 나타납니다.

# Check current CPU frequency and thermal state
sudo powermetrics --samplers cpu_power -i 1000 -n 3

# Force high-performance mode (plugged in only)
sudo pmset -c gpuswitch 2
sudo pmset -c highstandbythreshold 95

유용한 팁: 추론 작업은 반드시 전원에 연결된 상태에서 실행하세요. 배터리로 실행할 경우, macOS가 공격적인 효율 코어 스케줄링을 적용하여 초당 토큰 처리량이 절반으로 줄어들 수 있습니다.

활성 모니터를 킬 스위치로 활용하기

GUI 기반 워크플로우를 선호한다면, 활성 모니터를 다음과 같이 설정하세요:

1. 활성 모니터 → 메모리 탭 열기
2. 메모리 기준 내림차순 정렬
3. 하단의 메모리 압력 그래프 확인 — 초록색을 유지하세요
4. 노란색 또는 빨간색으로 바뀌면 즉시 추론을 중단하고, 스왑이 누적되기 전에 프로세스를 종료하세요

황금 규칙: 모델을 로드하기 전에 메모리 압박(Memory Pressure)이 녹색이 아니라면 반드시 스왑이 발생합니다. 8GB 머신에서 추론 중 스왑이 발생하면 단순히 속도가 느려지는 것에 그치지 않습니다 — 모델의 KV 캐시가 디스크 읽기 과정에서 난타당하면서 출력이 깨지거나, 잘리거나, 완전히 실패할 수 있습니다.

세션 종료 후 메모리 회수

macOS는 LLM 프로세스를 종료한 후 항상 메모리를 깔끔하게 해제하지는 않습니다. 강제로 해제하세요:

# After closing Ollama or LM Studio
sudo purge

# Verify swap cleared
sysctl vm.swapusage
# Target: vm.swapusage: total = 0.00B  used = 0.00B  free = 0.00B

앱 창을 그냥 닫는 것이 아니라 ollama 서비스를 재시작하세요 — 그렇지 않으면 모델 가중치가 메모리에 그대로 상주하는 경우가 많습니다:

ollama stop          # Stop any running model
pkill -f ollama      # Kill the background daemon
# Relaunch fresh when ready
ollama serve &

8GB Mac의 메모리를 수술실처럼 다루세요 — 무균 상태를 유지하고, 철저히 통제하며, 불필요한 것은 가차 없이 제거하세요.

Continue Reading

Performance

Mistral 7B vs Llama 3 on Apple Silicon

Tools

Best GUI clients for Local LLMs

Advanced

Quantization 101: Speed up your Inference