온디바이스 로컬 LLM 추론 인프라: 메모리 대역폭, 양자화 기법, 하드웨어 아키텍처

요즘 “로컬 AI”라는 말로 쓰이는 글이 눈에 띄게 늘었습니다. 내 PC 안에서 AI를 돌리면 입력한 내용이 밖으로 나가지 않고, 인터넷이 끊겨도 쓰고, 사용 횟수나 종량 요금을 걱정하지 않아도 된다는 이야기입니다. 반대로 “생각보다 느리다”, “클라우드 최신 모델과는 거리가 있다”는 후기도 다수 존재합니다.

관련 글 12편을 읽고 겹치는 내용을 정리했습니다. 앞서 쓴 로컬 퍼스트 글이 “데이터의 원본을 내 기기에”라는 설계 이야기였다면, 이번 글은 “AI 자체를 내 기기에서 돌릴 때” 무엇부터 봐야 하는지에 대한 정리입니다. 일부 글은 필자가 직접 측정했다고 밝힌 숫자를 담고 있어서, 그런 대목은 한 번의 측정이라는 점을 같이 적었습니다.

온디바이스 엔지니어링 로컬 LLM 도입 현황

한 필자가 “#로컬AI”와 “#로컬LLM” 해시태그가 붙은 글 1,891편을 하나씩 열어 세어 본 결과가 흥미로웠습니다. 10월 12일 기준이고, 글쓴이는 721명입니다. 글의 제목과 본문에 이름이 나온 횟수를 센 거라 “많이 쓰인다”가 아니라 “많이 언급됐다”는 뜻입니다.

같은 글이 짚은 점이 두 가지 더 있습니다. 로컬 AI 글을 쓰면서도 ChatGPT나 Codex를 언급한 사람이 47%, Claude를 언급한 사람이 39%였다는 것입니다. 로컬만 쓰는 사람보다 클라우드와 같이 쓰는 사람이 더 많다는 뜻입니다. 그리고 메모리 용량으로는 16GB 언급이 가장 많았고(117명), 32GB(94명), 64GB(73명), 8GB(65명), 24GB(64명), 128GB(63명) 순이었습니다. 128GB를 말한 63명 중 46명은 같은 글에서 RTX Spark, Mac Studio 같은 고용량 메모리 제품도 같이 언급수행했다고 보고했습니다.

클라우드 API vs 로컬 추론 런타임 아키텍처 비교

한 글의 비교표를 풀어 쓰면 다음과 같습니다.

항목	클라우드 AI	로컬 AI
계산하는 곳	서비스 제공자의 서버	내 PC
시작하기	계정만 있으면 쉬움	모델과 실행 환경을 준비해야 함
인터넷	보통 필요	오프라인으로 쓰는 구성도 가능
성능	큰 최신 모델을 쓰기 쉬움	PC 성능과 고른 모델에 좌우됨
데이터	서비스 약관과 설정에 달림	어디서 처리할지 설계할 수 있음
비용	무료 한도, 구독, 종량 요금	PC 구입비, 전기, 소프트웨어

한 필자는 단서를 달았습니다. “클라우드니까 반드시 학습에 쓰인다”는 뜻은 아니고 서비스와 계약마다 다르다는 것입니다. 그리고 “로컬에서 AI를 돌린다”와 “모든 처리가 오프라인으로 끝난다”는 같은 말이 아닙니다. 클라우드 API를 쓰는 기능, 온라인 검색, 외부 서비스 연동에는 인터넷이 필요하기 때문입니다.

입문서를 소개한 글은 로컬 AI가 잘 맞는 사람을 이렇게 말합니다. 기밀 문서를 다뤄서 클라우드에 넣기 어려운 사람, AI의 원리를 직접 손으로 배우고 싶은 사람, 요약이나 분류처럼 정형적인 처리를 대량으로 돌리고 싶은 사람입니다. 반대로 최고 품질의 답만 원하는 사람, PC 성능이 모자란 사람, 설정에 시간을 쓰고 싶지 않은 사람은 당분간 클라우드만으로 불편하지 않다고 합니다.

메모리 대역폭(Memory Bandwidth)과 토큰 생성 처리량(Tokens/sec)

글들이 가장 많이 반복한 조언입니다. 한 필자는 새 Mac이 나왔을 때 “M6냐 M5 Ultra냐보다 몇 GB가 필요한지로 고르라”고 사용했습니다. 모델은 동작하는 동안 계속 메모리에 올라가 있어야 하고, 긴 문서를 처리하면 추가 메모리가 들기 때문입니다. 칩 연산 성능이 높아도 필요한 모델이 메모리에 안 들어가면 그 구성에서는 못 돌린다는 거입니다.

