FreeToken: 프론티어급 MoE 모델을 게이밍 데스크톱 수준에서 서빙하기 위한 Edge-Serving에 대한 연구

9bow · 8월 25, 2026, 3:30오전

FreeToken 소개

가중치는 공개되었지만, 돌릴 수 있는 사람은 따로 있습니다

새로 나온 오픈 모델의 가중치를 받아 두기만 하고, 그 파일을 읽어 들일 GPU가 없어서 결국 API를 다시 열어 본 경험이 있으실 겁니다. 이번에 소개할 FreeToken 논문은 바로 이 지점을 다룹니다. 개인이 이미 가진 컴퓨터 한 대를 "작은 GPU"가 아니라 GPU와 CPU, 호스트 메모리, 인터커넥트를 통합한 하나의 탄력적인 추론(inference) 플랫폼으로 다루어, 프론티어급 전문가 혼합(Mixture-of-Experts, MoE) 모델을 로컬에서 서빙하는 시스템을 제안합니다. 저자는 11명입니다. Shuo Yang과 Xiaoze Fan이 공동 제1저자이고, Chenfeng Xu와 Ion Stoica가 공동 지도를 맡았으며, Kurt Keutzer와 Song Han, Matei Zaharia도 저자로 참여했습니다. 교신 저자는 Shuo Yang(berkeley.edu)과 Chenfeng Xu(utexas.edu)입니다.

최근 공개된 오픈 웨이트 모델은 최상위 상용 모델과의 성능 격차를 빠르게 좁히고 있습니다. Kimi-K3, GLM-5.2, DeepSeek-V4-Flash-0731 같은 모델이 여기에 해당합니다. 그런데 파라미터를 공개하는 일은 누가 모델을 얻을 수 있는지만 결정하고, 누가 그 모델을 돌릴 여력이 있는지는 결정하지 않습니다. 프론티어 오픈 모델은 여전히 수백만 달러짜리 데이터센터급 GPU 클러스터를 요구하고, 호스팅 API가 상용 모델보다 싸더라도 꾸준히 쓰면 비용이 만만치 않습니다. 에이전트(agent) 형태의 애플리케이션이 추론 수요를 급격히 끌어올리면서 이 비용은 개인과 소규모 팀에게 특히 부담이 됩니다. 연구팀은 이 상황을 이렇게 정리합니다. "오픈 모델과 상용 모델 사이의 성능 격차는, 프론티어 모델을 얻을 수 있는 쪽과 그것을 대규모로 쓸 수 있는 쪽 사이의 접근성 격차보다 훨씬 빠르게 좁혀지고 있습니다."

한눈에는 하드웨어 문제처럼 보입니다. 하지만 이미 1억 대가 넘는 소비자용 컴퓨터에 외장 GPU가 들어가 있습니다. 게이밍 데스크톱, 워크스테이션, 고성능 노트북이 여기에 포함됩니다. Steam만 해도 월간 활성 사용자가 2억 명을 넘고, 조사 대상 시스템의 약 72\% 에 NVIDIA 외장 GPU가 달려 있습니다. 논문이 지목하는 빈 자리는 하드웨어 자체가 아니라, 제각기 다른 소비자용 기기를 하나의 통합 추론 플랫폼으로 다루면서 그 기기의 GPU와 CPU, 메모리, 인터커넥트를 가장 강력한 모델 구성에 자동으로 대응시켜 주는 서빙 시스템입니다.

MoE는 기회이면서 동시에 난제입니다

MoE 아키텍처는 이 문제에 새로운 길을 열어 줍니다. MoE 계층은 수백 개의 전문가(expert)를 저장하지만 각 토큰은 그중 극히 일부만 거칩니다. 계층이 E 개의 전문가를 두고 토큰마다 k \ll E 개만 라우팅하므로, 한 번의 디코딩 단계가 건드리는 가중치는 계층 전체 파라미터의 작은 조각입니다. DeepSeek-V4-Flash 를 예로 들어보겠습니다. 이 모델은 43개 계층마다 256개의 라우팅 전문가 중 6개를 활성화하므로, 284B 파라미터 가운데 어느 한 토큰에 참여하는 것은 13B뿐입니다. 배포 정밀도에서 이 활성 파라미터 용량은 RTX 5090의 32GB 메모리에 들어갑니다.

문제는 희소성이 토큰당 연산량은 줄여 주지만 전문가 풀 전체를 담는 데 필요한 메모리는 그만큼 줄여 주지 않는다는 점입니다. 모델 전체는 여전히 GPU 메모리를 크게 초과할 수 있고, 그러면 비활성 전문가는 호스트 메모리나 보조 저장 장치에 머물다가 필요할 때 실행 경로로 들어와야 합니다. 희소 활성화는 연산을 가능하게 만들지만, 전문가 풀 전체는 효율적인 서빙을 어렵게 만듭니다.

기존 엣지 서빙 엔진이 놓치는 지점

강력한 오픈 웨이트 모델을 개인 하드웨어로 가져오려는 시도는 이미 여러 갈래로 진행되고 있습니다. llama.cpp, Ollama, KTransformers 같은 엔진이 대표적입니다. 논문은 이들이 엣지 MoE 서빙 문제의 일부만 다루고 있으며, 3가지 지점에서 하드웨어의 이론적 성능에 도달하지 못한다고 지적합니다.

첫 번째는 prefill, 즉 입력 처리 단계가 MoE의 희소성을 사실상 무너뜨린다는 점입니다. 토큰 하나는 전문가 몇 개만 활성화하지만, 긴 프롬프트 전체의 라우팅 경로를 합집합으로 모으면 계층마다 거의 모든 전문가를 덮습니다. 작업 집합이 실질적으로 밀집(dense) 상태가 됩니다. VRAM을 초과하는 전문가는 호스트 메모리에서 반복적으로 스트리밍되어야 하므로 연산과 메모리 이동이 동시에 부담이 됩니다. 컨텍스트가 길고 계속 자라면서 prefill을 자주 유발하는 에이전트형 도구 호출(tool call) 작업에서 이 문제가 특히 심각한데, 기존 엣지 서빙 시스템은 전문가 이동을 숨기거나 턴 사이의 상태를 재사용하는 장치를 거의 제공하지 않습니다.

두 번째는 decode, 즉 토큰 생성 단계가 정반대 양상을 보인다는 점입니다. 각 토큰은 전문가의 희소한 부분집합만 활성화하지만, 캐시 미스가 발생하면 전문가를 반복해서 적재하거나 축출하거나 호스트 메모리에서 실행해야 합니다. 기존 시스템에는 이 미스를 어떻게 처리할지에 대한 원칙이 없습니다. 정적 배치는 토큰 단위로 바뀌는 라우팅을 따라가지 못하고, 예측과 프리페치는 미스율을 낮출 수는 있어도 피할 수 없는 미스를 PCIe 전송과 GPU 실행, CPU 직접 실행 사이에 어떻게 나눌지는 정해 주지 않습니다.

세 번째는 엣지 자원의 다양성과 변동성이 앞의 두 문제를 증폭시킨다는 점입니다. 데이터센터 배포와 달리 소비자용 하드웨어는 GPU 용량, PCIe 대역폭, 호스트 메모리 대역폭, CPU 성능, 사용 가능한 VRAM이 기기마다 크게 다릅니다. 게다가 이 자원은 모델 서빙에만 쓰이지도 않습니다. 사용자는 브라우저와 게임을 동시에 실행하고, 그에 따라 쓸 수 있는 메모리와 연산 예산이 시간에 따라 변합니다. 따라서 단일한 정적 배치나 스케줄링 정책은 기기와 작업 단계, 변하는 런타임(runtime) 조건 전반에서 좋은 성능을 낼 수 없습니다.

