LFM2.5-DSpark, MacBook에서 140tok/s 구현한 추론 가속 방식

LFM2.5-DSpark의 성능 수치와 가속 범위

M4 Max MacBook Pro에서 LFM2.5-2.6B 모델이 약 140tok/s의 처리량을 기록하며 클라우드 모델 수준의 상호작용성을 확보했고, DSpark 적용 시 추론 속도는 최대 3.2배 향상되었다. 이는 고성능 서버 인프라 없이도 로컬 기기에서 실시간 응답이 가능한 수준의 속도를 구현할 수 있음을 보여준다. 하드웨어의 물리적 제약을 소프트웨어 가속으로 보완해 사용자 인터페이스의 반응 속도를 높여 실제 서비스 적용 가능성을 확장했다.

성능 검증은 대규모 연산 자원인 H100 80GB GPU와 엣지 컴퓨팅 환경인 M4 Max MacBook Pro에서 각각 수행되었다. GPU 환경에서는 SGLang(추론 최적화 프레임워크)을 활용해 BF16 정밀도로 처리량을 측정했다. MacBook 환경에서는 llama.cpp와 Metal(애플의 그래픽 가속 API)을 조합해 FP16 GGUF 가중치를 사용했으며, 최대 256개의 출력 토큰을 생성하는 조건으로 테스트했다. 두 환경 모두 DSpark 블록 크기를 9로 설정하고 배치 크기 1과 온도 0을 적용했으며, 총 5개의 서로 다른 벤치마크 데이터셋을 사용하여 다양한 입력 조건에서도 결과의 객관성을 확보했다.

LFM2.5-2.6B 모델은 복잡한 작업을 수행하는 멀티 툴 시나리오에서 지연 시간이 평균 57% 감소하는 성과를 냈다. 반면 LFM2.5-1.2B-Instruct 모델은 입력되는 데이터 분포에 따라 수락률의 편차가 크게 발생하는 특성을 보였다. 이로 인해 데이터셋의 성격에 따라 추론 속도 향상 폭이 최대 52%까지 변동되는 결과가 관찰되었다. 이는 모델의 파라미터 규모와 처리하는 텍스트의 통계적 특성에 따라 가속 효율이 다르게 나타난 결과다.

DSpark는 H100과 같은 고성능 가속기와 M4 Max MacBook 같은 개인용 단말기 모두에서 처리량 개선 효과를 확인했다. 하드웨어 규모에 상관없이 추론 속도를 높일 수 있다는 점은 모델 배포 전략의 유연성을 넓히는 핵심 요소다. 특히 엣지 환경에서 클라우드 수준의 처리량을 확보함으로써 온디바이스 AI의 실용성을 높였다. 측정된 수치는 DSpark가 서로 다른 아키텍처를 가진 하드웨어 환경에서도 일관되게 작동하며 추론 병목을 해결하는 실질적인 수단임을 보여준다.

300M 드래프트 모델 기반의 투기적 디코딩 작동 방식

투기적 디코딩은 약 300M 파라미터 규모의 가벼운 드래프트 모델이 후보 토큰을 먼저 생성하고 타겟 모델이 이를 한 번의 순전파로 검증하는 방식이다. 순전파(Forward Pass)는 입력 데이터가 신경망의 층을 통과하며 결과값을 내는 과정이다. 이 구조는 메모리 대역폭 병목, 즉 데이터가 메모리와 프로세서 사이를 이동할 때 발생하는 속도 제한 문제를 해결한다. 드래프트 모델이 미리 예측한 여러 개의 토큰을 타겟 모델이 일괄적으로 확인함으로써 전체 추론 횟수를 줄이는 원리다.

드래프트 모델은 5개 레이어와 블록 크기 9로 구성된 어텐션 전용 구조를 가진다. 어텐션 전용 모델은 복잡한 연산 층을 걷어내고 토큰 간의 관계를 계산하는 어텐션 메커니즘만 남긴 단순한 형태다. 블록 크기 9는 드래프트 모델이 한 번에 최대 9개의 토큰 후보를 제안할 수 있음을 의미한다. 이 블록 크기 값은 사이드카 메타데이터(Sidecar Metadata, 모델 부가 정보 파일)에서 읽어오며, 타겟 모델은 이 범위 내에서 제안된 토큰들을 동시에 검토하여 수락 여부를 결정한다.

학습 과정에서는 SFT(지도 미세 조정), 채팅, 코드, 함수 호출(function-calling) 데이터를 혼합해 사용했다. 함수 호출은 모델이 외부 도구를 사용하기 위해 특정 형식의 명령어를 생성하는 기능이다. 전체 데이터셋에 대해 15 에포크(epoch)를 실행했으며, 에포크는 전체 학습 데이터를 한 번 모두 훑는 단위를 말한다. 모델 선택 기준은 일반적인 손실 값(loss)의 최솟값이 아니라 수락률(acceptance rate)이 가장 높은 시점이었다. 수락률은 드래프트 모델이 제안한 토큰을 타겟 모델이 그대로 인정하는 비율을 뜻하며, 이는 두 모델의 출력 분포를 최대한 일치시키기 위한 선택이다.