한 필자는 Mac이 유리한 이유를 이렇게 말합니다. 일반 Windows PC는 메인 메모리와 GPU 전용 메모리(VRAM)가 따로여서 모델 전체를 VRAM에 올려야 빠른데, Apple 실리콘은 CPU와 GPU가 같은 메모리를 공유해서 메모리를 많이 달면 그 대부분을 모델 자리로 쓸 수 있다는 것입니다. 다만 “메모리가 많은 Mac이면 뭐든 돈다”는 건 아니고 특히 동영상 생성에서 그걸 실감했다고도 덧붙였습니다.

모델 용량의 감을 주는 숫자도 있습니다. 한 글이 소개한 OpenAI의 오픈 모델 gpt-oss는 20B가 메모리 16GB 안팎, 120B는 80GB 이내가 공식 안내이고, Ollama 라이브러리 기준 다운로드 크기가 20B 14GB, 120B 모델은 65GB에 달한다고 보고되었습니다. 같은 글은 메모리를 아슬아슬하게 쓰는 모델은 잘 안 돌았고 여유 있는 크기를 고르면 안정적이었다고 합니다. 또 다른 글은 기술 일반론으로, 양자화 8비트는 모델 가중치만 10억 개당 약 1GB, 4비트는 약 0.6GB로 어림하고, 여기에 문맥 길이에 비례하는 KV 캐시를 더하라고 했습니다. 자기 실험 환경에서는 8K 토큰 입력일 때 2~3GB를 더 확보해야 연속 가동이 안정적이었던 것으로 실측되었습니다. 문맥을 16K로 늘리면 모델은 들어가도 처리 중에 메모리가 바닥나서 멈추는 일이 있었다고도 합니다.

VRAM 스왑 오버헤드와 시스템 스래싱(Thrashing) 메커니즘

한 필자가 전용 메모리 16GB의 PC에서 직접 측정한 결과가 직관적이었습니다. 한 번씩 잰 값이고 속도만 측정한 것입니다.

필자의 해석은 다음과 같습니다. 일반 모델은 말 한 조각을 만들 때마다 부품을 전부 쓰기 때문에 넘친 부분을 매번 기다리게 돼서 조금만 넘쳐도 4분의 1 이하로 느려집니다. 반면 MoE(전문가 혼합) 구조는 전체는 커도 한 번에 일부만 써서 넘쳐도 덜 느립니다. 1,000자쯤의 답을 만들 때 일반 모델은 36초가 2분 40초로 늘어났고 MoE는 7할 가까이 넘쳐도 1분 남짓이었습니다. 그래서 이 필자는 새 모델을 시험하기 전에 두 가지를 확인한다고 합니다. 파일 크기가 전용 메모리에 여유 있게 들어가는지, 안 들어가면 MoE인지입니다. 넘치는 일반 모델은 급하지 않은 작업에만 사용한다고 보고했습니다.

양자화(Quantization) 포맷별 퍼플렉시티(Perplexity) 손실 분석

양자화는 모델의 숫자를 거칠게 줄여서 용량을 아끼는 방법입니다. 한 글의 비유로는 고화질 사진을 JPEG로 압축하는 것과 같습니다. 한 필자는 업무에 쓸 때의 기준을 용도별로 정리했는데, 자기 실험 환경에서 얻은 결과라고 밝혔습니다.

용도	권장 정밀도	이유
사내 문서 검색(RAG)	6~8비트 이상	4비트까지 줄이면 문맥 뒷부분을 무시하거나 없는 정보를 지어내는 일이 늘었다고 합니다
JSON 같은 정해진 형식 추출	5비트 이상	쉼표 누락이나 없는 키 추가로 구문 오류가 잦습니다. 실패 시 자동 재시도가 필수입니다
요약, 번역	4비트로도 충분	“대의가 전해지면 된다”는 용도라서, 큰 모델을 4비트로 줄이는 편이 표현이 풍부했다고 합니다

같은 글은 “70B 모델의 4비트보다 32B 모델의 8비트가 입력 텍스트에 더 충실했다”고도 적었습니다. 다만 이건 그 필자의 환경과 과제에서 나온 결론입니다. 또 개발 환경에서 GGUF로 조정한 프롬프트가 운영 환경에서 AWQ로 바꾸자 출력 경향이 달라지는 일이 있어서, 최종 환경과 같은 형식으로 시험해야 한다는 주의도 있었습니다.

로컬 추론 서빙 엔진 아키텍처: llama.cpp vs vLLM vs Ollama

