- FreeToken 벤치마크: 대규모 전문가 혼합 모델의 로컬 서빙 성능을 측정합니다.
- 핵심 아이디어: GPU, CPU, 시스템 메모리, PCIe 대역폭을 하나의 추론 플랫폼으로 결합합니다.
- 최적의 사용 사례: 사용 가능한 GPU 메모리를 초과하는 오픈 웨이트 MoE 모델을 실행하는 것입니다.
- 설정 과정: 런타임을 설치하고, 모델 파일을 확인한 뒤, 로컬 엔드포인트를 실행하고 요청을 테스트합니다.
- 주요 장점: 적응형 캐싱과 CPU-GPU 실행을 통해 다양한 소비자용 하드웨어에서 성능 일관성을 높입니다.
FreeToken 벤치마크 개요
FreeToken 벤치마크는 대규모 전문가 혼합, 즉 MoE 모델을 위해 설계된 엣지 네이티브 서빙 시스템을 평가합니다. 전체 모델이 VRAM에 들어가야 하는 대신, FreeToken은 전체 전문가 풀을 호스트 메모리에 유지하면서 GPU를 탄력적인 캐시이자 실행 리소스로 사용합니다.
이 시스템은 GPU 용량, PCIe 연결, CPU 대역폭, 메모리 예산이 서로 다른 컴퓨터에서의 로컬 추론을 목표로 합니다. 벤치마크는 디코드 처리량, 첫 토큰까지의 시간, 멀티턴 에이전트 워크로드, 여러 소비자용 GPU 등급에서의 성능에 초점을 맞춥니다.
영상 주요 내용:
- FreeToken은 로컬 모델 서빙을 위해 GPU VRAM, CPU 처리 능력, 시스템 RAM을 결합합니다.
- 데스크톱 애플리케이션은 Windows, Linux, macOS 워크플로를 지원합니다.
- 명령줄 인터페이스를 통해 모델을 실행하고 OpenAI 호환 로컬 엔드포인트를 제공할 수 있습니다.
- 런타임 통계에는 토큰 속도, 처리된 토큰 수, 요청 수, 캐시 활동이 포함됩니다.
| 벤치마크 영역 | 측정 항목 | 중요한 이유 |
|---|---|---|
| 디코드 처리량 | 초당 생성되는 토큰 수 | 지속적인 생성 속도를 보여줍니다 |
| TTFT | 첫 토큰까지 걸리는 시간 | 프롬프트 및 시작 응답성을 나타냅니다 |
| 전문가 캐시 | VRAM에 유지되는 라우팅된 전문가 | 제한된 GPU 메모리가 얼마나 효과적으로 사용되는지 보여줍니다 |
| 하드웨어 간 확장성 | GPU 및 호스트 구성에 따른 결과 | 단일 테스트 머신을 넘어선 이식성을 보여줍니다 |
처리량과 TTFT는 별도의 지표로 취급하세요. 시스템이 시작 후에는 토큰을 빠르게 생성하더라도, 긴 프롬프트에서는 첫 토큰이 나오기까지 불편할 정도로 오래 걸릴 수 있습니다.
FreeToken이 대규모 MoE 모델을 서빙하는 방식
MoE 모델에는 많은 전문가가 포함되어 있지만, 각 토큰에 대해서는 그중 일부만 활성화됩니다. 이를 통해 활성 연산량은 줄어들지만, 전체 전문가 집합은 여전히 소비자용 GPU의 VRAM보다 훨씬 클 수 있습니다. FreeToken은 2단계 메모리 계층을 통해 이러한 불일치를 해결합니다.
CPU에 상주하는 전문가 풀은 라우팅된 전체 전문가 가중치를 저장하며 기준 데이터 역할을 합니다. 비전문가 모델 가중치는 GPU에 유지되고, 남은 VRAM은 KV 캐시와 탄력적인 전문가 캐시로 나뉩니다.
| 런타임 계층 | 주요 역할 | 적응형 동작 |
|---|---|---|
| GPU 메모리 | 비전문가 가중치, KV 캐시, 선택된 전문가 저장 | 런타임 중 캐시 용량 변경 가능 |
| 시스템 메모리 | 전체 전문가 풀 보관 | VRAM이 제한적이어도 계속 사용 가능 |
| PCIe 연결 | 선택된 전문가를 GPU 캐시로 이동 | 전송 작업과 CPU 실행 간 균형 조정 |
| CPU | 일부 캐시 미스를 직접 실행 | 고정된 배치가 아닌 측정된 호스트 대역폭 사용 |
프리필 단계에서 FreeToken은 전체 레이어 이중 버퍼링을 사용합니다. GPU가 한 레이어를 계산하는 동안 다음 레이어의 전문가를 PCIe를 통해 이동할 수 있습니다. 이를 통해 각 전문가 이동이 완료될 때까지 기다린 후 실행하는 대신, 전송과 계산을 중첩합니다.
디코드 단계에서 시스템은 공유 LRU(최소 최근 사용) 전문가 캐시를 사용합니다. 최근에 라우팅된 전문가는 VRAM에 남아 있을 가능성이 높으며, 캐시 미스는 GPU 캐시 채우기와 직접적인 CPU 실행으로 나뉩니다.
논문에서는 이 균형을 q-star 정책으로 설명합니다. 런타임은 호스트 측 전문가 대역폭과 PCIe 전송 대역폭을 프로파일링한 다음, 해당 측정값을 사용해 누락된 전문가 중 몇 개를 GPU로 이동하고 몇 개를 CPU에서 실행할지 결정합니다.
탄력적 캐시
호스트에 상주하는 모델 풀을 다시 로드하지 않고도 안전한 런타임 지점에서 GPU 전문가 용량을 재구성할 수 있습니다.
시맨틱 상태
사고, 도구 호출, 대화 경계에서 체크포인트를 생성하여 에이전트 세션 중 불필요한 재계산을 줄입니다.
적응형 캐시 미스
측정된 대역폭에 따라 캐시 미스를 GPU 작업 또는 직접적인 CPU 작업으로 처리할 수 있습니다.
그래프 호환성
디바이스에 상주하는 제어 데이터가 라우팅에 의존하는 결정을 캡처된 CUDA 실행과 호환되도록 유지합니다.
시스템 메모리가 많다고 해서 자동으로 성능이 향상되는 것은 아닙니다. PCIe 대역폭, 호스트 메모리 대역폭, CPU 실행 속도, 모델 배치 방식이 모두 최종 결과에 영향을 줍니다.
FreeToken 설정 가이드
FreeToken은 데스크톱 애플리케이션 또는 명령줄 워크플로를 통해 사용할 수 있습니다. CLI는 모델 경로, 실행 인수, 엔드포인트 동작, 런타임 출력을 더 직접적으로 확인할 수 있으므로 반복 가능한 테스트에 유용합니다.
아래 설정 과정은 문서화된 빠른 시작 패턴을 따릅니다. 실행 명령에 지정한 경로에 모델 파일이 이미 존재하는지 확인하세요. 해당 위치에 모델이 없으면 런타임에서 모델을 서빙할 수 없습니다.
런타임 선택
안내형 워크플로를 사용하려면 데스크톱 애플리케이션을 선택하고, 스크립팅 및 벤치마크 자동화를 위해서는 CLI를 사용하세요. 공개된 프로젝트 자료에 따르면 사용 가능한 데스크톱 빌드는 Windows, Linux, macOS를 지원합니다.
패키지 설치
프로젝트에서 권장하는 UV 기반 명령어인 uv pip install freetoken을 사용해 FreeToken을 설치하세요. UV가 설치되어 있지 않다면 먼저 설치하고, 실행 파일이 시스템 PATH에서 사용 가능한지 확인하세요.
모델 경로 확인
지원되는 로컬 모델을 다운로드하거나 준비한 다음, 지정한 디렉터리에 필요한 파일이 포함되어 있는지 확인하세요. 설치가 정상적으로 완료되었다고 해서 모델 실행이 보장되는 것은 아닙니다.
서버 실행
freetoken start --model <model-name-or-path>와 같이 문서화된 모델 인수를 사용해 런타임을 시작하세요. 설치된 릴리스에서 지원하는 정확한 명령어 구문을 사용해야 합니다.
엔드포인트 확인
로컬 OpenAI 호환 엔드포인트에 요청을 보내고, 서빙 중인 모델을 확인한 뒤, 장시간 벤치마크를 시작하기 전에 테스트용 chat-completion 요청을 전송하세요.
| 설정 확인 항목 | 예상 결과 | 문제 해결 초점 |
|---|---|---|
| UV 명령어 작동 | 패키지 설치 시작 | 설치 및 PATH 구성 확인 |
| 종속성 설치 완료 | 런타임 사용 가능 | Python 및 패키지 오류 검토 |
| 모델 경로 확인 | 모델 파일 감지 | 디렉터리 및 파일 권한 확인 |
| 서버 시작 | 로컬 서비스가 수신 대기 | 모델 호환성 및 메모리 확인 |
| 테스트 요청 성공 | Completion 응답 반환 | 엔드포인트, 모델 이름, 요청 형식 확인 |
런타임 콘솔에서는 초당 토큰 속도, 요청 수, 처리된 토큰 총량, 캐시 적중 정보 등 유용한 운영 정보를 확인할 수 있습니다. 모델 구성이 적합한지 판단할 때는 GPU VRAM과 시스템 RAM의 가용량도 중요합니다.
장시간 평가를 실행하기 전에 짧은 요청을 보내세요. 이를 통해 모델 경로, 엔드포인트 이름, 메모리 할당, 기본적인 CPU-GPU 실행 경로를 한 번에 확인할 수 있습니다.
FreeToken 벤치마크 결과
공개된 평가에서는 짧고 독립적인 프롬프트만 사용하는 대신 에이전트 워크로드에서 FreeToken을 테스트합니다. 시나리오에는 수학 추론, 도구를 사용하는 코딩 작업, 네이티브 코딩 에이전트 요청, 이메일 및 캘린더 워크플로가 포함됩니다.
벤치마크는 FreeToken을 llama.cpp, Ollama, KTransformers를 포함한 엣지 서빙 시스템과 비교합니다. 평가에는 RTX 3090, RTX 4090, RTX 5090, RTX 4060 노트북, RTX PRO 6000 Blackwell 워크스테이션 등 여러 GPU 및 호스트 구성이 사용됩니다.
| 모델 | 모델 규모 | 활성 파라미터 | 평가 참고 사항 |
|---|---|---|---|
| DeepSeek-V4-Flash | 284B | 13B | 라우팅된 전문가는 MXFP4 배포 사용 |
| Qwen3.6-35B-A3B | 35B | 3B | BF16으로 테스트했으며, 노트북 빌드는 NVFP4 사용 |
| GLM-5.2 | 753B | 40B | RTX PRO 6000에서 프런티어 규모 시연 |
RTX 5090 평가에서 FreeToken은 Qwen3.6에서 초당 77–83토큰, DeepSeek-V4-Flash에서 초당 22–25토큰을 기록했습니다. 이 수치는 테스트된 워크로드와 구성에 해당하며, 모든 시스템에서 보장되는 보편적인 속도는 아닙니다.
| 워크로드 결과 | 보고된 FreeToken 결과 | 평가에서 설명한 비교 |
|---|---|---|
| Qwen3.6 디코드 | 77–83 tok/s | 워크로드별 가장 강력한 기준선보다 1.8–2.3배 |
| DeepSeek-V4-Flash 디코드 | 22–25 tok/s | 워크로드별 가장 강력한 기준선보다 1.5–1.9배 |
| RTX 4060 노트북 | Qwen3.6 NVFP4에서 39.3 tok/s | 테스트된 RTX 4090 속도의 92% |
| GLM-5.2를 탑재한 RTX PRO 6000 | 14.9 tok/s | llama.cpp의 7.3 tok/s와 비교 |
| 멀티턴 TTFT | 테스트된 셀에서 최악의 턴도 44초 미만 | 하나 이상의 셀에서 기준선은 150초 초과 |
벤치마크는 또한 FreeToken의 캐시 정책이 정적 배치 또는 프리필 기반 배치와 비교해 디코드 중 전문가 캐시 미스를 줄였다고 보고합니다. 테스트된 RTX 5090 용량에서 보고된 미스율은 Qwen3.6이 16%, DeepSeek-V4-Flash가 39%였으며, 평가된 기준선 정책의 미스율은 이보다 높았습니다.
추가 기술 세부 사항은 FreeToken 연구 논문을 참고하세요. 이 논문에서는 대역폭 적응형 실행 정책, 시맨틱 인식 캐싱, 구현 방식, 평가 방법론을 설명합니다.
최상의 결과는 모델 형식, 캐시 용량, 호스트 대역폭, 워크로드 형태에 따라 달라집니다. 공개된 수치는 로컬 환경에서 보장되는 성능이 아니라 참고 기준으로 활용하세요.
실전 테스트 체크리스트
유용한 로컬 벤치마크는 최대 토큰 속도 이상의 정보를 기록해야 합니다. 각 구성에서 동일한 모델, 프롬프트 형식, 양자화 방식, 컨텍스트 길이, 워크로드를 테스트하세요. 에이전트 서빙에서는 멀티턴 컨텍스트와 도구 호출 동작을 유지해야 합니다. 반복되는 프리필이 단일 턴 테스트에서는 드러나지 않는 차이를 보여줄 수 있기 때문입니다.
벤치마크 준비:
- 모델 경로를 확인하고 의도한 모델 형식을 검증합니다
- GPU VRAM, 시스템 메모리, CPU 종류, PCIe 연결 구성을 기록합니다
- 측정값을 수집하기 전에 짧은 워밍업 요청을 실행합니다
- 디코드 처리량과 첫 토큰까지의 시간을 모두 측정합니다
- 에이전트 성능을 평가할 때 멀티턴 또는 도구 사용 워크로드를 반복합니다
| 테스트 변수 | 일관되게 유지할 항목 | 별도로 기록할 항목 |
|---|---|---|
| 모델 | 동일한 체크포인트와 정밀도 | 파일 형식 및 양자화 |
| 프롬프트 | 동일한 텍스트와 토큰 예산 | 컨텍스트 길이 및 턴 수 |
| 런타임 | 동일한 실행 옵션 | 캐시 크기 및 CPU 스레드 수 |
| 하드웨어 | 직접 비교 시 동일한 머신 | 백그라운드 애플리케이션 및 메모리 압박 |
| 메트릭 | 동일한 측정 구간 | 평균, 꼬리 지연 시간, 실패한 요청 |
런타임 콘솔을 사용해 토큰 속도, 요청 총량, 처리된 토큰, 캐시 동작을 모니터링하세요. 실행할 때마다 성능이 달라진다면 다른 애플리케이션이 VRAM을 사용하고 있지는 않은지, 또는 사용 가능한 호스트 메모리 대역폭이 변하지 않았는지 확인하세요.
실용적인 테스트 순서는 다음과 같습니다.
- 정확성을 확인하기 위해 짧은 프롬프트로 시작합니다.
- 기준 디코드 속도를 측정하기 위해 단일 턴 생성을 실행합니다.
- 긴 프롬프트를 추가해 프리필과 TTFT를 관찰합니다.
- 컨텍스트를 재사용하면서 여러 턴을 실행합니다.
- 탄력적인 리소스 동작을 연구하려면 GPU 백그라운드 활동이 있는 상태에서 반복합니다.
대화형 에이전트에서는 꼬리 TTFT를 우선적으로 확인하세요. 짧은 프롬프트에서 더 높은 최대 속도를 내는 것보다 턴 전체에서 안정적인 응답 시간이 더 중요할 수 있습니다.
FreeToken FAQ
Q: FreeToken 벤치마크란 무엇인가요?
대규모 MoE 모델을 위한 엣지 네이티브 서빙 시스템인 FreeToken을 평가하는 벤치마크입니다. 디코드 처리량, 첫 토큰까지의 시간, 전문가 캐시 동작, 소비자용 하드웨어에서의 성능을 측정합니다.
Q: FreeToken을 사용하려면 전체 모델이 VRAM에 들어가야 하나요?
아니요. FreeToken은 전체 전문가 풀을 호스트 메모리에 유지하고, 사용 가능한 GPU 메모리를 탄력적인 캐시로 사용합니다. 다만 모델을 실행하려면 충분한 시스템 메모리, 저장 공간, 호환되는 실행 지원이 필요합니다.
Q: FreeToken은 캐시 미스를 어떻게 처리하나요?
런타임은 선택된 누락 전문가를 GPU로 전송하거나, 다른 캐시 미스를 CPU에서 직접 실행할 수 있습니다. 측정된 대역폭에 기반한 정책이 배포된 머신에 맞는 균형을 결정합니다.
Q: 로컬 API를 통해 FreeToken을 사용할 수 있나요?
예. 문서화된 워크플로에서는 모델 서버가 시작된 후 로컬 OpenAI 호환 엔드포인트를 제공하므로, 호환 클라이언트나 코딩 에이전트가 chat-completion 요청을 보낼 수 있습니다.
FreeToken은 게임이나 콘텐츠 코드 플랫폼이 아니라 로컬 MoE 서빙 시스템으로 이해하는 것이 가장 적절합니다. FreeToken의 가치는 메모리, 대역폭, 캐싱, 실행을 조율하는 데서 나옵니다.