753B GLM-5.2를 워크스테이션 GPU 한 장으로 돌린다: FreeToken, llama.cpp 대비 2배 처리량

FreeToken은 파라미터 753B의 GLM-5.2를 RTX PRO 6000 한 장에서 초당 14.9토큰으로 서빙해 같은 조건의 llama.cpp 7.3토큰을 정확히 2배 앞섰다고 arXiv 논문 2608.16157이 2026년 8월 17일 공개했다. Shuo Yang, Xiaoze Fan, Melissa Pan, Haocheng Xi, Kurt Keutzer, Song Han, Matei Zaharia, Chenfeng Xu, Ion Stoica 등이 쓴 'FreeToken: Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Execution'은 8GB 노트북 GPU에서 35B, 게이밍 데스크톱에서 284B까지 실제로 돌아가는 것을 함께 보였다. 코드는 Apache 2.0으로 공개됐고 GitHub 저장소는 8월 24일 기준 별 3,346개를 모았다. ASAP은 논문과 저장소를 1차 출처로 이 결과를 정리한다.

고정된 오프로딩 전략을 버리고 대역폭을 실측해 배치한다

FreeToken이 기존 엣지 추론 엔진과 갈라지는 지점은 무엇을 GPU에 올릴지 미리 정하지 않는다는 것이다. llama.cpp는 라우팅과 무관하게 전문가(expert) 가중치를 GPU와 CPU로 고정 분할하고, KTransformers는 프리필 단계에서 관측한 라우팅으로 배치를 정한다. FreeToken은 개인 기기를 작은 GPU가 아니라 GPU와 CPU, 메모리, 인터커넥트가 묶인 하나의 탄력적 추론 플랫폼으로 놓고, 그때그때 남아 있는 자원 위로 계산과 모델 상태를 계속 다시 매핑한다.

구체적인 장치는 세 가지다. 프리필에서는 전체 레이어 이중 버퍼링으로 전문가 전송과 계산을 겹친다. 8,192토큰 단위 프리필 청크 하나가 1.19초에서 1.22초 만에 끝나는데, 이는 64.4GB 전문가 풀을 PCIe 5.0 x16의 실측 52.7GB/s로 한 번 흘려보내는 시간과 같다. 계산이 전송 뒤에 완전히 숨었다는 뜻이고, 16k 토큰 구간에서 프리필 처리량은 초당 6,700토큰까지 올라간다. 두 번째 버퍼를 끄면 4k에서 19%, 8k에서 25%, 16k에서 26%의 처리량을 잃는다. 프롬프트가 길수록 손해가 커지는 것은 숨길 수 있었던 계산의 비중이 그만큼 커지기 때문이다.

디코드에서는 전문가 캐시를 미스가 날 때마다 갱신하는 전역 LRU로 관리한다. 논문은 세 엔진의 배치 정책을 동일한 라우팅 트레이스로 재생해 비교했다. RTX 5090의 서빙 용량(Qwen3.6 전문가 풀의 37%, DeepSeek-V4-Flash의 11%)에서 FreeToken의 미스율은 각각 16%와 39%였다. 같은 조건에서 KTransformers는 41%와 59%, llama.cpp는 62%와 89%였다. 세 번째 장치인 탄력적 메모리 관리는 런타임 중에 VRAM 배분을 다시 조정한다. 개인 기기에서는 브라우저와 게임이 언제든 같은 GPU를 요구하기 때문이다.

8GB 노트북에서 35B, 96GB 워크스테이션에서 753B

측정은 여섯 대의 시스템에서 이뤄졌다. RTX 3090, 4090, 5090 서버 세 대와 RTX 5090 데스크톱, RTX 4060 노트북(8GB), 그리고 프론티어급 시연을 맡은 RTX PRO 6000(96GB) 한 대다. 임대 서버 세 대는 CPU가 실제 엣지 환경보다 지나치게 강력해서 6스레드로 제한하고 GPU의 NUMA 노드에 고정했다. 이렇게 묶었을 때 서버들의 호스트 대역폭은 56.7에서 77.3GB/s였고, 실제 엣지 기기인 데스크톱 16코어가 53.8GB/s, 노트북 14코어가 47.5GB/s였다. 표에 실린 대역폭은 플랫폼 사양이 아니라 실제 배포된 텐서 모양에서 측정한 값이다.