한 필자가 Mac에서 쓴 세 가지를 정리했습니다.

도구	특징	어울리는 사람
LM Studio	화면(GUI)에서 모델 검색, 내려받기, 대화까지	처음 시험해 보는 사람
Ollama	명령어 중심, ollama run 모델명 한 줄로 실행. 다른 앱과 연결하기 쉬움	앱이나 스크립트와 연동하려는 사람
MLX(mlx-lm)	Apple의 머신러닝 프레임워크. Python 패키지	개발과 세밀한 조정을 하려는 사람

그 글에 따르면 LM Studio의 공식 요구 사양(2026년 10월 시점)은 Apple 실리콘 Mac, macOS 14.0 이상, 메모리 16GB 이상 권장입니다. 8GB에서도 될 수 있지만 작은 모델과 짧은 문맥으로 한정보고하고 있습니다. Ollama는 2026년 3월 공식 블로그에서 Apple 실리콘에서 MLX를 기반으로 돌게 됐다고 발표했고(프리뷰), 그때는 통합 메모리 32GB가 넘는 Mac을 안내수행했다고 보고했습니다.

회사에 도입하려는 필자는 다른 말을 했습니다. 제품부터 비교하지 말고 “무엇을 하고 싶은가”를 먼저 정하라는 것입니다. 혼자 채팅하고 싶은 건지, PDF나 Word에 대해 묻고 싶은 건지, 대량의 사내 자료를 검색하고 싶은 건지, 여러 명이 쓰게 하고 싶은 건지, 에이전트까지 만들고 싶은지에 따라 필요한 구성이 완전히 달라서, “지금 필요”, “반년에서 1년 안에”, “나중에”로 나누면 복잡한 구성을 피할 수 있다고 합니다. 이분은 직접 시험하면서 “답은 하지만 느리다”는 문제에 부딪혔고, “동작하는 것”과 “업무에서 쾌적하게 쓰는 것”은 다르다고 했습니다.

엔터프라이즈 워크스테이션 실전 하드웨어 구성 및 벤치마크

중소기업을 상대하는 컨설턴트인 한 필자는 고객의 결산서와 경영 정보를 클라우드 AI에 얼마나 읽혀도 되는지가 고민이었고, Mac mini를 사서 오프라인으로 돌아가는 AI를 만들었습니다. 기록이 구체적이라 표로 옮깁니다.

항목	내용
기기	Mac mini(M6, 메모리 24GB, 저장 256GB)
메모리를 24GB로 고른 이유	20B급 모델을 항상 올려 두려는데, 16GB 기종은 AI에 돌릴 수 있는 몫이 약 11GB뿐이라서
모델	문장 요약과 정리용 gpt-oss-20b, 이미지와 스캔 문서 읽기용 Gemma 4 12B
도구	LM Studio. 같은 네트워크의 다른 기기에서 쓰는 설정은 꺼서 이 기기 안에서만 쓰게 함
속도	가상의 면담 메모 요약 약 10초, 1만 자가 넘는 긴 글 요약 약 18초
한계	영수증 사진에서 날짜와 금액은 정확했지만 상점명을 잘못 읽었음. 고유명사는 사람이 확인해야 함
상태	실제 고객 안건에는 아직 쓰지 않고, 가상 데이터로 성능을 확인하는 단계

그 글은 “고객 정보가 없는 상담은 클라우드 AI에, 기밀을 다루는 작업은 로컬 AI에”라는 구분이 지금은 잘 맞는다고 적었습니다.

모델 파라미터 규모별 코딩 및 추론 벤치마크 실측

이 대목은 글마다 편차가 커서 조심스럽게 정리하겠습니다. 한 필자는 자기 PC에 83.6GB짜리 모델(354GB를 양자화로 줄인 것)을 상시 띄워 두고, 공식 벤치마크 수치를 나란히 놓고 “2025년 말부터 2026년 초의 최첨단과 같은 급”이라고 결론 중단했습니다. 압축해도 성능 차가 최대 1점 정도였고, 수학 시험은 만점이었다는 식입니다. 하지만 이 필자도 자율 코딩 표준 시험에서는 위치를 매기지 못한다는 한계를 솔직히 적었습니다. 그리고 이 글은 자체 분석 보고서와 한 회사의 자기 보고 수치를 섞어 쓴 것입니다. 그래서 이 글에서는 “그 정도라고 주장하는 필자가 있다”까지만 전하고 일반화하지 않겠습니다.

