NVIDIA와 Apple은 하드웨어 문제를 해결했습니다. 이제 남은 과제는 무엇일까요?

GTC 2026 이후, 한 가지 사실은 기본적으로 결정되었습니다. 온디바이스 AI (on-device AI)를 위한 하드웨어 계층은 더 이상 병목 현상이 아닙니다.

NVIDIA의 RTX Spark는 Blackwell GPU + Grace CPU + 128GB 통합 메모리 (unified memory)를 데스크톱 폼 팩터에 담아냈습니다. 통합 메모리 아키텍처 (unified memory architecture)와 효율성 우선 설계를 갖춘 Apple의 M-시리즈 칩은 4B, 심지어 7B 파라미터 모델도 MacBook에서 원활하게 실행할 수 있게 해줍니다. 두 가지 서로 다른 접근 방식이지만 목적지는 같습니다. 이제 소비자용 하드웨어는 온디바이스 AI 에이전트 (on-device AI agents)를 실행하기 위한 컴퓨팅 기반을 갖추게 되었습니다.

칩 제조사들은 자신들의 역할을 다했습니다. 다음 질문은 이것입니다: "칩이 AI 모델을 실행할 수 있는 상태"와 "온디바이스 에이전트가 실제로 유용한 작업을 완료할 수 있는 상태" 사이에는 여전히 얼마나 많은 계층이 빠져 있는가?

이 포스트는 온디바이스 AI 에이전트를 위한 전체 기술 스택 (technology stack)을 그려내며, 각 계층의 성숙도를 검토하고, 격차를 식별하며, 지금까지 오픈 소스 (open-source) 커뮤니티가 구축한 것들을 추적합니다.

계층 1: 실리콘 (준비 완료)

온디바이스 AI 추론 (inference)은 전통적인 컴퓨팅 워크로드와는 다른 칩 요구 사항을 가집니다. 핵심 병목 현상은 최대 FLOPS가 아니라, 메모리 대역폭 (memory bandwidth)과 통합 메모리 용량입니다. LLM 추론은 모델 가중치 (model weights)가 메모리에 완전히 로드되어야 하며, 연산 과정에서 가중치 행렬 (weight matrices)과 활성화 함수 (activations) 사이의 고주파 데이터 이동이 필요합니다. 만약 메모리 대역폭이 따라가지 못하면, 순수 연산 능력은 데이터를 기다리며 유휴 상태로 머물게 됩니다.

오늘날 세 가지 주요 실리콘 경로가 존재합니다:

NVIDIA N1X: Blackwell GPU + Grace CPU 이기종 아키텍처 (heterogeneous architecture), 128GB 통합 메모리, 페타플롭 (petaflop)급 컴퓨팅, 데스크톱 워크스테이션 타겟
Apple M-시리즈 (M4/M5): GPU와 CPU가 메모리를 공유하는 통합 메모리 아키텍처, 최적화된 메모리 대역폭, 32GB에서 192GB까지의 구성
Qualcomm Snapdragon X: 노트북 및 모바일 타겟, NPU 가속 추론, 상대적으로 제한적인 메모리 구성

강조점은 다르지만, 한 가지 공통된 결론은 다음과 같습니다: 2026년 소비자용 실리콘은 실시간 추론을 위해 4B 이상의 파라미터 모델을 실행할 수 있습니다. 이 계층은 준비되었습니다.

계층 2: 추론 프레임워크 (성숙함)

실리콘(Silicon)이 준비되었으므로, 모델을 실제로 실행하기 위해서는 효율적인 추론 프레임워크 (Inference Frameworks)가 필요합니다. 이 계층은 딥러닝 모델을 특정 칩의 연산 유닛(Compute Units)에 효율적으로 매핑하는 문제를 해결합니다.

Apple 생태계: MLX는 Apple Silicon에서 가장 성숙한 추론 프레임워크입니다. 가중치 양자화 (Weight Quantization, W8A16, W4A16)에 대한 네이티브 지원, 심도 있는 Metal GPU 최적화, 활발한 커뮤니티를 갖추고 있습니다.

NVIDIA 생태계: TensorRT-LLM이 이에 대응하는 솔루션으로, CUDA 및 Tensor Core에 최적화되어 있으며, RTX Spark의 Blackwell 아키텍처를 위한 특정 최적화가 적용되어 있습니다.

크로스 플랫폼 (Cross-platform): 멀티 플랫폼 배포를 위한 ONNX Runtime, 그리고 다양한 하드웨어에서 실행되는 미니멀리스트 접근 방식을 취하는 llama.cpp가 있습니다.

이 계층은 충분히 성숙했습니다. 개발자들은 추론 커널 (Inference Kernels)을 처음부터 직접 작성할 필요가 없습니다. 프레임워크를 선택하기만 하면 모델이 실행됩니다.

계층 3: 양자화 가속 (Quantization Acceleration, 따라잡기)

추론 프레임워크가 모델을 "실행 가능하게" 만든다면, 양자화 가속 계층은 모델을 "빠르게" 만듭니다.

