- FreeToken 753b 모델은 엣지 네이티브 MoE 엔진을 통해 GLM-5.2를 로컬에서 서비스하는 것을 의미합니다.
- 핵심 방식: GPU에서 활성 작업을 처리하는 동시에 비활성 전문가를 호스트 메모리로 페이징합니다.
- 권장 설정: Linux x86-64, NVIDIA GPU, R580 이상 드라이버 및 CUDA 13을 사용하세요.
- 가장 큰 장점: 데이터센터 GPU 클러스터 없이도 비공개 저지연 추론을 실행할 수 있습니다.
- 주요 제한 사항: 대규모 MoE 모델에는 여전히 상당한 호스트 메모리와 호환 가능한 하드웨어 빌드가 필요합니다.
FreeToken 753b 모델이란?
FreeToken은 매우 큰 오픈 웨이트 혼합 전문가 모델을 개인용 컴퓨터에서 실용적으로 사용할 수 있도록 설계된 엣지 네이티브 서빙 엔진입니다. 중요한 점은 FreeToken 자체가 753B 모델이 아니라는 것입니다. FreeToken은 약 7530억 개의 파라미터를 가진 것으로 설명되는 GLM-5.2를 단일 워크스테이션 GPU에서 서비스하는 런타임입니다.
이 시스템은 컴퓨터 전체를 탄력적인 추론 플랫폼으로 취급합니다. 모든 모델 텐서가 VRAM에 남아 있어야 한다고 가정하는 대신 GPU 메모리, CPU 메모리, 호스트 스토리지, PCIe 대역폭 및 CPU 실행 용량을 조율합니다.
동영상 주요 내용:
- FreeToken은 단일 워크스테이션 GPU에서 약 400억 개의 활성 파라미터를 사용하는 GLM-5.2를 서비스합니다.
- 런타임은 포트 1919에서 OpenAI 호환 및 Anthropic 호환 엔드포인트를 제공합니다.
- 혼합 전문가의 희소성은 각 토큰에 필요한 연산량을 줄입니다.
- 공유 캐시와 호스트 메모리 페이징 시스템은 디코드 중 발생하는 캐시 미스를 줄이는 데 도움을 줍니다.
MoE 모델에서는 전체 파라미터 수가 개별 토큰에 사용되는 파라미터 수보다 훨씬 클 수 있습니다. 예를 들어 DeepSeek-V4-Flash는 43개 레이어에 걸쳐 256명의 전문가 중 6명을 통해 각 토큰을 라우팅합니다. 따라서 하나의 토큰 계산에는 약 13B개의 파라미터가 참여하고, 비활성 전문가는 더 큰 모델 풀에서 사용할 수 있는 상태로 유지됩니다.
| 개념 | 의미 | 중요한 이유 |
|---|---|---|
| 전체 파라미터 | 비활성 전문가를 포함한 전체 모델 용량 | 스토리지 및 호스트 메모리 요구 사항을 결정합니다 |
| 활성 파라미터 | 현재 토큰에 선택된 전문가 | 연산 수요와 토큰 속도에 영향을 줍니다 |
| 전문가 풀 | 사용 가능한 모든 MoE 전문가 | 라우팅이 변경될 때 저장 및 페치되어야 합니다 |
| 호스트 페이징 | 시스템 메모리를 통해 비활성 전문가를 이동하는 방식 | VRAM 한계를 넘어 더 큰 모델을 실행할 수 있게 합니다 |
| 통합 플랫폼 | GPU, CPU, 메모리 및 인터커넥트가 함께 작동하는 환경 | 사용 가능한 하드웨어에 맞춰 실행을 조정합니다 |
753B 파라미터라는 수치가 모든 토큰에서 밀집형 753B 연산을 수행한다는 뜻은 아닙니다. FreeToken은 작업을 관리 가능한 수준으로 만들기 위해 MoE 희소성, 적응형 배치 및 메모리 페이징을 활용합니다.
하드웨어 및 설치 설정
FreeToken은 범용 CPU 전용 배포가 아니라 호환 가능한 NVIDIA 시스템을 대상으로 합니다. 문서에 명시된 명령줄 환경은 NVIDIA GPU, R580 이상 드라이버 및 CUDA 13을 사용하는 Linux x86-64입니다. FlashML을 통해 Windows와 Linux에서 원클릭 데스크톱 애플리케이션도 사용할 수 있습니다.
PyPI 패키지는 freetoken으로 배포되며, 참조된 릴리스 버전은 0.1.2입니다. 일반적인 가속 설치에는 다음 명령을 사용합니다.
uv pip install "freetoken[accel]"
실제 성능은 GPU 세대, 드라이버, 메모리 용량, PCIe 링크, 호스트 메모리 대역폭, 모델 형식 및 해당 구성에 필요한 NVFP4 또는 MXFP4 빌드를 사용할 수 있는지 여부에 따라 달라집니다.
| 설정 영역 | 문서화된 요구 사항 | 실제 확인 사항 |
|---|---|---|
| 운영 체제 | CLI는 Linux x86-64, 데스크톱 앱은 Windows 및 Linux | 설치 전에 아키텍처를 확인하세요 |
| GPU | NVIDIA GPU | 드라이버가 그래픽 카드를 인식하는지 확인하세요 |
| 드라이버 | R580 이상 | nvidia-smi로 확인하세요 |
| CUDA | CUDA 13 대상 | 런타임과 가속기 빌드를 일치시키세요 |
| 패키지 | PyPI의 freetoken[accel] | 격리된 환경에 설치하세요 |
| API 포트 | 포트 1919 | 로컬 서비스를 위해 포트를 예약하세요 |
NVIDIA 환경 확인
GPU가 인식되는지, 드라이버가 R580 이상 요구 사항을 충족하는지, CUDA 스택이 사용하려는 FreeToken 빌드와 호환되는지 확인하세요. 모델을 선택하기 전에 사용 가능한 VRAM과 시스템 RAM을 기록하세요.
가속 패키지 설치
격리된 Python 환경을 만들고 작업 흐름에서 지원하는 패키지 관리자를 사용해 freetoken[accel]을 설치하세요. 문제 해결을 간소화하려면 다른 추론 엔진과 환경을 분리해 두세요.
시스템 대역폭 측정
ft bench bw를 실행해 PCIe 전송 대역폭과 호스트 메모리 대역폭의 관계를 프로파일링하세요. FreeToken은 이 측정값을 사용해 캐시 미스를 GPU 채우기와 CPU 실행 사이에 어떻게 나눌지 결정합니다.
호환 엔드포인트 실행
ft serve로 서빙 프로세스를 시작한 다음, OpenAI 호환 또는 Anthropic 호환 클라이언트를 포트 1919에 연결하세요. 에이전트 워크플로에서는 ft launch claude를 사용해 지원되는 코딩 클라이언트를 로컬 엔드포인트에 연결할 수 있습니다.
공개된 벤치마크 수치를 모든 NVIDIA 카드에서 보장되는 결과로 간주하지 마세요. 드라이버 버전, 양자화 형식, 호스트 RAM, PCIe 토폴로지 및 열 제한은 성능을 크게 바꿀 수 있습니다.
MoE 페이징과 캐싱의 작동 방식
핵심 과제는 단순히 대형 모델을 저장하는 것에 그치지 않습니다. 적절한 전문가를 적절한 시점에 적절한 실행 위치로 이동해야 합니다. 토큰마다 라우팅이 변경되기 때문에 기존의 정적 배치는 비효율적일 수 있습니다. 한 요청에서 사용되지 않던 전문가가 다음 디코드 단계에서는 중요해질 수 있습니다.
FreeToken은 서로 연관된 세 가지 메커니즘을 통해 이 문제를 해결합니다.
첫째, 대역폭 적응형 실행은 PCIe를 통해 전송할 작업량과 CPU에 남겨 둘 작업량을 추정합니다. 시스템은 호스트 메모리 대역폭과 PCIe 대역폭을 프로파일링한 뒤, 그 결과를 사용해 캐시 미스를 분할합니다. 이는 고정된 “GPU 우선” 또는 “CPU 폴백” 규칙보다 유연합니다.
둘째, 시맨틱 인식 캐싱은 에이전트 작업에서 의미가 있는 컨텍스트 경계를 사용합니다. 체크포인트는 사고 블록, 도구 호출 및 도구 출력에 맞춰 정렬될 수 있습니다. 에이전트가 대화의 마지막 부분을 수정하면 런타임은 앞선 모든 작업을 반복하는 대신 변경된 접미사만 프리필하면 될 수 있습니다.
셋째, 탄력적 메모리 관리는 수정된 VRAM 예산에 따라 안전한 스케줄러 지점에서 GPU 전문가 캐시를 재구축할 수 있게 합니다. 전체 엔진을 재시작하거나 GPU를 완전히 워밍업하지 않고도 전문가를 최종 호스트 레이아웃에 로드할 수 있습니다.
| 메커니즘 | 작동 원리 | 가장 큰 장점 |
|---|---|---|
| 대역폭 적응형 실행 | PCIe 채우기와 CPU 연산 사이에 캐시 미스를 분할합니다 | 실제 시스템 프로필을 활용합니다 |
| 시맨틱 인식 캐싱 | 에이전트 경계에 반복 상태 체크포인트를 배치합니다 | 반복적인 프리필 작업을 줄입니다 |
| 전역 LRU 전문가 캐시 | MoE 레이어 전체에서 캐시 결정을 공유합니다 | 변화하는 라우터 수요를 추적합니다 |
| 탄력적 메모리 관리 | 새로운 VRAM 예산에 맞춰 GPU 캐시를 재구축합니다 | 엔진을 재시작하지 않고 적응합니다 |
| 직접 호스트 로딩 | 전문가를 최종 호스트 레이아웃으로 읽어 들입니다 | 불필요한 재배치를 방지합니다 |
동일한 캐시 용량에서 보고된 전역 LRU 전략은 인용된 평가의 Qwen3.6 풀에서 디코드 중 전문가 읽기 캐시 미스율 16%를 기록했습니다. 이는 KTransformers의 41%, llama.cpp의 62%와 비교됩니다. 이 수치는 특정 테스트 설정을 기준으로 하지만, 에이전트 기반 디코딩에서 전역 라우팅 인식이 중요한 이유를 보여줍니다.
가장 큰 개선 효과는 라우팅, 메모리 배치 및 대역폭 측정을 조율할 때 얻을 수 있습니다. VRAM만 늘린다고 모든 MoE 서빙 병목이 해결되는 것은 아닙니다.
성능 벤치마크 및 모델 적합성
보고된 결과는 FreeToken이 오프라인 배치 처리뿐만 아니라 대화형 로컬 추론을 목표로 한다는 것을 보여줍니다. RTX 5090에서 런타임은 BF16의 Qwen3.6-35B-A3B에서 초당 77–83토큰, MXFP4의 DeepSeek-V4-Flash에서 초당 22–25토큰을 지속적으로 처리했습니다.
8GB RTX 4060 노트북에서는 NVFP4 빌드가 35B 모델을 초당 39.3토큰으로 서비스했습니다. RTX PRO 6000에서는 약 40B개의 활성 파라미터를 사용하는 GLM-5.2가 초당 14.9토큰을 기록했으며, 인용된 테스트에서 llama.cpp의 초당 7.3토큰과 비교되었습니다.
| 하드웨어 | 모델 또는 빌드 | 보고된 처리량 | 컨텍스트 |
|---|---|---|---|
| RTX 5090 | Qwen3.6-35B-A3B, BF16 | 77–83 tok/s | 지속적인 디코드 |
| RTX 5090 | DeepSeek-V4-Flash, MXFP4 | 22–25 tok/s | 지속적인 디코드 |
| RTX 4060, 8GB | 35B 모델, NVFP4 | 39.3 tok/s | 노트북 GPU 결과 |
| RTX PRO 6000 | GLM-5.2, 약 40B 활성 | 14.9 tok/s | llama.cpp의 7.3 tok/s와 비교 |
| RTX 5090 | 에이전트 작업 | 단일 턴 디코드 대비 12% 이내 | 보고된 세 가지 작업 |
동일한 평가에서는 테스트 매트릭스 전체에서 최악의 첫 토큰 생성 시간도 44초 미만이라고 보고했습니다. 일부 사례에서 기준 엔진은 더 높은 최악 지연 시간을 기록했으며, llama.cpp는 232초, Ollama는 179초, KTransformers는 946초에 달했습니다. 에이전트 클라이언트에서는 긴 시작 지연으로 인해 타임아웃이 발생할 수 있으므로 이러한 비교가 유용하지만, 보편적인 벤치마크로 해석해서는 안 됩니다.
가장 적합: 비공개 에이전트
- 로컬 코딩 어시스턴트
- 민감한 프로젝트 컨텍스트
- 저지연 대화형 세션
- OpenAI 호환 클라이언트 지원
높은 적합성: 대규모 MoE 모델
- 로컬 VRAM을 초과하는 모델
- 동적 전문가 라우팅
- 충분한 호스트 메모리 용량
- GPU 캐시 튜닝 필요
주의해서 사용: 프로덕션 규모
- 제한적인 워크스테이션 하드웨어
- 많은 동시 요청 수
- 엄격한 지연 시간 서비스 수준 목표
- 데이터센터 대체에 대한 기대
FreeToken은 프런티어급 모델을 워크스테이션에서 더 쉽게 사용할 수 있도록 하지만, 동시성, 모델 로딩 시간, 메모리 압박 및 하드웨어 호환성이 여전히 실제 배포 한계를 결정합니다.
배포 체크리스트 및 문제 해결
안정적인 FreeToken 배포는 추측이 아니라 측정에서 시작됩니다. 시스템 프로필을 확인하고, 호환 가능한 모델 형식을 선택한 다음, 전체 에이전트 스택을 연결하기 전에 짧은 요청을 테스트하세요.
엔드포인트를 사용할 준비가 되었다고 판단하기 전에 다음 체크리스트를 사용하세요.
배포 준비 상태:
- NVIDIA GPU와 R580 이상 드라이버를 확인합니다
- CUDA 13과 선택한 NVFP4 또는 MXFP4 빌드를 확인합니다
- ft bench bw로 PCIe 및 호스트 메모리 대역폭을 측정합니다
- 로컬 API 엔드포인트에 포트 1919를 예약합니다
- 에이전트 도구를 활성화하기 전에 짧은 완료 요청을 테스트합니다
| 증상 | 가능한 원인 | 권장 조치 |
|---|---|---|
| 설치 실패 | 드라이버, CUDA 또는 가속기 불일치 | 지원되는 빌드와 환경을 다시 확인합니다 |
| 낮은 디코드 속도 | 약한 호스트 대역폭 또는 불량한 PCIe 링크 | 대역폭 프로파일링을 실행하고 토폴로지를 점검합니다 |
| 잦은 전문가 캐시 미스 | 캐시 예산이 너무 작거나 라우팅이 빠르게 변경됨 | 가능한 경우 사용 가능한 캐시를 늘립니다 |
| 높은 프리필 지연 시간 | 큰 컨텍스트 또는 광범위한 전문가 트래픽 | 시맨틱 체크포인트와 더 짧은 테스트 프롬프트를 사용합니다 |
| 에이전트 타임아웃 | 첫 토큰 생성의 최악 지연 시간이 너무 높음 | 작업량을 줄이고 다른 모델 형식을 테스트하거나 원격 런타임을 사용합니다 |
코딩 어시스턴트의 경우 적당한 컨텍스트와 단일 도구 호출로 시작하세요. 첫 토큰 지연 시간, 디코드 속도, 호스트 메모리 사용량 및 GPU 사용률을 관찰합니다. CPU와 메모리 버스가 포화된 동안 GPU가 유휴 상태라면 문제는 모델 연산 부족이 아니라 전송 또는 호스트 실행 대역폭일 수 있습니다.
문서화된 실행 워크플로를 통해 FreeToken을 Claude Code, Codex, OpenCode 또는 OpenClaw에도 연결할 수 있습니다. 도구를 활성화할 때는 권한을 제한적으로 유지하세요. 특히 엔드포인트가 로컬 시스템 외부에서 접근 가능한 경우 더욱 주의해야 합니다.
API 호환 로컬 엔드포인트도 서비스 경계로 취급해야 합니다. 네트워크 노출을 제한하고, 에이전트 권한을 검토하며, 신뢰할 수 없는 공개 인터페이스에 포트 1919를 배치하지 마세요.
FreeToken 753b 모델 FAQ
다음 답변은 2026년에 로컬 753B급 모델 서빙을 평가하는 개발자에게 가장 중요한 실용적 내용을 요약합니다.
Q: FreeToken 자체가 753B 모델인가요?
아니요. FreeToken은 서빙 엔진입니다. 753B라는 표현은 GLM-5.2를 가리키며, 워크스테이션 평가에서 FreeToken은 약 40B개의 활성 파라미터를 사용하는 이 모델을 서비스할 수 있는 것으로 보고되었습니다.
Q: FreeToken을 단일 소비자용 GPU에서 실행할 수 있나요?
인용된 결과에는 8GB RTX 4060에서 실행한 35B 모델과 워크스테이션 하드웨어에서 실행한 더 큰 모델이 포함되어 있습니다. 단일 워크스테이션 GPU에서의 GLM-5.2 실행 결과는 RTX PRO 6000에서 보고되었으므로 하드웨어 용량과 모델 형식이 여전히 중요합니다.
Q: CLI에 필요한 운영 체제와 드라이버는 무엇인가요?
문서화된 CLI 대상 환경은 NVIDIA GPU, R580 이상 드라이버 및 CUDA 13을 사용하는 Linux x86-64입니다. Windows와 Linux용 원클릭 데스크톱 앱도 설명되어 있습니다.
Q: FreeToken에는 왜 이렇게 많은 호스트 메모리가 필요한가요?
MoE 희소성은 활성 연산량을 줄이지만 비활성 전문가를 모델 풀에서 제거하지는 않습니다. 이러한 전문가는 호스트 메모리에 남아 있다가 라우팅에 필요할 때 페치될 수 있습니다.
추가 기술 정보는 MarkTechPost가 게시한 FreeToken 753B GLM-5.2 분석 기사를 참고하세요. 이 글에서는 서빙 아키텍처, 보고된 벤치마크, 설치 세부 정보 및 배포 제한 사항을 다룹니다.
개인정보 보호, 로컬 제어 및 워크스테이션 추론이 중요하다면 FreeToken을 사용하세요. 먼저 대역폭을 프로파일링하고, 올바른 양자화 빌드를 선택한 다음, 작업량을 확대하기 전에 에이전트 지연 시간을 검증하세요.