음.. 명절인데도 코덱스와 클로드랑 아침부터 함께 하고 있습니다.
평소에 시간이 없어서 못하던 작업들을 불러서 일시키고 있습니다.
ADHD생기는 것 같습니다. 지금 돌리는 작업이 4개인데 한창때는 9개까지 돌려봤습니다.
지금은 4개도 벅차네요. 토큰도 벅차고요..
쓸만한 로컬 llm이 얼른 생겼으면 좋겠습니다.
Mac mini m4 32g를 사용중인데 gemma4-26b-a4b를 얹어서 쓰고 있습니다. 속도도 괜찮고 다 좋은데 램을 조금 많이 먹는 느낌이라서 다른 것 써보려고 이것 저것 테스트 시작했습니다. 며칠전 xiaomidptj mimoV2.6을 가지고 qwen3.5-9b를 증류했다고 해서 그거 깔고 테스트 해보았습니다. 여러분의 토큰을 아껴드리기 위해서 테스트 결과 공유해봅니다.
두 모델을 한 번에 하나씩 올려 비교했습니다. MiMo는 메모리를 크게 아끼지만, 현재 설정에서 Gemma를 기본 모델로 교체하기에는 아직 이릅니다. 시험 후 MiMo 서버를 모두 내리고 기존 Gemma 서비스를 복구했습니다.
실측 항목 | 현재 Gemma 4 QAT | MiMo 일반 4bit | MiMo oQ/MTP |
|---|
프로세스 메모리 | 약 15.8 GiB | 약 6.8 GiB | 약 5.7 GiB |
한국어 요약 완료 | 9.9초 | 24.3초 | 12.3초 |
생성 속도 | 30.8 tok/s | 19.2 tok/s | 23.7 tok/s |
합성 에이전트 과제 | 3/3 통과 | 3/3 통과 | 도구 인자 전달 실패 |
일반 4비트 MiMo는 문서 조회→계산→답변을 정확히 수행했습니다. 반면 이번 작은 과제에서 Gemma도 모두 통과해, MiMo의 에이전트 능력이 Gemma보다 높다는 근거는 얻지 못했습니다. MiMo가 제시한 코드 테스트에는 실행 오류가 있었고, 긴 입력의 최종 답변도 Gemma 14.1초, 일반 MiMo 22.3초였습니다.
oQ/MTP판은 더 적은 메모리와 빠른 생성을 보여줬지만, 현재 oMLX 0.6.4가 도구 호출 인자를 {}로 전달하는 호환성 문제가 재현됐습니다. 이 구성은 아직 에이전트 백엔드로 쓰면 안 됩니다. Xiaomi가 공개한 에이전트 평가 향상은 Qwen3.5-9B 대비 수치이며 Gemma와의 직접 비교는 아닙니다. 시험한 일반 4비트와 oQ/MTP판도 서로 다른 변환본입니다.
장기적으로 MiMo를 쓰려는 판단은 메모리 측면에서 타당합니다. 약 9 GiB의 여유를 얻을 수 있습니다. 다만 기본 모델 전환 전에는 도구 인자 문제를 해결하고, 실제 읽기·요약 작업에서 품질과 지연을 더 확인하는 편이 좋겠습니다.