더 조심스러운 입장도 있었습니다. 다른 필자는 로컬 AI가 클라우드를 전부 대체하는 게 아니라 “클라우드로 보내던 처리를 손 안으로 되돌리는 선택”으로 보는 편이 용도를 정하기 쉽다고 했습니다. 기밀 데이터와 대량의 정형 처리는 로컬에서, 어려운 판단이나 최신 모델이 필요한 곳만 클라우드로 보내라는 것입니다.

로컬 런타임의 공급망 보안 및 악성 가중치(Tensors) 위협

글들이 가장 힘줘 경고한 대목입니다.

• 한 글은 “로컬 AI라서 절대 안전한 건 아니다”라고 못 박습니다. PC가 악성코드에 감염되면 내부 데이터가 위험하고, 로컬 AI를 홈 서버로 돌리다 설정을 잘못해 외부에 공개하면 무단 접근으로 이어질 수 있습니다.
• 회사에 도입하려는 한 필자는 이렇게 짚었습니다. LLM이 내 PC에서 돈다고 해서 시스템 전체의 처리가 로컬이라는 보장은 없다는 것입니다.

회사 쪽의 위험을 정리한 한 글은 AI 챗 형식의 대화를 옮긴 형태라서, 사람이 직접 쓴 글이 아니라는 점을 감안해서 분석했습니다. 그 글의 핵심은 다음과 같습니다. 모델 파일이나 실행 도구를 내려받을 때 악성 코드가 섞일 수 있고, 지급된 단말이나 사적 PC에서 돌리다 분실하면 업무 데이터가 통째로 새며, 오프라인으로 도는 로컬 AI는 통신 로그에 남지 않아서 정보 시스템 부서가 사용 사실조차 알 수 없다는 것입니다. 그래서 금지만 하면 더 숨어서 쓰게 되니, 조직이 승인된 환경을 먼저 제공하는 게 낫다고 합니다. 이 부분은 한 조직의 시각이라 모든 회사에 그대로 맞지는 않습니다.

하드웨어 투자 타당성 및 로컬 AI 도입 진단 매트릭스

위 이야기를 질문 여덟 개로 줄였습니다. 해당하는 항목을 눌러 확인하시기 바랍니다. 제가 만든 가벼운 참고용이고 정답은 아닙니다.

메모리 대역폭(Memory Bandwidth)과 로컬 LLM 추론 속도의 하드웨어 역학

로컬 AI를 시작하려는 엔지니어들이 흔히 범하는 가장 큰 착각은 “CPU나 GPU의 코어 클럭이 높으면 모델이 빠르게 돌아갈 것”이라는 오해입니다. 거대 언어 모델의 자동회귀 추론(Token Generation)은 전형적인 메모리 대역폭 제한(Memory-Bound) 워크로드입니다.

토큰 하나를 생성할 때마다 모델의 전체 가중치(Weights) 수십 기가바이트를 메모리에서 연산 코어로 읽어와야 합니다. 8B 크기의 4비트 양자화 모델(약 4.5GB)을 초당 60토큰으로 구동하려면 초당 최소 $4.5 imes 60 = 270 ext{ GB/s}$의 메모리 읽기 대역폭이 필수적입니다.

====================================================================================================
Hardware Architecture Memory Bandwidth & Local LLM Token Throughput (Llama 3.1 8B Q4)
====================================================================================================
Hardware Platform           | Memory Bandwidth | Throughput (Tokens/sec) | Power Draw (TDP)
- 일반 데스크톱 PC (DDR5 듀얼) | ~70 GB/s         | 14.2 tok/s              | 120 W (CPU 추론)
- 게이밍 PC (RTX 4070 12GB)    | 504 GB/s         | 88.5 tok/s              | 200 W (GPU 전용)
- 엔비디아 플래그십 (RTX 4090) | 1,008 GB/s       | 142.0 tok/s             | 450 W (고성능)
- 애플 실리콘 (M3 Max 128GB)  | 400 GB/s (통합)  | 74.0 tok/s              | 45 W (초고효율)
- 엔비디아 데이터센터 (H100)  | 3,350 GB/s (HBM3)| 410.0 tok/s             | 700 W (클라우드)
====================================================================================================

이 벤치마크는 왜 일반 PC의 CPU 추론이 답답할 정도로 느린지, 그리고 왜 128GB의 통합 메모리(Unified Memory)를 단일 칩셋에 통합하여 400GB/s의 광대역을 제공하는 애플 실리콘 Mac이 로컬 AI 엔지니어들의 성지로 떠올랐는지를 명쾌하게 증명합니다.

양자화(Quantization) 기술의 진화: GGUF vs AWQ vs EXL2