이 연구의 발상 전환

FreeToken은 2가지 실행 원칙과 1가지 탄력적 자원 관리 정책 위에 세워집니다.

대역폭 적응 실행(Bandwidth-Adaptive Execution) 은 제한된 엣지 대역폭을 고정된 병목이 아니라 런타임 스케줄링 신호로 바꿉니다. prefill에서는 전문가 이동과 연산을 이중 버퍼링(double buffering)으로 겹쳐, GPU가 현재 계층을 계산하는 동안 다음 계층의 전문가가 PCIe로 흘러 들어오게 합니다. decode는 더 세밀한 배분이 필요합니다. PCIe 전송과 CPU 직접 실행이 같은 호스트 메모리 대역폭을 끌어다 쓰기 때문입니다. FreeToken은 각 단계의 캐시 미스를 GPU 캐시 채우기와 CPU 직접 실행으로 나누는 q^{\star} 정책을 적용해, 배포된 기기가 실제로 감당할 수 있는 대역폭에 맞춥니다.

의미 인식 캐싱(Semantic-Aware Caching) 은 희소한 메모리에 무엇을 남길지 결정합니다. 에이전트 하네스는 사고 구간이나 도구 호출처럼 의미적 경계에서 컨텍스트를 편집합니다. FreeToken은 prefill 중 이 경계에 순환 상태(recurrent state) 체크포인트를 고정해 두어, 편집이 일어난 뒤에도 새로 생긴 접미부만 다시 계산하게 합니다. decode에서는 인접한 토큰이 겹치는 전문가로 라우팅되는 경향을 공유 LRU(Least Recently Used) 전문가 캐시로 포착해, 대부분의 라우팅 접근이 VRAM에서 적중하도록 하고 남은 미스만 q^{\star} 정책에 넘깁니다.

탄력적 엣지 자원 관리 는 개인 하드웨어의 변하는 메모리 조건에 맞춰 줍니다. 스케줄러의 안전 지점에서 FreeToken은 엔진을 재시작하거나 호스트에 상주하는 전문가 풀을 다시 적재하지 않고도 GPU 전문가 캐시의 크기를 조정하고 재구성합니다.

연구팀에 따르면 FreeToken은 20종이 넘는 MoE 모델과 실제 코딩 및 도구 사용 에이전트를 8GB 노트북 GPU부터 워크스테이션 GPU까지 지원합니다.

위 그림은 이 시스템이 실제로 무엇을 바꾸는지 보여줍니다. 왼쪽 그래프는 대표적인 호스팅 모델을 가로축에 혼합 API 정가(입력과 출력을 9:1로 섞은 값), 세로축에 Code Arena Elo의 WebDev 부문 점수로 놓은 것입니다. 파란 사각형이 FreeToken이 서빙하는 모델이고, DeepSeek-V4-Flash부터 GLM-5.2까지 이어지는 프론티어 구간이 정확히 이 집합입니다. Kimi-K3는 오픈 가중치를 공개했지만 594GB로 소비자용 메모리를 초과해 여기에 들어오지 못합니다. 그래프에 Qwen3.5-35B가 올라와 있는 것은 후속 모델인 Qwen3.6-35B의 아레나 점수가 아직 집계되지 않아 대신 표시한 것입니다.

오른쪽 그래프는 하드웨어 등급마다 그 기기가 담을 수 있는 가장 강한 모델의 에이전트 작업 decode 처리량입니다. 앞의 두 등급은 코딩 에이전트, 세 번째 등급은 수리 에이전트 작업입니다. 8GB RTX 4060 노트북은 Qwen3.6-35B를 39.3 tok/s로 서빙해, 프로덕션 트레이스에서 측정된 Codex의 중앙 decode 속도 33 tok/s를 넘어섭니다. 32GB RTX 5090 데스크톱에서는 284B 규모의 DeepSeek-V4-Flash가 21.5 tok/s를 기록했는데, 같은 기기에서 llama.cpp는 14.7 tok/s, KTransformers는 10.2 tok/s이고 Ollama는 이 모델을 아예 서빙하지 못합니다.

엣지 MoE 서빙의 3가지 난관

FreeToken의 설계를 이해하려면 논문이 정량화한 병목을 먼저 볼 필요가 있습니다. 아래 3개 항목은 각각 뒤에 나오는 설계 절과 순서대로 대응합니다.

prefill: 전문가 전송과 재계산 비용

prefill은 모든 에이전트 턴의 첫 토큰 지연 시간(Time-To-First-Token, TTFT)을 결정합니다. 엣지 하드웨어에서 prefill 시간은 크게 2가지로 나뉩니다. 하나는 활성화 경로가 아니라 모델 전체 크기에 비례하는 전문가 전송이고, 다른 하나는 에이전트 세션이 기존 시스템이 감당할 수 있는 것보다 훨씬 자주 유발하는 컨텍스트 재계산입니다.

전문가 전송은 매번의 prefill에 수 초를 얹습니다. decode는 토큰마다 k 개의 전문가만 거치지만, prefill은 계층마다 수천 개의 토큰을 처리하므로 라우팅된 토큰들이 거의 전체 전문가 집합을 활성화합니다. 결국 한 번의 prefill이 전문가 풀 거의 전부를 CPU와 GPU 사이 인터커넥트로 흘려보냅니다. DeepSeek-V4-Flash의 FP4 배포를 예로 들어보겠습니다. 약 140GB의 전문가 가중치를 옮겨야 하고, PCIe 5.0 x16(약 60GB/s)을 쓰는 RTX 5090 시스템에서 약 2초, PCIe 4.0 x16(약 25GB/s)을 쓰는 RTX 4090과 3090급 데스크톱에서 약 5초, 노트북에 흔한 x8 링크에서는 10초 이상이 추가됩니다. 필요할 때 전문가를 가져오는 엔진은 이 시간 전체를 GPU 유휴 시간으로 노출합니다.

에이전트의 도구 호출은 prefill을 자주 다시 유발합니다. 두 번째 비용은 모델이 이미 한 일을 되풀이하는 연산입니다. 많은 프론티어 모델이 전체 어텐션과 슬라이딩 윈도우 어텐션(sliding-window attention)을 번갈아 배치하는 하이브리드 어텐션 구조를 채택하거나, 순환 계층을 함께 씁니다. DeepSeek-V4-Flash와 GPT-OSS가 앞쪽에, Qwen3.6-35B-A3B의 gated DeltaNet과 Kimi-K3 의 Kimi Delta Attention이 뒤쪽에 해당합니다. 이런 계층은 표준 어텐션과 달리 과거 컨텍스트를 하나의 상태나 최근 구간의 KV 항목으로 압축합니다. 저장된 상태 하나가 수백 토큰 분량의 KV 캐시만큼 메모리를 차지하므로, 서빙 엔진은 체크포인트를 소수만 유지합니다.

그런데 에이전트 작업은 거의 매 턴 컨텍스트를 수정합니다. 도구 호출이 오래된 출력을 제거하고 사고 구간을 삭제하는 식입니다. 수정된 위치 이후에 잡힌 체크포인트는 모두 무효가 되므로, 엔진은 변경 지점 이전의 마지막 유효 체크포인트로 되돌아가야 합니다. 체크포인트가 희소하기 때문에 엔진은 수천 토큰을 다시 prefill하는 일이 잦습니다. 소비자용 GPU는 이 반복 비용을 숨길 여력이 없습니다. RTX 5090의 밀집 BF16 처리량은 H100의 약 5분의 1, B200의 약 10분의 1 수준이어서, 긴 컨텍스트를 한 번 다시 prefill할 때마다 GPU가 수십 초 동안 붙잡힙니다.

decode: 캐시 미스와 CPU 대역폭의 한계

