FreeToken vram: 로컬 MoE 추론 설정 가이드

FreeToken vram은 통합된 로컬 추론 시스템의 일부로 이해하는 것이 가장 좋습니다. FreeToken은 GPU 메모리, 시스템 RAM, CPU 처리, 그리고 이들을 연결하는 PCIe 링크를 결합하여 혼합 전문가(MoE) 모델을 서빙합니다. 라우팅된 전체 전문가 풀은 호스트 메모리에 유지할 수 있으며, 사용 가능한 VRAM에는 비전문가 가중치, 런타임 상태, KV 캐시 페이지 및 최근 사용된 전문가가 저장됩니다.

이 설계가 중요한 이유는 MoE 모델의 전체 파라미터 수가 매우 많더라도 각 토큰에 대해 더 작은 일부만 활성화될 수 있기 때문입니다. DeepSeek-V4-Flash는 284B 파라미터 모델이며 토큰당 약 13B의 활성 파라미터를 사용하는 것으로 설명됩니다. 이로 인해 로컬 서빙이 더욱 실용적이지만, 더 넓은 전문가 풀을 어딘가에 보관해야 한다는 점은 변하지 않습니다.

동영상 주요 내용:

• 단일 GPU 테스트에서 RTX 3090을 사용한 로컬 FreeToken 서빙을 확인할 수 있습니다.
• DeepSeek-V4-Flash는 한 서버 구성에서 초당 약 10~11토큰의 속도를 달성합니다.
• 데스크톱 클라이언트는 실행하기 더 쉽지만 서버 경로보다 처리량이 낮을 수 있습니다.
• 시스템 RAM 용량과 메모리 대역폭은 실제 성능에 직접적인 영향을 줍니다.

실용적인 결론은 간단합니다. VRAM이 많으면 도움이 되지만, VRAM만으로 지원 가능한 모델 범위가 결정되지는 않습니다. GPU가 크더라도 호스트 메모리가 부족한 시스템에서는 프런티어급 모델을 로드하지 못할 수 있습니다. 반대로 RAM이 충분한 시스템은 더 유연한 오프로딩 방식으로 모델을 실행할 수 있지만, 응답 속도는 대역폭에 크게 좌우됩니다.

FreeToken의 메모리 요구 사항은 모델, 양자화 형식, 컨텍스트 길이, 그리고 전문가 캐싱을 위해 예약된 VRAM의 양에 따라 달라집니다. 현재 참고 자료에서는 단일 GPU 구성에 시스템 RAM 32GB를 실용적인 시작점으로 제시하며, 64GB는 더욱 여유로운 사용 범위를 제공합니다. 더 큰 모델에는 상당히 많은 메모리가 필요할 수 있습니다.

전체 모델 용량을 활성 파라미터와 혼동해서는 안 됩니다. 희소 활성화는 각 토큰에 필요한 계산량을 줄이지만, 비활성 전문가도 호스트 메모리나 다른 저장 계층에 계속 유지되어야 합니다. 따라서 계산 측면에서는 실행 가능한 모델이라도 사용 가능한 VRAM과 RAM의 합산 예산이 너무 작으면 로드에 실패할 수 있습니다.

더 긴 컨텍스트는 메모리 균형도 변화시킵니다. 에이전트 세션이 길어지면 KV 캐시 요구량은 증가할 수 있지만 전문가 작업 세트는 비교적 안정적으로 유지됩니다. 따라서 FreeToken은 초기 실행 시 할당량을 영구적인 값으로 취급하는 대신 KV 캐시 페이지와 전문가 캐시 슬롯 간의 배분을 조정해야 합니다.

2026년에 공개된 논문 FreeToken: Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Execution은 이러한 탄력적 메모리 접근 방식을 설명합니다. GPU 전문가 캐시는 엔진을 재시작하거나 CPU에 상주하는 전체 전문가 풀을 다시 로드하지 않고도 스케줄러의 안전 지점에서 재구축할 수 있습니다.

