--- title: "RAM과 LLM의 관계: 가중치, KV Cache, 대역폭, 학습 메모리까지" slug: "ram-and-llm-memory" category: "CS" topic: "cs" subtopic: "computer-architecture" tags: ["RAM","VRAM","KV Cache","Memory Bandwidth","Quantization","LLM Systems"] status: "published" created: "2026-07-21" updated: "2026-07-21" summary: "RAM·VRAM·통합 메모리가 LLM의 가중치 적재, KV Cache, 추론 속도, 동시성, 학습 상태와 어떤 관계를 맺는지 용량과 대역폭 관점에서 계산한다." kind: "Deep Dive" evidence: "Transformer·MQA·GQA·PagedAttention·FlashAttention·QLoRA·ZeRO·LoRA 원 논문과 NVIDIA·Apple·Hugging Face·PyTorch·Linux·llama.cpp 공식 문서를 대조했다." --- ## 0. 결론부터 RAM은 LLM의 지능을 만들어 내는 부품이 아니라, **실행 중 필요한 가중치와 상태를 보관하는 작업 공간**이다. | 관점 | RAM·VRAM이 결정하는 것 | | --- | --- | | 용량 | 모델, context, batch, 동시 요청이 메모리에 들어가는가 | | 대역폭 | 연산기에 가중치와 KV cache를 얼마나 빨리 공급하는가 | | 추론 | 가중치 + KV cache + activation/workspace를 감당하는가 | | 학습 | 추론 상태 + gradient + optimizer state + activation을 감당하는가 | 가장 중요한 식은 다음과 같다. ```text 추론 peak memory ≈ 모델 가중치 + KV cache + activation·kernel workspace + 런타임 예약·파편화 + 로딩 중 임시 복사본 ``` 같은 모델과 같은 설정이라면 RAM을 늘려도 모델의 학습된 지식은 바뀌지 않는다. 대신 더 큰 모델, 덜 공격적인 양자화, 더 긴 문맥, 더 높은 동시성을 선택하고 swap·offload를 줄일 수 있다. > 이 문서의 계산 예시는 구조를 명시한 이론값이다. 실제 배포 용량은 모델 config와 최대 workload에서 측정한 peak로 확정해야 한다. 가중치 표의 GB는 10진 단위, KV 예시의 KiB·MiB·GiB는 2진 단위를 사용한다. --- ## 1. 한 문장으로 잡는 관계 RAM은 LLM의 지능을 만들어 내는 부품이 아니라, 실행 중 필요한 상태를 보관하는 작업 공간이다. 메모리가 많으면 더 큰 모델, 더 긴 문맥, 더 많은 동시 요청을 수용할 수 있지만 같은 모델의 추론 능력이 RAM 증설만으로 좋아지지는 않는다. **핵심 구분** **용량**은 주로 “이 구성이 들어가는가?”를 결정한다. **대역폭**은 주로 “들어간 모델이 얼마나 빨리 데이터를 공급받는가?”를 결정한다. **연산 성능**은 행렬곱·attention·dequantization을 얼마나 빨리 수행하는지 결정한다. 실제 성능은 세 요소 중 하나로만 설명할 수 없다. 모델이 메모리에 들어가도 대역폭이 낮으면 decode가 느릴 수 있고, 대역폭이 높아도 긴 prompt의 prefill은 연산량 때문에 느릴 수 있다. ## 2. RAM, VRAM, 통합 메모리는 무엇이 다른가 ### 시스템 RAM CPU가 직접 사용하는 주 메모리다. CPU 추론의 가중치와 KV cache, 모델 파일의 page cache, 데이터셋, tokenizer 결과, DataLoader 버퍼, 체크포인트 staging, GPU로 보낼 pinned buffer 등이 여기에 놓인다. ### VRAM 또는 HBM 이산 GPU에 붙은 장치 메모리다. GPU 추론에서는 가중치, KV cache, activation, kernel workspace가 주로 이곳에 있어야 한다. 학습에서는 gradient와 optimizer state까지 추가된다. GPU 내부 메모리 대역폭은 보통 호스트 RAM과 GPU를 잇는 PCIe 경로보다 훨씬 높으므로, 호스트-장치 전송을 최소화하는 것이 중요하다. NVIDIA의 CUDA 가이드도 이 차이 때문에 전송 최소화를 우선 원칙으로 둔다. [6] ### 통합 메모리 Apple Silicon 같은 통합 메모리 구조에서는 CPU와 GPU가 같은 물리 메모리 풀에 접근한다. 별도 VRAM으로 전체 tensor를 복사하는 비용과 용량 경계를 줄일 수 있다. 그러나 운영체제, 애플리케이션, 프레임 버퍼, 모델, KV cache가 같은 풀을 경쟁하므로 표시된 메모리 전부를 모델이 쓸 수 있다는 뜻은 아니다. Apple의 Metal 문서도 CPU와 GPU가 시스템 메모리를 공유한다고 정의한다. [7] ```text 이산 GPU: SSD → RAM → PCIe/NVLink → VRAM → GPU 통합 구조: SSD → 통합 메모리 ↔ CPU/GPU ``` ## 3. 추론 메모리에는 무엇이 들어가는가 ```text 추론 peak memory ≈ 가중치 W + KV cache K + activation 및 kernel workspace A + 런타임 예약·메모리 파편화 R + 로딩 중 임시 복사본 L ``` 이 식의 항목은 같은 방식으로 움직이지 않는다. 가중치는 모델을 올린 뒤 거의 고정되고, KV cache는 실제 token 수와 동시 sequence 수에 따라 늘어난다. activation과 workspace는 prefill/decode, kernel 선택, batch shape에 따라 순간적으로 달라진다. 프레임워크가 확보한 reserved memory와 실제 tensor가 점유한 allocated memory도 다를 수 있다. 그래서 “모델 파일이 8GB이니 8GB RAM이면 된다”는 계산은 불완전하다. 파일 크기는 대체로 가중치 보관 비용만 보여 주며, 실행 상태와 운영체제 여유를 포함하지 않는다. ## 4. 고정 비용의 중심: 모델 가중치 가중치의 이론적 최소 저장량은 parameter 수와 저장 bit 수로 계산한다. ```text 가중치 bytes = parameter 수 P × parameter당 bit 수 ÷ 8 ``` | 표현 | parameter당 크기 | 7B 원시 크기 | 70B 원시 크기 | |-----------|------------------|--------------|---------------| | FP32 | 4 bytes | 28 GB | 280 GB | | FP16/BF16 | 2 bytes | 14 GB | 140 GB | | INT8 | 1 byte | 7 GB | 70 GB | | 4-bit | 0.5 byte | 3.5 GB | 35 GB | 표는 10진수 GB로 계산한 원시 하한이다. 실제 checkpoint 또는 GGUF 파일에는 tensor metadata, alignment, quantization scale·zero point, block별 정보, 일부 고정밀 tensor가 추가된다. “7B”라는 이름 자체도 정확히 70억 parameter라는 보장이 없으므로 최종 판단은 실제 모델 파일과 런타임의 로드 결과로 해야 한다. weight tying, adapter, multimodal projector, speculative decoding용 draft model도 실제 상주 가중치를 바꾼다. 특히 vision-language 모델은 텍스트 모델 파일 외에 vision encoder나 projector가 추가될 수 있다. ## 5. 양자화는 용량과 대역폭을 함께 줄인다 양자화는 FP16/FP32 값을 더 적은 bit로 근사한다. group 또는 block마다 scale과 zero point를 두는 방식이 일반적이므로 실제 bit-per-weight는 명칭의 bit 수보다 커질 수 있다. Hugging Face 문서도 per-tensor와 per-channel/group 방식이 정확도·복잡도·메모리의 trade-off를 가진다고 설명한다. [8] - **이점:** 가중치 용량 감소, 메모리 읽기량 감소, 더 큰 모델 적재 가능. - **비용:** 반올림 오차, scale metadata, dequantization, 지원 kernel 의존성. - **성능:** bandwidth-bound 환경에서는 빨라질 수 있지만, 비효율적인 kernel에서는 unpack 비용 때문에 기대만큼 빨라지지 않을 수 있다. - **별도 축:** weight quantization과 KV-cache quantization은 서로 다른 설정이다. 같은 “Q4”도 block 크기, 중요 tensor의 혼합 정밀도, calibration 여부에 따라 파일 크기와 품질이 다르다. 그러므로 모델 선택 시 Q4라는 이름만 보지 말고 실제 포맷, bytes-per-weight, 지원 backend, benchmark를 함께 확인해야 한다. ## 6. 대화가 길어질수록 커지는 KV cache autoregressive decoder는 새 token을 생성할 때 이전 token의 attention Key와 Value를 다시 사용한다. 이를 저장하지 않으면 과거 token의 K/V를 매 단계 재계산해야 하므로, 일반적인 생성 런타임은 layer별 K/V tensor를 cache한다. Transformer의 attention 구조가 출발점이며 [1], MQA 논문은 incremental decode에서 K/V tensor의 반복 로딩이 메모리 대역폭 비용이 된다고 명시한다. [2] ```text KV bytes = batch/동시 sequence B × 저장 token 수 T × layer 수 L × 2 (Key + Value) × KV head 수 H_kv × head dimension D_head × 원소당 bytes ``` ### 8B급 가상 구조 계산 ```text B=1, L=32, H_kv=8, D_head=128, FP16=2 bytes 1 token = 1 × 32 × 2 × 8 × 128 × 2 = 131,072 bytes = 128 KiB ``` | 실제 저장 token | KV cache | |-----------------|------------| | 4,096 | 약 512 MiB | | 8,192 | 약 1 GiB | | 32,768 | 약 4 GiB | | 131,072 | 약 16 GiB | 이는 구조를 고정한 계산 예시이지 모든 8B 모델의 값이 아니다. layer 수, KV head 수, head dimension, cache dtype을 실제 config에서 읽어야 한다. 또한 일부 런타임은 최대 context를 미리 예약하고, 다른 런타임은 사용량에 따라 block을 늘린다. ## 7. MHA·GQA·MQA가 KV 메모리를 바꾸는 방식 | 구조 | K/V 공유 방식 | KV cache 특성 | |------|--------------------------------------|---------------| | MHA | 대체로 query head마다 K/V head | 가장 큼 | | GQA | 여러 query head가 K/V head 그룹 공유 | MHA보다 작음 | | MQA | 모든 query head가 단일 K/V head 공유 | 가장 작음 | MQA는 K/V head를 공유해 incremental decoding의 K/V 크기와 대역폭을 줄인다. [2] GQA는 K/V head 수를 query head 수와 1 사이로 두어 MHA 품질과 MQA 속도 사이를 절충한다. [3] 따라서 parameter 수가 같은 모델도 긴 context에서 필요한 메모리가 크게 다를 수 있다. **실무 결론** 필요 메모리를 “몇 B 모델인가?”만으로 계산하지 않는다. 반드시 `num_hidden_layers`, `num_key_value_heads`, `head_dim`, KV dtype을 확인한다. ## 8. context, batch, 동시 사용자는 곱셈 관계다 가중치는 여러 요청이 공유하지만 각 sequence의 KV cache는 별도다. 한 대화의 KV cache가 2GiB라면 동일 길이 sequence 10개는 단순 근사로 20GiB를 요구한다. 실제 서버는 길이가 제각각이고 요청이 종료되므로 allocator와 scheduler가 메모리 효율을 좌우한다. ```text 서빙 메모리 ≈ 공유 가중치 + Σ(요청 i의 실제 token 수 × token당 KV bytes) + workspace + allocator overhead ``` vLLM의 PagedAttention은 KV cache를 block 단위로 관리해 fragmentation과 중복을 줄이고 block sharing을 가능하게 한다. [4] 그러나 token마다 저장해야 하는 K/V 정보 자체가 사라지는 것은 아니다. Prefix caching도 동일 prefix를 재사용할 때만 이득이며, 서로 다른 대화의 고유 token은 계속 공간을 차지한다. 모델이 “128K context를 지원”한다는 말은 매 요청이 항상 128K cache를 쓴다는 뜻이 아니다. 실제 token 수만큼 증가하는 구현도 있고 최대치 기준으로 pool을 예약하는 구현도 있다. 지원 길이와 동시에 처리 가능한 요청 수는 별도 지표다. ## 9. activation, prefill, decode는 병목이 다르다 ### Prefill prompt 전체를 병렬 처리해 최초 KV cache를 만든다. 표준 full attention의 연산량은 sequence 길이에 대해 제곱으로 증가하고 큰 행렬곱이 많아 compute-bound가 되기 쉽다. Time To First Token에 직접 영향을 준다. ### Decode 새 token을 하나씩 생성한다. batch가 작을 때는 매 단계 큰 가중치를 읽고 적은 수의 token만 처리하므로 arithmetic intensity가 낮아 memory-bandwidth-bound가 되기 쉽다. context가 길어지면 이전 KV를 읽는 비용도 증가한다. ### Activation과 workspace hidden state, Q/K/V, MLP 중간값, logits, 정렬·행렬곱 kernel workspace가 순간적으로 존재한다. 추론 decode에서는 학습보다 작지만 0은 아니며, 긴 prompt의 prefill과 큰 batch에서는 peak가 커질 수 있다. FlashAttention은 attention 계산을 tiling하고 HBM과 on-chip SRAM 사이 I/O를 줄이는 exact attention 알고리즘이다. [5] 중간 메모리와 실제 속도를 개선하지만 full attention의 모든 논리적 비용을 제거하는 마법은 아니다. ## 10. 용량보다 더 자주 놓치는 대역폭 batch 1 decode에서 가중치가 cache에 전부 머물지 못하고 매 token 단계마다 주 메모리에서 스트리밍된다고 단순화하면 다음 상한을 생각할 수 있다. ```text 이론적 token/s 상한 ≈ 유효 메모리 대역폭 ÷ 한 단계에서 읽는 bytes ``` 예를 들어 실제로 읽는 모델 데이터가 token당 4GiB이고 유효 대역폭이 64GiB/s라면 메모리만 고려한 상한은 약 16 token/s다. 실제 값은 attention, dequantization, sampling, cache miss, kernel 효율, 동기화 때문에 더 낮다. 이 식은 benchmark 결과가 아니라 연산 성능·메모리 대역폭·연산 집약도를 함께 보는 Roofline 모델에 기반한 병목 이해용 근사다. [18] batch를 키우면 한 번 읽은 가중치를 여러 token/sequence 계산에 재사용할 수 있어 처리량이 올라가고 compute-bound 쪽으로 이동한다. 대신 요청 하나의 지연시간과 KV cache 사용량이 늘 수 있다. 그래서 interactive latency와 aggregate throughput은 서로 다른 목표다. **증설 해석** 32GB에 모델이 이미 안정적으로 들어간다면 64GB로 용량만 늘려도 token/s가 두 배가 되지 않는다. 채널 수·메모리 속도·유효 대역폭이나 GPU backend가 달라져야 속도 변화가 생긴다. ## 11. CPU 코어, 메모리 채널, NUMA CPU 추론은 코어 수를 늘리면 처음에는 빨라지지만 메모리 채널이 포화되면 추가 코어가 가중치를 기다리게 된다. 물리 코어, vector instruction 지원, 메모리 채널 수, DIMM 배치, backend의 thread scheduling을 함께 봐야 한다. 멀티소켓 서버에서는 각 CPU socket에 가까운 local RAM과 다른 socket의 remote RAM이 존재한다. thread와 weight page가 다른 NUMA node에 놓이면 interconnect를 건너며 대역폭과 지연시간이 악화될 수 있다. llama.cpp도 distribute/isolate/numactl 전략을 별도로 제공한다. [15] - thread 수를 논리 코어 수로 무조건 최대화하지 말고 token/s와 prompt processing 속도를 각각 측정한다. - 모든 메모리 채널이 활성화되도록 플랫폼 권장 DIMM 구성을 따른다. - NUMA node별 CPU affinity, memory placement, remote access를 관측한다. - ECC는 장시간 학습·서빙에서 오류 탐지/수정 신뢰성을 높이지만 플랫폼별 용량·대역폭 비용은 별도 확인한다. ## 12. RAM 부족, swap, mmap, page cache ### Swap은 느린 확장 메모리이지 동일한 RAM이 아니다 working set이 물리 RAM보다 크면 운영체제는 page를 swap으로 내보내고 다시 필요할 때 page fault로 읽어 온다. LLM decode는 큰 가중치를 반복 접근하므로 내보낸 page를 곧 다시 요구하는 thrashing이 생길 수 있다. SSD 용량이 크더라도 DRAM과 같은 latency·대역폭을 제공하지 않는다. ### mmap은 복사를 줄이지만 물리 법칙을 없애지 않는다 `mmap`은 파일을 프로세스 가상 주소 공간에 연결한다. [14] 접근된 page는 운영체제 page cache를 통해 resident memory에 들어오며 필요하면 회수될 수 있다. 초기 로딩과 이중 복사를 줄일 수 있지만 active page가 RAM에 상주하지 못하면 page fault와 I/O가 decode 경로에 들어온다. llama.cpp는 기본 mmap, swap 방지를 위한 mlock, mmap 비활성화, NUMA 전략을 제공한다. [15] `mlock`은 모델 page를 RAM에 붙잡아 pageout을 막지만 그만큼 다른 프로세스가 쓸 수 있는 RAM을 줄인다. **모니터링할 숫자** 가상 메모리 크기(VSZ)만 보지 말고 RSS/PSS, major page fault, swap-in/out, memory pressure, page cache, 실제 token/s를 함께 본다. mmap된 전체 파일 크기와 현재 resident set은 같지 않다. ## 13. RAM offloading과 PCIe 병목 VRAM에 들어가지 않는 layer나 tensor를 시스템 RAM에 두고 일부만 GPU에서 계산할 수 있다. 이는 실행 가능성을 높이지만 VRAM과 RAM을 같은 속도의 pool로 합치는 것은 아니다. 이산 GPU는 호스트와 장치 사이 전송을 거쳐야 하며 CUDA 가이드는 GPU device memory 내부 대역폭이 이 경로보다 훨씬 높다고 설명한다. [6] - **정적 layer offload:** 일부 layer는 GPU, 나머지는 CPU에서 실행한다. - **동적 tensor offload:** 필요한 tensor를 RAM/SSD에서 GPU로 옮겨 계산한다. - **KV offload:** KV cache를 CPU에 두어 VRAM을 아끼지만 layer마다 전송·동기화 비용이 추가될 수 있다. - **optimizer offload:** 학습 상태를 CPU RAM이나 NVMe로 옮겨 VRAM을 절약한다. FlexGen은 GPU·CPU·disk를 함께 사용해 제한된 GPU에서 throughput-oriented 추론을 가능하게 하는 사례다. [13] 이는 큰 batch와 latency-insensitive workload에 맞춘 설계이며, “SSD도 RAM처럼 빠르다”는 뜻이 아니다. 대화형 latency, batch 크기, 전송 overlap을 구분해야 한다. ## 14. 로딩 순간의 peak RAM과 이중 복사 최종적으로 가중치가 VRAM에만 있더라도 로더 구현에 따라 다음 중간 상태가 생긴다. ```text checkpoint를 RAM에 읽음 → dtype/quantization 변환용 새 tensor 생성 → VRAM으로 복사 → CPU 원본과 임시 tensor 해제 ``` 이 구간에는 원본, 변환본, GPU 복사본이 겹칠 수 있다. shard streaming, mmap, safetensors식 lazy loading, low-memory loader는 peak를 줄일 수 있지만 런타임별 동작을 확인해야 한다. 모델 로딩 OOM과 정상 추론 중 OOM은 원인이 다를 수 있다. GPU 관측에서도 “allocated”와 framework가 미리 잡아 둔 “reserved”를 구분한다. allocator fragmentation 때문에 총 여유 byte가 충분해 보여도 필요한 연속 block을 확보하지 못할 수 있다. 재현 가능한 최대 context·batch로 warm-up한 뒤 peak를 기록해야 한다. ## 15. 학습 메모리는 왜 추론보다 훨씬 큰가 추론은 주로 가중치를 읽지만 full fine-tuning은 gradient, optimizer state, backward용 activation을 유지한다. Adam은 1차·2차 moment를 관리한다. [10] 흔한 mixed-precision Adam 구성의 보수적 회계는 다음과 같다. | 상태 | parameter당 예시 | |------------------------|---------------------------| | FP16/BF16 model weight | 2 bytes | | gradient | 2 bytes | | FP32 master weight | 4 bytes | | Adam first moment | 4 bytes | | Adam second moment | 4 bytes | | **합계** | **약 16 bytes/parameter** | ```text 7B × 16 bytes ≈ 112 GB (activation과 workspace 제외) ``` 16 bytes는 보편 상수가 아니다. BF16 optimizer 구현, master copy 유무, gradient dtype, 8-bit optimizer, fused optimizer에 따라 달라진다. 그러나 “7B FP16 가중치가 14GB이니 16GB GPU에서 full fine-tuning 가능”이라는 추론이 왜 틀리는지는 이 회계로 알 수 있다. 여기에 backward용 activation이 추가된다. 크기는 구현별 상수항이 다르지만 대략 micro-batch, sequence length, hidden dimension, layer 수가 커질수록 증가한다. autograd는 역전파에서 사용할 forward 중간값을 보존하므로 긴 sequence나 큰 micro-batch에서는 activation이 model state만큼 중요하거나 더 큰 peak 요인이 될 수 있다. [12] ## 16. 학습 메모리 절약 기술의 정확한 효과 ### Activation checkpointing backward에 필요한 중간 activation 일부를 저장하지 않고 backward 시 forward 일부를 재실행한다. 메모리를 계산 시간과 교환한다. PyTorch도 저장 tensor 감소와 recomputation의 trade-off로 정의한다. [12] ### LoRA와 QLoRA LoRA는 base weight를 고정하고 작은 low-rank 행렬만 학습해 trainable gradient와 optimizer state를 크게 줄인다. [17] 그러나 base model weight와 forward/backward activation은 여전히 필요하다. QLoRA는 quantized base model 위에서 LoRA adapter를 학습해 base weight 저장량까지 낮춘다. [9] ### ZeRO와 FSDP식 sharding 일반 data parallelism은 각 GPU에 weight, gradient, optimizer state를 복제한다. ZeRO는 이 상태들을 단계적으로 GPU 사이에 분할해 중복을 제거한다. [11] 장치당 메모리는 줄지만 collective communication, 네트워크 topology, bucket 크기, overlap이 성능 변수가 된다. ### Gradient accumulation 작은 micro-batch 여러 번의 gradient를 누적해 큰 effective batch를 흉내 낸다. 한 번의 activation peak를 낮출 수 있지만 step당 forward/backward 횟수가 증가한다. sequence가 너무 길어 한 샘플도 들어가지 않는 문제를 혼자 해결하지는 못한다. ## 17. GPU 학습에서도 시스템 RAM이 필요한 이유 학습 파이프라인의 시스템 RAM은 다음을 담당한다. - 원본·전처리 데이터셋, shuffle buffer, tokenizer 출력 - DataLoader worker별 prefetch queue와 batch - GPU 비동기 전송을 위한 pinned host memory - checkpoint 로딩·직렬화·저장용 staging buffer - CPU optimizer/parameter offload 상태 - 분산 학습 프로세스와 통신 라이브러리의 host buffer RAM이 부족하면 GPU가 다음 batch를 기다리거나 worker가 OOM으로 종료되고, checkpoint 저장 순간에만 실패할 수도 있다. pinned memory는 전송에 유리하지만 pageout할 수 없는 희소 자원이므로 과도하게 잡으면 시스템 전체의 메모리 압력을 높인다. CUDA 가이드도 pinned memory 남용을 경고한다. [6] CPU offload를 쓴다면 RAM은 VRAM의 단순 보조가 아니라 학습 상태의 주 저장소가 된다. 이때 필요한 용량뿐 아니라 CPU-GPU interconnect와 CPU optimizer 처리량도 측정해야 한다. ## 18. 긴 context의 용량·속도 문제와 완화법 context가 길어질수록 KV cache는 선형 증가한다. 표준 full attention의 prefill 연산은 길이에 대해 제곱으로 증가하고, decode에서도 새 query가 읽을 과거 K/V가 늘어난다. 즉 “최대 context를 지원”과 “최대 context에서 빠르고 동시성이 높음”은 다른 주장이다. - **GQA/MQA:** KV head 수를 줄여 token당 cache를 축소한다. [2][3] - **KV quantization:** K/V 저장 dtype을 낮춘다. 품질과 kernel 지원을 검증해야 한다. - **Sliding-window/local attention:** 일부 layer가 최근 window만 유지하도록 설계한다. 모델 구조 지원이 필요하다. - **Paged KV 관리:** 동적 요청의 파편화와 낭비를 줄인다. [4] - **Prefix caching:** 동일한 system prompt나 prefix의 KV를 재사용한다. - **Prompt 압축·RAG 선별:** 관련 없는 token을 넣지 않아 cache와 연산을 동시에 줄인다. 긴 문서를 무조건 전부 prompt에 넣는 것은 정확도와 비용 모두에 최선이 아닐 수 있다. retrieval 품질, chunking, reranking을 통해 필요한 근거만 넣는 것은 애플리케이션 차원의 메모리 최적화다. ## 19. MoE, RAG, speculative decoding의 추가 메모리 ### Mixture of Experts MoE는 token마다 일부 expert만 활성화해 active compute를 줄일 수 있다. Switch Transformer는 sparse activation으로 parameter 수를 늘리는 대표 사례다. [16] 그러나 즉시 선택될 수 있는 모든 expert weight는 RAM/VRAM/다른 장치 어딘가에 있어야 한다. ```text MoE 연산량 판단 → token당 active parameters MoE 적재 용량 판단 → total parameters ``` ### RAG embedding model, vector index, reranker, document cache는 LLM weight와 별개로 RAM을 사용한다. 검색된 문서를 prompt에 넣으면 그 token은 LLM의 prefill 계산과 KV cache에도 반영된다. “벡터 DB 메모리”와 “LLM 메모리”를 한 숫자로 뭉치지 말고 서비스 구성요소별로 예산을 잡아야 한다. ### Speculative decoding draft model과 target model을 함께 쓰면 draft weight와 별도 실행 상태가 추가된다. target model의 decode 호출을 줄여 속도를 높일 수 있지만 총 메모리가 반드시 감소하는 기술은 아니다. ## 20. RAM이 많으면 모델이 더 똑똑해지는가 같은 weight, 같은 precision, 같은 prompt, 같은 sampling 설정이라면 RAM 증설 자체는 학습된 지식이나 reasoning 능력을 바꾸지 않는다. 다만 간접적으로 더 좋은 실행 조건을 허용한다. - 더 큰 모델 또는 여러 모델을 적재한다. - Q2 대신 Q4/Q8/FP16처럼 덜 공격적인 양자화를 선택한다. - 더 긴 실제 문맥과 더 많은 동시 대화를 유지한다. - swap, disk streaming, 과도한 CPU offload를 피한다. - RAG index, reranker, safety model을 함께 운영한다. 따라서 “RAM이 품질을 올린다”보다 “RAM이 어떤 모델·정밀도·문맥·시스템 구성을 선택할 수 있게 하는가”라고 묻는 것이 정확하다. ## 21. 실제 메모리 산정 절차 ### CPU 또는 통합 메모리 추론 ```text 필요 RAM ≈ 실제 model weight bytes + 실제 최대 token 기준 KV cache + activation/workspace peak + 런타임·allocator·파일 cache + OS와 동시 실행 앱 + 측정 기반 안전 여유 ``` ### 이산 GPU 추론 ```text 필요 VRAM ≈ GPU에 올릴 weights + GPU KV + GPU workspace + allocator 여유 필요 RAM ≈ CPU weights/offload + loader peak + host buffers + OS/앱 ``` ### 학습 ```text 장치당 peak ≈ 장치당 weight/gradient/optimizer shard + micro-batch activation + communication bucket + workspace 시스템 RAM ≈ dataset/prefetch/checkpoint staging + CPU offload state + host buffers + OS ``` 1. 모델 이름이 아니라 실제 checkpoint/GGUF 파일 크기와 config를 확인한다. 2. 목표 input 길이, 생성 길이, 동시 sequence, batch를 정한다. 3. KV 공식을 실제 layer·KV head·head dimension·dtype에 대입한다. 4. CPU/GPU에 어떤 tensor를 둘지 device map을 작성한다. 5. 목표 최대 shape로 warm-up하고 RAM RSS/PSS, VRAM allocated/reserved, page fault를 측정한다. 6. OOM 직전이 아니라 운영 중 다른 프로세스와 순간 peak를 견디는 여유를 둔다. ## 22. 계산 예시: 8B Q4와 70B Q4 ### 가상의 8B Q4, 8K context - 원시 weight 하한: `8B × 4bit ÷ 8 = 4GB`. - 앞의 32-layer GQA 예시 KV: 8,192 token에서 약 1GiB. - 실제 모델 파일: scale, metadata, 혼합 정밀도 때문에 4GB보다 클 수 있음. - 추가: workspace, runtime, OS, 앱, 로딩 peak. 따라서 “5GB 정도니 8GB RAM이면 된다”라고 결론 내릴 수 없다. 16GB 통합 메모리에서 실행되는 조합도 있을 수 있지만, 최대 context·동시 앱·runtime 구현까지 확인하지 않고 안정성을 보장할 수 없다. ### 가상의 70B Q4, 32K context - 원시 weight 하한: `70B × 4bit ÷ 8 = 35GB`. - 가정: 80 layers, 8 KV heads, head dimension 128, FP16 KV. - token당 KV: `80 × 2 × 8 × 128 × 2 = 327,680 bytes`, 즉 320KiB. - 32,768 token KV: 약 10GiB. weight 원시 하한과 KV만 더해도 약 35GB + 10GiB이며, 실제 weight metadata, workspace, OS는 아직 포함하지 않았다. 그래서 64GB 시스템도 workload에 따라 여유가 작을 수 있다. 반대로 context를 짧게 쓰고 일부 offload를 조정하면 요구량은 줄어든다. 정확한 추천은 모델 config와 측정 없이 할 수 없다. ## 23. 클라우드 LLM API에서는 내 RAM이 얼마나 중요한가 외부 API나 웹 Chat 서비스를 쓰면 모델 weight, 서버 KV cache, GPU activation은 제공자의 서버에 있다. 클라이언트 RAM은 브라우저, IDE, 로컬 파일 전처리, 업로드 버퍼, 응답 렌더링에 사용될 뿐 서버 모델의 parameter 적재량을 부담하지 않는다. 다만 대규모 파일을 클라이언트에서 parsing·embedding하거나 로컬 gateway가 응답을 캐시한다면 그 애플리케이션 메모리는 별도 고려해야 한다. “API를 호출한다”와 “모델을 로컬 호스팅한다”를 같은 하드웨어 요구사항으로 비교하면 안 된다. ## 24. 자주 틀리는 주장 | 주장 | 교정 | |----|----| | 모델 파일이 8GB면 RAM 8GB면 충분하다. | KV cache, workspace, runtime, OS, 로딩 peak가 빠졌다. | | RAM을 두 배로 늘리면 token/s도 두 배다. | 이미 적재된다면 용량보다 대역폭·kernel·연산 병목이 중요하다. | | VRAM 부족은 RAM만 많으면 같은 속도로 해결된다. | offload는 PCIe와 CPU 계산 비용을 추가한다. | | 128K context 지원은 128K에서도 항상 빠르다는 뜻이다. | KV 용량, prefill 연산, decode KV 읽기가 증가한다. | | 4-bit면 정확히 0.5 byte/parameter다. | scale, zero point, block metadata, 고정밀 tensor가 추가된다. | | 양자화는 무조건 빠르다. | backend의 저정밀 kernel과 dequantization 효율에 달렸다. | | SSD가 빠르면 RAM을 대체한다. | page fault와 저장장치 I/O는 DRAM/HBM보다 훨씬 느리다. | | mmap이면 RAM을 쓰지 않는다. | 접근한 file page는 결국 resident/page cache에 올라와야 빠르다. | | LoRA면 base model 메모리가 필요 없다. | base weight와 activation은 필요하고 trainable state만 크게 줄어든다. | | MoE 100B가 10B만 활성화하니 10B 메모리면 된다. | 연산은 active parameter 기준이지만 적재는 total expert weight 기준이다. | ## 25. 구매·배포 전 체크리스트 - 목표가 CPU 로컬 추론, 이산 GPU 추론, 통합 메모리 추론, 학습 중 무엇인가? - 실제 모델 parameter 수와 파일 크기, quantization 포맷은 무엇인가? - layer 수, KV head 수, head dimension, KV dtype은 무엇인가? - 평균/최대 input token과 output token은 얼마인가? - 동시 sequence와 throughput 목표는 얼마인가? - weight와 KV를 어느 장치에 둘 것인가? - RAM/VRAM의 용량뿐 아니라 유효 대역폭과 PCIe/NVLink 경로는 충분한가? - 로딩 peak, allocator reserved memory, fragmentation을 측정했는가? - swap-in/out, major page fault, NUMA remote access가 발생하는가? - 학습이라면 optimizer state, activation, checkpoint staging, DataLoader까지 계산했는가? - RAG index, embedding/reranker, draft model 같은 주변 구성요소를 별도 합산했는가? - 최대 workload로 warm-up·부하 테스트한 peak와 안전 여유가 있는가? ## 26. 결론 ```text LLM 메모리의 본질 적재 가능성 = 가중치 + KV + 실행 상태가 용량 안에 드는가 생성 속도 = 필요한 bytes를 대역폭과 연산기가 얼마나 빨리 처리하는가 동시성 = 공유 weight 위에 요청별 KV를 몇 개까지 쌓을 수 있는가 학습 가능성 = 추론 상태 + gradient + optimizer + activation을 감당하는가 ``` RAM은 LLM의 지능 그 자체가 아니다. 그러나 어떤 모델을 어떤 정밀도와 context, batch, 동시성으로 실행할 수 있는지를 제한한다. 정확한 판단은 “몇 B에 RAM 몇 GB”라는 단일 표가 아니라 실제 model config, tensor 배치, peak workload, 유효 대역폭을 함께 측정하는 과정에서 나온다. --- ## 출처 확인일 2026-07-21 Transformer 원 논문, 메모리 최적화 원 논문, 하드웨어·런타임 공식 문서를 우선했습니다. 본문의 [n]은 아래 순번을 가리킵니다. 1. [Attention Is All You Need](https://arxiv.org/abs/1706.03762) Vaswani et al., Transformer와 multi-head attention의 원 논문. 2. [Fast Transformer Decoding: One Write-Head is All You Need](https://arxiv.org/abs/1911.02150) Shazeer, incremental decoding의 K/V 대역폭 비용과 MQA. 3. [GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints](https://arxiv.org/abs/2305.13245) Ainslie et al., GQA의 구조와 MHA/MQA 사이 trade-off. 4. [Efficient Memory Management for Large Language Model Serving with PagedAttention](https://arxiv.org/abs/2309.06180) Kwon et al., KV cache fragmentation과 PagedAttention/vLLM. 5. [FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness](https://arxiv.org/abs/2205.14135) Dao et al., attention의 HBM I/O와 tiling 기반 최적화. 6. [CUDA C++ Best Practices Guide](https://docs.nvidia.com/cuda/cuda-c-best-practices-guide/) NVIDIA, host/device memory, 대역폭, pinned memory, 데이터 전송 원칙. 7. [Choosing a resource storage mode for Apple GPUs](https://developer.apple.com/documentation/metal/choosing-a-resource-storage-mode-for-apple-gpus) Apple Metal 공식 문서, Apple GPU의 CPU/GPU 통합 메모리 모델. 8. [Transformers: Quantization concepts](https://huggingface.co/docs/transformers/quantization/concept_guide) Hugging Face 공식 문서, scale/zero point와 quantization granularity. 9. [QLoRA: Efficient Finetuning of Quantized LLMs](https://arxiv.org/abs/2305.14314) Dettmers et al., 4-bit base model과 adapter fine-tuning. 10. [Adam: A Method for Stochastic Optimization](https://arxiv.org/abs/1412.6980) Kingma and Ba, 1차·2차 moment를 사용하는 Adam optimizer. 11. [ZeRO: Memory Optimizations Toward Training Trillion Parameter Models](https://arxiv.org/abs/1910.02054) Rajbhandari et al., optimizer/gradient/parameter 상태 중복 제거와 sharding. 12. [Current and New Activation Checkpointing Techniques in PyTorch](https://pytorch.org/blog/activation-checkpointing-techniques/) PyTorch Foundation, activation 저장과 recomputation의 memory/compute trade-off. 13. [FlexGen: High-Throughput Generative Inference of Large Language Models with a Single GPU](https://arxiv.org/abs/2303.06865) Sheng et al., GPU·CPU·disk offloading과 throughput-oriented 추론. 14. [mmap(2) — Linux manual page](https://man7.org/linux/man-pages/man2/mmap.2.html) Linux man-pages, 파일과 가상 주소 공간의 memory mapping 의미. 15. [llama.cpp server README](https://github.com/ggml-org/llama.cpp/blob/master/tools/server/README.md) ggml-org 공식 저장소, mmap/mlock/NUMA/KV dtype/GPU offload 실행 옵션. 16. [Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity](https://arxiv.org/abs/2101.03961) Fedus et al., sparse expert activation 기반 MoE. 17. [LoRA: Low-Rank Adaptation of Large Language Models](https://arxiv.org/abs/2106.09685) Hu et al., base weight 고정과 low-rank trainable adapter. 18. [Roofline: An Insightful Visual Performance Model for Floating-Point Programs and Multicore Architectures](https://www2.eecs.berkeley.edu/Pubs/TechRpts/2008/EECS-2008-134.html) Williams, Waterman, Patterson, 연산 성능·대역폭·operational intensity 기반 병목 모델.