최근 오픈소스 AI 모델은 중국쪽이 열일 하는 느낌입니다. 클로드 코드를 학습하고 있다느니 어쩌느니 이러쿵 저러쿵 말도 많긴 합니다만, 현실적으로 개인 사용자들이 사용 가능한 범주 내에서 의미 있는 모델을 주기적으로 계속 배포하고 있는 면에서는 Qwen이 가장 활발한 편이라고 볼 수 있겠네요.
Qwen 3.6 과 관련해서는 클라우드 서비스 쪽에 Qwen 3.6 Plus 연나.. 여튼 클라우드 전용 모델로 먼저 공개된 모델이 평이 워낙 좋았어서 기대는 하고 있었습니다.
Qwen도 이제 슬슬 셀프 호스팅 목적으로 사용 가능한 공개모델과 클라우드 서비스 용의 전용 모델을 좀 차별해서 공개를 하려는것 같긴 합니다만 그럼에도 개선된 기반이라는 것이 어디 가는건 아니기 때문에 ㅎㅎ
여튼 출시 되자마자 Unsloth 에서도 열일 해서 바로 여러 양자화 모델을 공개해 줬습니다.
어제 Qwen-3.6-27b 모델도 공개되긴 했습니다만. 지금 다루는 35b는 MoE 모델로 실제 활성화 파라미터는 3b이지만 27b는 Dense모델이라 결과 품질은 27b가 유리할 순 있습니다만, 일반적으로 Dense모델이 제가 사용하는 맥 스튜디오에선 성능이 좀 떨어지더라구요.. 아직 다운로드 중이라서 정확한 성능차이를 논하긴 애매합니다만, 또 다뤄 볼 일이 있겠지요.
이 모델은 3일째 주력으로 사용중입니다. 사실 qwen-3.5-397b-a17b를 한달 가까이 주력으로 사용해 오긴 했습니다만 몇일 사용해본 경험으론 제가 LocalLLM으로 돌리는 기준에서는 qweb-3.5-397b-a17b를 대체 할 수 있을 것 같습니다.
You have 12 models, taking up 577.89 GB of disk space.
LLM PARAMS ARCH SIZE DEVICE
gemma-4-26b-a4b-it 26B-A4B gemma4 27.87 GB Local
gemma-4-31b-it 31B gemma4 35.02 GB Local
glm-4.7-flash 64x2.6B DeepSeek 2 17.52 GB Local
minimax-m2.7 256x4.9B minimax-m2 140.62 GB Local
qwen2.5-coder-3b-instruct 3B Qwen2 1.93 GB Local ✓ LOADED
qwen3-coder-next 512x2.5B qwen3next 49.61 GB Local
qwen3-vl-8b-instruct 8B qwen3vl 7.45 GB Local
qwen3.5-2b 2B qwen35 2.67 GB Local
qwen3.5-397b-a17b 397B-A17B qwen35moe 247.10 GB Local
qwen3.5-9b 9B qwen35 7.79 GB Local
qwen3.6-35b-a3b 35B-A3B qwen35moe 40.24 GB Local ✓ LOADED
EMBEDDING PARAMS ARCH SIZE DEVICE
text-embedding-nomic-embed-text-v1.5 Nomic BERT 84.11 MB Local현재 제가 사용중인 모델은 이정도이고 .. 모델은 자주 바뀌긴 합니다. 저것들이 다 쓸만한 것도 아니고 파이썬으로 개별 코드 작성해서 사용하기 위한 목적으로 설치한 모델들도 있기 때문에 위 모델들이 다 쓸만하다는 건 아닙니다.
기존에 한달 가까이 사용해온 qwen 3.5 가 전체적으로 나쁘지 않은 사용성을 보여주지만 .. 가장 큰 문제가 생각이 너무 길다는게 가장 큰 문제였습니다. 결과가 나오기 전에 Thinking 단계에서 지가 내부적으로 너무 깊고 길게 생각을 한다는게 가장 큰 문제였는데요.
qwen 3.6의 경우 3.5에서 워낙 원성을 많이 들어서 그런지 이러한 부분이 생각보다 꽤 많이 개선 되었네요.
Prediction Stats:
Stop Reason: eosFound
Tokens/Second: 74.81
Time to First Token: 0.476s
Prompt Tokens: 36
Predicted Tokens: 4327
Total Tokens: 4363Q8_K_XL 양자화 모델이고 Unsloth 의 UD 모델입니다. Unsloth 에서 Unsloth studio를 출시해서 그런지 모르겠는데 보통 Unsloth 에서 mlx 모델을 같이 내놓는 경우는 잘 없습니다만, 이 모델은 Unsloth 에서 파인튜닝한 Mlx 모델도 같이 올라 왔길래 8Bit 양자화 모델을 받아서 써봤는데.. 78tps 정도로 의미 있는 큰 속도차이는 아니라서, GGUF 모델을 그냥 쓰고 있습니다.
아직까직은 MLX에 대한 뿌리 깊은 불신을 버릴 수가 없네요. 단순히 모델의 품질이나 결과가 어느정도 수준이냐 문제를 떠나서 MLX 관련 런타임들이 여전히 불안정하다는 느낌을 지울 수 없습니다. 엉뚱한 답을 내놓거나 무한 추론에 빠지거나 이런 문제가 아니라 런타임 자체가 그냥 죽어있는류의 문제를 너무 많이 격다보니.. 여튼 다행히도 MLX/GGUF와 일반 GGUF가 큰 속도차이가 나는건 아니어서 더더욱 기대를 크게 했습니다.
제 기준에서 일반적으로 쓸만하다 정도의 기준을 30TPS로 보고 있습니다 보통 클로드의 Opus 같은 경우도 4~50 사이 tps를 보이는 경우가 많기 때문에 30Tps 이상은 나와줘야 클로드 코드 맥스를 사용하던 사용성과 그나마 비슷한 느낌으로 사용이 가능하기 때문인데요, 7~80tps 수준이면 매우 훌륭하다고 볼 수 있습니다.
물론 35b 정도의 중소형모델이라 그럴 수 있지만 파라미터수가 적다고 해서 무조건 빠른 속도를 보여주는게 아닌 시장이라 마냥 적은 파라미터덕에 괜찮은 속도를 보여준다고 하긴 힘들 것 같네요.
전체적으로 속도도 좋고 Thinking Mode 에서 내부적으로 추론과정을 거치는 것도 나름 만족 스럽습니다. 한국어 표현도 나쁘지 않은 편인데 Minimax 같이 심하게 중국어나 일본어가 한국어 답변에 섞여 나오는건 아니지만 간혹 한국어와 같은 의미를 가지는 한자어들로 단어가 대체되어 출력되는 경우가 매우 드물게 나오긴 합니다. 이건 기존에 쓰던 Qwen 모델들에선 거의 본적 없는 현상인데 생각보다 하루에 한두번 정도는 발생하는 것 같네요.
다만 Minimax 의 경우엔 메시지 외에 실제 코드 결과의 주석이나 코드내의 문자열에도 이런 한자가 튀어나오는 것과 달리 Qwen은 그나마 코드에는 이런 짓을 하진 않는것 같습니다.
또 한가지.. 중소형 모델에 Thinking Mode를 지원하는 모델들의 경우 내부 추론과정에서 무한 생각에 빠지는 경우가 생깁니다. 클로드 코드에서 추론과정 표시를 하면 같은 내용이 계속 무한 반복되는 경우를 보게 되는데 추론을 너무 깊게 들어가다 보면 컨텍스트가 오염되던 소실되던 갈피를 못잡고 같은 생각만 계속 반복하는 문제에 빠진다는 겁니다.
이게 이 모델만의 문제는 사실 아니고 중소형 모델의 경우 사용자가 어떤 프롬프트를 요청 했느냐 따라서 대체로 발생하는 문제긴 하지만 이 모델은 조금 심한 느낌이네요.
현재 전 에이전틱 코딩은 대부분 클로드 코드를 사용해서 진행 중이고 클로드 코드의 설정 파일을 계속 갱신해가며 쓰고 있습니다만. 이러한 추론 루프등은 설정에 제한을 거는 방식으로 어느정도 해결보고 있습니다.
{
"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_GIT_BASH_PATH": "C:\\Program Files\\Git\\bin\\bash.exe",
"CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING": "1",
"CLAUDE_CODE_DISABLE_1M_CONTEXT": "1",
"CLAUDE_CODE_DISABLE_AUTO_MEMORY": "1",
"MAX_THINKING_TOKENS": "31999"
},
"attribution": {
"commit": "",
"pr": ""
},
"model": "opus",
"plansDirectory" : "./plans",
"language": "korean",
"effortLevel": "high",
"alwaysThinkingEnabled": true
}
현재 제가 사용중인 ~/.claude/settings.json 파일입니다.
Unsloth 에서 제공하는 글과 기타 해외 커뮤니티 등에서 나오는 정보들로 계속 갱신하고 있는 설정이긴 합니다만. 앞으로도 관련 글 작성시에 종종 공유하도록 하겠습니다.
일단 로컬에서 사용중이니 굳이 effortLevel 을 낮게 잡거나 alwaysThinkingEnabled를 false 로 해서 토큰을 아끼려 할 필요는 없어서 사고모드 관련은 대부분 끄진 않고 사용중입니다.
다만, 현재로썬 대부분의 로컬용 오픈소스 모델들이 1M 컨텍스트를 지원하지 않기 때문에(Nemotron 제외) CLAUDE_CODE_DISABLE_1M_CONTEXT 를 켜서 100만 컨텍스트는 사용하지 않도록 했고, 기타 해외 유명 개발자들이 추천한 설정도 몇가지 추가했습니다.
이중 MAX_THINKING_TOKENS 이 내부 추론 과정에 대한 토큰을 제한한 건데요. 현재로썬 해외 커뮤니티에서 가장 많이 보이는 값으로 사용중이긴 합니다만 값은 계속 변경해보면서 테스트 해봐야 겠습니다.
CLAUDE_CODE_GIT_BASH_PATH 의 경우 저는 주로 윈도에서 개발을 하기때문에 LLM은 맥에 돌리고 있지만 주 개발환경이 윈도인지라 WSL2도 번잡스럽고 클로드코드가 툴콜링에 사용하는 bash 명령들은 git 클라이언트와 같이 설치되는 gitbash 로도 충분하기에 따로 Bash 경로를 git bash 의 실행파일 경로로 설정해서 사용중입니다.
클로드코드가 Windows PowerShell 명령 기반으로 동작가능한 환경변수 제공을 한다고 들은거 같은데 .. 아직은 잘 모르겟네요.. 수십년을 윈도 개발을 해왔지만 아직 PowerShell은 이상하게 못미더워서 ㅎㅎ
저는 LocalLLM의 경우 큰 규모의 백엔드 프로젝트등을 처음부터 에이전트가 구성하도록 하는 경우 같은 용도에는 사용하지 않습니다. 이런 일들이 많은 것도 아니지만 대부분은 부분적인 기능개발이나 Snippet 스러운 무언가들에 대해서 주로 사용하고 있기 때문에 전체 프로젝트 자체를 하네스 깍아가며 에이전트가 알아서 해주길 바라시는 분들과는 좀 목적이 다를 수 있습니다만. ( 근데 개인이 사용가능한 하드웨어 선에서 어…차피;; Opus 급을 바라는 하드웨어를 가진 사람이 누가 있겠습니까만은.. )
보조적인 수단으로는 충분히 매리트가 있습니다.
물론 512 램이 달린 맥 스튜디오는 이제 새 제품을 구입 할 수 조차 없는게 좀 아쉽긴 하지만요..
곧 27b dense 모델도 간단히 테스트 해보고 글하나 올려 보겠습니다.
이상입니다.