decode 지연 시간은 각 단계의 전문가 미스를 어떻게 처리하는지가 결정합니다. 논문은 기존 엔진의 성능 저하를 하드웨어 특성 2가지와 정책의 결과 1가지로 귀속시킵니다.

정적 전문가 배치는 라우팅 트래픽을 놓칩니다. 기존 하이브리드 엔진은 전문가 배치를 적재 시점이나 prefill 시점에 고정합니다. llama.cpp는 모델을 적재할 때 MoE 텐서를 장치에 배정하고, KTransformers는 "뜨거운" 전문가 부분집합을 GPU 메모리에 고정한 뒤 나머지를 CPU에서 실행합니다. 하지만 라우팅은 토큰마다, 작업마다 바뀝니다. prefill 시점에 얼어붙은 배치는 라우팅 트래픽의 작은 일부만 포착하고, 그 결과 대다수 전문가 평가가 CPU로 떨어지면서 GPU와 PCIe 링크가 함께 유휴 상태가 됩니다.

소비자용 CPU는 decode를 혼자 감당하지 못합니다. 작은 decode 배치에서 전문가 실행은 메모리 바운드이며, 토큰마다 라우팅된 전문가 가중치를 한 번씩 읽어 옵니다. 소비자용 플랫폼은 CPU에 DRAM 채널 2개를 연결합니다. 듀얼 채널 DDR4가 최대 약 50GB/s, DDR5가 약 80GB/s에서 90GB/s를 제공하는데, RTX 4090이나 5090 한 장이 온패키지 메모리에서 끌어오는 1TB/s에서 1.8TB/s와 비교하면 격차가 큽니다. 이 대역폭 차이 때문에 CPU 전용 전문가 경로는 코어 수와 무관하게 같은 가중치를 VRAM에서 읽을 때의 일부 속도밖에 내지 못합니다.

작업을 나누는 올바른 비율은 하드웨어마다 다릅니다. 미스된 전문가는 PCIe로 전송해 GPU에서 실행할 수도 있고, 가중치가 놓인 CPU에서 실행할 수도 있습니다. 어느 쪽도 보편적으로 낫지 않습니다. 전송만 쓰면 호스트 메모리가 링크보다 많은 바이트를 내보낼 수 있을 때 남는 호스트 대역폭과 CPU 코어가 유휴로 남습니다. 반대로 CPU 실행만 쓰면 PCIe 링크가 유휴가 되고, 캐시를 채워 두었다면 얻었을 미래의 적중을 포기하게 됩니다. LPDDR5를 쓰는 RTX 4060 노트북과 DDR5를 쓰는 RTX 5090 데스크톱은 호스트 대역폭과 PCIe 대역폭의 균형에서 정반대 지점에 있습니다. 이 최적 배합은 제품 사양서에서 읽어 낼 수 없으므로, 빠른 설계는 실제로 돌아가는 기기 위에서 이 분할을 정량적으로 정해야 합니다.

자원 관리: 엣지에서는 무엇도 전용이 아닙니다

데이터센터 환경에서는 GPU와 CPU 자원이 보통 서빙 작업에만 전용됩니다. 노트북과 개인용 컴퓨터 같은 엣지 기기에서는 LLM 서빙이 동시에 돌아가는 여러 애플리케이션 중 하나일 뿐이고, 그래서 서빙 엔진이 쓸 수 있는 자원이 매우 동적입니다.

VRAM 예산과 그 분할은 서빙 중에 자주 바뀝니다. 엣지 기기의 GPU는 데스크톱 컴포지터, 브라우저, 게임과 공유되며, 이들은 언제든 수 기가바이트의 VRAM을 요구할 수 있습니다. 서빙 엔진에 주어지는 예산은 실행마다 다르고 서빙 도중에도 줄거나 늘 수 있습니다. 그 예산의 최적 분할도 함께 움직입니다. 에이전트 세션은 턴을 거치며 컨텍스트를 쌓으므로 KV 캐시 수요는 늘어나는 반면 전문가 작업 집합은 거의 고정된 크기를 유지합니다. 첫 턴에 고른 분할은 여러 턴 뒤에는 틀린 값이 됩니다.

엔진 시작이 느린데, 시작하는 일이 자주 있습니다. 서빙 엔진을 띄우는 일은 자원을 많이 씁니다. 첫 요청 전에 전문가 풀 전체를 디스크에서 읽고 GPU를 워밍업해야 합니다. DeepSeek-V4-Flash의 FP4 배포에서는 약 140GB의 풀을 7GB/s NVMe 드라이브에서 읽어 오는 것만으로 약 20초가 걸리고, 워밍업은 그다음입니다. 엣지 기기에서는 이 비용이 반복됩니다. 사용자는 필요할 때 엔진을 열고, 기기를 비우려고 닫으며, 다른 모델로 바꾸면 엔진이 다시 시작됩니다.

FreeToken의 설계

FreeToken은 엣지 MoE 서빙을 전문가 메모리 2단 계층 위에 구성합니다. CPU에 상주하는 전문가 풀이 라우팅 전문가 가중치 전부를 담아 진실 공급원(source of truth) 역할을 하고, 전문가가 아닌 가중치는 GPU에 상주합니다. FreeToken은 남은 GPU 메모리를 모든 MoE 계층이 공유하는 하나의 탄력적 전문가 캐시로 바꿉니다. 각 슬롯은 하나의 계층과 전문가 짝을 평가하는 데 필요한 텐서를 모두 담으므로, 상주와 조회, 실행이 모두 텐서 샤드가 아니라 논리적인 (계층, 전문가) 식별자 단위로 동작합니다.

위 그림은 두 단계의 동작을 한 장에 담고 있습니다. 상단이 prefill이고 하단이 decode입니다. decode 예시에서는 라우터가 고른 12개 전문가 중 8개가 공유 LRU 캐시에서 적중하고, 남은 4개의 미스가 PCIe 전송 1개와 CPU 직접 실행 3개로 나뉩니다. 이 기기에서 프로파일링된 두 대역폭의 비가 B_{\mathrm{P}} : B_{\mathrm{H}} \approx 1 : 4 였으므로, 아래에서 유도할 q^{\star} = 4 \times \frac{1}{4} = 1 이 나온 것입니다.

prefill 공동 설계: 전층 이중 버퍼링과 의미 기반 상태 캐시

앞 절에서 prefill 비용을 대규모 전문가 전송과 불필요한 재계산 2가지로 나누었습니다. FreeToken은 각각에 전용 장치로 대응합니다.

전층 이중 버퍼링

prefill이 모든 계층의 전문가 집합을 거의 전부 활성화하므로, FreeToken은 prefill 전문가를 필요할 때 가져오지 않습니다. 대신 전역 슬롯 풀에서 전층 버퍼 2개를 확보합니다. GPU가 한 버퍼에서 계층 l 의 라우팅 전문가를 계산하는 동안, 전용 전송 스트림이 계층 l+1 의 전문가 집합 전체를 다른 버퍼에 적재합니다. 계층 전체를 적재하기 때문에 그 계층의 라우팅 결과를 알기 전에도 전송을 시작할 수 있습니다. 가중치 이동이 계층 사이에서 순차적으로 일어나지 않고 배경에서 끊임없이 진행됩니다. 두 버퍼는 그다음에 역할을 바꿉니다.

이 버퍼가 decode 캐시의 슬롯 풀을 공유한다는 점이 설계상 중요합니다. 별도의 prefill 캐시가 없고 단계 사이의 인계 과정도 없으므로, prefill에서 살아남은 항목이 지연에 민감한 decode 단계의 씨앗이 됩니다. 슬롯 풀이 전층 2개를 내줄 수 없을 때는 GPU 메모리를 초과 할당하지 않고 필요할 때 가져오는 prefill 적재로 되돌아갑니다.