RTX 5090에서 FreeToken은 Qwen3.6-35B-A3B를 초당 77에서 83토큰, DeepSeek-V4-Flash(284B, 활성 13B)를 초당 22에서 25토큰으로 서빙했다. 각 워크로드에서 가장 강한 베이스라인 대비 1.8배에서 2.3배, 1.5배에서 1.9배다. 다섯 개 소비자용 시스템에서 코딩 에이전트 워크로드를 반복했을 때 우위는 RTX 3090과 4090에서 1.3배, 5090 서버에서 1.9배, 5090 데스크톱에서 2.1배, RTX 4060 노트북에서 1.8배였다. 노트북은 PCIe x8에 VRAM 8GB라는 제약 아래서 NVFP4 빌드로 초당 39.3토큰을 냈는데, 이는 RTX 4090이 낸 속도의 92%다.

가장 눈에 띄는 대비는 같은 GPU 실리콘을 쓰는 5090 두 대 사이에서 나왔다. 다채널 서버에서 듀얼채널 소비자용 데스크톱으로 옮길 때 FreeToken은 디코드 속도의 4%만 잃었지만, llama.cpp는 80%만 유지했다. CPU에 상주시킨 전문가들이 DDR5 두 채널에서 굶었기 때문이다. 프론티어 구간에서는 GLM-5.2(753B, 활성 40B, NVFP4 전문가, 체크포인트 433GB)를 RTX PRO 6000 한 장에서 초당 14.9토큰으로 서빙해 llama.cpp의 7.3토큰을 2.0배 앞섰다. 전문가 가중치는 비트 단위로 동일했고 평균 TTFT도 7.5초 대 7.8초로 비슷했다. KTransformers는 이 조합을 아예 서빙하지 못했다. 이 엔진의 GLM-5.2 경로는 호스트 메모리에 753GB에서 1.5TB의 전문가를 상주시켜야 하는데 해당 장비의 호스트 메모리는 512GiB였고, CPU 커널이 GLM-5.2의 NVFP4 레이아웃을 읽지도 못했다.

평균 지연이 아니라 꼬리 44초가 진짜 성과다

논문에서 가장 실무적인 숫자는 처리량이 아니라 TTFT 꼬리다. FreeToken의 최악 응답은 모든 조합에서 44초 아래에 머물렀다. 반면 베이스라인들은 어딘가에서 150초를 넘겼는데, llama.cpp가 232초, Ollama가 179초, KTransformers가 946초였다. 평균만 보면 이 차이가 사라진다. 실제로 짧고 고립된 프롬프트인 AIME 워크로드에서는 llama.cpp의 평균 TTFT가 더 나았다.

이 구분이 중요한 이유는 에이전트 클라이언트가 평균이 아니라 개별 요청의 타임아웃으로 동작하기 때문이다. 논문이 인용한 두 임계값은 OpenClaw의 120초 유휴 워치독과 Claude Code의 기본 요청 타임아웃 약 10분이다. 946초짜리 꼬리는 느린 응답이 아니라 실패한 요청이다. 사용자 입장에서는 초당 몇 토큰이 나오는지와 무관하게 세션이 끊긴다. 로컬 추론 벤치마크가 대부분 평균 TTFT와 정상 상태 처리량만 보고하는 관행을 생각하면, 꼬리를 가용성 경계로 다시 정의한 것 자체가 이 논문이 제시한 평가 기준의 변경에 가깝다.

같은 맥락에서 두 번째 관찰도 방법론에 관한 지적이다. FreeToken은 단일 턴 워크로드에서 측정한 속도의 12% 이내를 세 개의 에이전트 워크로드에서도 유지했다. 반면 맥락에 가장 민감한 베이스라인인 DeepSeek-V4-Flash 위의 KTransformers는 두 번째 워크로드에서 이미 첫 번째 워크로드 속도의 31%를 잃었다. MoE-Infinity는 첫 번째 워크로드만 서빙했고 그마저 초당 8.8토큰이었다. 여기서 나오는 결론은 명확하다. 싱글 스트림 벤치마크는 베이스라인의 에이전트 성능을 과대평가한다. 지금 유통되는 로컬 LLM 속도 비교표 상당수가 이 함정 위에 서 있다는 뜻이기도 하다.

프론티어 모델을 소유하는 비용이 재계산된다