LLM 추론의 계산 병목 지점은 행렬 곱셈 (Matrix Multiplication)입니다. 모델 가중치는 일반적으로 FP16 또는 BF16으로 저장되지만, 엣지 칩(Edge Chips)에는 저정밀도 연산을 위한 전용 하드웨어 가속 유닛이 있습니다. 가중치와 활성화 함수 (Activations)를 INT8 또는 INT4로 양자화하면 추론 속도가 크게 향상되고 메모리 점유율 (Memory Footprint)이 감소합니다.

MLX는 가중치 양자화 (W8A16, W4A16)를 네이티브로 제공하지만, 활성화 함수는 FP16으로 남아 있어 온라인 활성화 양자화 (Online Activation Quantization)는 지원하지 않습니다. 이는 행렬 곱셈의 한쪽은 INT8/INT4인 반면 다른 한쪽은 여전히 FP16임을 의미하며, 이로 인해 타입 변환 오버헤드 (Type Conversion Overhead)가 발생합니다.

오픈 소스 Cider SDK가 이 간극을 메워줍니다. MLX를 기반으로 구축된 Cider는 W8A8 및 W4A8 활성화 양자화 (Activation Quantization) 모드를 구현하여, 가중치 (Weights)와 활성화 (Activations)를 모두 INT8로 양자화함으로써 직접적인 INT8 TensorOps 행렬 곱셈 (Matrix Multiplication)을 수행합니다. 측정된 성능은 다음과 같습니다:

Apple M5 Pro에서, W8A8 채널별 양자화 (Per-channel Quantization)는 W8A16 베이스라인 대비 최대 1.8배의 프리필 (Prefill) 속도 향상을 달성합니다.
MLX 네이티브 W4A16과 비교했을 때, 프리필 속도 향상은 1.4배에서 2.2배 사이입니다.
특정 프로젝트에 국한되지 않고 모든 MLX 모델과 호환됩니다.

Cider는 조건부 컴파일 (Conditional Compilation)을 사용합니다. M5+ 칩은 전체 C++ 확장 기능과 Metal 커널이 빌드되어 제공되지만, M4 이하 모델은 호환성 폴백 (Fallback)을 위해 순수 Python 패키지로 설치됩니다. 하드웨어는 다르더라도 설치 명령은 동일하지만, 가속은 M5+에서만 활성화됩니다.

이 계층은 현재 "추격" 단계에 있습니다. 가중치 양자화 (Weight Quantization)는 표준이 되었습니다. 활성화 양자화 (Activation Quantization)는 주류가 되어가고 있습니다. 더 세밀한 전략 (그룹별, 토큰별)은 여전히 진화 중입니다.

계층 4: 모델 (수직적 도메인에서 사용 가능)

처음 세 계층은 인프라입니다. 계층 4는 모델이 작업에 직접 직면하는 단계입니다. 온디바이스 (On-device) 모델의 핵심 과제는 다음과 같습니다. 파라미터 수 (Parameter Count)는 디바이스 메모리에 의해 제한되지만, 로컬에서 실행한다고 해서 작업의 복잡도가 줄어들지는 않는다는 점입니다.

일반적인 접근 방식은 클라우드 규모의 모델을 온디바이스 크기로 증류 (Distillation)하거나 가지치기 (Pruning)하는 것이지만, 이는 보통 눈에 띄는 성능 저하를 동반합니다.

더 효과적인 경로는 도메인 특화 최적화 (Domain-specific Optimization)입니다. 특정 작업 유형 (GUI 조작, 웹 탐색, 코드 생성)에 대한 타겟팅된 학습을 통해, 소형 모델은 타겟 도메인에서 대형 모델과 대등하거나 이를 능가할 수 있습니다.

Mano-P가 이 경로를 따릅니다. 이는 GUI 자동화에 초점을 맞추어 엣지 디바이스 (Edge Devices)를 위해 특별히 설계된 Apache 2.0 라이선스의 GUI-VLA (Vision-Language-Action) 에이전트입니다.

핵심 기술은 3단계 점진적 학습(SFT → Offline RL → Online RL)과 고정밀 GUI 이해 및 조작을 위한 "think-act-verify" 루프 추론 메커니즘을 사용하는 Mano-Action 양방향 자기 강화 학습 (bidirectional self-reinforcement learning)입니다.

벤치마크 데이터 (72B 평가 모델):

OSWorld: 정확도 58.2%, 특화 모델 중 1위, 2위인 opencua-72b (45.0%)를 13.2%포인트 차이로 앞섬
WebRetriever Protocol I: 41.7 NavEval, Gemini 2.5 Pro (40.9) 및 Claude 4.5 (31.3)를 앞섬

참고: 이 결과는 72B 평가 모델 기준입니다. 실제 온디바이스 (on-device) 배포에는 4B 버전(Mano-CUA-4B-Thinking-1.1)이 사용되며, 64GB RAM을 탑재한 M5 Pro에서 약 80 tokens/s의 디코딩 속도를 달성합니다. Cider의 W8A8 양자화 (quantization)를 적용하면, 프리필 (prefill) 단계에서 W8A16 베이스라인 대비 약 12.7%의 추가 속도 향상을 얻을 수 있습니다.

