FreeToken 논문: MoE 서빙 비교 및 설정 가이드

FreeToken 논문은 모델 가중치가 사용 가능한 GPU 메모리를 초과할 때 대규모 혼합 전문가 모델을 서빙하기 위한 엣지 지향 접근 방식을 제시합니다. 정식 제목은 FreeToken: Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Execution입니다. 이 논문은 2026년 8월 17일 arXiv에 제출되었으며, Song Han, Matei Zaharia, Ion Stoica를 포함한 연구자들이 저자로 기재되어 있습니다.

FreeToken은 추론을 단순한 GPU 전용 작업으로 취급하는 대신, GPU 메모리, 시스템 메모리 및 프로세서 사이에서 전문가 가중치가 이동하고 배치되는 방식에 초점을 맞춥니다. 이 구분이 중요한 이유는 희소 연산이 자동으로 희소 메모리 요구량을 의미하지 않기 때문입니다. 모델은 각 토큰에 대해 소수의 전문가만 활성화할 수 있지만, 전체 전문가 풀에 계속 접근할 수 있어야 합니다.

논문 프로필:

영상 하이라이트:

• 적절한 메모리 전략을 사용하면 매우 큰 MoE 모델도 단일 워크스테이션에서 실행할 수 있는 이유를 설명합니다.
• FreeToken의 라우팅 인식 배치 방식과 고정 레이어 기반 전문가 분할을 비교합니다.
• 보고된 처리량, 꼬리 지연시간, 하드웨어 지원 및 독립 벤치마크의 한계를 다룹니다.

핵심 연구 질문은 간단합니다. 다음 토큰이 현재 GPU에 상주하지 않는 전문가를 요청할 때 추론 엔진은 어떻게 동작해야 할까요? 정적 배치 정책은 예측 가능하지만, 실제로 어떤 전문가가 필요한지를 결정하는 런타임 라우팅 동작을 반영하지 못할 수 있습니다. FreeToken의 설계는 이러한 변화하는 접근 패턴에 맞춰 실행을 조정하려고 합니다.

공식 참고 자료는 arXiv의 FreeToken 논문에서 확인할 수 있습니다.

혼합 전문가 모델은 일반적으로 전문가라고 부르는 여러 특화 피드포워드 모듈로 구성됩니다. 라우터는 각 토큰에 대해 제한된 수의 전문가를 선택합니다. 이로 인해 희소 연산이 발생합니다. 즉, 특정 토큰에 대해서는 네트워크의 일부만 산술 연산을 수행합니다. 그러나 라우터가 다음 토큰에서 다른 전문가를 선택할 수 있으므로 전체 파라미터 집합에는 계속 접근할 수 있어야 합니다.

FreeToken은 이러한 변화하는 수요를 시스템 문제로 다룹니다. 엔진은 전문가를 GPU에 계속 유지할지, 시스템 메모리에 둘지, 아니면 저장된 위치에 더 가까운 곳에서 처리할지를 결정할 수 있습니다. 목표는 런타임 라우팅을 따라갈 수 있는 충분한 유연성을 유지하면서 하드웨어 버스를 통한 비용 높은 전송을 줄이는 것입니다.

공개된 기술 논의에서 설명된 기준 비교는 고정 레이어 기반 정책을 대조군으로 사용합니다. 이 모델에서 운영자는 초기 레이어 중 몇 개의 MoE 가중치를 프로세서에 둘지 미리 선택합니다. 이 분할은 추론이 시작되기 전에 설정되며 토큰 라우팅이 바뀌어도 변경되지 않습니다.

반면 FreeToken은 라우팅 인식 동작을 강조합니다. 보고된 실험에서는 배치 정책만 변경하고 동일한 캐시 크기에서 동일한 라우팅 추적을 재생했습니다. 논의에 따르면 RTX 5090과 연관된 메모리 구성에서 FreeToken의 전문가 읽기 캐시 미스율은 **16%**였으며, 비교 대상인 정적 분할은 **62%**였습니다. 이 수치는 모든 모델이나 장치에 적용되는 보편적 결과가 아니라 인용된 테스트 조건을 설명합니다.

실질적인 핵심은 캐시 미스가 사소한 기록 관리 이벤트가 아니라는 점입니다. 각각의 미스는 가중치 전송이나 실행 위치 변경을 필요로 할 수 있습니다. 자기회귀 생성 중 이런 일이 반복되면 처리량 저하로 이어지며, 더 중요하게는 개별 턴에서 긴 대기 시간이 발생합니다.

공개된 벤치마크 논의는 일반적인 GPU 전용 로딩으로는 감당하기 어려운 MoE 모델을 실행하는 최신 Nvidia 시스템에서 FreeToken이 특히 유용하다고 설명합니다. 보고된 결과에는 RTX 5090에서 실행한 Qwen 35B, 유사한 하드웨어에서 실행한 DeepSeek V4 Flash, 워크스테이션급 카드에서 실행한 GLM이 포함됩니다.

아래 수치는 공개된 논의에서 보고된 측정값을 옮긴 것입니다. 더 광범위한 제3자 재현이 이루어지기 전까지는 연구 결과로 받아들여야 합니다.

