지난번 「24/365 가동되는 나만의 로컬 LLM에 최적인 Mac은? — 대역폭이 아닌 prefill(GPU 코어)로 선택한다」의 결과를 바탕으로, 로컬 LLM 가동 기반으로서 Mac mini M4 Pro (64GB)를 선택하여 도입했습니다.

곧바로 AI 비서를 배치하고 이것저것 가동 준비를 진행하고 있습니다만, 우선 회의 녹화 데이터로부터 의사록을 작성하는 단계까지를 완전히 자동으로 대응하도록 했습니다. 처리를 Mac mini 1대·외부 전송 없이 완결시킨 상태에서, 동일한 음성으로 여러 모델을 비교하여 어떤 LLM이라면 실무에 맡길 수 있을지를 확인했습니다. 결론부터 말씀하자면, 클라우드 최상위인 Opus 4.8과 동등한 수준의 의사록을 로컬만으로 얻을 수 있었습니다.

(Mac mini의 키팅(Kitting)이나 셋업에서도 많은 지견이 나왔습니다만, 그것은 다른 기회에 정리하겠습니다.)

로컬로 완결시키는 이유

고객과의 미팅 정보(음성이나 문자 데이터)는 가장 외부로 유출해서는 안 되는 것 중 하나입니다. 클라우드의 받아쓰기 (Transcription) API나 SaaS 의사록 서비스에 올리면, 그 시점에서 외부로 복사본이 넘어갑니다. 100명 이하의 조직이라도 기밀을 수중에서 내보내지 않고 자동화하고 싶은 요구는 많지 않을까요?

방침은 완전 로컬입니다. 추론은 모두 수중에서 수행하며, 네트워크에 나가는 것은 모델 가중치(Weight)의 최초 다운로드뿐입니다. 그 이후에는 오프라인에서도 돌아갑니다.

처리 흐름

1대 안에서 「받아쓰기 → 발언을 화자별로 분류 (화자 분리, Speaker Diarization) → 의사록 생성」을 순차적으로 진행합니다 (사용한 엔진 이름은 생략합니다). 화자 분류를 거침으로써 의사록에 「누가 무엇을 말했는가」가 남게 됩니다.

결과 (실측)

채택한 모델 (Gemma 4 26B-A4B)로 실제 회의 음성(약 91분·일본어)을 통과시켰을 때의 실측치입니다.

회의 종료 후 비동기로 실시하여, 단 11분 만에 고품질의 의사록이 생성되었습니다. 사람이 직접 작성하는 시간보다 몇 배나 빠른 계산입니다. 왜 이 모델을 채택했는지(여러 모델의 비교)는 후술하겠습니다.

속도는 「사전 처리의 정교함」으로 보완

당초에는 지난번 검증 결과에 따라, 품질 면에서 우수한 dense (밀집) 모델인 31B를 채택할 계획으로 시작했습니다. 31B는 의사록 생성에 약 11분, 파이프라인 전체로는 20분 이상 걸립니다 (통합 메모리 상에서 실효 5 tok/s 정도). 그럼에도 사람이 처음부터 의사록을 작성하는 것에 비하면 충분히 빠른 수준입니다. 다만 운용에 올리려면 빠른 편이 좋고, 그렇다고 해서 작고 빠른 모델로 바꾸기만 하면 단독으로는 의사록의 질이 한 단계 떨어집니다.

효과를 본 것은 사전 처리의 정교한 설계였습니다. 화자별 분류, 깨지기 쉬운 고유명사 보정, 절 구성과 자기 점검을 포함시킨 지시 사항——이러한 외부적인 노하우를 통해, 소형 모델로도 31B와 동등한 의사록 품질을 훨씬 빠르게 얻을 수 있었습니다. 지난 검증에서는 이 31B급의 의사록 품질을 클라우드 최상위인 Opus 4.8과 동등한 수준이라고 판단했습니다. 즉, 수중의 로컬에서 클라우드 최상위에 필적하는 품질을 외부 전송 없이 낼 수 있었다는 뜻입니다.

즉 「31B의 벽을 순수 모델 성능으로 넘었다」는 것이 아닙니다. 주변의 전처리 (노하우)로 실용 품질에 도달하게 했다는 것이 정확한 표현입니다. 모델을 크게 만들어 밀어붙이는 것보다, 정교한 설계가 더 효과적이었습니다.

보충: 작은 모델이 빠른 이유는 1 토큰당 일부의 파라미터만 계산하는 MoE (Mixture of Experts) 구조 때문입니다. 다만 빠른 것은 계산뿐이며, 모델 전체는 메모리에 올려야 합니다. 64GB 통합 메모리라면 총합 65GB급 모델은 애초에 올라가지 않습니다.

여러 모델을 동일한 음성으로 비교

