r/LocalLLaMA: 커뮤니티 벤치마크 데이터가 Apple Silicon local LLM 성능 논의를 측정 가능한 형태로 바꾸다
Original: Almost 10,000 Apple Silicon benchmark runs submitted by the community — here's what the data actually shows View original →
이번 주 r/LocalLLaMA에서 빠르게 주목받은 글은 Mac에서 local LLM 성능을 이야기할 때 반복되던 문제를 정면으로 다뤘다. 스크린샷과 체감담은 넘치지만, 비교 가능한 데이터는 거의 없다는 문제다. 작성자는 LM Studio의 benchmark submission 기능과 open-source oMLX 앱 덕분에 그 공백이 빠르게 메워지고 있다고 주장한다. 글에 따르면 약 2주 동안 Apple Silicon 환경에서 거의 10,000건에 이르는 benchmark run이 모였고, 대상 모델도 400개가 넘는다. local inference 커뮤니티에서 이 정도 규모의 공개 비교 자료는 드물기 때문에 반응이 컸다.
글은 데이터셋이 빠르게 커진 이유도 설명한다. 작성자는 oMLX가 3일 만에 GitHub star 3.8k를 기록했고, 이후 benchmark submission이 “flood”처럼 들어오기 시작했다고 적었다. 그 결과 중요한 것은 단순한 run 개수보다도 hardware curve의 형태다. 예를 들어 M5 Max는 Qwen 3.5 122B 4bit 기준 1k에서 8k context 구간에서 약 1,200 PP tok/s에 도달하고 16k까지도 1,000 이상을 유지한다고 한다. M3 Ultra는 1k context에서 약 893 PP tok/s로 시작해 8k까지 비교적 안정적으로 유지된다. 반면 M4 Max는 대부분의 context 길이에서 500대에 머물러 상위 칩과는 다른 tier를 형성한다는 것이 글의 요지다.
이 framing이 중요한 이유는, 작성자가 진짜 흥미로운 비교는 1k context에서의 최고 수치가 아니라 더 긴 context에서 칩들이 어떻게 교차하는지라고 보기 때문이다. unified memory bandwidth, cache behavior, model size가 길어진 prompt에서 서로 다르게 영향을 주기 때문이다. 글은 실시간 비교용 링크 omlx.ai/c/jmxd8a4도 함께 제시해, 정적인 차트보다 더 검증 가능한 형태로 논의를 열었다. 댓글에서는 community-submitted 결과를 어떻게 검증할지, 128k를 넘는 context에서는 어떤 양상이 나오는지, 같은 칩에서도 engine에 따라 large prompt와 concurrent workload에서 어떤 차이가 나는지 같은 후속 질문이 바로 붙었다.
실무적으로 이 글의 가치는 Apple Silicon local inference 논의를 “느낌상 빠르다” 수준에서 조금이나마 측정 가능한 문화로 밀어붙인다는 데 있다. 물론 community benchmark는 항상 검증 문제가 따라오고, 이 데이터셋 역시 완벽하지 않다. 그래도 hardware 구매나 local coding workflow의 실현 가능성을 판단해야 하는 사용자에게는, 흩어진 tok/s 자랑보다 구조화된 dataset이 훨씬 유용하다. Apple Silicon 기반 local LLM 환경을 고민하는 개발자라면 이 스레드가 사실상 공개 기준선 역할을 할 가능성이 있어 계속 추적할 만하다.
Related Articles
최근 r/LocalLLaMA 벤치마크 글은 Apple Silicon에서 MLX와 llama.cpp를 비교할 때 단순 tok/s 화면만 보면 중요한 차이를 놓칠 수 있다고 지적했다. MLX는 짧은 context의 generation에서는 여전히 빠르지만, 긴 context workload에서는 prefill이 전체 지연 시간을 지배해 체감 속도 우위가 크게 줄어들 수 있다.
r/LocalLLaMA의 실험 글은 Qwen 3.5 0.8B를 MacBook Air에서 test feedback loop와 LoRA로 돌려, 13개의 self-generated repair pair만으로 holdout slice를 16/50에서 28/50으로 끌어올렸다는 tinyforge 사례를 공유했다.
새로운 llama.cpp 변경은 <code>--reasoning-budget</code>를 template stub이 아니라 sampler 차원의 실제 제어로 바꾼다. LocalLLaMA thread는 긴 think loop를 줄이는 것과 answer quality를 지키는 것 사이의 tradeoff, 특히 local Qwen 3.5 환경에서의 의미를 집중적으로 논의했다.
Comments (0)
No comments yet. Be the first to comment!