대충 느낌은 알고 있었는데 생각한 것과 같군요...

직접 개발하냐 다른 런타임에 의존하느냐...

윈도, 리눅스 vulkan에서 젬마3n 비전이 아직도 지원이 안되요!! ㅜ ㅜ

나온지 한달 가까이 되어가는 qwen3 vl도 맥용에서만 돌아가는군요...

이하 지피티의 요약입니다.

요점만 딱 정리해볼게요. “왜 LM Studio에서 GGUF(=llama.cpp 엔진) 쪽 신기능/새 모델 지원이 더 느리고, MLX는 더 빨리 되느냐?”는 질문은 결국 누가 엔진을 통제하느냐, 변환(컨버전) 파이프라인이 얼마나 간단하냐, 목표 플랫폼이 얼마나 좁으냐로 갈립니다.

1. 엔진 통제권

• MLX: LM Studio가 자체 MLX 엔진을 붙여서(mac 전용) 최적화·기능 개발 사이클을 자기들이 직접 돌립니다. 실제로 LM Studio는 2024년 10월에 “MLX 내장”을 공식화했고, 이후에도 자사 릴리스에서 MLX 관련 기능을 지속적으로 늘렸어요. 즉, 의존성이 적어 속도가 납니다.  
• GGUF(=llama.cpp 런타임): GGUF는 포맷이고, 실행은 주로 llama.cpp에 의존합니다. 새 모델/기능은 먼저 llama.cpp 쪽에 구현·병합돼야 하고(예: MoE 오프로딩 옵션 등), 그 뒤에야 LM Studio가 가져다 쓸 수 있어요. 즉, 한 단계를 더 거칩니다.  

1. 변환 파이프라인의 마찰

• GGUF는 “양자화된 가중치로 배포하는 바이너리 포맷”이라 원본 체크포인트를 GGUF로 변환해야 합니다. 토크나이저/로프 스케일/비전용 mmproj 같은 부가자산도 맞춰야 하고, 새 아키텍처(비전·MoE·롱컨텍스트 증강 등)가 나오면 변환 스크립트·런타임 지원이 갱신돼야 하죠. 이 과정이 느리면 지원이 늦습니다.  
• MLX는 애초에 Apple Silicon용 프레임워크라(메탈·유니파이드 메모리) 모델을 그대로(또는 MLX용으로 바로) 로드하는 흐름이 많고, LM Studio의 MLX 엔진 이슈·개선도 같은 리포에서 빠르게 도는 편입니다(성능 토론 이슈들도 활발). 변환 장벽이 상대적으로 낮으니 신모델 대응이 빠르게 느껴집니다.  

1. 목표 플랫폼의 폭 vs. 깊이

• MLX는 사실상 “Apple Silicon 전용”이라, 하드웨어 스택이 좁은 대신 깊은 최적화(Metal 커널, KV 캐시/스펙 데코 연구 적용 등)에 집중할 수 있습니다. Apple 자체 연구(스펙큘러티브 디코딩 최적화 등)가 MLX 생태계에 빨리 들어오는 것도 한몫합니다.  
• GGUF/llama.cpp는 “CPU/다양한 GPU/여러 OS”를 전부 겨냥합니다. 범용성은 최고지만, 그만큼 기능 하나를 넣어도 모든 조합에서 안정화가 필요해 릴리스 템포가 상대적으로 보수적일 수밖에 없습니다.  

1. 기능 격차가 생기는 전형적인 지점들

• 멀티모달/비전, MoE, 새로운 양자화 스킴, 초장문 컨텍스트 트릭처럼 런타임이 깊게 관여하는 기능은, MLX 쪽이 먼저 달리는 사례가 자주 보입니다. 반대로 llama.cpp에서도 차근차근 따라잡지만(예: MoE CPU offload), 그 사이 딜레이가 체감됩니다.  
• 다만 GGUF 쪽도 계속 발전 중이라, 최신 비전 모델 GGUF 지원이 런타임 업데이트와 함께 어느 날 “한 번에” 열리기도 합니다(예: LM Studio 런타임 업데이트로 Gemma 3 Vision GGUF 동작). 즉, 느리지만 안 되는 건 아닙니다.  

정리하면:

• MLX = 좁은 플랫폼(맥) + 자사 엔진 통제 + 변환 부담 적음 → 빠른 지원/최적화
• GGUF = 광범위 플랫폼 + 업스트림(llama.cpp) 의존 + 변환 파이프라인 필요 → 상대적으로 느린 지원

맥을 쓰신다면(Apple Silicon) “최신 기능/최적화”는 MLX 쪽이 먼저 체감되는 게 자연스럽고, 반대로 크로스플랫폼·광범위 모델 유통은 GGUF의 강점입니다. 필요에 따라 두 엔진을 혼용하는 게 LM Studio의 의도이기도 하고요.