의미 앵커가 컨텍스트 편집을 견딥니다

하이브리드 어텐션 모델은 KV 캐시 외에 두 번째 접두 문맥(prefix) 자원을 추가합니다. FreeToken은 전체 어텐션의 KV를 기존 서빙 시스템처럼 래딕스 트리(radix prefix tree)로 관리합니다. 그러나 순환 계층은 접두 문맥 전체를 하나의 변화하는 상태로 압축하므로 부분 재사용이 불가능하고, 이런 계층의 접두 문맥 재사용은 prefill과 decode 중에 잡아 둔 상태 체크포인트에 의존합니다. 그래서 FreeToken은 이 래딕스 트리의 노드에 붙은 소규모 순환 상태 체크포인트 풀, 즉 의미 인식 상태 캐시 를 유지합니다. 새 요청이 들어오면 프롬프트가 편집된 뒤에도 위치가 살아남은 가장 깊은 체크포인트에서 복원합니다.

체크포인트 하나가 해당 계층 전체의 순환 상태를 담기 때문에 소수만 보관할 수 있고, 그래서 그 배치가 가치를 좌우합니다. FreeToken은 이 예산을 의미 앵커(semantic anchor), 즉 사고 구간과 도구 호출 및 출력, 대화 턴을 표시하는 특수 토큰 경계에 씁니다. 여기가 바로 에이전트 프레임워크가 컨텍스트를 수정하고 잘라내는 위치입니다. OpenClaw는 가장 최근 턴을 제외한 모든 어시스턴트 턴에서 사고 블록을 제거하고, OpenCode는 최근 구간을 넘어선 도구 출력을 고정된 자리 표시자로 대체하며, SWE-agent는 마지막 n 개 관측을 제외한 나머지를 생략합니다.

이 모든 경우에서 편집은 특수 토큰으로 표시된 블록 단위로 이루어집니다. 하네스가 편집된 블록 앞의 접두 문맥을 정확히 보존하므로, 이 의미 경계에 잡아 둔 체크포인트는 임의의 위치에 놓인 것보다 잘림에서 살아남을 확률이 훨씬 높습니다. 에이전트 프레임워크가 도구 호출 뒤의 이력을 편집하면, 보존된 접두 문맥은 그런 경계에서 끝납니다. 그 자리에 앵커된 체크포인트가 있으면 전체 어텐션 계층은 편집 지점까지 KV 캐시를 재사용하고 순환 계층은 앵커에서 재개하므로, 진짜로 새로 생긴 접미부만 다시 prefill됩니다. 체크포인트 슬롯은 KV 풀과 독립적으로 LRU 축출로 재활용됩니다.

decode 공동 설계: 의미 인식 전문가 캐싱과 q star 정책

decode 중 각 MoE 계층에서 라우터와 캐시 조회는 GPU에서 수행되며, 캐시에 이미 상주하는 활성 전문가 집합 \mathcal{H} 를 식별합니다. 이들은 GPU에서 곧바로 실행됩니다. 남는 과제는 m 개의 서로 다른 미스 전문가 집합 \mathcal{M} 을 어떻게 처리할지입니다.

라우터를 따라 움직이는 LRU 캐시

decode 중 라우팅은 강한 시간적 전문가 지역성을 보입니다. 연속된 단계에서 같은 MoE 계층이 겹치는 전문가나 최근에 쓴 전문가로 반복해서 라우팅하는 것인데, 이 라우팅 일관성은 여러 모델 계열에서 측정된 성질입니다. FreeToken은 이 성질을 GPU 상주로 전환합니다. 적재 시점에 고른 작업 무관 배치로 전문가를 고정하는 대신, 라우터가 선택한 전문가를 계속 따라가는 공유 LRU 상주 공간을 유지합니다. 캐시 적중은 해당 전문가의 최근성을 갱신하고, 캐시 채우기는 새로 선택된 전문가를 받아들이며, 축출은 모델이 가장 오래 요구하지 않은 전문가를 내보냅니다. 희소한 GPU 메모리가 현재 생성의 작업 집합을 따라가게 됩니다.

캐싱만으로 미스를 없앨 수는 없습니다. 콜드 스타트, 작업 집합의 급격한 이동, 제한된 용량 때문에 선택된 전문가 일부는 여전히 GPU 밖에 남습니다. 대역폭 적응 실행이 이 잔여 미스를 처리하며, 어떤 전문가를 캐시로 가져오고 어떤 전문가를 CPU에서 제자리 실행할지 결정합니다.

측정된 대역폭이 분할을 결정합니다

FreeToken의 대역폭 적응 실행은 측정된 2가지 대역폭의 균형을 바탕으로 m 개의 미스 전문가를 PCIe 전송과 CPU 실행으로 동적으로 나눕니다. 하나는 고정 메모리 기반 전문가 전송 대역폭 B_{\mathrm{P}} 이고, 다른 하나는 호스트 측 전문가 처리 대역폭 B_{\mathrm{H}} 입니다. 미스 집합은 캐시 채우기 집합 \mathcal{F} 와 CPU 실행 집합 \mathcal{C} 로 서로 겹치지 않게 나뉘고, 채우기 개수를 q = |\mathcal{F}| 로 둡니다.

\mathcal{F} 의 전문가는 캐시 슬롯으로 전송되어 GPU에서 실행되고 이후 재사용을 위해 상주합니다. \mathcal{C} 의 전문가는 CPU에 상주하는 전문가 풀에서 직접 실행되며 상주 상태를 바꾸지 않습니다. 두 집합은 동시에 처리됩니다. 캐시 채우기는 PCIe 최대 속도로 진행되고, CPU는 포화된 링크가 남긴 호스트 대역폭만 소비합니다.

최적 분할 비율은 잔여 대역폭 논증에서 유도됩니다. 전문가 하나의 크기를 바이트 단위로 S 라고 하겠습니다. 전문가 DMA 전송과 CPU 실행이 같은 호스트 메모리 서브시스템에서 읽어 오므로, 포화된 PCIe 전송은 다음과 같은 잔여 대역폭을 남깁니다.

B_{\mathrm{R}} = \max(B_{\mathrm{H}} - B_{\mathrm{P}},\, 0)

이 잔여 대역폭이 동시 CPU 전문가 실행에 쓸 수 있는 양입니다. 따라서 두 분기의 실행 시간은 아래와 같이 정리됩니다.

T_{\mathrm{fill}}(q) \approx \frac{qS}{B_{\mathrm{P}}}, \qquad T_{\mathrm{cpu}}(m-q) \approx \frac{(m-q)S}{B_{\mathrm{H}} - B_{\mathrm{P}}}

동시에 진행되는 두 분기를 균형 맞추면 최적 채우기 개수가 나옵니다.

\frac{q}{m-q} \approx \frac{B_{\mathrm{P}}}{B_{\mathrm{H}} - B_{\mathrm{P}}}, \qquad q^{\star} \approx m\,\frac{B_{\mathrm{P}}}{B_{\mathrm{H}}}

이 단일 수식이 모든 하드웨어 균형을 포괄합니다. B_{\mathrm{H}} 가 B_{\mathrm{P}} 에 가까워지면 q^{\star} 는 전체 미스 개수 m 에 접근하고, 시스템은 별도의 실행 분기나 정책 없이 순수한 온디맨드 캐시 채우기로 자연스럽게 수축합니다.

