다양한 모델을 테스트하며 2주간 1억 토큰 이상의 개발 작업을 진행해 본 결과, 당분간은 Qwen 3.6 35b a3b 모델을 LM Studio와 Claude Code 환경에서 주력으로 사용할 계획입니다.
Deepseek-V4 Flash가 기대되긴 하지만, 어째서인지 아직 LM Studio에는 관련 업데이트가 진행되지 않고 있습니다. Hugging Face에는 이미 모델들이 올라오고 있음에도 말이죠. 현재 제 활용 범위에서는 LM Studio를 벗어날 이유가 없기에 조금 더 기다려보려 합니다.
DeepSeek-V4 Pro의 경우 양자화를 타협한다면 구동은 가능할 것입니다. 다만 타협을 잘 해도 2-bit 양자화 정도가 한계일 텐데, 아무리 MoE 구조로 1.6T 파라미터 중 49B만 활성화된다고 해도 30B급 Dense 모델들이 보통 10~20 TPS 내외인 점을 고려하면, 49B 활성 파라미터 모델의 속도 또한 충분히 예측 가능합니다. 따라서 실사용하기에는 다소 답답할 것으로 보입니다.
최근 제 기준으로는 30 TPS 미만의 속도가 나오는 모델은 에이전틱 코딩용으로 사용하기에 무리가 있다는 결론입니다. 속도가 느려도 ‘돌려놓고 자면 된다’고 생각할 수 있지만, 오픈소스 모델은 작업 도중 예상치 못한 지점에서 무한 루프에 빠지는 경우가 종종 발생합니다. 그래서 모델이 알아서 돌아가게 방치하기보다는 중간중간 동작 상태를 확인하며 사용하게 되는데, 속도가 느릴수록 사용자 입장에서는 상당히 지치게 됩니다. 따라서 최소 30 TPS 이상, 가능하면 50~70 TPS 정도는 나와주는 모델을 선호합니다.
512GB의 대용량 메모리를 보유하고 있더라도, GLM-5.1이나 Kimi-K2 같은 대형 모델들은 2-bit 양자화 정도로 타협해야 겨우 구동이 가능한 수준입니다. 속도 또한 10~20 TPS 내외에 불과하며, 컨텍스트가 쌓일수록 속도는 더욱 저하되기 때문에 실사용하기에는 매우 제약이 큽니다.
Local LLM으로 오픈소스 모델을 활용해 에이전틱 코딩을 수행할 때는 AI에 모든 것을 일임하기보다, 결국 중간중간 상태를 확인하고 개입해야 하는 상황이 반드시 발생합니다. 제 경험상 이는 GLM-5.1이나 DeepSeek 같은 거대 모델이라 할지라도 빈도의 차이만 있을 뿐, 공통적으로 나타나는 문제입니다.
각설하고 ..
현재 가장 만족스럽게 사용 중인 모델은 Qwen 3.6입니다. Qwen 3.5의 경우 Thinking 과정이 지나치게 길다는 단점이 있습니다. 그렇다고 Non-Thinking 모드로 사용하면 결과물의 품질이 아쉬운 경우가 많아, Thinking 모드라면 한두 번 만에 끝날 작업이 Non-Thinking 모드에서는 4~5번씩 반복해야 하는 상황이 빈번합니다. 결국 Non-Thinking 모드가 개별 프롬프트에 대한 응답 시간은 짧을지 몰라도, 전체 작업 시간 측면에서는 오히려 더 오래 걸리는 경우가 많았습니다.
최근 출시된 Qwen 3.6은 3.5 버전까지 점차 비대해졌던 Thinking 과정을 대폭 개선한 모습입니다. 오픈소스 모델들도 파라미터 규모와 상관없이 점점 에이전틱 코딩(Agentic Coding)에 초점을 맞춰 발전하고 있습니다. 초창기에는 개발사들이 자사 CLI 환경에만 최적화하여 모델을 배포하는 경향이 강했으나, 최근에는 클로드 코드(Claude Code) 등 외부 CLI에 타사 모델을 연동해 사용하는 사례가 늘어남에 따라 Anthropic API 규격이나 펑션 콜링(Function Tool Calling) 관련 호환성까지 어느 정도 고려하여 출시하는 추세입니다.
You have 7 models, taking up 162.42 GB of disk space.
LLM PARAMS ARCH SIZE DEVICE
qwen2.5-coder-3b-instruct-mlx 3B Qwen2 1.75 GB Local
qwen3.6-27b-mlx 27B qwen3_5 34.73 GB Local
qwen3.6-27b-ud-mlx 27B qwen3_5 26.21 GB Local
qwen3.6-35b-a3b 35B-A3B qwen35moe 40.24 GB Local
qwen3.6-35b-a3b-mlx 35B qwen3_5_moe 37.74 GB Local
qwen3.6-35b-a3b-ud-mlx 35B qwen3_5_moe 21.66 GB Local현재 IDE 자동완성용으로 사용 중인 qwen2.5-coder-3b-instruct-mlx 모델을 제외하면, 실질적인 작업에는 qwen3.6-35b-a3b 모델만을 단독으로 활용하고 있습니다.
MiniMax-m2.7은 결과물 중간중간에 중국어가 섞여 나오는 문제를 해결하지 못해 결국 사용을 포기했습니다.
Gemma-4 역시 한동안 잘 사용해 보았으나, 한국어 문장 생성 능력은 Gemini와 흡사해 문서 작성 등의 용도로는 꽤 쓸만하다는 인상을 받았습니다. 하지만 개발 작업 시에는 유독 자주 멈추는 현상이 발생하여 결국 사용을 중단했습니다.
그 외 Qwen 3.6 모델들의 경우, Unsloth에서 MLX 버전도 함께 배포하고 있습니다만..
전 MLX 버전이 아닌 일반 GGUF 버전을 사용중인데, 이유는 단순합니다.
앞으로 어떻게 변할지는 모르겠으나, MLX Vision 모델의 경우 아직 병렬 처리를 지원하지 않습니다. 클로드 코드와 같은 에이전틱 코딩 툴을 연동해 사용하면 ‘Plan’ 모드 등에서 여러 서브 에이전트를 동시에 생성하여 병렬로 작업을 진행하게 되는데, 보통 LM Studio의 기본값은 4로 설정되어 있습니다. 제 경우 리소스가 충분하여 보통 6~8 정도로 늘려 사용하기도 하지만, MLX Vision 모델은 이 값이 현재 1로 고정된 상태입니다.
아무래도 한번에 하나의 작업만 진행이 가능하단 소리라 ..
성능 차이가 어느 정도일지 궁금하여 MLX 모델들도 추가로 다운로드해 보았습니다.
현재 주로 쓰고 있는 모델은 qwen3.6-35b-a3b 이고 Q8_K_XL 양자화된 GGUF 모델입니다.
Unsloth에서 권장하는 Precise Coding Tasks용 Thinking Mode 설정값을 적용한 상태입니다. 현재 주력으로 사용 중인 Q8_K_XL GGUF 모델에 ‘Python Snake Game’ 프롬프트를 입력하여 얻은 결과는 다음과 같습니다.
모든 결과는 lms unload –all 후에 lms chat –stats 로 다시 모델을 로드해서 진행하고 있습니다.
Prediction Stats:
Stop Reason: eosFound
Tokens/Second: 73.65
Time to First Token: 0.454s
Prompt Tokens: 36
Predicted Tokens: 5612
Total Tokens: 5648
이번엔 mlx/8bit 양자화 모델을 진행해봅니다.
Prediction Stats:
Stop Reason: eosFound
Tokens/Second: 77.11
Time to First Token: 0.435s
Prompt Tokens: 36
Predicted Tokens: 3899
Total Tokens: 3935MLX 모델이 약간 더 속도가 나오는 편이긴 하네요.
이번엔 mlx/4bit 양자화 모델을 돌려보겠습니다.
Prediction Stats:
Stop Reason: eosFound
Tokens/Second: 86.47
Time to First Token: 0.325s
Prompt Tokens: 36
Predicted Tokens: 4120
Total Tokens: 4156TPS가 다소 낮아지더라도, 구동 가능한 메모리 용량이 충분하다면 8-bit 양자화 모델을 사용하는 것이 최선의 선택일 것으로 보입니다.
27B 모델은 35B 모델과 달리 Dense 구조입니다. MoE 모델의 경우 모델 전체가 메모리에 상주해야 하는 점은 같으나, 실제 추론 시에는 활성 파라미터만 연산에 참여하므로 상대적으로 빠른 속도를 보여줍니다. 반면 Dense 모델은 추론 시 모든 파라미터가 사용됩니다. 따라서 Qwen 3.6 35B A3B는 전체 파라미터 규모가 35B일지라도 실제 추론은 3B만으로 수행되지만, 27B 모델은 27B 전체를 연산에 활용합니다. 결과적으로 27B Dense 모델이 35B MoE 모델보다 실제 추론 과정에서 몇 배나 더 많은 파라미터를 처리하게 되는 셈입니다.
물론 그만큼 좀더 나은 결과를 보여줄 순 있겠습니다만..
https://huggingface.co/unsloth/Qwen3.6-27B-MLX-8bit
Hugging Face의 벤치마크 결과상으로는 27B 모델이 35B A3B 대비 확실히 우수한 수치를 보여주는 것이 사실입니다. 하지만 제 기준에서는 속도 저하를 감수할 만큼의 유의미한 성능 차이는 아니라고 판단되어, 현재는 35B A3B 모델을 주력으로 사용하고 있습니다.
왜 속도 대비 감수할만한 성능차이가 아니냐 하면 ..
qwen3.6-27b mlx/8bit 양자화 모델의 경우..
Prediction Stats:
Stop Reason: eosFound
Tokens/Second: 18.60
Time to First Token: 0.605s
Prompt Tokens: 36
Predicted Tokens: 3006
Total Tokens: 304218.60 Tps 입니다.
qwen3.6-27b mlx/4bit 의 경우도 돌려보면 ..
Prediction Stats:
Stop Reason: eosFound
Tokens/Second: 24.04
Time to First Token: 0.499s
Prompt Tokens: 36
Predicted Tokens: 3824
Total Tokens: 386024.04 tps 네요 ..
단순히 ‘Python Snake Game’을 생성하는 정도의 프롬프트에서는 차이가 적을지 몰라도, 에이전트를 연동해 컨텍스트가 쌓이기 시작하면 모델 자체의 TPS와 별개로 최종 결과를 얻기까지 걸리는 시간은 더욱 늘어나게 됩니다. 따라서 거의 2.5~3배에 달하는 속도 차이를 감수하면서까지 사용할 만큼의 성능 차이는 아니라고 판단하여, 저는 35B A3B 모델을 주로 활용하고 있습니다.
표로 간단히 정리해보자면
| Model | Quant | Size | TPS |
| qwen3.6-35b-a3b | Q8_K_XL (UD/GGUF) | 40.2GB | 73.65 |
| qwen3.6-35b-a3b-mlx | 8Bit (mlx/gguf) | 37.7GB | 77.11 |
| qwen3.6-35b-a3b-ud-mlx | 4Bit (mlx/UD/gguf) | 21.7GB | 86.47 |
| qwen3.6-27b-mlx | 8Bit (mlx/gguf) | 34.7GB | 18.60 |
| qwen3.6-27b-ud-mlx | 4Bit (mlx/UD/ggif) | 26.2GB | 24.04 |
Quant 의 UD 는 Unsloth 의 Unsloth Dynamic의 약자입니다.
일반적으로 Hugging Face의 mlx-community나 lmstudio-community 등에서 배포되는 MLX 모델들이 Unsloth에서 파인튜닝한 모델보다 속도 면에서 우위인 경우가 많습니다. 하지만 제 경험상 LM Studio에서 가장 안정적이었던 모델은 Unsloth의 GGUF(MLX가 아닌) 모델들이었기에, MLX 모델 또한 Unsloth에서 파인튜닝한 모델들만을 기준으로 테스트를 진행했습니다.
일반적으로 MLX 모델이 기존 모델 대비 10~20%가량 더 빠르다고 알려져 있는데, 이번 모델 역시 실제로 그 정도의 성능 차이를 보여주는 것 같습니다.
하지만 앞서 말씀드렸듯이 Qwen 3.6은 비전 기능이 포함된 멀티모달 모델이며, 현재 MLX Vision은 병렬 처리가 불가능합니다. 20% 정도의 속도 향상이 있다 하더라도, 아직은 상대적으로 불안정한 MLX 런타임과 병렬 처리 제약까지 고려한다면 저는 당분간 MLX가 아닌 GGUF 모델을 그대로 사용하겠습니다.
LM Studio + Claude Code 팁을 몇가지 공유하겠습니다.
{
"env": {
"ANTHROPIC_BASE_URL": "http://192.168.0.110:11434",
"ANTHROPIC_AUTH_TOKEN": "lmstudio",
"ANTHROPIC_MODEL": "qwen3.6-35b-a3b",
"ANTHROPIC_DEFAULT_OPUS_MODEL": "qwen3.6-35b-a3b",
"ANTHROPIC_DEFAULT_SONNET_MODEL": "qwen3.6-35b-a3b",
"ANTHROPIC_DEFAULT_HAIKU_MODEL": "qwen3.6-35b-a3b",
"CLAUDE_CODE_SUBAGENT_MODEL": "qwen3.6-35b-a3b",
"CLAUDE_CODE_ENABLE_TELEMETRY": "0",
"CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1",
"CLAUDE_CODE_ATTRIBUTION_HEADER" : "0",
"CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING": "1",
"CLAUDE_CODE_DISABLE_1M_CONTEXT": "1",
"CLAUDE_CODE_DISABLE_AUTO_MEMORY": "1",
"MAX_THINKING_TOKENS": "63999"
},
"attribution": {
"commit": "",
"pr": ""
},
"model": "opus",
"plansDirectory" : "./plans",
"language": "korean",
"effortLevel": "high",
"alwaysThinkingEnabled": true
}
제가 사용중인 클로드코드 ~/.claude/settings.json 파일입니다. 설정에 참고 하시구요.
다른건 그대로 사용하시거나 클로드 코드 공식문서에서 각 설정이 뭔 의미인진 찾아보시면 될텐데..
"CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING": "1",
"MAX_THINKING_TOKENS": "63999"다음 두 설정은 반드시 적용하시기 바랍니다. CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING의 경우 클로드 코드가 사고(Thinking)의 수준을 능동적으로 조정하는 기능인데, 클로드 API 서비스를 직접 사용하는 것이 아니라면 큰 의미가 없습니다. 또한, MAX_THINKING_TOKENS 옵션을 활성화하려면 반드시 CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING을 설정하여 ‘어댑티브 씽킹’ 기능을 꺼야만 합니다.
로컬에서 소형 모델을 클로드 코드에 연동해 사용할 때 발생하는 가장 대표적인 문제는, 추론 단계가 깊어지거나 컨텍스트가 쌓이면 무한 루프에 빠지는 현상입니다. 이 경우 사고 과정(Thinking) 메시지를 확인해 보면 동일한 내용을 끝없이 반복하며 멈추지 않는 상황이 자주 발생합니다.
MAX_THINKING_TOKENS를 설정하면 사고(Thinking) 단계의 토큰이 지정된 값을 초과할 경우 추론을 강제로 중단시킵니다. 이를 통해 모델이 무한 루프에 빠져 자원을 낭비하는 것을 방지할 수 있습니다.
물론 클로드 자체도 중간에 갑자기 멈춰버리는 느낌이 들겠지만, 무한히 반복되는 것보다는 차라리 추론이 중단되는 편이 상황을 인지하기에 훨씬 수월합니다. 그렇지 않으면 몇 시간 뒤에 확인했을 때, 작업이 잘 진행된 줄 알았는데 알고 보니 추론 무한 루프에 빠져 있는 것을 보게 되는 것만큼 허탈한 일도 없기 때문입니다.
이 값은 모델의 최대 컨텍스트 크기에서 1을 뺀 값이 최댓값입니다. 저는 리소스가 넉넉한 편이라 컨텍스트는 항상 모델이 지원하는 최대 크기로 지정하지만, 이 옵션만큼은 64k를 기준으로 잡아 사용하고 있습니다. 사용자의 시스템 리소스 상황에 따라 적절히 조절하여 사용하시기 바랍니다.
이상입니다.
댓글을 달려면 로그인해야 합니다.