디바이스 AI 에이전트, 메모리 한계에 봉착… 애플 새 아키텍처로 해결

출처: VentureBeat

온‑디바이스 AI 모델은 전체 가중치 집합을 DRAM에 저장해야 하기 때문에 규모가 작게 유지돼 왔으며, 실용적인 파라미터 수는 서버‑사이드 배포에서 사용하는 수준보다 훨씬 낮았습니다. 에이전트형 워크로드를 평가하는 기업 아키텍트들은 성능이 뛰하지만 클라우드에 의존하는 모델과, 제한된 온‑디바이스 모델 사이에서 선택해야 했습니다. WWDC26에서 발표된 애플의 3세대 파운데이션 모델은 가중치를 DRAM에서 완전히 제외함으로써 이 제약을 깨뜨렸습니다.

AFM 3 패밀리는 구글과 협업해 개발됐으며, 5개의 모델로 구성됩니다: 온‑디바이스용 2개와 서버 기반 3개가 모두 애플의 Private Cloud Compute 경계 안에서 실행됩니다. 서버‑사이드 모델에는 에이전트형 툴 사용 및 복잡한 추론을 위한 AFM 3 Cloud Pro가 포함되며, 이는 구글 클라우드의 Nvidia GPU에서 구동됩니다. 온‑디바이스 아키텍처는 애플 자체 기술입니다. AFM 3 Core Advanced는 200억 파라미터 모델로, 가중치를 DRAM이 아닌 NAND 플래시(NAND flash)에 저장합니다.

“전체 모델을 DRAM에 강제로 넣는 대신, 전체 모델을 플래시 메모리에 저장합니다.”라고 애플 연구팀이 적었습니다. “NAND‑to‑DRAM 대역폭이 토큰 단위로 가중치를 교환하기에 너무 느리기 때문에(표준 MoE 모델이 요구하는 바와 같이), AFM 3 Core Advanced는 프롬프트당 라우팅 결정을 내립니다.”

실제 아키텍처 작동 방식

애플이 우회하고 있는 메모리 장벽은 모든 로컬 AI 개발자가 마주치는 문제입니다.

“20 B 파라미터를 합리적인 정밀도로 RAM에 넣을 수 없습니다,”라고 Anthropic 연구원이자 전 애플 연구 과학자인 Awni Hannun이 X에 올렸습니다. “이를 구현하려면 오늘날 기준으로는 꽤 이색적인 아키텍처를 사용하고 있습니다. 작은 모델이 쿼리(또는 프롬프트)로부터 어떤 전문가(Expert)를 NAND에서 RAM으로 로드할지 예측합니다.”

예측‑로드 메커니즘은 소비자 실리콘의 하드웨어 제약에 의해 구동되는 세 가지 뚜렷한 구성 요소로 이루어집니다.

1. 전체 200억 가중치 집합이 플래시(NAND flash)에 존재하고, DRAM에는 없습니다. AFM 3 Core Advanced는 전체 파라미터를 활성 메모리가 아닌 NAND 플래시에 저장합니다. 기존 온‑디바이스 배포는 전체 모델이 DRAM에 들어가야 한다는 전제 때문에 파라미터 수가 제한됩니다. 애플은 이를 Instruction‑Following Pruning (IFP)이라 부르며, 플래시를 모델의 영구 저장소, DRAM을 프롬프트가 요구하는 전문가들을 위한 작업 버퍼로 활용합니다.

2. 전문가 라우팅은 토큰이 아니라 프롬프트당 한 번만 수행됩니다. 전통적인 Mixture‑of‑Experts(MoE) 모델에서는 토큰이 생성될 때마다 라우터가 서로 다른 전문가를 선택하는데, 이는 추론 속도에서 플래시와 DRAM 사이의 지속적인 가중치 이동을 요구합니다. NAND‑to‑DRAM 대역폭은 이를 지원하지 못합니다. AFM 3 Core Advanced는 프롬프트 시점에 한 번 라우팅을 수행해 고정된 전문가 집합을 선택하고, 이를 항상 활성화된 공유 전문가와 함께 DRAM에 로드한 뒤, 동일한 구성을 사용해 모든 토큰을 생성합니다.

   “일반 MoE와의 핵심 차이점은 쿼리당 한 번만 라우팅하고, 그 이후에는 같은 전문가들로 모든 토큰을 생성한다는 점입니다.”라고 Hannun이 적었습니다.