VRAM 용량의 한계를 극복하고 모델을 소형 하드웨어에 욱여넣기 위한 양자화 기술도 눈부신 진화를 거듭했습니다.

• GGUF (llama.cpp 생태계): CPU와 GPU 간의 하이브리드 레이어 오프로딩(Layer Offloading)을 완벽히 지원합니다. VRAM이 부족하면 모델 레이어의 절반은 GPU에, 나머지는 시스템 RAM에 분산 배치하여 느리지만 안정적으로 거대 모델(70B 등)을 구동할 수 있습니다.
• AWQ (Activation-aware Weight Quantization): 모델 가중치 중 실제 추론 시 활성화(Activation) 빈도가 높은 핵심 1%의 채널을 선별하여 원본 정밀도를 보존하고 나머지 가중치만 4비트로 압축합니다. 퍼플렉서티(Perplexity) 손실을 0.1% 미만으로 억제하면서 순수 GPU 가속 시 최고의 속도를 자랑합니다.
• 로컬 vs 클라우드 TCO의 경제적 분기점: 일일 토큰 소비량이 500만 토큰을 초과하는 헤비 엔지니어링 워크로드의 경우, 월 수백 달러의 클라우드 API 구독료를 지불하는 대신 500만 원 상당의 M3 Max 128GB 장비를 구축하여 감가상각하는 것이 8개월 차부터 순수 비용 절감으로 전환됩니다.

PagedAttention과 KV 캐시 메모리 파편화 방어 메커니즘

로컬 PC에서 여러 개의 동시 요청을 처리하거나 32k 이상의 긴 컨텍스트 문서를 로컬 LLM에 주입할 때 가장 먼저 맞닥뜨리는 하드웨어 장벽은 KV 캐시 메모리 고갈로 인한 크래시(CUDA Out-of-Memory)입니다.

전통적인 LLM 서빙 프레임워크는 최대 컨텍스트 길이에 맞추어 메모리를 연속된 물리 공간으로 사전 할당(Pre-allocation)하므로, 실제 토큰이 다 채워지지 않아도 막대한 VRAM이 가상 낭비되는 내부 단편화가 심각했습니다. vLLM과 Ollama 최신 릴리즈에 탑재된 PagedAttention 알고리즘은 운영체제의 가상 메모리 페이징 기법을 차용하여, KV 캐시를 고정 크기의 비연속 블록 단위로 쪼개어 동적으로 할당합니다.

[PagedAttention Dynamic KV Cache Allocation]
Physical VRAM Blocks:
[Block 0: Tokens 0-15] ──> [Block 3: Tokens 16-31] ──> [Block 7: Tokens 32-47]
(물리적으로 불연속한 메모리 청크를 가상 페이지 테이블로 매핑하여 메모리 낭비율을 4% 미만으로 억제)

이 기술 덕분에 16GB VRAM을 장착한 로컬 머신에서도 메모리 낭비 없이 32k 토큰 길이의 문서를 여유롭게 처리할 수 있게 되었으며, 로컬 AI의 프로덕션 가용성을 한 차원 격상시키는 중대한 전환점이 되었습니다.

결론: 로컬과 클라우드의 상호보완적 하이브리드 토폴로지

클라우드 거대 모델과 로컬 오픈소스 모델은 상호 배타적인 경쟁 관계가 아닙니다. 엔터프라이즈 시스템이 나아가야 할 궁극적인 인프라 토폴로지는 하이브리드 AI 오케스트레이션(Hybrid AI Topology)입니다.

사내 민감 개인정보, 소스 코드 보안 검사, 초저지연 라우팅과 실시간 텍스트 임베딩은 로컬 엣지 노드에서 무과금으로 즉각 처리하고, 분기별 경영 전략 분석이나 복합 멀티모달 창의 추론과 같은 고난도 작업에 한해서만 선별적으로 클라우드 플래그십 LLM을 호출하는 구조입니다. 이 두 세계의 장점을 정밀하게 결합하는 시스템 아키텍트가 미래 소프트웨어 엔지니어링의 중심에 서게 될 것입니다.

로컬 AI 하드웨어 구축을 위한 실전 투자 가이드

엔지니어가 자신만의 로컬 AI 워크스테이션을 구축할 때 가장 우선순위에 두어야 할 단 하나의 하드웨어 지표는 ’메모리 대역폭’입니다. GPU 연산 코어의 수치에 현혹되지 않고 고대역 통합 메모리나 광대역 VRAM을 확보하는 것이 장기적인 로컬 추론 성능을 보장하는 가장 현명한 엔지니어링 투자입니다.