FreeToken 엣지 네이티브 MoE 서빙: 아키텍처 가이드

FreeToken 엣지 네이티브 MoE 서빙은 일반적인 로컬 하드웨어에서 매우 큰 혼합 전문가(MoE) 언어 모델을 실행하기 위한 연구 시스템입니다. 제한된 GPU 메모리를 자동으로 실행 불가능한 요소로 간주하는 대신, 그래픽 프로세서, 중앙 프로세서, 호스트 메모리 및 사용 가능한 인터커넥트 사이에 작업을 분산합니다.

핵심 개념은 리소스 오케스트레이션입니다. 일반 소비자용 컴퓨터는 성능이 뛰어난 GPU를 갖추고 있을 수 있지만, 최첨단 규모의 모델을 수용하기에는 그래픽 메모리가 부족할 수 있습니다. 모든 작업을 동일한 느린 경로로 이동하면 병목이 발생합니다. FreeToken은 대신 대역폭, 캐시 상태, 현재 추론 단계에 맞춰 실행 방식을 조정합니다.

이 프로젝트는 2026년 8월 17일 FreeToken: Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Execution이라는 제목으로 arXiv에 공개되었습니다. 등재된 저자로는 Shuo Yang, Xiaoze Fan, Melissa Pan, Haocheng Xi, Zhe Wang, Shanlin Sun, Kurt Keutzer, Song Han, Matei Zaharia, Chenfeng Xu, Ion Stoica가 포함됩니다.

영상 하이라이트:

• 대규모 MoE 모델을 CPU와 GPU 리소스에 분산할 수 있습니다.
• 프리필은 전송, 연산, 체크포인팅을 겹쳐 실행합니다.
• 디코드는 캐시 미스가 발생하면 전문가 로딩 방식을 조정합니다.
• 보고된 테스트는 8GB 노트북부터 96GB 워크스테이션까지 포함합니다.
• 에이전트 워크로드는 더 빠른 디코딩과 짧아진 응답 시작 지연의 이점을 얻습니다.

FreeToken은 추론을 프리필과 디코드라는 두 가지 중요한 단계로 나눕니다. 프리필은 입력 컨텍스트를 처리하고, 디코드는 한 번에 하나씩 새로운 토큰을 생성합니다. 두 단계는 성능상의 압박 요소가 서로 다르므로, 양쪽에 하나의 고정된 스케줄링 정책만 사용하면 하드웨어가 충분히 활용되지 않을 수 있습니다.

프리필 중 시스템은 전체 레이어 더블 버퍼링을 사용합니다. 모델의 한 부분을 계산하는 동안 다른 부분을 전송하거나 준비할 수 있습니다. 전문가 가중치를 GPU 메모리에 영구적으로 상주시키기 어려운 경우 이러한 구성이 특히 중요합니다.

시스템은 특수한 토큰 앵커에 상태 체크포인트도 유지합니다. 에이전트 워크플로에서는 사용자나 도구가 대화의 일부를 편집할 수 있습니다. 편집할 때마다 전체 프롬프트 상태를 다시 구축하는 대신, 체크포인트를 활용하면 재사용 가능한 연산을 보존하고 반복적인 프리필 작업을 줄일 수 있습니다.

디코드 단계에서는 다른 전략을 사용합니다. 활성 캐시에 전문가가 없을 때 FreeToken은 인터커넥트를 통해 해당 전문가를 로드하는 작업과 CPU에서 수행하는 인플레이스 연산 사이의 균형을 맞출 수 있습니다. 한쪽이 유용한 작업을 계속할 수 있는 상황에서 다른 쪽이 유휴 상태가 되지 않도록 정책이 설계되었습니다.

이 구분은 MoE 모델이 모든 토큰에 대해 모든 전문가를 활성화하지 않기 때문에 중요합니다. 시스템은 어떤 전문가가 필요한지 식별하고, 해당 전문가가 어디에서 사용 가능한지 확인한 다음, 작업을 이동하는 것과 로컬에서 처리하는 것 중 어느 쪽이 더 효율적인지 선택해야 합니다.

FreeToken은 하나의 이상적인 시스템이 아니라 다양한 로컬 구성에서 평가되었습니다. 보고된 테스트 범위는 8GB 노트북부터 96GB 워크스테이션까지 이어집니다. 이러한 시스템은 호스트 메모리 대역폭과 인터커넥트 성능에서 큰 차이를 보이므로 적응형 스케줄링이 중요합니다.

한 소형 노트북 구성에서는 인터커넥트 대역폭이 초당 12GB 미만이었습니다. 반대편의 가장 강력한 워크스테이션 구성은 CPU 메모리 대역폭이 초당 178GB에 도달했습니다. 이러한 차이는 전문가를 GPU로 이동할지, CPU에서 처리할지, 아니면 나중에 사용하기 위해 캐시에 유지할지에 영향을 줍니다.

