FreeToken qwen: 로컬 Qwen MoE 설정 가이드

FreeToken은 대규모 Mixture-of-Experts, 즉 MoE 언어 모델을 위해 설계된 로컬 추론 엔진입니다. FreeToken qwen의 맥락에서 가장 주목할 만한 사용 사례는 GPU 메모리가 제한된 일반 소비자용 하드웨어에서 Qwen3.6–35B 모델을 실행하는 것입니다.

기존의 모델 로딩 방식은 모델 가중치의 대부분 또는 전부를 GPU 메모리에 배치합니다. 모델의 전체 파라미터 수가 사용 가능한 VRAM보다 훨씬 많을 경우 이러한 방식은 어려워집니다. FreeToken은 다른 접근 방식을 취합니다. 전체 가중치 집합을 시스템 RAM에 저장하고, 활성 상태이거나 최근에 사용된 전문가로 구성된 더 작은 작업 캐시를 GPU에 유지합니다.

MoE 모델은 모든 토큰에 대해 모든 전문가를 활성화하지 않기 때문에 이러한 방식이 가능합니다. 라우팅 네트워크는 각 추론 단계마다 전문가의 일부만 선택합니다. 참조된 2026년 보고서에 따르면 Qwen3.6–35B는 전체 파라미터 수가 훨씬 더 많음에도 토큰당 약 3B개의 파라미터를 활성화합니다.

밀집형 35B 모델은 런타임 오버헤드를 고려하기 전에도 상당한 메모리를 필요로 할 수 있습니다. 소스 자료는 이를 MoE의 동작 방식과 대조합니다. Qwen3.6–35B 모델은 각 토큰에 대해 전체 파라미터의 일부만 활성화할 수 있지만, 비활성 전문가도 어딘가에 저장되어야 합니다.

FreeToken은 저장과 실행을 분리합니다. 시스템 RAM은 대규모 가중치 저장소 역할을 하며, GPU 메모리는 더 빠른 캐시로 사용됩니다. 라우터가 현재 캐시되지 않은 전문가를 선택하면 엔진은 해당 전문가를 PCIe를 통해 전송할지, 아니면 CPU 경로를 통해 관련 작업을 실행할지 결정합니다.

라우팅 결정은 토큰마다 달라지기 때문에 이러한 설계가 중요합니다. 고정된 오프로딩 정책은 한 컴퓨터에서는 잘 작동해도 다른 컴퓨터에서는 성능이 좋지 않을 수 있습니다. 반면 FreeToken은 최초 실행 시 로컬 하드웨어를 한 번 프로파일링하고, 측정된 대역폭 관계를 스케줄링 결정에 반영합니다.

보고된 전략은 하드웨어에 민감합니다. 빠른 PCIe 연결을 갖춘 고급 데스크톱 GPU는 전송 방식을 선호할 수 있지만, 8GB 노트북 GPU는 더 많은 캐시 미스를 CPU를 통해 처리하는 편이 유리할 수 있습니다. 메모리 대역폭, RAM 용량, PCIe 세대, 프로세서 성능이 모두 결과에 영향을 주므로 이러한 선택을 시스템 간에 무작정 복사해서는 안 됩니다.

2026년에 공개된 자료에서는 대규모 MoE 모델 전반에 걸친 FreeToken의 여러 벤치마크 수치를 보고합니다. Qwen 사용자에게 가장 관련성이 높은 결과는 8GB GPU에서 Qwen3.6–35B가 초당 39.3토큰을 기록했다는 것입니다. 이러한 수치는 모든 컴퓨터에서 보장되는 결과가 아니라 보고된 결과로 받아들여야 합니다.

성능은 디코딩 속도에만 국한되지 않습니다. 대화형 애플리케이션에서는 지속적인 생성 속도보다 첫 토큰 지연 시간이 더 중요할 수 있습니다. 보고서에서는 에이전트 프레임워크를 위한 체크포인트 컨텍스트 세그먼트를 설명하며, 이를 통해 FreeToken은 편집할 때마다 변경되지 않은 수천 개의 토큰을 다시 계산하는 대신 이전 프리필 작업을 재사용할 수 있습니다.

같은 자료는 벤치마크 비교에서 가장 느린 첫 토큰 지연 시간이 44초 미만이었다고 보고합니다. 이는 llama.cpp의 232초, KTransformers의 946초와 비교되는 수치입니다. 정확한 결과는 워크로드와 시스템 구성에 따라 달라지므로, 이 수치는 보편적인 벤치마크라기보다 최적화 목표를 보여주는 지표로 활용하는 것이 좋습니다.

일부 독립 테스트에서는 llama.cpp를 사용한 유사한 Qwen3.6 35B 양자화 설정이 FreeToken의 주요 디코딩 속도에 근접한 것으로 보고되었습니다. 이 비교는 중요한 차이를 보여줍니다. 짧고 안정적인 디코딩 세션에서의 작은 속도 우위보다, 통합 CPU/GPU 스케줄링과 반복적인 에이전트 프리필에서 FreeToken의 가치가 더 크게 나타날 수 있습니다.

단일 벤치마크 수치가 일상적인 워크로드를 대표한다고 가정하지 않고, 다음 워크플로를 사용해 로컬 Qwen MoE 설정을 평가하세요.

가장 좋은 평가는 대표성 있는 워크로드를 사용합니다. 일반적인 채팅에서는 지속적인 생성 속도가 우선순위일 수 있습니다. 코딩 에이전트에서는 반복적인 컨텍스트 변경과 첫 토큰 지연 시간이 사용 경험을 좌우할 수 있습니다. 모델이 워밍업된 후의 결과를 기록하되, 콜드 스타트 동작은 별도로 문서화하세요.

FreeToken은 원하는 MoE 모델이 GPU의 실제 처리 용량을 초과하지만 시스템 RAM으로는 관리 가능한 경우에 특히 적합합니다. 또한 컨텍스트 기록을 반복적으로 수정하는 코딩 에이전트를 대상으로 합니다. 이러한 경우 체크포인트 세그먼트는 순수 디코딩 속도의 작은 향상보다 더 의미 있는 개선을 제공할 수 있습니다.

물론 이 접근 방식에도 트레이드오프가 있습니다. 시스템 RAM과 GPU 메모리 사이에서 전문가를 이동하면 대역폭 부담이 발생합니다. 긴 프롬프트는 프리필 비용을 증가시킬 수 있으며, 8GB GPU는 더 많은 메모리를 갖춘 데스크톱 GPU와 CPU 실행 및 PCIe 전송 사이에서 다른 균형점을 보일 수 있습니다.

개인정보 보호를 중시하는 사용자의 경우 로컬 추론을 사용하면 프롬프트를 원격 서비스로 전송할 필요를 줄일 수 있습니다. 그러나 로컬에서 실행된다고 해서 모든 워크플로가 자동으로 안전해지는 것은 아닙니다. 로컬 API를 보호하고, 어떤 도구가 해당 API에 연결할 수 있는지 검토하며, 신뢰할 수 없는 네트워크에 추론 엔드포인트를 노출하지 마세요.

이 프로젝트는 Apache 2.0 라이선스로 배포되는 것으로 설명되어 있습니다. 최신 구현 세부 정보는 2026년 8월 23일에 게시된 FreeToken 오픈 소스 개요를 참조하세요.