그리디 디코딩(Greedy Decoding) 환경에서 드래프트 토큰은 타겟 모델의 확률 분포와 일치할 때만 수락된다. 그리디 디코딩은 매 단계에서 가장 확률이 높은 토큰 하나만 선택하는 방식이다. 만약 제안된 토큰이 타겟 모델의 예측과 다르면 즉시 거부되고 타겟 모델이 생성한 토큰이 그 자리를 대체한다. 응답별 타이밍 기록에서는 제안된 토큰 수와 수락된 토큰 수의 비율인 `draft_n / draft_n_accepted` 형태로 성능을 측정한다. 타겟 모델이 제안된 모든 토큰을 엄격하게 검증하므로 결과값의 무결성이 보장된다. 이 과정은 구조적으로 타겟 모델 단독 생성 결과와 완전히 동일하게 설계되었으므로 pass@1(첫 번째 생성 결과의 정답률)이나 exact match(정확한 일치도) 같은 벤치마크 정확도는 기존 모델과 동일하게 유지된다.

모델 구조 및 하드웨어별 가속 효율 대비

LFM2.5-2.6B 모델은 MacBook 환경에서 가장 뚜렷한 가속 효과를 나타낸다. 데이터셋의 특성에 따라 일부 차이가 존재하지만 초당 약 140개의 토큰을 생성하는 140tok/s 수준의 처리량을 기록한다. 이는 대다수의 상용 클라우드 모델이 제공하는 일반적인 처리 속도를 크게 상회하는 수치다. 로컬 하드웨어만으로 클라우드 서비스 이상의 즉각적인 응답성을 확보함으로써 사용자가 체감하는 인터랙티브 수준을 실질적으로 높였다.

반면 MoE 구조를 채택한 LFM2.5-8B-A1B 모델은 평균 18%라는 상대적으로 낮은 개선율을 기록했다. MoE는 Mixture of Experts의 약자로 모든 파라미터를 사용하는 대신 입력값에 적합한 일부 전문가 파라미터만 선택적으로 활성화하는 구조다. 이 모델은 일반적인 Dense 모델과 비교했을 때 토큰 수락률이 더 높게 측정되는 특성을 보인다. 수락률은 드래프트 모델이 제안한 후보 토큰을 타겟 모델이 검증했을 때 일치하여 그대로 채택하는 비율을 의미한다. 하지만 높은 수락률이 실제 추론 속도의 비례적인 상승으로 연결되지 않는 성능 간극이 확인되었다.

가속 효율이 저하되는 구체적인 원인은 llama.cpp의 Metal 백엔드 구현 한계와 가중치 트래픽 증가에 있다. Metal은 애플 실리콘의 GPU 성능을 최적화하여 사용하는 하드웨어 가속 프레임워크다. 투기적 디코딩 구조에서 k개의 후보 토큰을 한 번에 검증하려면 단일 토큰을 생성하는 단계보다 훨씬 더 많은 전문가 모델을 동시에 활성화해야 한다. 이 과정에서 메모리와 프로세서 사이를 오가는 가중치 트래픽, 즉 데이터 전송량이 급격히 증가하며 시스템 병목이 발생한다. 결국 연산 자체의 속도보다 데이터를 옮기는 비용이 더 커지면서 MoE 모델이 가진 구조적 이점이 가속 효율 면에서 상쇄된다.

LFM2.5-1.2B-Instruct 모델의 경우 처리하는 텍스트 분포에 따라 속도 향상 폭의 변동성이 매우 크게 나타난다. 이는 드래프트 모델이 예측하는 토큰의 정확도가 입력 데이터의 성격이나 도메인에 따라 민감하게 반응하기 때문이다. 특정 텍스트 패턴에서는 타겟 모델과 예측 분포가 일치하여 높은 수락률을 기록하고 속도가 빠르게 상승하는 결과가 나온다. 반면 분포가 다른 데이터에서는 수락률이 급격히 떨어지며 가속 효과가 미미해지는 현상이 반복된다. 모델의 파라미터 규모가 작을수록 이러한 데이터 분포에 따른 수락률 편차가 실제 추론 속도의 변동성으로 직접 연결된다.

SGLang 및 llama.cpp 구현 세부 사항

SGLang(고성능 LLM 추론 엔진)을 사용하는 개발자는 PR #31041이 반영된 빌드를 통해 LFM2.5 타겟 모델에 DSpark를 즉시 적용할 수 있다. 이 구현은 공식 SGLang 코드베이스의 DSpark 구현체를 기반으로 하며 타겟 모델과 드래프트 모델을 결합해 추론 속도를 높인다. 서버를 실행할 때는 다음과 같은 명령어를 입력해 타겟 모델에 드래프트 모델을 연결한다.

bash

python -m sglang.launch_server --model-path <target> --speculative-model <draft> --speculative-draft <draft> --speculative-block-size 9