보고된 결과는 워크로드와 하드웨어에 따라 달라집니다. 한 노트북 구성에서 FreeToken은 7530억 파라미터 모델을 서빙하면서 초당 40토큰에 근접했습니다. 워크스테이션에서는 동일한 범주의 테스트에서 해당 모델에 대해 초당 약 15토큰에 도달했으며, 비교 서빙 엔진보다 처리량이 약 2배인 것으로 보고되었습니다.

RTX 5090 데스크톱에서는 보고된 테스트에서 코딩 에이전트 워크로드가 초당 76토큰을 초과했습니다. 대규모 모델을 사용하는 또 다른 워크로드는 초당 22토큰을 초과했고, 별도의 모델은 초당 80토큰을 넘겼습니다. 이러한 수치는 모든 장치에 적용되는 보편적인 보장이 아니라 특정 구성, 모델 변형 및 워크로드에 연결된 벤치마크 관찰 결과로 해석해야 합니다.

캐싱은 FreeToken의 가장 중요한 성능 메커니즘 중 하나입니다. MoE 추론은 선택된 전문가를 활성화하므로, 효율적인 캐시는 반복적인 전송을 방지할 수 있습니다. 배치 정책이 좋지 않으면 캐시 미스가 증가하여 시스템이 불편한 시점에 데이터를 이동하거나 다시 계산해야 합니다.

보고된 평가에서는 가장 최근에 사용된 항목을 우선 제거하는(LRU) 캐시 정책을 정적 배치 및 프리필 기반 배치 전략과 비교했습니다. FreeToken의 LRU 정책은 테스트된 모델 전반에서 전문가 캐시 미스를 크게 줄였습니다. 이 접근 방식은 변화하는 워크로드에 직관적으로 대응합니다. 최근 사용된 전문가는 가까운 디코딩 단계에서도 유용할 가능성이 높지만, 워크로드의 동작은 달라질 수 있습니다.

긴 프롬프트의 경우, 테스트 구성에서 16,000토큰 컨텍스트의 프리필 처리량이 초당 6,600토큰을 넘어선 것으로 보고되었습니다. 더블 버퍼링 파이프라인은 비파이프라인 실행 및 기준 시스템과 비교되었으며, 보고된 측정 결과에서 중첩 실행 설계가 더 높은 처리량을 보였습니다.

실용적인 튜닝 순서는 시스템 아키텍처를 따릅니다.

• 고정된 배치를 선택하기 전에 호스트 메모리 대역폭과 인터커넥트 동작을 측정합니다.
• 프리필과 디코드의 병목이 다르므로 두 분석을 분리합니다.
• 전체 모델 크기만으로 성능을 판단하지 말고 전문가 캐시 미스를 관찰합니다.
• 프롬프트를 반복적으로 편집하는 에이전트 워크플로에서는 재사용 가능한 상태를 보존합니다.
• 실제 워크로드에서 CPU 측 실행 비용과 전송 비용을 비교합니다.

FreeToken은 엣지 네이티브 모델 서빙에 관심이 있는 연구자, 인프라 엔지니어 및 고급 로컬 추론 사용자에게 가장 관련성이 높습니다. 보고된 에이전트 워크로드에는 코딩 중심 작업이 포함되어 있으며, 이러한 작업에서는 첫 토큰까지의 시간과 지속적인 디코드 속도가 모두 사용성에 영향을 줍니다.

이 시스템은 또한 초대형 MoE 모델을 서빙하는 것이 단순히 메모리 용량만의 문제가 아니라고 강조합니다. 메모리는 여전히 중요하지만, 저장 위치 사이의 데이터 경로, 호스트 연산 속도, 캐시 동작 및 스케줄링 결정에 따라 사용 가능한 하드웨어가 얼마나 효율적으로 활용되는지가 결정될 수 있습니다.

강조된 RTX 5090 에이전트 테스트에서 보고된 첫 토큰까지의 시간은 수 초 이내로 유지되었지만, 비교 시스템은 때때로 훨씬 더 긴 시간이 필요했거나 성공적으로 완료되지 못했습니다. 이 지표는 디코드 처리량과는 다릅니다. 시스템이 느린 시작 후 빠르게 토큰을 생성할 수도 있고, 빠르게 시작한 뒤 더 낮은 출력 속도를 유지할 수도 있습니다.

FreeToken이 적합한 하드웨어, 모델 지원 또는 신중한 평가의 필요성을 없애 주는 것은 아닙니다. 성능은 메모리 용량, 대역폭, 인터커넥트 속도, 모델 구조, 프롬프트 길이 및 서빙 워크로드의 동작에 따라 달라집니다. 공개된 자료 역시 보편적인 호환성 목록이 아니라 연구 평가를 설명합니다.

기술 독자에게 기본 참고 자료는 FreeToken arXiv 논문이며, 분산·병렬·클러스터 컴퓨팅 분야의 arXiv:2608.16157로 등재되어 있습니다. 2026년 8월에 발표된 이 논문은 구현 세부 사항, 실험 방법론 및 저자들이 사용하는 공식 용어를 확인하기 위한 적절한 출발점입니다.