FreeToken llama: 로컬 MoE 설정 가이드 및 팁

FreeToken llama는 독립적인 Llama 제품의 이름이라기보다 로컬 추론을 나타내는 검색어로 이해하는 것이 가장 적절합니다. FreeToken은 소비자용 하드웨어 전반에서 프런티어급 오픈 웨이트 Mixture-of-Experts 모델을 실행하도록 설계된 엣지 네이티브 서빙 엔진입니다. 이 프로젝트는 GPU 연산, CPU 실행, 호스트 메모리 및 인터커넥트 대역폭을 하나의 추론 플랫폼으로 결합합니다.

현재 공개된 프로젝트 정보만으로는 모든 Llama 계열 모델에 대한 보편적인 지원이 확립되어 있지 않습니다. Llama 호환성은 모델별로 확인해야 합니다. 설정을 결정하기 전에 아키텍처, 가중치 형식, 토크나이저, 컨텍스트 동작 및 지원되는 런타임 경로를 확인하세요. 이렇게 하면 모델 제품군과 서빙 엔진을 혼동하는 일을 피할 수 있습니다.

FreeToken 공식 프로젝트 페이지에는 Windows 및 Linux용 데스크톱 애플리케이션과 uv 또는 pip를 통한 명령줄 설치 방법이 안내되어 있습니다. 같은 페이지에서는 대역폭 적응형 CPU–GPU 공동 실행, 이중 버퍼 프리필 스트리밍, 전역 최소 최근 사용(LRU) 전문가 캐싱, 그래프 호환 실행 및 FTW 고속 가중치 형식과 같은 기능을 소개합니다.

주요 용어:

공식 프로젝트 개요: GitHub의 FreeToken

FreeToken은 대규모 MoE 추론의 핵심 문제를 해결합니다. 전체 모델은 사용 가능한 그래픽 메모리보다 훨씬 클 수 있지만, 각 토큰은 전문가 중 일부만 활성화합니다. 따라서 런타임은 어떤 가중치를 GPU에 유지하고, 어떤 가중치를 호스트 메모리에 둘지, 그리고 어떤 가중치를 CPU에서 직접 실행할지 결정해야 합니다.

프리필 중에는 여러 프롬프트 토큰이 광범위한 전문가에 접근합니다. FreeToken은 전체 레이어 이중 버퍼 스트리밍을 사용하여 한 레이어를 계산하는 동안 다음 레이어를 전송합니다. 이 중첩은 모든 전송이 순차적으로 완료되기를 기다리는 대신 연산 작업으로 전송 비용의 일부를 감추는 것을 목표로 합니다.

디코드 중에는 접근 패턴이 희소하고 상호작용 중심으로 변합니다. 정적인 전문가 배치는 자주 요청되는 전문가를 놓칠 수 있으므로 FreeToken은 전역 LRU 전문가 캐시를 유지합니다. 대역폭 적응형 정책은 GPU 채우기와 CPU 실행 사이의 실제 시스템 균형을 측정한 다음, 더 빠르게 완료될 가능성이 높은 경로에 따라 캐시 미스를 분배합니다.

이 프로젝트는 에이전트형 컨텍스트를 위한 의미 인식 캐싱도 소개합니다. 도구 호출, 사고 블록 또는 기타 컨텍스트 편집이 발생할 때 의미 앵커 체크포인트를 활용하면 변경되지 않은 컨텍스트를 다시 계산하는 일을 피할 수 있습니다. 이는 한 번 실행하는 짧은 프롬프트보다 장시간 실행되는 대화형 작업에서 특히 중요합니다.

영상 하이라이트:

• FreeToken은 프리필과 디코드를 서로 다른 대역폭 문제로 분리합니다.
• 전문가 배치와 캐시 미스는 대화형 응답 시간에 영향을 줍니다.
• 로컬 하드웨어로 사용 가능한 GPU 메모리보다 큰 모델을 서비스할 수 있습니다.
• 에이전트 세션에서는 평균 속도뿐 아니라 최악의 턴 지연 시간도 중요합니다.

FreeToken은 이기종 소비자 시스템을 위해 설계되었으므로 GPU 메모리는 용량 계산의 한 부분에 불과합니다. 시스템 RAM은 모델 가중치를 위한 추가 공간을 제공하며, CPU 실행 성능과 메모리 풀 사이의 연결은 누락된 전문가를 얼마나 빠르게 전달할 수 있는지에 영향을 줍니다.

