지난 기사에서는 Mac Studio M1 Max 64GB 환경에서 llama.cpp / llama-server를 사용하여 사내 RAG(Retrieval-Augmented Generation)의 문서 생성 태스크를 검증했습니다.

이번에는 그 후속편으로, llama-server가 아닌 mlx_lm.server를 사용하여 MLX 형식의 모델을 동일한 사내 RAG 태스크에서 테스트했습니다.

이번에 알고 싶었던 것은 단순합니다.

Apple Silicon용 MLX 모델을 사용하면 llama-server보다 좋아지는가.

결론부터 말씀드리면, 이번 사내 RAG 용도에서는

MLX가 llama-server를 전면적으로 대체할 만큼 좋다는 결과는 아니었습니다.

하지만 MLX가 별로라는 뜻도 아닙니다.

gemma-4-26B-A4B-it-4bit와 qwen3-30b-a3b-instruct-2507-4bit-no-think는 상당히 실용적이며, 특히 메모리 효율성이 매력적입니다.

제 개인적인 결론은 다음과 같습니다.

이미 llama-server + GGUF로 안정적인 운용이 가능하다면, 주력은 여전히 llama-server 쪽이 좋습니다.

단, MLX의 MoE (Mixture of Experts) 4bit 모델은 저메모리 대체 후보 또는 비교 후보로서 충분히 사용할 수 있습니다.

본 기사의 데이터 측정은 당사의 사와구치가 전적으로 실시하였습니다.

태스크는 지난번과 동일합니다.

DOCUMENT BOX에 등록된 품질 부적합 보고서 test1.pdf를 RAG로 참조하여, 다음 3가지 종류의 문서를 구분하여 작성하게 합니다.

• 보도 자료(Press Release)용 문구
• BtoB 고객 대상 개별 통지문
• 사내용 시정 조치 보고서 (ISO 9001 / 8D / CAPA 스타일)

주요 측정 조건은 다음과 같습니다.

이번 MLX 측정에서는 llama.cpp와 같은 내부 timings가 아니라, OpenAI 호환 API를 호출했을 때의 wall time (실제 경과 시간)으로부터 상당 지표를 계산하고 있습니다.

따라서 표 중의 prompt tok/s 상당 및 decode tok/s 상당은 llama-server의 내부 prompt_eval_tok_s / decode_tok_s와 엄밀히 동일한 것은 아닙니다.

이 점은 중요한 주의 사항입니다.

다만, 사내 사용자에게 중요한 것은 "화면에서 얼마나 기다려야 하는가", "Mac Studio 64GB에서 다른 프로세스와 공존할 수 있는가"입니다.

그런 의미에서 wall time 유래 지표는 실제 운용 시의 체감에 가까운 비교로서 사용할 수 있습니다.

이번에 비교한 MLX 모델은 다음 4가지입니다.

모델명만 보면 27B, 30B, 31B로 비슷한 사이즈로 보입니다. 하지만 실제 속도는 총 파라미터 수보다 Dense인지 MoE인지, 그리고 active parameter(활성 파라미터)가 어느 정도인지에 강하게 영향을 받습니다.

3회 실행의 중앙값은 다음과 같습니다.

가장 실용적으로 보이는 것은 gemma-4-26B-A4B-it-4bit입니다.

및 Qwen3-30B-A3B-Instruct-2507-4bit입니다.

두 모델 모두 첫 번째 wall time(전체 소요 시간)이 약 38초, decode tok/s(초당 디코딩 토큰 수) 상당치가 약 39 tok/s입니다. 사내 RAG (Retrieval-Augmented Generation)에서 1,400~1,500 토큰 정도의 답변을 생성한다면 기다릴 수 있는 범위 안에 있습니다.

특히 gemma-4-26B-A4B-it-4bit는 Peak Mem (최대 메모리 사용량)이 13.94GB로 낮아, 이번 4개 모델 중 메모리 효율이 가장 좋은 결과였습니다.

반면, Dense 계열인 Qwen3.6-27B-OptiQ-4bit와 gemma-4-31B-it-OptiQ-4bit는 상당히 무겁습니다. OptiQ를 통해 메모리는 억제되었지만, Dense 연산 자체가 가벼워지는 것은 아닙니다.

