AI 개발용 PC를 새로 산다면 클라우드 AI 코딩 도구만 쓰는 일반 개발자는 32GB, Docker·에뮬레이터·코딩 에이전트를 함께 돌리면 64GB가 현실적인 기준이다. 96GB부터는 32B~70B급 로컬 LLM과 여러 가상머신을 위한 선택이고, 128GB는 70B Q8이나 긴 컨텍스트처럼 메모리 사용량을 계산해 본 사람에게 의미가 있다. 숫자가 클수록 무조건 좋은 것이 아니라, 클라우드 모델을 쓰는지 로컬에서 모델 가중치를 올리는지부터 구분해야 한다.
핵심 요약
- 32GB: 웹·백엔드 개발, 클라우드 Claude Code·Codex, 가벼운 Docker 작업의 기본값이다.
- 64GB: 여러 컨테이너, Android 에뮬레이터, 로컬 Kubernetes, 병렬 코딩 에이전트까지 다루는 실무 스위트 스폿이다.
- 96GB: 32B Q8 또는 70B Q4 로컬 LLM에 개발 도구를 함께 띄우려는 경우 의미가 생긴다.
- 128GB: 70B Q8, 긴 컨텍스트, 여러 VM·데이터 처리처럼 명확한 워크로드가 있을 때 선택한다.
- 클라우드 AI 코딩 도구는 모델 전체를 PC RAM에 올리지 않는다. 에이전트 수보다 빌드·테스트·브라우저·컨테이너의 동시 실행량이 중요하다.
결론부터 보는 용량별 선택표
| 용량 | 잘 맞는 사용 방식 | 현실적인 한계 | 구매 판단 |
|---|---|---|---|
| 16GB | 기존 PC에서 웹 개발, 클라우드 AI 보조 | 브라우저·IDE·Docker가 겹치면 메모리 압박이 빠르다 | 새 AI 개발 PC에는 권하지 않는다 |
| 32GB | 웹·백엔드, IDE 1~2개, 클라우드 코딩 에이전트, 소수 컨테이너 | 에뮬레이터·로컬 Kubernetes·여러 테스트를 동시에 돌리면 빠듯하다 | 일반 개발자의 기본값 |
| 64GB | Android, Docker Compose, 로컬 Kubernetes, VM, 병렬 에이전트, 8B~32B Q4 로컬 LLM | 70B 모델이나 긴 컨텍스트는 여유가 부족할 수 있다 | 가장 균형 잡힌 권장값 |
| 96GB | 32B Q8, 70B Q4, 여러 VM과 개발 스택 동시 실행 | 일반 클라우드 AI 개발에는 사용하지 않는 메모리가 많다 | 로컬 LLM 사용자용 |
| 128GB | 70B Q8, 70B Q4 장문 컨텍스트, 대형 데이터·가상화 랩 | 가격·메모리 속도·메인보드 호환성을 함께 봐야 한다 | 계산 근거가 있을 때 선택 |
이 표는 프로그램 하나를 실행하기 위한 최소사양이 아니다. 운영체제, 브라우저, IDE, 빌드 도구, 컨테이너와 로컬 모델을 함께 사용하는 개발 환경에서 스왑을 피하기 위한 시작점이다.
AI 개발에서 RAM을 쓰는 주체는 모델만이 아니다
AI 개발용 RAM을 고를 때 가장 흔한 오해는 “코딩 에이전트를 쓰니 모델 크기만큼 RAM이 필요하다”는 것이다. Claude Code나 Codex처럼 클라우드 모델을 호출하는 도구는 거대한 모델 가중치를 로컬 PC에 적재하지 않는다. 로컬에서는 저장소 인덱싱, 여러 작업 트리, 빌드, 테스트, 브라우저 자동화와 셸 프로세스가 RAM을 사용한다.
반대로 Ollama나 llama.cpp로 로컬 LLM을 실행하면 상황이 완전히 달라진다. 이때는 양자화된 모델 파일, KV 캐시, 런타임 버퍼가 RAM이나 VRAM에 올라간다. 같은 “AI 개발”이라도 필요한 메모리가 32GB에서 128GB까지 벌어지는 이유다.
공식 최소사양은 도구 하나가 실행되는 하한이지 전체 개발 PC의 권장 용량이 아니다. 대표적인 공식 수치를 나란히 놓으면 차이가 더 명확하다.
| 도구·작업 | 공식 RAM 기준 | 해석할 때 주의할 점 |
|---|---|---|
| VS Code | 1GB 권장 | 언어 서버·빌드·테스트·브라우저는 별도 프로세스다 |
| IntelliJ IDEA | 시스템 8GB, IDE에 3GB 가용 | IDE 힙과 Gradle·컴파일러 힙은 서로 다르다 |
| Android Studio | 8GB 최소 | 에뮬레이터 없이 Studio 중심 기준이다 |
| Android Studio+Emulator | 16GB 최소, 32GB 권장 | Google이 밝힌 가장 현실적인 범용 개발 기준이다 |
| Docker Desktop Windows | 시스템 8GB | 컨테이너 워크로드의 실제 사용량은 별도다 |
| minikube | 2GB 여유 메모리 | 배포할 Pod·DB·관측성 스택은 추가된다 |
| Claude Code | 4GB 이상 | 세션 하나가 4GB를 쓴다는 뜻이 아니다 |
| Codex CLI | 4GB 최소, 8GB 권장 | 역시 제품 실행용 시스템 기준이다 |
| 메모리를 쓰는 요소 | 클라우드 코딩 에이전트 | 로컬 LLM |
|---|---|---|
| IDE·언어 서버·브라우저 | 필요 | 필요 |
| 빌드·테스트·컨테이너 | 필요 | 필요 |
| 모델 가중치 | 서버에 존재 | RAM·VRAM에 적재 |
| KV 캐시 | 서버가 부담 | 사용자가 부담 |
| 컨텍스트 증가 비용 | API 비용·한도에 반영 | 로컬 메모리 사용량도 증가 |
따라서 먼저 “AI 도구를 쓰는 개발”인지 “AI 모델을 로컬에서 실행하는 개발”인지 구분해야 한다.
32GB: 클라우드 AI를 쓰는 일반 개발자의 기본값
32GB는 웹 프론트엔드, 백엔드 API, 데이터베이스 한두 개, IDE와 브라우저를 함께 쓰는 환경에 적합하다. Claude Code·Codex가 클라우드 모델을 호출하는 방식이라면 AI 자체 때문에 64GB가 필요한 것은 아니다.
다만 32GB에서도 다음 작업이 겹치면 여유가 빠르게 줄어든다.
- JetBrains IDE와 VS Code를 함께 실행한다.
- Chrome 탭을 많이 열고 Playwright 브라우저 테스트를 병렬로 돌린다.
- Docker Desktop에서 데이터베이스·캐시·메시지 브로커를 함께 띄운다.
- Android Studio 에뮬레이터나 로컬 Kubernetes를 추가한다.
- 코딩 에이전트가 여러 작업 트리에서 빌드와 테스트를 동시에 수행한다.
VS Code의 공식 RAM 권장은 매우 낮지만 이는 에디터 단독 실행 기준이다. Android Studio와 Docker도 공식 최소사양만 더해서 PC 용량을 정하면 실제 개발 흐름을 반영하지 못한다. 32GB는 “각 도구가 실행된다”보다 “일반적인 작업 한 세트를 무리 없이 유지한다”는 기준에 가깝다.
32GB가 맞는 경우
- 로컬 LLM을 거의 실행하지 않는다.
- Docker 컨테이너가 소수이고 메모리 제한을 설정한다.
- 모바일 에뮬레이터와 VM을 상시 사용하지 않는다.
- 필요하면 무거운 작업을 순차적으로 실행할 수 있다.
64GB: Docker·에뮬레이터·병렬 에이전트의 스위트 스폿
64GB는 2026년 AI 개발 PC에서 가장 실패 확률이 낮은 선택이다. 용량 자체가 AI 모델을 빠르게 만들지는 않지만, 에이전트가 여러 브랜치에서 테스트를 돌리는 동안 IDE·브라우저·컨테이너를 닫지 않아도 되는 여유를 만든다.
특히 다음 조합에서 64GB의 가치가 커진다.
- Android Studio와 에뮬레이터를 켠 상태에서 백엔드 컨테이너까지 실행한다.
- Docker Compose로 데이터베이스, Redis, 큐, 관측성 스택을 함께 띄운다.
- minikube나 kind 기반 로컬 Kubernetes에 여러 서비스를 배포한다.
- Claude Code와 Codex를 별도 작업 트리에서 실행하고 테스트를 병렬화한다.
- 8B·14B Q4 로컬 모델을 개발 도구와 함께 유지한다.
- 32B Q4 모델을 짧은 컨텍스트로 CPU 또는 GPU 분할 실행한다.
코딩 에이전트 프로세스 자체보다 에이전트가 실행하는 작업이 핵심이다. 두 에이전트가 각각 패키지를 설치하고 테스트 서버와 브라우저를 띄우면, 사람 두 명이 같은 PC에서 동시에 개발하는 것에 가까운 부하가 생긴다.
새 PC를 3~5년 사용할 계획이고 메모리 증설이 어려운 노트북이라면 32GB보다 64GB가 안전하다. 반대로 데스크톱에서 나중에 증설할 수 있고 현재 작업이 가볍다면 32GB로 시작해도 된다.
96GB: 70B Q4와 32B Q8을 위한 현실적 구간
96GB는 일반 개발용 중간 단계가 아니라 로컬 LLM 때문에 생긴 용량 구간에 가깝다. DDR5 데스크톱에서는 48GB 모듈 두 개, Apple Silicon에서는 96GB 통합 메모리 구성으로 만나는 경우가 많다.
32B 모델은 Q4 가중치만 약 20GB, Q8은 약 35GB 수준이다. 여기에 KV 캐시, 런타임 버퍼, 운영체제와 개발 도구가 더해진다. 64GB에서도 32B Q8을 실행할 수는 있지만 긴 컨텍스트와 컨테이너를 함께 쓰면 여유가 줄어든다.
70B Q4는 가중치만 약 42GB 수준이므로 64GB에서 “파일이 올라간다”와 “개발 환경을 함께 쾌적하게 쓴다”는 다른 문제다. 96GB는 운영체제와 IDE에 충분한 공간을 남기면서 70B Q4를 다루기 위한 현실적인 시작점이다.
96GB가 맞는 경우
- Apple Silicon에서 70B Q4 모델을 GPU 가속과 함께 사용한다.
- 32B Q8 모델에 긴 컨텍스트를 사용한다.
- 로컬 LLM 서버와 Docker 개발 환경을 같은 장비에서 운영한다.
- 48GB 두 장 구성이 메인보드 QVL과 CPU 메모리 컨트롤러에서 검증됐다.
128GB: 명확한 워크로드가 있을 때 선택한다
128GB는 “AI 시대니까 많이”라는 이유로 살 용량은 아니다. 70B Q8 가중치는 약 75GB 수준이고, 70B Q4도 컨텍스트가 길어지면 KV 캐시가 크게 증가한다. 이런 모델을 개발 스택과 동시에 유지하거나 여러 VM·데이터 처리 작업을 함께 돌릴 때 128GB가 의미를 갖는다.
128GB가 필요한 대표 사례는 다음과 같다.
- 70B Q8 모델을 적당한 컨텍스트로 CPU·GPU 분할 또는 대용량 통합 메모리에서 실행한다.
- 70B Q4 모델에 32K 이상의 컨텍스트를 사용한다.
- 여러 운영체제 VM과 Kubernetes 랩을 동시에 유지한다.
- 대형 데이터 전처리, 검색 인덱스와 로컬 LLM을 한 장비에서 처리한다.
- 장시간 실행되는 서버에서 메모리 여유와 파일 캐시를 확보한다.
반대로 API 기반 코딩 에이전트, 웹 개발, 일반 Docker 환경만 쓴다면 128GB는 성능보다 유휴 용량이 될 가능성이 높다. 남는 예산은 CPU, SSD, GPU VRAM 또는 백업 장치에 쓰는 편이 체감이 크다.
로컬 LLM은 파라미터 수만 보면 안 된다
양자화 모델의 가중치 크기는 대략 파라미터 수 × 비트 수 ÷ 8로 시작해 계산할 수 있다. 그러나 GGUF 메타데이터와 일부 텐서, 양자화 블록 오버헤드가 추가되므로 실제 파일은 단순 계산보다 커진다.
llama.cpp 계열의 일반적인 Q4_K_M·Q8_0 모델을 기준으로 보면 다음 정도다.
| 모델 크기 | Q4 가중치 근사 | Q8 가중치 근사 | 개발 도구까지 고려한 시작 RAM |
|---|---|---|---|
| 8B | 약 4.9GB | 약 8.5GB | 32GB |
| 14B | 약 9.0GB | 약 15.7GB | 32~64GB |
| 32B | 약 19.9GB | 약 34.8GB | 64~96GB |
| 70B | 약 42.5GB | 약 75.0GB | 96~128GB 이상 |
이 수치는 2026년 8월 3일 기준 Hugging Face에 공개된 Llama 3.1 8B·70B와 Qwen2.5 14B·32B GGUF의 Q4_K_M·Q8_0 파일 크기를 합산한 값이다. 가중치 중심의 근사치이므로 모델 구조, GGUF 양자화 방식, 컨텍스트 길이, 동시 요청 수에 따라 실제 사용량은 달라진다.
KV 캐시는 컨텍스트 길이에 비례한다
KV 캐시는 이미 처리한 토큰의 attention 상태를 저장한다. 컨텍스트를 8K에서 32K로 네 배 늘리면 KV 캐시도 대체로 네 배 방향으로 증가한다. Hugging Face는 KV 캐시가 긴 컨텍스트에서 메모리 병목이 될 수 있다고 명시하며, Ollama도 사용 가능한 VRAM에 따라 기본 컨텍스트를 다르게 설정한다.
예를 들어 Llama 계열 구조를 FP16 KV 캐시로 단순 계산하면 8B 모델은 8K에서 약 1GiB, 32K에서 약 4GiB 수준이 추가될 수 있다. 70B 모델은 같은 조건에서 약 2.5GiB와 10GiB 수준까지 커질 수 있다. 실제 런타임은 캐시 양자화, 배치, 병렬 요청 설정에 따라 달라진다.
따라서 “70B Q4 파일이 43GB이니 64GB면 충분하다”는 계산은 위험하다. 모델 파일 외에 KV 캐시와 운영체제, IDE, 런타임 여유를 남겨야 한다.
시스템 RAM·VRAM·통합 메모리는 서로 다르다
일반 PC의 시스템 RAM과 GPU VRAM
NVIDIA·AMD 외장 GPU를 쓰는 PC에서는 시스템 RAM과 VRAM이 분리돼 있다. 128GB 시스템 RAM을 장착해도 12GB GPU가 24GB GPU처럼 동작하지 않는다. llama.cpp는 일부 레이어를 RAM과 CPU로 넘겨 실행할 수 있지만 PCIe 전송과 CPU 연산 때문에 완전한 GPU 적재보다 느려질 수 있다.
로컬 LLM의 응답 속도가 중요하다면 시스템 RAM만 늘리기 전에 모델이 VRAM에 얼마나 올라가는지 확인해야 한다. 반면 모델 크기보다 데이터 전처리, VM, 컨테이너가 병목이면 시스템 RAM 증설이 직접적인 해결책이다.
Apple Silicon의 통합 메모리
Apple Silicon과 MLX는 CPU와 GPU가 같은 통합 메모리 풀을 공유한다. 대용량 모델이 GPU 작업에 접근하기 유리하지만, 표시된 메모리 전체를 모델이 독점할 수 있다는 뜻은 아니다. macOS, 앱, 그래픽 버퍼와 모델이 같은 공간을 나눠 쓴다.
통합 메모리는 구매 후 DIMM을 추가할 수 없으므로 로컬 LLM이 목적이라면 처음부터 모델 가중치와 KV 캐시, 개발 도구 여유를 함께 계산해야 한다.
DDR5는 4개보다 2개 모듈이 안전한 경우가 많다
같은 128GB라도 32GB × 4와 64GB × 2는 동작 조건이 다르다. DDR5에서 네 개의 DIMM은 CPU 메모리 컨트롤러에 더 큰 전기적 부하를 주므로, XMP·EXPO 고클럭이 그대로 유지되지 않거나 안정화를 위해 속도를 낮춰야 할 수 있다.
CPU 제조사가 표기하는 최대 메모리 속도도 DIMM 수와 랭크 구성에 따라 달라질 수 있다. 예를 들어 AMD Ryzen 데스크톱 제품 사양은 2-DIMM과 4-DIMM 구성의 공식 지원 속도를 구분한다. 메인보드가 광고하는 최고 오버클럭 속도와 CPU가 모든 구성에서 보장하는 속도는 같은 숫자가 아니다.
Ryzen 9 9950X 공식 사양은 이 차이를 구체적으로 보여준다.
| 메모리 구성 | AMD 공식 최대 지원 속도 |
|---|---|
| 2×1R 또는 2×2R | DDR5-5600 |
| 4×1R 또는 4×2R | DDR5-3600 |
이는 모든 AMD CPU가 4-DIMM에서 DDR5-3600만 가능하다는 뜻이 아니다. 해당 SKU의 공식 보증선 사례이며, 실제 구매에서는 정확한 CPU와 메인보드의 사양·QVL·BIOS를 다시 확인해야 한다.
구매할 때는 다음 순서로 확인하는 것이 안전하다.
- 메인보드의 최대 용량만 보지 말고 해당 BIOS 버전의 QVL을 확인한다.
- 48GB·64GB 고용량 모듈이 CPU와 보드에서 검증됐는지 본다.
- 가능하면 처음부터 동일 킷의 두 개 모듈로 목표 용량을 맞춘다.
- XMP·EXPO 적용 후 MemTest86이나 실제 빌드·테스트로 안정성을 확인한다.
- 네 개 슬롯을 채울 때는 표시 클럭을 낮춰야 할 가능성을 받아들인다.
대부분의 AI 개발 워크로드에서는 RAM 클럭 몇 단계보다 스왑을 피할 수 있는 용량이 더 중요하다. 다만 사용하지 않을 128GB를 위해 불안정한 4-DIMM 오버클럭을 감수할 이유도 없다.
ECC 메모리는 누구에게 필요한가
ECC는 메모리의 비트 오류를 감지·수정하는 기능이다. 일반적인 코딩 PC나 게임·개인 로컬 LLM 장비에서는 필수 조건이 아니다. 다음 조건이라면 검토할 가치가 있다.
- 장비를 며칠씩 켜 두고 모델 서버나 데이터베이스를 운영한다.
- 계산 결과와 데이터 무결성이 중요한 장시간 작업을 수행한다.
- 메모리 용량이 크고 워크스테이션·서버 플랫폼을 사용한다.
- CPU, 메인보드, BIOS와 메모리 모듈 모두 ECC 동작을 공식 지원한다.
“ECC 모듈이 장착된다”와 “ECC가 실제 활성화된다”는 다를 수 있다. 플랫폼 전체 지원과 운영체제에서 오류 수정 상태를 확인해야 한다.
현재 PC에서 필요한 RAM을 측정하는 방법
새 PC를 감으로 고르기보다 지금 하는 가장 무거운 작업을 재현하는 편이 정확하다.
1. 평소 프로그램을 모두 실행한다
IDE, 브라우저, Docker, 데이터베이스, 에뮬레이터와 테스트를 실제 작업처럼 띄운다. 코딩 에이전트를 병렬로 쓴다면 각 작업 트리에서 빌드와 테스트도 실행한다.
2. 사용량보다 메모리 압박을 본다
- Windows: 작업 관리자의 메모리 사용량과 커밋된 메모리, 페이지 파일 사용을 확인한다.
- macOS: 활성 상태 보기의 메모리 압력과 스왑 사용량을 본다.
- Linux:
free -h,vmstat, 컨테이너별 제한과 swap in/out을 확인한다.
운영체제는 남는 RAM을 파일 캐시로 사용하므로 “사용 중” 숫자가 높다는 이유만으로 부족한 것은 아니다. 메모리 압력이 계속 높고 작업 중 스왑 입출력이 반복되며 빌드·앱 전환이 느려지는지가 중요하다.
Windows의 pagefile은 특별한 측정 근거가 없다면 시스템 관리 설정을 유지하는 편이 안전하다. pagefile은 커밋 한도와 크래시 덤프를 위한 안전장치이지 RAM과 같은 속도를 제공하는 대체품은 아니다.
3. 피크에 25~30% 여유를 더한다
현재 피크가 24GB라면 32GB는 최소선이고, 앞으로 컨테이너와 에이전트 수가 늘어난다면 64GB가 안전하다. 피크가 48~52GB라면 64GB는 당장 실행 가능하지만 장기 사용을 고려해 96GB를 검토할 수 있다.
용도별 최종 추천
| 사용 시나리오 | 권장 RAM | 선택 이유 |
|---|---|---|
| React·Spring·Node.js, 클라우드 AI 코딩 | 32GB | 모델은 서버에 있고 일반 개발 스택 중심이다 |
| Android Studio·에뮬레이터·백엔드 동시 실행 | 32~64GB | 프로젝트 규모와 에뮬레이터 수에 따라 달라진다 |
| Docker Compose·로컬 Kubernetes·관측성 스택 | 64GB | 여러 서비스와 빌드 캐시를 함께 유지한다 |
| Claude Code·Codex 2~3개 병렬 작업 | 64GB | 각 작업의 빌드·테스트·브라우저가 겹친다 |
| 8B·14B Q4 로컬 LLM | 32~64GB | 개발 도구와 컨텍스트 여유를 확보한다 |
| 32B Q4 또는 Q8 로컬 LLM | 64~96GB | Q8과 긴 컨텍스트는 추가 여유가 필요하다 |
| 70B Q4 로컬 LLM | 96GB 이상 | 약 42GB 가중치 외 KV 캐시와 OS 공간이 필요하다 |
| 70B Q8 또는 70B Q4 긴 컨텍스트·여러 VM | 128GB 이상 | 약 75GB 가중치 또는 큰 KV 캐시와 런타임 여유가 필요하다 |
결국 가장 무난한 답은 클라우드 AI 중심이면 32GB, AI 개발 환경을 넓게 쓰려면 64GB, 로컬 70B가 목적이면 96GB 이상이다. 128GB는 미래 대비라는 말보다 실제 모델 파일과 컨텍스트, VM 사용량으로 근거를 만들 수 있을 때 선택하는 것이 맞다.
구매 전 체크리스트
- [ ] 클라우드 AI와 로컬 LLM 중 어느 쪽이 주력인지 정했다.
- [ ] 실행할 로컬 모델의 GGUF 파일 크기와 양자화 방식을 확인했다.
- [ ] 목표 컨텍스트 길이와 동시 요청 수를 정했다.
- [ ] 외장 GPU VRAM과 시스템 RAM을 따로 계산했다.
- [ ] Apple Silicon이면 구매 후 메모리 증설이 불가능함을 반영했다.
- [ ] 데스크톱이면 메인보드 QVL과 BIOS 지원을 확인했다.
- [ ] 4-DIMM보다 2-DIMM 구성으로 목표 용량을 맞출 수 있는지 확인했다.
- [ ] 현재 PC에서 가장 무거운 작업의 피크와 스왑을 측정했다.
- [ ] 피크 사용량에 25~30% 여유를 더했다.
- [ ] 남는 예산을 GPU VRAM, SSD와 백업에 쓰는 편이 나은지 비교했다.
FAQ
Claude Code나 Codex를 쓰려면 64GB가 필요한가
그렇지 않다. 클라우드 모델을 호출하는 코딩 에이전트는 모델 가중치를 로컬 RAM에 올리지 않는다. 웹·백엔드 개발과 소수 컨테이너라면 32GB로도 충분할 수 있다. 여러 에이전트가 빌드·테스트·브라우저를 동시에 실행할 때 64GB의 가치가 커진다.
32GB와 64GB 중 하나만 고른다면 무엇이 좋은가
새 노트북을 오래 쓸 계획이거나 Android·Docker·VM을 함께 사용한다면 64GB가 안전하다. 데스크톱이고 일반 웹 개발과 클라우드 AI가 중심이며 나중에 증설할 수 있다면 32GB로 시작해도 된다.
96GB는 64GB와 128GB 사이의 애매한 용량인가
일반 개발에서는 그렇지만 로컬 LLM에서는 명확한 용도가 있다. 48GB 두 장으로 70B Q4 모델과 개발 도구를 함께 실행할 여유를 확보할 수 있다. 단, CPU와 메인보드가 48GB DIMM을 지원하는지 확인해야 한다.
RAM 4개를 꽂으면 무조건 느려지는가
항상 그런 것은 아니지만 DDR5에서는 네 개의 DIMM이 메모리 컨트롤러에 더 큰 부담을 준다. 같은 XMP·EXPO 속도가 유지되지 않을 수 있으므로 CPU 공식 사양과 메인보드 QVL을 확인해야 한다. 고용량은 두 개 모듈로 구성하는 편이 안정화에 유리한 경우가 많다.
시스템 RAM을 늘리면 GPU VRAM 부족을 해결할 수 있는가
완전히 해결할 수 없다. 일부 로컬 LLM 런타임은 모델 레이어를 시스템 RAM과 CPU로 넘길 수 있지만 속도가 낮아질 수 있다. GPU 가속 성능이 중요하다면 모델이 VRAM 안에 얼마나 적재되는지 먼저 봐야 한다.
스왑이나 페이지 파일이 있으니 RAM이 적어도 괜찮은가
스왑은 프로그램 종료를 막아주는 안전장치이지 RAM과 같은 성능을 제공하지 않는다. 작업 중 스왑 입출력이 반복되고 빌드·앱 전환이 느려진다면 실제 메모리 용량이 부족하다는 신호다.
함께 읽으면 좋은 글
참고 자료
- Visual Studio Code Requirements
- IntelliJ IDEA 시스템 요구사항
- Android Studio 설치 및 시스템 요구사항
- Docker Desktop for Windows 요구사항
- Docker Desktop 리소스 설정
- minikube 시작 요구사항
- Claude Code 시스템 요구사항
- OpenAI Codex 설치 요구사항
- llama.cpp 양자화 및 메모리 요구사항
- Hugging Face Transformers KV Cache
- Llama 3.1 8B GGUF 파일
- Qwen2.5 14B GGUF 파일
- Qwen2.5 32B GGUF 파일
- Llama 3.1 70B GGUF 파일
- Ollama Context Length
- Apple MLX: 통합 메모리 모델
- AMD Ryzen 9 9950X 메모리 사양
- Microsoft Windows 페이지 파일 안내