FreeToken이 바꾸는 것은 속도가 아니라 어떤 하드웨어에서 어떤 모델을 후보로 놓을 수 있는지의 경계다. 지금까지 753B급 오픈웨이트 모델을 돌리려면 다중 GPU 노드가 전제였고, 그래서 오픈웨이트라는 라이선스상의 자유는 실제로는 데이터센터 예산을 가진 조직만 행사할 수 있는 권리였다. 워크스테이션 한 대에서 초당 14.9토큰이면 대화형 응답으로는 느리지만, 배치 분류나 문서 처리, 야간 파이프라인 같은 비대화형 작업에는 충분히 쓸 만한 구간이다.

국내 맥락에서 이 지점이 가장 크게 걸리는 곳은 데이터 반출이 막힌 조직이다. 의료, 금융, 공공에서 외부 API 호출이 원천적으로 어려운 팀은 그동안 성능을 상당히 포기하고 소형 모델을 쓰거나 아예 도입을 미뤄왔다. 워크스테이션 한 대와 오픈웨이트 체크포인트로 프론티어급 모델을 사내에 두는 선택지가 생긴다면 계산의 전제가 달라진다. 다만 여기에는 조건이 붙는다. GLM-5.2 체크포인트만 433GB이고, 논문이 쓴 RTX PRO 6000 장비의 호스트 메모리는 512GiB다. 스토리지와 램을 포함한 총소유비용을 다시 계산해야 하며, GPU 가격표만 보고 판단할 문제가 아니다.

또 하나 눈여겨볼 대목은 이 논문의 기여가 새 모델이나 새 양자화가 아니라 서빙 스택 전체의 공동 설계라는 점이다. 최근 NVIDIA의 사례를 두고 하네스가 모델보다 중요해졌다는 논의가 나왔는데, FreeToken은 그 논의를 추론 인프라 층위에서 반복한다. 같은 가중치, 같은 비트 정밀도, 같은 하드웨어에서 2배가 갈린다면 남은 성능은 모델이 아니라 배치 정책과 메모리 관리에 있었다는 뜻이다. 오픈웨이트 생태계에서 앞으로 경쟁이 벌어질 자리 하나가 여기라고 읽을 수 있다.

숫자를 그대로 받기 전에 확인할 것들

논문이 명시한 제약부터 정리하면, 실행 환경은 Linux x86_64에 NVIDIA GPU, 드라이버 r580 이상(CUDA 13)이다. 맥이나 윈도우 사용자, AMD나 애플 실리콘 사용자에게는 지금 당장 해당하지 않는다. 서버로 측정한 세 대는 CPU를 6스레드로 묶어 엣지 환경을 모사한 것이지 진짜 엣지 기기가 아니다. 논문은 이 모사가 실제 데스크톱 및 노트북의 실측 대역폭과 같은 범위에 있음을 보여 정당화하지만, 모사는 모사다.

측정된 수치의 성격도 따져볼 필요가 있다. 보고된 값은 단일 사용자 대화형 서빙에서의 디코드 처리량이고, 여러 요청을 동시에 처리하는 배치 서빙 성능은 이 실험의 범위가 아니다. GLM-5.2 비교에서 KTransformers가 빠진 것은 FreeToken이 이겨서가 아니라 그 조합을 서빙할 경로가 없어서였다. 즉 프론티어 구간의 2.0배는 사실상 llama.cpp 하나와의 비교다. 노트북의 초당 39.3토큰도 BF16이 아니라 NVFP4 빌드에서 나온 값이라, 같은 열의 다른 숫자와 정밀도가 다르다.

마지막으로 이 결과가 답하지 않은 질문이 하나 남는다. 초당 14.9토큰은 사람이 읽는 속도로는 견딜 만하지만 도구를 여러 번 호출하는 코딩 에이전트에는 여전히 느리다. 논문이 에이전트 워크로드를 평가 대상으로 삼았으면서도 과제 완수율이나 정확도가 아니라 처리량과 지연만 보고했다는 점은 짚어둘 만하다. 엣지에서 프론티어 모델을 돌리는 일이 실제로 쓸모 있는지는 속도 표가 아니라 그 모델이 로컬에서 무엇을 끝까지 해내는지로 판정될 것이다.

출처: Shuo Yang 외, 'FreeToken: Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Execution'(arXiv:2608.16157, 2026년 8월 17일) 및 GitHub FlashML-org/FreeToken 저장소 기반 ASAP 정리.