이번 MLX 계열 모델 중에서는 가장 균형이 좋은 모델이었습니다.

첫 번째 wall 초: 37.51 초
decode tok/s 상당치: 39.11 tok/s
Peak Mem: 13.94 GB

속도, 메모리, 출력의 일관성 사이의 균형이 좋습니다. 보도 자료, BtoB 통지, 사내용 CAPA(시정 및 예방 조치) 구분도 자연스러워, 일반적인 사내 RAG의 상용 후보로 삼을 수 있습니다.

출력 품질만 본다면 더 큰 Dense 모델에 기대하게 됩니다. 하지만 실제 대기 시간과 메모리 사용량까지 포함하면, 이 모델은 상당히 다루기 쉽습니다.

Qwen3-30B-A3B-Instruct-2507-4bit도 상당히 빠릅니다.

첫 번째 wall 초: 37.71 초
decode tok/s 상당치: 38.70 tok/s
Peak Mem: 16.32 GB

input tokens (입력 토큰)가 1,726으로 다른 모델보다 많은 상태에서도, 첫 번째 wall time은 gemma-4-26B-A4B와 거의 같습니다. prompt tok/s (프롬프트 초당 토큰 수) 상당치도 45.77로 높아 전체적인 효율이 좋아 보입니다.

다만, 출력은 다소 짧은 편입니다. 사내용 초안 작성이나 요약에는 사용하기 좋지만, 고객 통지나 감사용 문서의 경우 프롬프트 측에서 "필요 항목을 누락하지 말 것"이라는 지시를 조금 더 강화하는 것이 좋아 보입니다.

Qwen3.6-27B-OptiQ-4bit는 no-thinking 모드로 설정했을 때 정상적으로 완료되었습니다.

첫 번째 wall 초: 132.92 초
decode tok/s 상당치: 12.47 tok/s
Peak Mem: 15.95 GB

메모리만 보면 나쁘지 않습니다. Peak Mem은 15.95GB로 Qwen3-30B-A3B와 비슷합니다.

하지만 속도는 큰 차이가 납니다. Dense 계열이기 때문에 OptiQ로 양자화(Quantization)를 해도 연산량의 무게가 남습니다. 화면상에서 대화형으로 사용하는 사내 RAG의 제1 후보로 삼기에는 어렵습니다.

출력은 안정적이지만, 일상적인 운용 시에는 대기 시간이 눈에 띕니다. 사용한다면 품질 비교용, 배치 처리(Batch Processing), 야간 생성용으로 적합합니다.

gemma-4-31B-it-OptiQ-4bit도 정상적으로 완료되었으나, 이번 4개 모델 중에서는 가장 무거운 결과였습니다.

첫 번째 wall 초: 156.35 초
decode tok/s 상당치: 9.18 tok/s
Peak Mem: 21.78 GB

출력 구성은 잘 잡혀 있습니다. BtoB 통지나 CAPA 스타일의 사내 보고서로서 읽기 쉬운 형태로 나오기 쉽습니다.

다만, 상용하기에는 대기 시간이 너무 깁니다. 역할로서는 품질 상한 확인, 타 모델 출력과의 비교, 중요 문서 리뷰용이 적합합니다.

이 부분이 이번의 핵심입니다.

지난번 llama-server / GGUF 측정에서는 예를 들어 다음과 같은 결과였습니다.

이 표에서 llama-server의 첫 번째 초와 MLX의 첫 번째 초는 의미가 다릅니다.

llama-server는 내부 timings의 prompt eval (프롬프트 평가) 시간입니다.

반면, MLX는 OpenAI 호환 API 요청 전체의 wall time입니다.

따라서 첫 번째 초를 그대로 나열하여 순위를 매겨서는 안 됩니다.

한편, decode tok/s

는 출력 tokens당 생성 속도를 확인하는 데 참고가 됩니다.

이 관점에서 보면, 이번 MLX 최속 그룹은 약 39 tok/s였으며, 지난번 llama-server의 Qwen3.6 MoE 계열은 46에서 51 tok/s 대였습니다.