다음 단계에 따라 로컬 FreeToken 배포를 준비하세요. 제공된 테스트 자료에서는 데스크톱 애플리케이션이 베타 소프트웨어로 설명되어 있으므로, 정확한 인터페이스와 지원 모델 목록은 변경될 수 있습니다.

첫 실행은 최종 성능 결과가 아니라 기준선 테스트로 간주해야 합니다. 메모리 사용량, 프롬프트 처리 시간, 디코드 속도 및 여러 요청에서 모델이 안정적으로 유지되는지를 기록하세요.

FreeToken의 성능은 자주 사용되는 전문가를 VRAM에 얼마나 효과적으로 유지하는지와 캐시 미스를 어떻게 처리하는지에 따라 달라집니다. 디코드 중에는 라우팅된 전문가가 이미 상주해 있을 수도 있고 호스트 메모리에서 이동해야 할 수도 있습니다. FreeToken은 공유 LRU 방식의 전문가 캐시를 사용하므로 최근 라우팅 동작이 이후의 상주 상태에 영향을 줄 수 있습니다.

런타임은 또한 캐시 미스를 GPU 전송과 직접적인 CPU 실행으로 나눕니다. 이 분할은 하나의 고정된 규칙이 아니라 측정된 호스트 측 처리 대역폭과 고정 전송 대역폭을 기준으로 결정됩니다. 이러한 방식은 PCIe 성능이 강한 데스크톱과 링크가 좁은 노트북이 서로 다른 배분의 이점을 얻을 수 있다는 점에서 유용합니다.

프리필과 디코드는 서로 다르게 작동합니다. 프리필은 대규모 프롬프트를 처리하므로 전문가 풀의 상당 부분을 이동해야 할 수 있습니다. FreeToken은 사용 가능한 메모리 예산이 허용하는 경우 전체 레이어 더블 버퍼링을 사용하여 전문가 전송과 GPU 계산을 겹쳐 처리합니다. 디코드는 더 점진적으로 진행되지만, 반복적인 캐시 미스는 여전히 응답성을 저하시킬 수 있습니다.

제공된 자료의 테스트에서는 단일 RTX 3090 구성으로 서버 측 한 시나리오에서 초당 약 10.5토큰을 생성했습니다. 다른 구성의 데스크톱 클라이언트 테스트에서는 초당 약 8.8토큰에 도달했습니다. 이 수치는 보편적인 벤치마크가 아니라 특정 구성에 따른 결과이므로 보장된 성능이 아닌 참고값으로 사용하세요.

모든 모델이 FreeToken에서 동일하게 작동하는 것은 아닙니다. 참고된 테스트에서는 한 환경에서 밀집형 Qwen 3.8 27B BF16 구성이 예기치 않은 엔진 종료를 일으키며 시작에 실패했습니다. 이는 메모리 용량뿐만 아니라 모델 호환성, 양자화 형식 및 런타임 지원도 중요하다는 점을 보여 줍니다.

대형 모델은 단순히 사용 가능한 RAM이 부족해서 실패할 수도 있습니다. 한 테스트에서는 GLM-5.2 NVFP4 구성이 사용 가능한 예산을 넘어 수백 GB의 추가 시스템 메모리를 필요로 하는 것으로 나타났습니다. 이러한 모델에는 더 높은 사양의 워크스테이션 구성이 필요할 수 있습니다.

다음과 같이 통제된 순서로 문제를 해결하세요.

• 동일한 모델에 짧은 프롬프트를 사용해 테스트합니다.
• 로드 중에 실패하는지 생성 중에 실패하는지 확인합니다.
• 모델이 지원되는 양자화 형식을 사용하는지 확인합니다.
• 다른 애플리케이션을 종료하기 전후의 사용 가능한 메모리를 비교합니다.
• 재현 가능한 엔진 오류를 보고할 때 서버 로그를 저장합니다.

가장 신뢰할 수 있는 전략은 한 번에 하나의 변수만 변경하는 것입니다. 모델, 클라이언트, 운영 체제 패키지, 메모리 할당 및 추론 모드를 동시에 변경하면 실제 원인을 파악하기 어렵습니다.