3. 활성 파라미터 수는 작업 복잡도에 따라 10억에서 40억까지 조정됩니다. 요청마다 고정된 모델 크기를 사용하는 대신, AFM 3 Core Advanced는 작업 요구에 따라 활성화할 파라미터 수를 동적으로 조절합니다. 간단한 작업에는 10억 파라미터, 복잡한 작업에는 최대 40억 파라미터를 사용하며, 모두 플래시 안에 있는 200억 파라미터 풀에서 끌어옵니다.

애플이 공개한 내용과 아직 공개되지 않은 내용

아키텍처 논문은 메모리 설계와 희소 활성화 메커니즘에 대해 상세히 다루지만, 실제 배포 시 제약 조건에 대해서는 덜 명확합니다.

애플의 프로파일링 도구는 실행 시간은 보여주지만, 생산성 판단에 필요한 에너지 소비, 메모리 대역폭, 열 등 핵심 지표는 제공하지 않습니다.

“에너지, 메모리 대역폭, 열? 문서에 없습니다,”라고 로컬 AI 프로파일러 Ziraph를 개발 중인 Marco Abis가 X에 올렸습니다. “이것이 온‑디바이스 성능을 좌우한다는 점을 고려하면 큰 공백입니다.”

Abis는 또한 애플 문서(코어 AI 문서, 파운데이션 모델 문서, Private Cloud Compute 보안 포스트) 어디에서도 온‑디바이스 요청이 언제 투명하게 오프로드되는지, 혹은 그 라우팅이 개발자나 사용자에게 보이는지 여부에 대한 명시를 찾지 못했습니다. 추론이 어디서 실행되는지를 문서화해야 하는 기업 입장에서는 직접적인 컴플라이언스 문제가 됩니다.

현재 모든 정보가 공개된 것은 아닙니다. 애플은 이번 여름에 벤치마크를 포함한 전체 기술 보고서를 발표할 예정이라고 밝혔습니다.

기업 아키텍트에게 주는 의미

에이전트형 AI 배포를 평가하는 규제 산업은 이제 구체적인 아키텍처 선택을 해야 합니다.

온‑디바이스 에이전트에 대한 DRAM 한계가 사라졌습니다. 클라우드 왕복 없이 실행돼야 하는 에이전트를 평가하는 기업은 이제 200억 파라미터 로컬 옵션을 검토할 수 있게 되었습니다. 제약 조건은 모델 능력에서 장치 하드웨어로 이동했습니다.

Private/Cloud 경계는 이제 기본값이 아니라 아키텍처 결정이 됩니다. 간단한 요청은 온‑디바이스에서 처리하고, 복잡한 에이전트 작업은 Private Cloud Compute 상의 AFM 3 Cloud Pro로 라우팅합니다. 애플은 언제 요청이 오프로드되는지, 그 라우팅이 개발자에게 보이는지에 대해 공개적으로 명시하지 않았으며, 이는 추론 위치를 문서화해야 하는 조직의 정책 결정에 복잡성을 더합니다.

에이전트 서버 계층은 Google Cloud에 의존합니다. AFM 3 Cloud Pro는 Google Cloud의 Nvidia GPU에서 구동됩니다. Private Cloud Compute 보장은 데이터 프라이버시를 제공하지만, 서버‑사이드 추론을 위해 Google Cloud 의존성을 없애지는 못합니다.

AFM 3 Core Advanced는 WWDC26 이전에는 존재하지 않았던 200억 파라미터 온‑디바이스 옵션을 기업에 제공합니다. 대규모 배포 가능 여부는 아직 애플이 공개하지 않은 세부 사항에 달려 있습니다. 해당 내용은 여름에 발표될 기술 보고서에 포함될 예정입니다.