실제로는 q^{\star} 를 정수로 반올림하고 \mathcal{F} 의 구체적 선택은 캐시 교체 정책에 위임합니다. CPU가 미스 대부분을 처리하는 상황에서도 캐시가 계속 예열되도록 채우기를 항상 최소 1개는 유지합니다. 대역폭 파라미터 B_{\mathrm{H}} 와 B_{\mathrm{P}} 는 배포 시점에 대상 하드웨어에서 실측으로 프로파일링합니다. 실행 중에 CPU와 GPU는 각자의 부분 합을 계산해 합치는데, 이때 알고리즘 수준의 근사 없이 정확한 MoE 출력을 보존합니다. 실행 순서를 보면 FreeToken은 CPU 분기를 먼저 실행하고, 이어서 캐시 갱신과 \mathcal{F} 의 일괄 복사, GPU 실행 집합 \mathcal{G} = \mathcal{H} \cup \mathcal{F} 의 그룹 평가로 이루어진 GPU 미스 경로를 실행합니다. 노출되는 계층 지연 시간은 동시에 진행되는 두 분기 중 느린 쪽이고, 이 값이 바로 위 수식이 균형을 맞추는 대상입니다.

탄력적 메모리 관리

두 장치 모두 하나의 성질에 기대고 있습니다. CPU에 상주하는 전문가 풀이 진실 공급원으로 남기 때문에, GPU 메모리는 성능에만 영향을 주고 정확성에는 절대 영향을 주지 않는다는 점입니다.

런타임 캐시 재구성 은 전문가가 아닌 가중치와 런타임 상태를 할당한 뒤, 남은 GPU 메모리 예산을 KV 캐시 페이지와 완전한 전문가 슬롯으로 나눕니다. 이 분할은 실행 시점에 고정되지 않습니다. 스케줄러의 어느 안전 지점에서든 FreeToken은 수정된 런타임 VRAM 예산에 맞춰 GPU 전문가 캐시를 재구성할 수 있습니다. 엔진을 재시작하거나 CPU에 상주하는 전문가 풀을 다시 적재하지 않고, 새 캐시 구성에 맞는 실행 경로를 동적으로 다시 확립합니다.

빠른 엔진 부트스트랩 은 시작 시간의 두 요소 중 하나를 줄이고 하나를 없앱니다. 적재 단계에서는 전문가 가중치를 디스크에서 최종 호스트 레이아웃으로 곧바로 읽어 들이고, 메모리 고정은 그다음에 합니다. 빈 버퍼를 먼저 고정하면 덮어쓰기만 할 페이지 수 기가바이트를 폴트 인하고 0으로 채우는 낭비가 생기기 때문입니다. 워밍업은 구조적으로 불필요합니다. 첫 요청은 차가운 캐시로 서빙되고 그 미스는 앞 절의 일반 decode 경로가 처리하므로, 캐시는 정상적인 서빙 과정에서 채워집니다.

구현

FreeToken은 SGLang과 vLLM이 세운 GPU 중심 서빙 아키텍처를 따릅니다. 페이지 단위 KV 캐시 관리와 래딕스 기반 접두 문맥 재사용을 가져오고, 여기에 FlashInfer 와 Flash Linear Attention 같은 커뮤니티 커널 라이브러리를 필요한 자리에서 함께 씁니다. 이 기반 위에 두 구현 계층이 앞의 설계를 실현하는데, 하나는 그래프와 공존하는 전문가 캐시이고 다른 하나는 그 아래의 저장 및 플랫폼 계층입니다.

CUDA Graph와 공존하는 LRU 캐시

전문가 캐싱은 본질적으로 동적입니다. 어떤 전문가가 미스하는지, 몇 개를 가져오는지, 어떤 슬롯을 축출하는지가 매 단계 바뀝니다. 호스트가 캐시를 제어하면 MoE 계층마다 비용이 큰 장치 동기화가 다시 들어옵니다. 이를 피하려고 FreeToken은 라우팅에 의존하는 제어를 전부 GPU에 둡니다. 이 동적 제어를 정적으로 캡처된 그래프 안의 데이터 로 표현하는 방식인데, 고정 형태의 작업 버퍼와 장치에 상주하는 유효 개수가 그 데이터입니다.

MoE 계층마다 GPU 커널 하나가 라우팅된 전문가를 중복 제거하고, 상주 테이블과 대조해 분류하고, 대역폭 기반 인출 개수 q 를 도출하고, 축출 대상을 선택하고, 논리 라우팅 ID를 물리 슬롯 ID나 CPU 배정 플래그로 다시 씁니다. 축출 대상 선택은 슬롯 하나를 비울 때마다 캐시 전체를 훑어야 하는 고전적인 LRU 함정을 피합니다. 단일 패스 커널이 축출 후보 슬롯 K 개를 한 번에 찾아내고, 미스 경로는 그중 앞쪽 q \leq K 개를 소비합니다. 실제 미스 개수와 무관하게 축출 후보 탐색은 항상 정확히 한 번의 패스로 끝납니다.

이렇게 만들어진 복사 작업 목록은 하나의 융합된 전송을 구동합니다. 모든 전문가 뱅크가 같은 논리 전문가 대 슬롯 대응을 공유하므로, 장치에 상주하는 하나의 출발지 및 도착지 인덱스 목록을 고정 형태의 실행 한 번으로 모든 뱅크에 적용할 수 있고, 쓰이지 않는 작업은 유효 개수로 가려냅니다. 그 결과 커널 실행 횟수가 적고 PCIe 이용률이 높으며, 라우팅에 따라 달라지는 결정 부담이 호스트에서 사라집니다.

대역폭 적응 실행의 CPU 분기도 같은 그래프에 캡처됩니다. 지원되는 decode 배치 크기마다 FreeToken은 안정적인 고정 입출력 버퍼와 영속적인 작업 서술자를 준비합니다. 장치에서 호스트로의 복사, 호스트 함수 제출 노드, 동시에 진행되는 GPU 경로, 동기화 노드, 호스트에서 장치로의 결과 복사가 모두 함께 캡처되므로, 재생만으로 이종 단계 전체가 다시 실행되고 토큰마다 Python 스케줄링을 할 필요가 없습니다. CPU 작업자는 물리 코어에 고정된 영속 C++ 풀을 이루며, 그 커널은 아키텍처별 SIMD와 커널 내부 역양자화로 전문가 가중치를 소비해 경로를 대역폭 바운드로 유지합니다.

전문가 뱅크와 FTW 포맷

FreeToken은 모델별로 다른 체크포인트 레이아웃을 소수의 전문가 뱅크로 정규화합니다. 각 뱅크는 계층과 전문가를 평탄화한 식별자 lE + e 를 선두 차원으로 씁니다. 모든 뱅크에서 같은 식별자를 가진 행들이 모여 하나의 완전한 전문가를 구성하므로, GPU 커널과 CPU 실행기가 물리 포맷과 무관하게 하나의 논리적 전문가 정체성을 공유합니다.

적재를 빠르게 하려고 FreeToken은 전문가 가중치를 이 런타임 뱅크 레이아웃으로 미리 합쳐 저장하는 FTW(FreeToken Weight) 포맷을 제공합니다. 엔진을 시작할 때 텐서 탐색과 재패킹을 통째로 건너뛰고, 정렬된 청크를 병렬 직접 입출력으로 정확한 크기의 호스트 뱅크에 곧바로 읽어 들인 뒤 채운 다음에만 고정합니다.

플랫폼 적응도 적재 시점에 이루어집니다. FreeToken은 전문가 표현과 GPU 아키텍처, CUDA 환경에 맞는 GPU 커널을 선택하고, CPU 실행기는 사용 가능한 SIMD 구현과 물리 코어 배치에 맞춰 디스패치합니다. 전문가 풀 전체를 고정하거나 DMA용으로 등록할 수 없는 경우, 즉 일부 운영체제와 드라이버 구성의 제약에 걸리는 경우에는 순수 CPU MoE 백엔드로 되돌아갑니다. 이 백엔드에서는 전문가 가중치가 페이지 가능한 호스트 저장 공간에 남고 라우팅된 전문가 전부가 CPU에서 실행되며, 전문가가 아닌 계층은 GPU에 남습니다. 최대 전송 대역폭을 포기하는 대신 빠른 경로를 확립할 수 없는 플랫폼에서의 배포 가능성을 얻는 선택입니다.