프로젝트 자료에 따르면 특정 테스트 구성에서 8GB 노트북 GPU가 350억 파라미터 모델을 초당 약 39토큰으로 서비스할 수 있습니다. 또한 단일 워크스테이션 GPU에서 7,530억 파라미터 모델을 초당 약 15토큰에 가깝게 실행했다고 보고합니다. 이러한 수치는 참고용 결과이며, 모든 Llama 체크포인트, 운영 체제, 양자화 방식, 프롬프트 또는 하드웨어 구성에 대한 보장은 아닙니다.

같은 성능 논의에서는 꼬리 지연 시간도 강조합니다. 네 가지 대화형 에이전트 작업에서 인용된 비교 기준으로 FreeToken의 가장 느린 턴은 44초 미만을 유지했지만, 기준 구성에서는 테스트 중 일부 구간에서 최소 150초에 도달했습니다. 한 기준 구성에서는 단일 턴에 946초가 필요했습니다. 이러한 수치는 특정 실험 조건을 설명하는 것이므로 보편적인 벤치마크로 간주해서는 안 됩니다.

Llama 계열을 실험할 때는 정확한 체크포인트, 형식, 컨텍스트 길이, 양자화 또는 가중치 표현 방식, GPU, 시스템 메모리 및 런타임 버전을 기록하세요. 이러한 세부 정보가 없으면 비교 결과가 오해를 불러일으킬 수 있습니다. 지역성이 더 나은 작은 모델이 느린 연결을 통해 차가운 전문가를 반복적으로 이동시키는 큰 모델보다 더 빠르게 반응할 수 있습니다.

다음 워크플로를 사용하여 막연한 모델 아이디어를 통제된 로컬 테스트로 전환하세요. 이 순서는 의도적으로 보수적으로 구성되어 있습니다. 먼저 엔진을 검증하고, 모델 지원을 확인한 다음 성능을 조정하세요.

실용적인 첫 테스트에는 짧은 대화형 프롬프트와 의도한 작업 부하를 반영하는 긴 프롬프트를 모두 포함해야 합니다. 짧은 프롬프트는 기본적인 시작 동작을 보여주고, 긴 프롬프트는 프리필 스트리밍과 컨텍스트 처리를 시험합니다. 시스템이 도구를 사용하는 에이전트를 지원할 예정이라면 단일 완료 결과에 의존하지 말고 컨텍스트 편집이 포함된 반복 턴을 테스트하세요.

FreeToken llama 설정이 느리게 느껴질 때는 문제가 로딩, 프리필 또는 디코드 중 어느 단계에서 발생하는지 확인하세요. 각 단계는 서로 다른 병목을 나타냅니다. 긴 시작 지연은 저장 장치 또는 초기 가중치 이동 문제를 의미하는 경우가 많습니다. 첫 응답이 느리다면 프롬프트 처리와 레이어 전송이 원인일 수 있습니다. 토큰 생성 속도가 불규칙하다면 캐시 미스, CPU 폴백, 메모리 압박 또는 열 스로틀링을 의심할 수 있습니다.

평균 속도만을 기준으로 최적화하지 마세요. 단순한 프롬프트에는 빠르게 응답하지만 긴 에이전트 턴에서 멈추는 구성은 실제 사용에 적합하지 않을 수 있습니다. FreeToken의 아키텍처는 최악의 대화형 동작을 명시적으로 고려하므로, 반복 및 혼합 작업 부하가 더 나은 평가 방법입니다.

일반적인 조정 우선순위:

• 스트리밍되는 모델 가중치와 런타임 상태를 위해 충분한 시스템 메모리를 확보하세요.
• 애플리케이션에 전체 대화 기록이 필요하지 않다면 불필요한 컨텍스트를 줄이세요.
• 고립된 프롬프트만이 아니라 캐시에 민감한 대화를 테스트하세요.
• 실제 시스템에서 CPU 폴백과 GPU 채우기 동작을 비교하세요.
• 처음 생성되는 몇 개의 토큰이 아니라 지속적인 성능을 모니터링하세요.
• 여러 설정을 변경하기 전에 정상적으로 작동하는 구성을 보존하세요.

연구 관점에서 이 프로젝트는 논문 제목을 **“FreeToken: Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Execution”**으로 소개합니다. 인용 정보는 공식 저장소와 연결된 arXiv 논문 기록을 통해 확인할 수 있습니다. 저장소에서는 SGLang, vLLM, FlashInfer, LightLLM 및 llama.cpp를 포함한 프로젝트에서 영감을 얻고 설계 아이디어를 재사용했음을 밝히고 있습니다.