맥 스튜디오 M3 Ultra 512g 모델로 이런짓 저런짓을 좀 해보고 있는 와중에 중간 중간 관련 글을 정리해 올려보고 있습니다.
pirogom@pirogom-Mac-Studio ~ % lms ls
You have 12 models, taking up 599.66 GB of disk space.
LLM PARAMS ARCH SIZE DEVICE
google/gemma-3-27b (1 variant) 27B gemma3 16.87 GB Local
llama-3.3-70b-instruct@4bit 70B Llama 39.71 GB Local
llama-3.3-70b-instruct@8bit 70B Llama 74.98 GB Local
llama-4-scout-17b-16e@4bit 17B llama4 61.14 GB Local
llama-4-scout-17b-16e@8bit 17B llama4 115.46 GB Local
minimax/minimax-m2.5 (1 variant) 230B minimax_m2 128.68 GB Local
qwen2.5-coder-3b-instruct-mlx 3B Qwen2 1.75 GB Local
qwen3-coder-next@4bit qwen3_next 44.86 GB Local
qwen3-coder-next@8bit qwen3_next 84.67 GB Local
zai-org/glm-4.6v-flash (1 variant) 9B glm4v 7.09 GB Local
zai-org/glm-4.7-flash (1 variant) 30B glm4_moe_lite 24.36 GB Local
EMBEDDING PARAMS ARCH SIZE DEVICE
text-embedding-nomic-embed-text-v1.5 Nomic BERT 84.11 MB Local현재 사용중인 모델은 이정도 되는것 같네요 전부 mlx용 모델들입니다.
우선 한동안 minimax-m2.5 모델을 사용해서 간단한 프로젝트를 몇 가지 진행 해봤습니다. 그 전에는 Qwen3-coder-next 나 Qwen2.5-coder 같은 모델들도 꽤 주력으로 사용을 했었습니다만. 모델 목록에서 Tool, Function Calling 을 지원한다 하는 모델들중 툴을 호출하는 프롬프트나 템플릿 설정이 Opencode 와 맞지 않는 놈들이 있는 것 같습니다.
어차피 Tool Calling 의 경우도 프롬프트에 같이 달려서 모델에 전송되는 정보인데 모델에 따라 그 형식 차이가 있는듯 한데요 .. Qwen같이 중국쪽 오픈소스 모델의 경우엔 각자 자신들의 Cli 에이전트에 맞춘 프롬프트가 모델 자체에 기본으로 달려 있는것 같습니다.
보통 LM Studio 나 Ollama 등이 모델을 로드하면 그 모델 자체에 설정된 각종 값들을 자동으로 끌어다 사용하게 되거든요.. 예를들어 temperature 나 top k, top p 같은 값들을 들 수 있겠죠..
또한 툴 사용과 관련된 것도 템플릿으로 기본적으로 모델에 관련 프롬프트가 포함되어 있는데 그 형식이 뭔가 안맞으면 제대로 툴이 호출되지 못하는 현상이 일어나는것 같습니다.
Qwen3-coder-next 의 경우에도 QwenCLI에서는 아무 문제 없이 Tool 잘만 쓰더라구요 .. 그런데 Opencode 나 클로드코드에만 붙이면 중간중간 툴이 제대로 동작 못해서 제대로 결과가 않나오는 경우도 생기곤 했습니다.
일단 이때까지 주로 사용한게 70, 80, 120b 정도 선의 모델들이라 최근에 나온 230b 모델이고 Opencode 에서 툴 사용에 문제가 없다고 이런저런 유튜버가 극찬(?)한 Minimax-m2.5 모델을 한동안 많이 사용해 봤습니다만..
우선 중간중간 중국어나 일본어가 섞여서 답이 나오는 문제가 있었고 ..
가장 큰 문제는 Oh my opencode 를 붙여서 병렬로 에이전트를 돌려대면 230b 파라미터 답게 이 모델 하나만 물리고 돌려도 480g 이상 메모리가 치솟아서 메모리가 좀 간당간당한 경우가 많았습니다.
일단 코드의 품질이나 결과에 대한 기준은 사람마다 다를 수 있긴 합니다만 .. 확실히 파리미터 수가 크면 클수록 좀더 디테일이 좋은 코드를 좀더 적은 시도 횟수에 끝내준다? 랄까요 ..
일단 현재까지 LM Studio + Opencode + Oh my Opencode 로 그나마 사용가능한 코드를 뱉어낸 모델을 나열하자면 ..
minimax-m2.5
glm-4.7-flash
현재까진 이 두개였습니다.
glm-4.7-flash 의 경우는 30b 정도의 작은 크기의 모델이라 아주 복잡한 추론은 조금 딸리긴 한데요 .. 중간 중간 좀 잘 끊어서 여러번 돌려대다 보면 그래도 사용가능한 코드가 나오긴 합니다.
클로드코드나 코덱스 같은 놈들과 로컬LLM의 가장큰 차이라 생각드는건 좀더 많은 횟수 또는 좀더 상세한 프롬프트가 필요한 경우가 많다는거 .. 아무래도 모델 파리미터수도 중소형 위주로 선택하게 되니까 그럴 수 밖에 없다 생각 되긴 합니다만 ..
참고로 glm-4.7-flash 의 경우 그냥 기본 상태로 돌리면 무한 루프에 자주 빠집니다.
전 설정값을 좀 손봐서 쓰고 있습니다만. ..
Temperature 는 0.7, Top K 는 20, Top P는 0.5, Min P는 0.01, Repeat Penalty는 1로 현재는 돌려보고 있습니다.
다른 모델들도 이 값들을 좀 조정해보면서 사용을 해야 좀 정상적으로 돌아갑니다. 많은 모델들이 모델의 기본 설정 값으로 돌리면 OMO 에서 울트라워크로 돌려대면 계속 실패하는 커맨드를 무한 반복하는 경우에 빠지곤 합니다.
아!
glm-4.7-flash 가 30b 정도로 작은 크기의 모델이고 이 모델은 컨텍스트 쌓이기 전에는 30기가? 내외로 메모리를 차지하는데요.. 모델의 문제인지 LM Studio의 문제인지 메모리릭이 있는 것 같습니다.
간단한 프로젝트 하나를 끝내고 10만 토큰정도 생성한 상황인데 400기가 정도 램을 잡아먹은 상태로 메모리를 해제를 하질 않네요. 이 상태로 hi 같은 간단한 채팅을 날려도 메모리가 계속 쌓이기만 하고 줄질 않습니다.
lms unload 명령으로 모델을 내리니 전부 해제되는 걸 보니 모델과 관련해서 어떤 이슈가 있는 것 같긴합니다만 ..
LM Studio는 오픈소스가 아닌관계로 제가 직접 디버깅이 가능한건 아니라서 ..
좀더 테스트가 필요할 것 같긴하네요 ..