명령어 내 `speculative-block-size` 플래그는 드래프트 모델이 한 번의 단계에서 생성할 후보 토큰의 개수를 결정한다. 이 수치가 적절히 설정되어야 타겟 모델의 검증 효율이 극대화된다.

llama.cpp(C++ 기반 LLM 추론 라이브러리) 환경에서는 PR #27383 빌드가 필수적이며 실험적인 Metal 커널을 사용해 구동한다. Metal 커널은 애플 실리콘 GPU의 연산 자원을 직접 제어해 처리량을 높이는 하드웨어 가속 인터페이스다. 모델 가중치는 Hugging Face의 https://huggingface.co/liquidai 저장소에서 Safetensors와 GGUF 포맷으로 제공된다. Safetensors는 텐서 데이터를 직렬화해 빠르게 로드하는 포맷이며 GGUF는 llama.cpp에서 메모리 매핑을 통해 효율적으로 모델을 읽어오는 전용 포맷이다. 사용자는 자신의 하드웨어 환경과 추론 프레임워크에 맞춰 두 포맷 중 하나를 선택해 내려받으면 된다.

추론 성능을 결정하는 핵심 설정값인 블록 크기는 드래프트 모델의 `config.json` 파일이나 사이드카 메타데이터에서 자동으로 읽어온다. 사이드카 메타데이터는 모델 가중치 파일과 별개로 구성되어 모델의 하이퍼파라미터나 실행 설정을 저장하는 보조 데이터 파일이다. 개발자는 공식 코드베이스의 PR 반영분과 특정 플래그 설정만으로 투기적 디코딩 시스템을 즉시 가동할 수 있다. 이는 복잡한 수동 최적화 과정 없이 가중치 로드와 명령어 입력만으로 추론 인프라를 구성할 수 있음을 의미한다. 다양한 포맷의 가중치 제공은 클라우드 GPU 서버부터 로컬 맥북 환경까지 폭넓은 배포 가능성을 확보한다.

온디바이스 AI 실무 적용 시 판단 기준

140tok/s(초당 토큰 생성 수) 수준의 처리량은 상용 클라우드 모델이 제공하는 평균적인 응답 속도를 넘어선 사용자 경험을 제공한다. 텍스트가 한 글자씩 출력되는 것을 기다리는 기존의 방식에서 벗어나, 사용자가 인지하는 즉시 전체 답변이 화면에 나타나는 인터랙티브 환경을 구축할 수 있다. 이는 온디바이스 AI가 단순한 보조 도구를 넘어 실시간 인터페이스로 작동하기 위한 성능 기준이 된다.

MoE(Mixture of Experts, 전문가 혼합) 구조의 모델을 에지 디바이스에 배포할 때는 검증 토큰 수 증가에 따른 가중치 이동량 변화를 주의 깊게 살펴야 한다. 검증해야 할 토큰 수가 많아질수록 더 많은 전문가 레이어가 활성화되어 메모리 대역폭에 가해지는 부하가 급격히 커진다. 특히 메모리 자원이 제한적인 에지 환경에서는 이 가중치 이동 시간이 계산 시간보다 길어지는 병목 현상이 발생할 수 있다. 런타임 백엔드가 MoE의 동적 가중치 로딩을 최적화하지 못했다면, 투기적 디코딩을 적용하더라도 기대만큼의 가속 효과를 얻기 어렵다.

실제 가속 효율은 llama.cpp(LLM 추론용 C++ 라이브러리) 실행 시 출력되는 `draft_n`과 `draft_n_accepted` 지표의 비율로 측정한다. `draft_n`은 가벼운 드래프트 모델이 미리 제안한 토큰의 개수이며, `draft_n_accepted`는 타겟 모델이 이를 검증하여 최종적으로 수락한 개수다. 이 비율이 1에 가까울수록 드래프트 모델의 예측 정확도가 높다는 뜻이며, 이는 곧 불필요한 재계산 없이 추론 속도가 선형적으로 증가함을 의미한다.

SGLang(고성능 LLM 서빙 프레임워크) 기반의 가속을 구현하려면 PR#31041 패치를 적용한 뒤 `http://localhost:30000/v1` 엔드포인트로 쿼리를 전송한다. llama.cpp 환경에서는 PR#27383 빌드를 통해 해당 기능을 활성화해야 한다. 드래프트 모델의 블록 크기는 `config.json` 설정 파일에서 자동으로 읽어오며, 가속 성능의 객관적 수치는 `--speculative-*` 플래그를 제외한 기본 실행 명령어의 처리량과 직접 대비하여 산출한다. 이러한 베이스라인 대비 측정 방식은 하드웨어별 가속 효율을 정량적으로 판단하는 근거가 된다.

H100 GPU와 같은 고대역폭 메모리 환경에서는 MoE 모델의 가중치 이동 부하를 충분히 처리할 수 있으나, M4 Max와 같은 통합 메모리 기반 에지 디바이스에서는 모델의 밀집도와 백엔드 최적화 수준에 따라 Dense 모델의 가속 효율이 더 높게 나타난다.