즉, 이번 사내 RAG 태스크에서는 생성 속도의 상한선은 아직 llama-server / GGUF 쪽이 더 높은 것으로 보입니다.

MLX의 장점도 확실히 있습니다.

특히 Peak Mem 13.94GB인 gemma-4-26B-A4B는 매력적입니다. Mac Studio 64GB에서 RAG, embedding, Qdrant, Web 앱을 동시에 구동하는 구성에서는 메모리 여유가 곧 운영의 안정성으로 이어집니다.

반면, llama-server와 비교했을 때 약한 점도 있습니다.

특히 운영 측면에서는 측정 가시성이 큽니다.

llama-server에서는 prompt eval, decode, prompt cache 이후의 처리 시간을 세밀하게 볼 수 있습니다. RAG의 병목(bottleneck)이 검색 측인지, prompt eval인지, 아니면 decode인지 구분하기 쉽습니다.

MLX에서도 실용적인 wall time은 측정할 수 있지만, 내부 timings를 포함한 튜닝(tuning)의 용이성 측면에서는 llama-server가 아직 더 다루기 쉽다고 느꼈습니다.

이번 결과를 운영에 적용한다면, 다음과 같이 구분하여 사용하는 것이 좋아 보입니다.

「어쨌든 하나로 결정한다」면, 현시점에서는 llama-server + GGUF의 Qwen3.6 MoE 계열을 주력으로 삼겠습니다.

한편, 「MLX도 수중에 두고 비교하고 싶다」거나 「메모리를 억제하여 다른 모델을 구동하고 싶다」는 용도라면, gemma-4-26B-A4B-it-4bit는 상당히 좋은 후보입니다.

이번 결과는 PDF 전문을 통째로 LLM에 던진 것이 아닙니다.

PDF를 등록하고, embedding과 Qdrant로 관련 청크(chunk)를 검색한 뒤, 그 RAG 문맥(context)을 LLM에 전달한 결과입니다.

따라서 수치나 품질은 다음 조건에 의존합니다.

• PDF 분할 방법
• embedding 모델
• top_k
• min_score
• 검색에서 채택된 청크
• prompt의 길이
• context_size
• max_tokens
• mlx_lm.server의 버전
• chat template 설정
• 모델의 변환 원천 및 양자화(quantization) 형식

또한, 이번 MLX 지표는 wall_clock_equivalent입니다. llama.cpp의 내부 timings와 완전히 동일한 의미는 아닙니다.

대외 문서, 고객 통지, 품질 불량, 보상, 리콜, 법무 표현을 포함하는 문서에서는 어떤 모델이든 인간의 리뷰(human review)가 필수입니다.

Mac Studio M1 Max 64GB 상에서, MLX 형식의 4개 모델을 사내 RAG 문서 생성 태스크로 비교했습니다.

결과는 다음과 같습니다.

• gemma-4-26B-A4B-it-4bit

는 Peak Mem 13.94GB, decode 39.11 tok/s에 해당하며, MLX 계열 중 가장 균형이 좋습니다.

Qwen3-30B-A3B-Instruct-2507-4bit

는 첫 실행(wall) 약 38초로, 속도를 중시하는 MLX 후보입니다.

Qwen3.6-27B-OptiQ-4bit

는 no-thinking 모드에서는 정상적으로 완료되지만, Dense 계열로서 무겁습니다.

gemma-4-31B-it-OptiQ-4bit

는 품질 확인용으로는 좋지만, 상시 사용하기에는 대기 시간이 깁니다.

그리고,

이 기사의 질문인 "MLX는 llama-server보다 좋은가"에 대한 답은 다음과 같습니다.

종합적으로, 이번 사내 RAG 용도로는 아직 llama-server가 더 좋습니다.

이유는 생성 속도의 상한선, 프롬프트 캐시 (prompt cache), 내부 타이밍 (internal timings)의 가시성, 그리고 기존 운영에서의 안정성 때문입니다.

하지만 MLX가 나쁜 것은 아닙니다.

특히 gemma-4-26B-A4B-it-4bit와 같은 MoE 4bit 모델은 적은 메모리로도 충분히 빠르며, Mac Studio 기반의 사내 RAG에 도입할 가치가 있습니다.