🤖
1314 in / 5210 out / 6524 total tokens
🔥 핫 토픽: 하드웨어 한계에 도전하는 LLM 실험들
1998년 iMac G3에서 돌아가는 LLM — 32MB 램의 기적
레딧 LocalLLaMA 커뮤니티에서 충격적인 실험 결과가 올라왔다. 1998년형 iMac G3—233MHz PowerPC 750 프로세서에 32MB 램—에서 LLM이 실제로 구동됐다. 사용한 모델은 Andrej Karpathy가 만든 260K 파라미터의 TinyStories로, Llama 2 아키텍처 기반이며 체크포인트 크기가 약 1MB다. OS는 Mac OS 8.5, 하드웨어 업그레이드 없이 순정 상태에서 실행했다.
이 실험이 중요한 이유는 "LLM은 최신 GPU가 있어야 한다"는 통념을 깨부수기 때문이다. 물론 260K 파라미터 모델은 실용적 성능과 거리가 멀다. 하지만 LLM 추론의 본질—행렬 연산과 토큰 생성—이 CPU만으로도 가능하다는 점을 증명했다. 게임 개발자로서 생각해보면, 예전에 언리얼 엔진 4를 GTX 960에서 돌리던 시절이 떠오른다. 하드웨어 제약이 있을수록 최적화에 집중하게 되고, 그 과정에서 시스템에 대한 이해가 깊어진다.
기술적 배경을 설명하자면, LLM 추론은 기본적으로 부동소수점 행렬 곱셈의 연속이다. GPU가 없어도 CPU에서 계산할 수 있고, 심지어 32MB 램에서도 1MB 모델을 로드할 수 있다. 속도는 굉장히 느리겠지만 논리적으로 불가능한 건 아니다. Karpathy의 TinyStories는 어린이용 이야기를 생성하도록 훈련된 초소형 모델로, Llama 2의 핵심 아키텍처—트랜스포머 디코더, RoPE 포지셔널 인코딩, RMSNorm—를 그대로 축소해 담았다. 즉, 구조적으로는 GPT-4나 Claude와 같은 원리로 작동한다.
이 실험이 시사하는 건 엣지 컴퓨팅과 오프라인 AI의 가능성이다. 게임 개발에서도 NPC 대화 시스템을 로컬에서 돌려야 하는 상황이 올 수 있다. 그때 이런 초소형 모델 최적화 경험이 빛을 발할 것이다. 물론 지금 당장은 7B 모델을 16GB VRAM에서 돌리는 게 현실적이지만, 하드웨어 제약 극복 노력은 언젠가 도움이 된다.
GuppyLM — LLM 작동 원리를 완벽히 이해하기 위한 초소형 구현
해커 뉴스에서 GuppyLM이라는 프로젝트가 화제다. LLM이 어떻게 작동하는지 이해하기 위해 직접 작은 LLM을 만들어본 프로젝트다. 저장소를 열어보면 토큰화, 임베딩, 어텐션, 레이어 정규화, 디코딩까지 전체 파이프라인이 깔끔하게 정리되어 있다. 복잡한 최적화나 추상화 없이 핵심 로직만 읽을 수 있게 설계됐다.
이 프로젝트가 중요한 이유는 교육적 가치다. 요즘 LLM 관련 글을 읽으면 어텐션, KV 캐시, RoPE 같은 용어가 난무하는데, 정작 코드 레벨에서 어떻게 구현되는지는 알기 어렵다. Hugging Face 트랜스포머 라이브러리나 PyTorch 내부를 뜯어보면 추상화 레이어가 너무 두껍다. 반면 GuppyLM은 수백 줄 안에서 전체 과정을 보여준다. 마치 언리얼 엔진 소스를 읽기 전에 직접 미니 렌더러를 만들어보는 것과 같다.
개발자 관점에서 보면, 이런 작은 구현체를 분석하는 건 디버깅 능력을 키우는 데 도움이 된다. 나도 언리얼 엔진으로 개발하다가 UObjects 생명주기 문제를 겪었을 때, 직접 간단한 리플렉션 시스템을 만들어보면서 원리를 이해했던 경험이 있다. LLM도 마찬가지다. KV 캐시가 왜 필요한지, 어텐션 마스크가 어떻게 작동하는지, 토큰 생성이 왜 auto-regressive인지—이론으로만 알던 게 코드로 명확해진다.
기술적으로 GuppyLM은 아마도 단일 트랜스포머 블록이나 몇 개의 레이어로 구성됐을 것이다. 어텐션은 scaled dot-product attention을 직접 구현하고, FFN은 간단한 두 개의 선형 레이어로 구성했을 것이다. 현대 LLM에 있는 MoE, Grouped Query Attention, Flash Attention 같은 최적화는 없겠지만, 핵심 원리는 동일하다. 이 프로젝트를 클론해서 한 줄씩 읽어보면 LLM 내부가 더 이상 블랙박스로 느껴지지 않을 것이다.
출처: GitHub - GuppyLM
🔗 두 뉴스의 연결고리
앞서 살펴본 iMac G3 실험과 GuppyLM은 서로 다른 맥락에서 출발했지만, 결국 같은 지점을 향한다—LLM의 본질적 이해다. 전자는 하드웨어 제약 속에서 "최소한으로 필요한 게 무엇인가"를 탐구했고, 후자는 소프트웨어 관점에서 "핵심 메커니즘이 무엇인가"를 파헹친다.
게임 개발에서도 비슷한 패턴이 있다. 최적화를 하려면 먼저 시스템이 어떻게 돌아가는지 이해해야 한다. Draw call이 왜 비싼지, 가비지 컬렉션이 언제 트리거되는지, 메모리 단편화가 어떻게 발생하는지—이걸 알아야 병목을 잡을 수 있다. LLM도 마찬가지다. 모델이 어떻게 토큰을 생성하는지, 메모리를 어떻게 사용하는지, 어텐션이 어떻게 계산되는지 알아야 제대로 활용하고 최적화할 수 있다.
두 프로젝트 모두 "작게 시작하기"의 가치를 보여준다. 70B 파라미터 모델을 돌리려고만 하지 말고, 260K 모델로 원리를 이해하고, 점진적으로 확장해가는 접근이 필요하다. AI 통합 게임을 만들 때도 7B 모델부터 시작하기보다, 작은 모델로 파이프라인을 먼저 구축하고 나중에 모델만 교체하는 식으로 개발하는 게 현명할 것이다.
💻 개발자 관점에서의 시사점
엣지 디바이스 AI의 현실과 가능성
iMac G3 실험은 극단적이지만, 엣지 디바이스에서의 AI 실행 가능성을 시사한다. 스마트폰, IoT 기기, 게임 콘솔—모두 GPU 메모리가 제한적이다. 클라우드 API 호출 없이 로컬에서 AI를 돌려야 하는 시나리오를 상상해보자. 오프라인 게임에서 NPC가 플레이어 행동에 반응해 대화를 생성해야 한다면? 260K 모델은 부족하겠지만, 양자화된 1B 모델 정도는 모바일 GPU에서 충분히 돌아간다. Qualcomm의 Snapdragon 8 Gen 3이나 Apple의 M 시리즈 칩은 NPU를 내장해 더 효율적인 추론이 가능하다.
교육용 프로젝트의 가치
GuppyLM 같은 프로젝트를 직접 따라 해보는 걸 강력히 추천한다. LLM API만 호출하다 보면 내부 동작을 영원히 모른다. 반면 직접 토크나이저를 구현해보고, 어텐션 행렬을 출력해보고, 생성 과정을 단계별로 추적해보면 완전히 다른 관점이 생긴다. 나도 언리얼 엔진 사용하다가 막히면 직접 미니 엔진을 만들어보곤 한다. 그러면 엔진이 왜 그렇게 설계됐는지 이해가 된다.
실무 적용 아이디어
당장 실무에 적용할 수 있는 아이디어들이다. 첫째, 게임 내 자연어 처리가 필요하면 작은 모델로 프로토타입을 먼저 만들어라. 둘째, 모델 양자화와 프루닝을 공부해라—4-bit 양자화만 해도 메모리 사용량이 1/4로 줄어든다. 셋째, KV 캐시 최적화를 이해해라—긴 컨텍스트 처리 시 필수적이다. 넷째, 추론 최적화 라이브러리인 llama.cpp, ONNX Runtime, TensorRT를 익혀라—각각 CPU, 크로스플랫폼, GPU 최적화에 특화돼 있다.
LLM의 본질은 거대한 행렬 곱셈이다. 하드웨어가 부족하면 모델을 작게 만들고, 원리를 모르면 직접 구현해보면 된다.