실험 결과 및 성능 분석

실험 환경

논문은 전문가 풀 전체가 VRAM을 초과하는 MoE 모델을 실제 에이전트 작업으로 서빙하며, 활발히 유지보수되는 엣지 서빙 엔진들과 6대의 기기에서 비교합니다. 아래 표는 연구팀이 자체적으로 측정해 공개한 테스트 시스템의 사양입니다. B_{\mathrm{P}} 는 PCIe를 통한 호스트에서 장치로의 전문가 전송 대역폭, B_{\mathrm{H}} 는 CPU 측 MoE 전문가 커널의 유효 대역폭이며, 모두 사양서 값이 아니라 배포된 텐서 형태에서 실측한 값입니다. 다만 임대 서버인 3090과 4090, 5090 행은 CPU 스레드와 DRAM 열이 물리 사양이 아니라 컨테이너 할당량입니다.

시스템	GPU (VRAM)	PCIe	B_{\mathrm{P}} (GB/s)	CPU (스레드)	DRAM (GiB)	B_{\mathrm{H}} (GB/s)
5090	RTX 5090 (32GB)	5.0 x16	52.7	Xeon Gold 6459C 2소켓 (32)	DDR5 180	77.3
4090	RTX 4090 (24GB)	4.0 x16	25.1	Xeon Platinum 8358P 2소켓 (32)	DDR4 240	63.2
3090	RTX 3090 (24GB)	4.0 x16	25.3	Xeon Gold 6330 2소켓 (28)	DDR4 180	56.7
5090 데스크톱	RTX 5090 (32GB)	5.0 x16	49.0	Ryzen 9 9950X3D (32)	DDR5 192	53.8
4060 노트북	RTX 4060 Laptop (8GB)	4.0 x8	11.8	Core i9-13900H (20)	LPDDR5 32	47.5
PRO 6000	RTX PRO 6000 (96GB)	5.0 x16	51.5	Xeon Platinum 8559C (48)	DDR5 512	178

위 표에서 4060 노트북과 나머지 기기의 차이가 눈에 띕니다. PCIe 4.0 x8 링크의 11.8 GB/s는 5090의 52.7 GB/s의 4분의 1에도 못 미치는데, 호스트 대역폭 B_{\mathrm{H}} 는 47.5 GB/s로 5090의 77.3 GB/s와 같은 자릿수입니다. 두 대역폭의 비율이 기기마다 이렇게 달라지는 것이 q^{\star} 정책이 필요한 이유입니다. 3090과 4090, 5090 시스템은 임대한 2소켓 서버이고 CPU가 어떤 엣지 호스트보다 강력하므로, 모든 서빙 실행과 대역폭 측정을 6개 CPU 스레드로 제한하고 GPU의 NUMA 노드에 고정했습니다. 이렇게 제한한 서버는 56.7 GB/s에서 77.3 GB/s의 호스트 대역폭을 내는데, 이는 실제 엣지 기기 2대가 스레드를 전부 쓸 때 도달하는 수준과 같은 자릿수입니다(데스크톱은 16코어에서 53.8 GB/s, 노트북은 14코어에서 47.5 GB/s). 데스크톱과 노트북은 스레드를 제한하지 않고 돌려, 이 서버 기반 모사가 실제 엣지 하드웨어에서도 성립하는지 검증하는 역할을 맡습니다.

모델 은 주 평가용 2종에 하드웨어 전반 연구용 1종이 더해집니다. DeepSeek-V4-Flash(284B 파라미터, 활성 13B)는 라우팅 전문가가 MXFP4로 양자화(quantization)된 공식 체크포인트(checkpoint)에서 서빙하고, Qwen3.6-35B-A3B는 엔진 사이의 정밀도 동일성을 확보하기 위해 BF16으로 서빙합니다. 8GB 노트북은 이 모델의 공식 NVFP4 릴리즈를 씁니다. 하드웨어 전반 연구에는 GLM-5.2(753B 파라미터, 활성 40B, NVFP4 라우팅 전문가, 433GB 체크포인트)가 프론티어 등급으로 추가됩니다.

작업 은 4가지 에이전트 시나리오입니다.

W1, 수리 추론: AIME 경진 문제를 긴 사고 연쇄 decode로 답하며 도구를 쓰지 않습니다. 단일 턴이고 decode가 지배적입니다.
W2, 코딩 에이전트: SWE-bench 저장소 이슈를 OpenCode 하네스로 풀며, 3번의 스크립트된 사용자 턴 동안 실제 도구를 실행합니다.
W3, 코딩 에이전트, 네이티브 프로토콜: 같은 이슈를 Claude Code가 각 엔진의 Anthropic 호환 엔드포인트로 구동합니다. 동시에 요청하는 서브에이전트가 생성되고 세션이 56k에서 65k 토큰까지 자랍니다.
W4, 이메일 및 캘린더 에이전트: OpenClaw 기본 설정으로 메일박스 킷 위에서 13번의 고정된 사용자 턴을 수행하며, 약 24.5k 토큰의 시스템 컨텍스트 하한을 안고 갑니다. 단 느린 엔진도 측정 가능하도록 OpenClaw의 120 초 유휴 감시 장치는 껐습니다.

베이스라인 은 llama.cpp, Ollama, KTransformers, MoE-Infinity이며, MoE-Infinity는 지원하는 구성에서만 실행했습니다. 가중치 포맷은 정확히 정렬했습니다. 모든 엔진이 Qwen3.6을 BF16으로 서빙하고, DeepSeek-V4-Flash의 네이티브 MXFP4 전문가 블록을 비트 단위로 동일하게 소비합니다. 또한 모든 엔진이 같은 하네스에 같은 요청을 받으며, 실행이 유효하려면 코딩 작업은 기준 정답 패치(gold patch)를 만들어 내야 하고 W4는 13번의 턴을 모두 끝내야 합니다. 따라서 아래 처리량은 과제를 완수한 실행에서 나온 값입니다. 지표는 decode 처리량(요청당 평균 tok/s)과 TTFT(요청당 평균)입니다. 에이전트 궤적이 엔진마다 달라지므로 엔진 사이의 전체 벽시계 시간은 비교하지 않습니다.

종단간 서빙 성능

위 그림은 RTX 5090에서 두 모델과 4가지 작업에 대한 decode 처리량과 평균 TTFT를 보여줍니다. 상단이 decode 처리량이고 하단이 TTFT(로그 축)이며, x 표시는 해당 엔진이 서빙할 수 없는 구성입니다. CPU 스레드는 Qwen3.6에 6개, DeepSeek-V4-Flash에 8개를 배정했습니다. Ollama와 MoE-Infinity는 DeepSeek-V4-Flash를 지원하지 않고, MoE-Infinity는 다중 턴 에이전트에 쓸 수 있는 서버를 제공하지 않습니다.