이 계층의 상태: 일반적인 능력에는 여전히 격차가 존재하지만, GUI 조작 및 웹 네비게이션과 같은 수직적 도메인(vertical domains)에서는 온디바이스 특화 모델이 상용화 가능한 수준(production-ready)에 도달했습니다.

계층 5: 에이전트 오케스트레이션 (초기 엔지니어링 단계)

지시 사항을 이해하고 인터페이스를 조작할 수 있는 모델이라 할지라도, 전체 워크플로우를 완료하기 위해서는 작업 분해 (task decomposition), 도구 호출 (tool invocation), 오류 복구 (error recovery) 및 상태 추적 (state tracking)을 관리할 오케스트레이션 계층 (orchestration layer)이 여전히 필요합니다.

이 단계의 과제: 온디바이스 에이전트는 복잡한 계획 수립 및 백트래킹 (backtracking)을 위해 거대한 클라우드 컴퓨팅에 의존할 수 없습니다. 모든 결정은 로컬 리소스 제약 조건 내에서 이루어져야 합니다.

Mano-AFK는 온디바이스 에이전트 오케스트레이션 (Agent Orchestration)의 한 가지 구현 사례입니다. 이는 자연어 요구사항으로부터 PRD (제품 요구사항 문서) 생성, 아키텍처 설계, 코드 작성, 로컬 배포, 다단계 테스트 (lint + API + 실제 브라우저 E2E 테스트 + 독립적 적대적 검토 (Adversary Review)), 그리고 작동하는 애플리케이션이 전달될 때까지의 자동 버그 수정에 이르기까지, 완전히 자율적인 애플리케이션 구축 파이프라인입니다. E2E (End-to-End) 테스트 단계에서는 Mano-P를 로컬 비전 모델 (Vision Model)로 사용하여 브라우저를 제어하며, 인간의 개입은 전혀 필요하지 않습니다.

이 계층은 초기 엔지니어링 단계에 있습니다. 프레임워크들이 빠르게 반복(Iterating)되고 있지만, 안정성, 오류 복구, 그리고 다단계 계획 (Multi-step Planning)의 정밀도 측면에서는 모두 개선의 여지가 있습니다.

전체 그림: 각 계층의 성숙도

실리콘 (Silicon): ✅ 준비 완료. NVIDIA, Apple, Qualcomm 모두 실행 가능한 경로를 확보함
추론 프레임워크 (Inference Frameworks): ✅ 성숙함. MLX, TensorRT-LLM 등이 프로덕션 수준(Production-ready)임
양자화 가속 (Quantization Acceleration): 🔧 추격 중. 가중치 양자화 (Weight Quantization)는 표준화되었으며, 활성화 양자화 (Activation Quantization, 예: Cider의 W8A8)가 도입되고 있음
모델 (Models): 🔧 수직적 영역 (Verticals)에서 사용 가능함. 범용 능력의 격차는 여전히 존재하지만, GUI 및 유사한 특화된 작업들은 프로덕션 품질임
에이전트 오케스트레이션 (Agent Orchestration): 🔨 초기 엔지니어링 단계. 기초적인 역량은 존재하나, 안정성과 복잡한 시나리오 처리 능력이 정교화되는 과정에 있음

이것이 개발자에게 의미하는 바

만약 여러분이 온디바이스 AI 분야에서 무언가를 구축하고 있다면, 지금은 주목할 만한 시기입니다. 실리콘과 프레임워크 계층은 성숙했습니다. 양자화와 모델 계층은 빠르게 반복되고 있습니다. 지금 참여하는 것은 생태계가 "작동함"에서 "잘 작동함"으로 넘어가는 결정적인 단계에 여러분을 위치시킵니다.

구체적인 스택 선택은 여러분의 사용 사례 (Use case)에 따라 달라집니다:

온디바이스 GUI 에이전트 역량의 빠른 검증 (Quick validation of on-device GUI agent capabilities): Mano-P의 클라우드 모드(mano.mininglamp.com을 통해 제공)를 사용하여 시작한 다음, 로컬 모드로 전환하십시오.
Apple Silicon에서의 추론 가속 최적화 (Inference acceleration optimization on Apple Silicon): Cider의 INT8 TensorOps 구현은 유용한 참고 자료가 됩니다.
엔드 투 엔드 (End-to-end) 자율 작업 파이프라인 구축: Mano-AFK의 아키텍처(별도의 빌더 에이전트 + 적대적 검토자 에이전트 구성)는 연구할 가치가 있습니다.

모든 프로젝트는 Mininglamp-AI GitHub 조직 아래 오픈 소스로 공개되어 있습니다. Mano-P는 Apache 2.0 라이선스를 따르며, brew tap Mininglamp-AI/tap && brew install mano-cua를 통해 설치할 수 있습니다. 이 작업이 유용하다고 느끼신다면, GitHub 스타(star)를 눌러주시는 것이 큰 도움이 됩니다.