비교의 목적은 「31B 클래스의 품질을 더 빠르게 낼 수 있는 모델은 없는가」입니다. 그래서 품질 기준인 dense 31B에 더해, 총 파라미터 수는 31B급이지만 계산이 가벼운 MoE 모델 2개를 도입했습니다——Qwen3.6-35B-A3B (총수 35B / active 3B)와 IBM Granite 4.0 H-Small (총수 32B / active 9B)입니다. 아울러 한 단계 작은 Gemma 4 26B-A4B도 함께 배치했습니다.

조건은 동일하게 맞추었습니다. 동일한 트랜스크립트(Transcript)·동일한 지시 사항 (12절 구성 · 날조 방지와 불확실한 고유명사에 대한 【확인 필요】 부착을 최우선으로 명시)로, 의사록 생성 모델만 교체했습니다.

숫자만 보면 Qwen3.6이 가장 빠르고, 가장 길며, 가장 상세합니다.

숫자의 1위가 품질의 1위는 아니었습니다

Qwen3.6은 【확인 필요】를 단 하나도 붙이지 않았습니다. 그리고 전사(Transcription) 과정에서 깨진 고유명사를 올바른 단어인 것처럼 단정 지었으며, 원문에 없는 어구나 인물 관계까지 자연스러운 일본어로 창작했습니다. 지시 사항에 "날조 방지가 가장 중요함"이라고 명시했음에도 이를 무시했습니다.

의사록 작성에서 이것은 가장 곤란한 실패입니다. 읽기 쉽고 그럴싸하지만 사실이 아닌 문장은 오히려 사람의 리뷰 부하를 높여버립니다.

반면 Gemma (26B / 31B)는 동일하게 깨진 고유명사에 【확인 필요】를 붙였고, 원문에 없는 내용은 쓰지 않았습니다. 지시를 준수하는가에서 차이가 났습니다.

Granite는 태스크 이전에 결과가 좋지 않았습니다

출력이 다른 모델의 절반 이하로 나왔으며, 서로 다른 절에 동일한 문장이 그대로 중복되었고, 구체성이 떨어져 범용적인 문장이 되었습니다. 일본어 처리 효율도 나빴으며 (동일한 문장에서 1.8배의 토큰을 소비), 컨텍스트(Context) 측면에서도 불리했습니다.

참고로, catap_art3d 씨도 Granite 4.0을 논리 추론 태스크에서 "성능이 나쁘다"고 평가했습니다 (출처). 본 검증은 요약이라는 별도의 태스크이지만, 소견은 일치했습니다.

알게 된 점: 의사록은 "속도"보다 "사실에 충실한가"가 중요하다

의사록은 "기록된 사실만을 정확하게 포착하는" 업무입니다. 따라서 빠르고 유창한 모델보다, 지시를 준수하며 사실에 충실한 모델이 적합합니다. 계약서 요약, 문의 대응, 조사 메모 등과 같은 동일한 성격의 실무에도 적용됩니다.

• 빠름·유창함과 사실에 충실함은 별개의 능력입니다. 그럴싸한 창작은 느린 것보다 더 큰 비용을 치르게 합니다.
• 모델의 크기보다 사전 처리(Pre-processing)의 완성도(화자 분리·용어 보정·지시 설계)가 품질을 좌우했습니다.
• 고객 데이터를 다룬다면 제공처(출처)도 선정 기준에 포함됩니다. 로컬 실행이라면 구조적으로 유출은 발생하지 않지만, 설명 가능성이나 사내 정책상 제공처를 통일하는 판단을 내릴 수 있습니다.

현 시점에서 채택한 것은 가장 빠르거나 가장 크지는 않은 Gemma 4 26B-A4B였습니다. 속도·충실도·지시 준수·메모리 절약의 균형이 이 용도에 가장 적합했기 때문입니다.

요약

• 회의 녹음 → 전사 → 화자 분리 → 의사록 작성을 Mac mini 1대·완전 로컬 환경에서 약 11분/91분 음성으로 돌릴 수 있었습니다.
• 26B 모델을 채택하고 사전 처리를 정비함으로써 31B와 동등한 품질의 출력을 빠르고 가벼운 모델로 구현했습니다.
• 동일한 음성에 대한 비교의 핵심은 "빠름 ≠ 정확함"입니다. 가장 빠르고 유창한 Qwen3.6은 확신을 가지고 창작하여 의사록에는 사용할 수 없었습니다. 따라서 **지시에 충실한 소형 모델(Gemma 26B-A4B)**을 채택했습니다.
• 실무를 AI에 맡길지 여부는 벤치마크 숫자가 아니라 "자신의 용도·자신의 데이터·자신의 환경"에서 측정하여 결정했습니다.

Discussion