(https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fiypc2lmv2ga0hnqyosc8.png)

저는 약 1년 반 동안 로컬 LLM을 구동해 왔습니다. 그리고 솔직히 말해서? 그 시간의 대부분 동안 잘못하고 있었습니다.

새로 나오는 모델은 전부 다운로드했습니다. Gemma 4요? 가져왔죠. Llama 4도요? 물론이죠. Mixtral 8x22B도요? 왜 안 되나요. 제 SSD는 가득 찼고, GPU는 과열되었으며, 저는 다음 출시작이 마침내 모든 것을 작동하게 할 '그것'일 거라고 계속 생각했습니다.

하지만 그렇지 않았습니다.

지난주에 제가 완전히 설정을 뒤엎는 무언가를 발견했습니다: Mesh LLM. 이것은 여러 대의 머신에 걸쳐 GPU를 하나의 통합 API로 모아주는 오픈 소스 도구입니다. 비슷한 시기에 저는 Apple의 실리콘 책임자인 Tim Millet이 $799짜리 Mac Mini가 AI 에이전트 워크로드를 아무 문제 없이 처리할 수 있다고 말하는 것을 읽었습니다. 서로 다른 두 이야기지만, 결론은 같습니다: 당신은 이미 필요한 하드웨어를 가지고 있습니다.

모델을 모으는 함정

XDA에 올라온 글 하나가 정말 와닿았습니다. 누군가가 AI 모델의 '포켓몬 접근 방식'을 멈추라고 쓴 글이었는데, 저는 개인적으로 공격받은 기분이 들었습니다. 왜냐하면 그게 바로 저였기 때문입니다. 모든 새로운 출시는 절박하게 느껴졌습니다. 여러분은 벤치마크 점수와 과장된 게시물을 보고, 갑자기 자신의 로컬 설정이 구식이라고 느낍니다.

하지만 아무도 알려주지 않는 것이 있습니다: 구조화된 추론을 위해 파인튜닝된 2년 된 코딩 LLM이 적절하게 프롬프팅만 한다면 Gemma 4보다 비코딩 작업에서 더 나은 성능을 보일 수 있다는 것입니다. XDA 작성자는 이를 증명했습니다. 반짝이는 새 모델 대신 오래된 CodeLlama 변형 모델로 교체하자, 그들의 로컬 설정이 '더 잘' 작동했습니다. 더 빠른 추론 속도, 낮은 메모리 사용량, 더 일관된 출력입니다.

직접 경험해 보았습니다. 평소 에이전트 워크플로우(코드 리뷰, 요약, 간단한 데이터 추출 등)에 사용하던 기본 Qwen2.5를 구형 DeepSeek-Coder 변형 모델로 교체했습니다. 출력 품질의 차이는 거의 느껴지지 않았지만, 속도 향상은 확실했습니다. 제 작은 RTX 4060 노트북이 갑자기 더 많은 여유 공간을 가진 것처럼 느껴졌습니다.

AI 에이전트 허브로서의 Mac Mini

이제 Apple에 대한 이야기입니다. Tim Millet은 TechRadar에 저에게 깊은 인상을 남긴 말을 했습니다.

이 시스템의 영리한 점은 대규모 모델을 처리하는 방식입니다. 이 시스템의 'Skippy' 모드는 모델을 레이어 범위별로 노드에 분할합니다: 기계 A에서는 0-15 레이어, 기계 B에서는 16-31 레이어와 같이요. 따라서 단일 장치에는 들어가지 않을 235B MoE(Mixture of Experts) 모델도 네 대의 소형 기계를 거쳐 실행할 수 있습니다. 고객은 차이를 전혀 알지 못합니다.

이 시스템은 노트북에서 구동되는 작은 반-빌리언 파라미터 모델부터 거대 모델에 이르기까지 40개 이상의 모델을 내장하고 출고됩니다. 그리고 iroh(P2P 네트워킹 레이어)를 기반으로 구축되었기 때문에, 메시(mesh)에 새로운 기계를 추가하는 것은 거의 설정이 필요 없습니다.

리더보드가 주는 경각심

Forbes는 Databricks의 최신 엔터프라이즈 벤치마크를 바탕으로 기사를 게재했는데, 이는 우리 중 많은 사람이 의심했던 것을 기본적으로 확인시켜 주었습니다. 즉, 공개된 LLM(대규모 언어 모델) 리더보드는 실제 구매 결정에 있어 관련성이 떨어지고 있다는 것입니다. 기업 구매자들은 이제 MMLU나 HumanEval에서의 몇 퍼센트 포인트 차이보다는 작업당 비용, 부하 상태에서의 지연 시간(latency under load), 그리고 배포 유연성을 우선시합니다.

이는 저의 경험과도 일치합니다. 리더보드에서 85%를 기록하지만 80GB의 VRAM을 필요로 하고 질의당 3초가 걸리는 모델은, 24GB에 들어맞고 300ms 만에 응답하는 78% 모델보다 활용도가 떨어집니다. 특히 로컬 환경에서 구동할 때는 더욱 그렇습니다.

간단한 현실 점검

모든 것이 장밋빛인 것은 아닙니다. Mesh LLM은 초기 단계입니다. 문서화가 부족하며, 작동시키려면 커맨드라인(command line)에 대한 어느 정도의 숙련도가 필요할 것입니다. Mac Mini를 에이전트 허브로 사용하는 것은 이론적으로는 훌륭하지만, macOS 기반의 실제 에이전트 프레임워크들은 아직 따라잡는 중입니다. 그리고 '모델 수집 중단'이라는 조언은 실제로 무엇이 필요한지 이미 알고 있을 때만 작동합니다—만약 이제 막 시작하는 단계라면 여전히 실험이 필요합니다.

하지만 방향성은 명확합니다.

이번 주에는 Mesh LLM을 백엔드로, MacBook Air를 오케스트레이터로 사용하여 맞춤형 에이전트 워크플로우를 구축했습니다. 추론 속도가 충분히 빨라서 모델이 같은 기기에서 로컬로 실행되고 있다는 사실을 잊을 정도였습니다. 그 순간만으로도 이 전체 실험은 가치가 있었습니다.

PayCalc