측정 결과, FreeToken은 Qwen3.6에서 77 \sim 83 tok/s, DeepSeek-V4-Flash에서 22 \sim 25 tok/s를 유지합니다. 각 작업에서 가장 강한 베이스라인 대비 각각 1.8 \sim 2.3\times 와 1.5 \sim 1.9\times 에 해당합니다. 이 속도는 작업이 에이전트에 가까워져도 안정적으로 유지됩니다. FreeToken의 decode 속도는 3가지 에이전트 작업 전체에서 단일 턴인 W1 값의 12\% 안에 머무릅니다. 반면 컨텍스트에 가장 민감한 베이스라인인 DeepSeek-V4-Flash 위의 KTransformers는 이미 W2에서 W1 속도의 31\% 를 잃었습니다. 연구팀은 단일 스트림 벤치마크가 베이스라인의 에이전트 성능을 과대평가한다고 지적합니다. MoE-Infinity는 W1만 서빙했습니다(8.8 tok/s). 전문가 단위 prefill 스테이징 상한이 프롬프트가 긴 작업을 중단시키고, 함께 제공되는 서버가 요청 사이에 KV 캐시를 유지하지 않기 때문입니다.

TTFT에서는 FreeToken이 6개 다중 턴 항목 중 5개에서 가장 낮은 평균을 기록했습니다. Qwen3.6과 W3의 조합에서는 KTransformers의 GPU prefill 쪽이 유리했고, W1의 짧은 단발 프롬프트에서는 llama.cpp가 유리했습니다. 다만 평균보다 꼬리 지연이 엔진 사이의 차이를 훨씬 선명하게 드러냅니다. FreeToken의 최악 턴은 모든 항목에서 44 초 아래에 머물렀지만, 각 베이스라인은 어느 한 설정에서 150 초를 넘겼습니다. llama.cpp가 232 초, Ollama가 179 초, KTransformers가 946 초입니다. 이 정도 지연은 실제 클라이언트가 요청을 포기하는 임계값을 넘어섭니다. OpenClaw는 120 초 유휴 감시 장치를 기본 탑재하고, Claude Code의 기본 요청 타임아웃은 약 10분입니다. 연구팀은 꼬리 TTFT를 지연 통계가 아니라 가용성의 경계선으로 규정합니다.

무엇이 성능을 만들었나

위 그림의 왼쪽은 파이프라인 prefill의 효과이고, 오른쪽은 전문가 캐시 지역성의 효과입니다.

파이프라인 prefill 을 먼저 보겠습니다. 전층 이중 버퍼링은 prefill을 전송 바운드로 만듭니다. 겹침을 켜면 8,192 토큰 prefill 청크가 1.19 \sim 1.22 초에 완료되는데, 이는 64.4GB의 전문가 풀을 52.7 GB/s로 한 번 흘려보내는 시간이자 PCIe 5.0 x16 링크의 실질적 상한입니다. 전문가 연산이 전송 뒤에 완전히 숨은 것이고, 처리량은 16k 토큰에서 6{,}700 tok/s까지 올라갑니다. 두 번째 버퍼를 끄면 전송과 연산이 직렬화되어 4k 토큰에서 처리량의 19\%, 8k에서 25\%, 16k에서 26\% 를 잃습니다. 숨겨지는 연산의 비중이 커지는 만큼 프롬프트가 길어질수록 손해가 커집니다.

오른쪽 그래프는 전문가 지역성 을 보여줍니다. 4가지 작업에서 뽑은 동일한 라우팅 트레이스를 세 엔진의 배치 정책에 같은 캐시 용량으로 재생한 결과입니다. 선은 W1부터 W4까지의 평균이고 옅은 띠는 최솟값과 최댓값 범위입니다. RTX 5090의 서빙 용량에서, 즉 Qwen3.6 전문가 풀의 37\% 와 DeepSeek-V4-Flash 풀의 11\% 에서, FreeToken의 전역 LRU는 decode 시점 전문가 읽기의 16\% 와 39\% 를 놓칩니다. 같은 조건에서 KTransformers의 prefill 갱신 배치는 41\% 와 59\%, llama.cpp의 라우팅 무관 정적 분할은 62\% 와 89\% 를 놓칩니다. 이 순서는 전문가 풀 전체에 미치지 못하는 모든 용량에서, 그리고 모든 작업에서 유지됩니다.

하드웨어 전반의 일반성

위 그림은 W2 코딩 에이전트 작업을 소비자용 시스템 5대에서 반복한 결과입니다. FreeToken은 RTX 3090과 4090에서 가장 강한 베이스라인을 1.3\times, 5090 서버에서 1.9\times, 5090 데스크톱에서 2.1\times, RTX 4060 노트북에서 1.8\times 앞섭니다. 노트북에서는 NVFP4 빌드가 8GB, PCIe x8 기기에서 39.3 tok/s를 유지하는데, 이는 RTX 4090 속도의 92\% 에 해당합니다.

위 그림의 5090 항목 2개를 비교하면 호스트의 영향만 따로 볼 수 있습니다. 두 항목은 같은 GPU 실리콘을 쓰고 호스트만 다릅니다. 채널이 많은 서버에서 듀얼 채널 소비자용 데스크톱으로 옮기면 FreeToken은 decode 속도의 4\% 를 잃습니다(76.7 tok/s에서 73.8 tok/s). 같은 이동에서 llama.cpp는 속도의 80\% 만 유지합니다(41.1 tok/s에서 33.0 tok/s). CPU에 상주하는 전문가가 DDR5 두 채널에서 필요한 대역폭을 확보하지 못하기 때문입니다.

위 그림의 PRO 6000 항목은 W2가 아니라 별도 시연이며 작업도 수리 추론입니다. 이 등급에서 FreeToken은 단일 RTX PRO 6000으로 GLM-5.2를 14.9 tok/s로 서빙해 llama.cpp의 7.3 tok/s를 2.0\times 앞서고, 전문가 가중치는 비트 단위로 동일하며 평균 TTFT도 비슷합니다(7.5 초 대 7.8 초). Ollama는 이 기기에서 실행하지 않았습니다. KTransformers는 이 기기에서 이 모델을 서빙할 경로가 없습니다. GLM-5.2용 방식이 호스트에 상주하는 전문가로 753GB에서 1.5TB를 요구하는데 호스트 메모리는 512GiB이고, CPU 커널이 GLM-5.2의 NVFP4 레이아웃을 읽지 못하기 때문입니다.

설치 및 사용 방법

FreeToken은 Apache License 2.0으로 공개되어 있고, 데스크톱 앱과 CLI 두 경로를 제공합니다. Windows나 Linux용 데스크톱 앱은 flashml.ai 에서 받을 수 있으며, 엔진을 대신 설정해 주고 모델 실행과 대화, 엔진 튜닝용 GUI를 함께 제공합니다.

CLI는 Linux x86_64와 NVIDIA GPU, r580 이상 드라이버(CUDA 13), Python 3.10 이상을 요구합니다. 런타임 자체가 PyTorch 위에 구현되어 있고 의존성이 torch>=2.11,<2.12 로 좁게 고정되어 있으므로, 기존 환경의 PyTorch와 충돌하지 않도록 별도 가상 환경에 설치하는 편이 안전합니다. uv 사용을 권장합니다.

# PyPI에서 설치
uv venv && source .venv/bin/activate
uv pip install "freetoken[accel]"   # CUDA 커널은 첫 사용 시 JIT 컴파일되므로 nvcc가 PATH에 있어야 합니다

# 소스에서 빌드
git clone https://github.com/FlashML-org/FreeToken.git && cd FreeToken
uv venv && source .venv/bin/activate
uv pip install -e ".[accel]"

[accel] 는 FlashInfer와 sglang-kernel 네이티브 커널을 함께 설치하는 옵션입니다. 이 옵션 없이 설치하면 순수 Triton 커널 경로로 되돌아갑니다.

서버는 --model 하나만 주면 실행됩니다. 자료형과 어텐션 및 MoE 백엔드, 캐시 크기, 도구 호출과 추론 파서는 체크포인트와 GPU에서 자동으로 결정됩니다. --model 에는 로컬 경로 대신 Hugging Face 저장소 ID도 넣을 수 있습니다.

ft serve --model ~/models/Qwen3.6-35B-A3B