처리량은 유용한 지표지만 대화형 에이전트의 전체 상황을 보여주지는 않습니다. 평균 생성 속도가 높더라도 간헐적으로 몇 분씩 멈추는 시스템은 응답 시간이 예측 가능한 더 느린 엔진보다 유용성이 떨어질 수 있습니다.

따라서 보고된 최악의 턴 비교가 중요합니다. 인용된 시나리오에서 FreeToken의 가장 느린 단일 턴은 44초 미만으로 유지된 반면, 논의에서는 llama.cpp가 232초, 다른 구현이 179초, KTransformers가 946초에 이른 것으로 제시됩니다. 이는 특정 작업 부하에서의 결과이며 일반적인 보장이 아닙니다.

또 다른 비교 문제는 분모와 관련이 있습니다. 논의에서는 FreeToken의 디코드 수치를 초당 33토큰인 클라우드 에이전트 추적값과 비교하지만, 해당 추적 측정에는 첫 토큰까지의 시간과 중간 추론이 포함된 것으로 알려져 있습니다. 순수 디코드 중앙값과 동일한 기준으로 비교하면 헤드라인 차트가 암시하는 것보다 우위가 작아집니다. 그렇다고 벤치마크가 무효가 되는 것은 아닙니다. 측정 정의가 일치하는지 비교해야 한다는 의미입니다.

FreeToken의 가장 강력한 사용 사례는 좁지만 분명합니다. 최신 Nvidia GPU와 충분한 시스템 메모리를 보유하고 대규모 MoE 모델을 중심으로 작업하는 사용자는 라우팅 인식 서빙의 이점을 얻을 수 있습니다. 정적 배치로 인해 전문가 전송이 자주 발생하거나 긴 멈춤 때문에 에이전트 감시자가 작업을 종료하는 경우 그 장점이 더욱 뚜렷해집니다.

이러한 사용자 프로필은 일반적인 로컬 AI 사용자와는 다릅니다. 공개된 자료에 요약된 프로젝트 정보에 따르면 지원 환경은 Nvidia CUDA와 POSIX Linux이며, 패키징은 베타 수준입니다. 구형 Nvidia 카드, 듀얼 GPU Docker 지원, GGUF, Windows 수정 사항 및 Apple Silicon 지원에 대한 요청은 2026년 8월 출시 기간에도 여전히 확인되었습니다.

FreeToken을 초당 최대 토큰 수만으로 평가해서는 안 됩니다. 설치 과정의 불편함, 모델 호환성, 메모리 용량, 운영체제 지원 및 안정성은 벤치마크 우위를 상쇄할 수 있습니다. 더 적은 시스템에서 실행되는 도구라도 특화된 연구 엔진으로서는 가치가 있을 수 있지만, 모든 로컬 배포 환경에 자동으로 가장 적합한 기본 선택이 되는 것은 아닙니다.

llama.cpp와의 비교는 이러한 상충 관계를 잘 보여줍니다. 기존 프로젝트는 더 폭넓은 백엔드와 플랫폼을 지원하는 것으로 설명되는 반면, FreeToken은 더 좁은 하드웨어 프로필을 대상으로 새로운 실행 정책에 집중합니다. 따라서 두 도구는 서로 다른 우선순위를 충족하는 것으로 보는 것이 적절합니다. 한쪽은 이식성과 성숙도에, 다른 한쪽은 특화된 MoE 효율성에 초점을 맞춥니다.

신뢰할 수 있는 비교를 위해서는 두 엔진을 실행하고 가장 빠른 수치를 읽는 것만으로 부족합니다. 동일한 모델 파일, 양자화 방식, 프롬프트 세트, 컨텍스트 길이, 생성 설정 및 하드웨어 조건을 사용하세요. 평균 처리량과 의미 있는 최악의 턴을 모두 기록해야 합니다.

재현성을 위해 정확한 명령줄 옵션, 커밋 또는 릴리스 식별자, 모델 체크섬 및 테스트 날짜를 공개하세요. 공개 프로젝트는 2026년 8월 기준으로 역사가 짧은 것으로 설명되었으므로 커널, 지원 형식 및 배치 정책이 발전함에 따라 결과가 빠르게 달라질 수 있습니다.

FreeToken의 연구 방향이 중요한 이유는 전문가 이동을 추론에서 핵심적으로 다뤄야 하는 문제로 보기 때문입니다. 그러나 현재 이용 가능한 증거는 모든 사용자를 위한 보편적인 대체재라는 주장보다는 신중한 결론을 뒷받침합니다. 프로젝트는 초기 단계였고 플랫폼 지원 범위는 제한적이며, 벤치마크 세트에는 더 폭넓은 독립 검증이 필요했습니다.

이 논문은 더 큰 생태계 차원의 질문도 제기합니다. 라우팅 인식 전문가 캐싱이 유용하다는 사실이 입증된다면, 성숙한 추론 엔진도 결국 유사한 메커니즘을 도입할 수 있습니다. 그렇게 되면 FreeToken의 장기적인 기여는 독립 런타임으로서의 지속적인 우위보다는 실행 정책에 있을 수 있습니다.