SiliconBench가 보여준 로컬 LLM 서빙의 진짜 기준

들어가며

Apple Silicon에서 로컬 LLM을 실행할 때 가장 쉽게 비교하는 수치는 초당 생성 토큰 수다. 하지만 여러 채팅 세션이나 에이전트 작업을 동시에 처리하려면 단순한 속도만으로는 충분하지 않다. 통합 메모리가 모델 가중치와 KV 캐시, 활성 요청을 감당할 여유를 유지하는지, 그리고 동시 실행 중에도 출력 품질이 보존되는지가 실제 서비스 가능성을 좌우한다. SiliconBench는 이 문제를 속도, 메모리, 출력 충실도의 세 축으로 평가했다.

핵심 결과

• Apple Silicon의 9개 엔진을 평가했다. 대상은 vllm-metal, omlx, llama.cpp, Ollama, mlx_lm, vllm-mlx, SGLang, Hugging Face Transformers, mistral.rs다. DGX Spark에서는 vLLM, SGLang, llama.cpp를 보조적인 서빙 성능 기준으로 비교했다.
• 동시성 확장은 엔진 구조에 따라 달라진다. Qwen3-0.6B에서 동시 실행 수가 1에서 16으로 증가하자 vllm-metal은 채팅과 에이전트 워크로드 모두에서 처리량을 두 배 이상 높였다. 그러나 같은 프롬프트를 사용한 비교에서는 CUDA vLLM과 SGLang이 더 강한 동시성 확장성을 보였다.
• 메모리 제한이 곧 안전한 여유를 의미하지는 않는다. 두 스택은 모든 요청을 완료했지만 메모리 사용량이 물리 용량에 가까워졌고 처리량은 떨어졌다. 통합 메모리 시스템에서는 모델, KV 캐시, 동시 요청이 동일한 자원을 공유하므로, 설정된 예산만으로 안정적인 운영을 보장할 수 없다.
• 모델 지원 범위와 품질을 함께 봐야 한다. 최신 Qwen3.5와 Gemma 4는 지원 엔진의 범위가 더 좁았다. 평가된 구현은 NVIDIA 기준 결과와 충실도가 일치했지만, 요청 완료, 출력 충실도, 모델 지원 범위라는 세 조건을 모두 통과한 스택은 3개뿐이었다.
• 첫 토큰 지연은 스케줄링 차이를 드러낸다. 더 큰 밀집 모델과 MoE 모델을 대상으로 한 테스트에서 vllm-metal의 패킹된 prefill-decode 경로는 동시 부하에서 omlx보다 낮은 첫 토큰 지연을 유지했다. 지속적인 생성 중에도 새 프롬프트 처리를 어떻게 배치하느냐가 중요하다는 의미다.
• 멀티노드에서는 연결 방식이 중요하다. 평가된 두 대 구성에서는 Thunderbolt RDMA를 이용한 텐서 병렬화가 확장됐지만, TCP를 이용한 파이프라인 병렬화는 성능 저하를 보였다.

의미와 영향

SiliconBench의 핵심은 특정 환경에서 사용할 단 하나의 최고 엔진을 선언하는 데 있지 않다. 단일 요청의 속도가 뛰어난 백엔드라도 여러 대화나 에이전트 작업을 동시에 처리하면 메모리 압박과 첫 응답 지연이 나타날 수 있다. 따라서 로컬 추론 엔진은 처리량 하나가 아니라 실제 워크로드에 맞춰 선택해야 한다.

사용자는 먼저 필요한 모델이 지원되는지 확인하고, 현실적인 동시 요청 수에서 메모리 여유와 처리량을 측정한 뒤, 작업 수준의 품질 검증을 진행해야 한다. 엔진 개발자에게는 커널 최적화뿐 아니라 prefill-decode 스케줄링, 메모리 관리의 가시성, 새로운 모델 구조 지원, 다중 노드 통신이 모두 중요한 과제가 된다.

Hugging Face Daily Papers