FreeToken은 OpenAI API(/v1/chat/completions, /v1/responses, /v1/models)와 Anthropic API(/v1/messages, /v1/messages/count_tokens)를 함께 서빙하므로, 두 규격 중 아무 클라이언트 라이브러리나 기본 URL만 이 서버로 바꾸면 동작합니다. 코딩 에이전트를 붙일 때는 아래 명령이 해당 에이전트의 프로바이더 설정을 작성하고 CLI가 없으면 설치한 뒤 서버를 향해 실행해 줍니다. --dry-run 으로 변경 내용을 미리 볼 수 있습니다.

ft launch claude   # claude / codex / dsh / hermes / openclaw / opencode

논문의 q^{\star} 정책은 --moe-backend hybrid 에 대응합니다. 기기마다 분할 비율을 보정해야 하므로 기기당 한 번 ft bench bw 를 실행합니다.

ft bench bw                            # CPU 대역폭과 PCIe 대역폭을 측정해 프로파일 저장
ft serve --model <경로> --moe-backend hybrid

--moe-backend 는 auto, fused, offload, cpu, hybrid 를 받습니다. fused 는 전문가를 GPU에 상주시키므로 VRAM이 충분해야 하고 자동으로 선택되지 않습니다. offload 는 전문가를 호스트 RAM에 두고 GPU에 전문가 슬롯 LRU 캐시를 유지하며 미스를 PCIe로 스트리밍합니다. cpu 는 미스를 가져오는 대신 CPU에서 계산합니다. hybrid 는 단계마다 일부 미스를 PCIe로 가져오고 나머지를 CPU에서 계산해 겹칩니다. auto 는 밀집 모델을 항상 fused 로, MoE 모델을 offload 로 해석하고, 캐시된 ft bench bw 프로파일이 권고하면 hybrid 로 올립니다.

지원 모델은 DeepSeek-V4, GLM-5.2와 GLM-4.7, Qwen3.6과 Qwen3.5 MoE 및 밀집 계열, Qwen3-MoE, gpt-oss, Gemma-4, MiniMax-M2.5, Muse-Glimmer 등입니다. 체크포인트는 Hugging Face safetensors를 직접 읽으며, Gemma-4는 GGUF도 그대로 지원합니다. 전체 목록과 체크포인트는 저장소의 지원 모델 문서 에 정리되어 있습니다. 멀티모달 체크포인트는 텍스트 전용으로 서빙됩니다.

한계점 및 향후 전망

논문이 제안하는 방식에도 경계가 분명한 제약이 있습니다.

첫째, CLI가 지원하는 플랫폼이 좁습니다. 설치 문서는 Linux x86_64와 NVIDIA GPU, CUDA 13 환경을 요구하며, 애플 실리콘이나 다른 가속기는 대상이 아닙니다. 데스크톱 앱이 Windows를 지원하지만, 논문의 실험도 전부 NVIDIA GPU에서 수행되었습니다. 전문가 풀 전체를 고정하거나 DMA용으로 등록할 수 없는 운영체제와 드라이버 조합에서는 순수 CPU 백엔드로 되돌아가는데, 이 경로는 최대 전송 대역폭을 포기하는 대신 배포 가능성을 얻는 선택입니다.

둘째, 전문가 풀 전체가 호스트 메모리에 들어가야 합니다. CPU에 상주하는 전문가 풀이 진실 공급원이므로, 서빙할 수 있는 모델 크기는 GPU가 아니라 DRAM 용량으로 결정됩니다. 위 실험 환경 표를 보면 433GB 체크포인트인 GLM-5.2를 돌린 기기의 DRAM은 512GiB, CPU는 48스레드 Xeon Platinum이고, 실측 호스트 대역폭 B_{\mathrm{H}} 는 178 GB/s로 5090 데스크톱의 53.8 GB/s의 세 배가 넘습니다. KTransformers가 같은 기기에서 이 모델을 서빙하지 못한 이유도 그 방식이 요구하는 753GB에서 1.5TB가 512GiB를 넘었기 때문입니다. 다시 말해 GPU 한 장으로 753B를 서빙했다는 결과가 곧 소비자용 메인보드에서 된다는 뜻은 아니며, 각 등급의 성과는 그 기기의 DRAM이 해당 전문가 풀을 담을 수 있었다는 조건 위에 있습니다.

셋째, q^{\star} 정책이 기기별 사전 프로파일링에 의존합니다. 대역폭 파라미터 B_{\mathrm{H}} 와 B_{\mathrm{P}} 는 배포 시점에 실측으로 얻으므로, 기기를 바꾸거나 메모리 구성을 변경하면 ft bench bw 를 다시 돌려야 합니다. 또 이 정책은 두 대역폭의 비율로 미스를 나누는 닫힌 형태의 근사이며, 프로파일링 시점과 실제 서빙 시점의 시스템 부하가 크게 다르면 그 비율은 최적에서 멀어집니다. 논문은 스케줄러 안전 지점에서 캐시를 재구성하는 장치는 제시하지만, 대역폭 프로파일 자체를 서빙 중에 다시 측정하는 방식은 다루지 않습니다.

넷째, 평가의 비교 범위가 제한적입니다. 3090과 4090, 5090 시스템은 임대한 2소켓 서버를 6개 CPU 스레드로 제한해 엣지 호스트를 모사한 구성이고, 실제 엣지 기기는 데스크톱과 노트북 2대뿐입니다. 논문은 이 두 대가 서버 기반 모사를 검증한다고 밝혔지만, 소비자용 하드웨어의 다양성을 감안하면 표본이 넓다고 보기는 어렵습니다. 또 에이전트 궤적이 엔진마다 달라지기 때문에 엔진 사이의 전체 벽시계 시간을 비교하지 않았고, 그래서 "같은 과제를 끝까지 푸는 데 걸린 총 시간"이라는 사용자 체감 지표는 이 실험에서 직접 확인되지 않습니다.

다섯째, 다중 사용자 서빙은 목표가 아닙니다. CLI 기본값의 최대 동시 실행 요청은 4개이고, 설계 전반이 작은 decode 배치를 전제로 합니다. q^{\star} 유도 자체가 토큰마다 전문가 가중치를 한 번 읽어 오는 메모리 바운드 영역을 가정하므로, 배치가 커져 연산 바운드로 넘어가는 구간에는 그대로 적용되지 않습니다.

이런 제약을 감안해도, 이 연구가 가리키는 방향은 분명합니다. 논문은 "희소 활성화가 모델의 연산을 가능하게 만든 다음부터, 로컬 추론은 모델이 GPU에 들어가는지의 문제라기보다 시스템이 그 기기를 얼마나 잘 조율하는지의 문제가 된다"고 정리합니다. 이어서 연구팀은 로컬 AI의 경계선이 하드웨어 용량만으로 정해지지 않고 이미 갖춰진 자원을 조합하는 서빙 소프트웨어로도 정해진다고 결론짓습니다. 같은 기기에서 같은 가중치를 비트 단위로 동일하게 놓고도 엔진에 따라 decode 속도가 두 배까지 벌어진 실험 결과가 그 근거입니다. 개인 기기로 프론티어급 모델을 돌려 보려는 독자에게는, GPU를 한 등급 올리기 전에 서빙 엔진을 바꿔 보는 것이 더 싼 선택일 수 있습니다.

FreeToken: Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Execution 논문

FreeToken 프로젝트 홈페이지

FreeToken GitHub 저장소

https://github.com/FlashML-org/FreeToken

더 읽어보기

이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다.

논문의 주장이나 벤치마크에 대한 의견, 직접 재현해보신 결과가 있다면 파이토치 한국 사용자 모임 회원들을 위해 댓글로 공유해주세요!