🤖
1330 in / 3131 out / 4461 total tokens
🔥 핫 토픽
Qwen3.6-35B-A3B — 35B 파라미터 중 3B만 쓰는 MoE 모델이 나왔다
알리바바 큐웬팀이 Qwen3.6-35B-A3B를 공개했다. 총 파라미터 35B 중 활성 파라미터 3B인 Mixture of Experts 구조다. 이건 쉽게 말하면 35B급 지식을 가진 모델이 실제 추론할 때는 3B 모델 수준의 연산량만 필요하다는 뜻이다. 로컬에서 돌릴 수 있는 사이즈면서도 대형 모델에 준하는 성능을 기대할 수 있다는 게 핵심이다.
MoE(Mixture of Experts) 구조가 왜 중요한지 게임 개발 관점에서 비유해보겠다. 언리얼 엔진에서 LOD(Level of Detail) 시스템과 비슷하다. 멀리 있는 메시는 저폴리곤으로, 가까이 있으면 고폴리곤으로 전환하잖아. MoE도 비슷하게, 입력 토큰마다 필요한 "전문가(Expert)" 네트워크만 활성화해서 연산을 아낀다. 전체 파라미터 35B를 항상 다 돌리는 게 아니라, 상황에 따라 3B 분량의 라우팅된 전문가들만 돌리는 식이다.
로컬 LLM 커뮤니티에서 이 모델이 화제인 이유가 있다. 기존에 3B~8B 급 모델은 중소형 GPU에서 돌리기 좋지만 성능 한계가 뚜렷했고, 35B 이상 모델은 성능은 좋은데 VRAM 요구량이 20GB 이상이라 일반 개발자가 접근하기 어려웠다. 이 모델은 그 사이의 간극을 메운다. RTX 3060 12GB나 RTX 4060 Ti 16GB 같은 보급형 GPU에서도 충분히 돌릴 수 있을 것으로 보인다.
개발자 실무 관점에서 보면, 에이전트 파이프라인이나 RAG 시스템에서 로컬 추론을 쓰고 싶을 때 선택지가 늘어난다. 클라우드 API 호출 비용을 줄이면서도 품질을 어느 정도 보장받을 수 있으니까. 특히 게임 내 NPC 대화 시스템이나 실시간 콘텐츠 생성처럼 지연 시간이 중요한 워크로드에서 로컬 모델의 가치가 크다. 서버 아키텍처 관점에서도, API 의존도를 낮추면 응답 시간 예측 가능성이 올라가고 장애 전파를 막을 수 있다.
다만 MoE 모델의 단점도 분명히 인지해야 한다. 전체 파라미터 35B를 메모리에 올려야 하니 VRAM 사용량은 순수 3B 모델보다 훨씬 크다. VRAM은 연산량과 별개로 모델 로딩 자체를 위해 필요하다. 또한 라우팅 오버헤드로 인해 실제 추론 속도가 이론치보다 느릴 수 있다. 이 부분은 벤치마크가 더 나와봐야 확인할 수 있을 것이다.
출처: Reddit r/LocalLLaMA | HuggingFace
📰 뉴스
llm-anthropic 0.25 — Simon Willison의 CLI 도구가 Anthropic 지원을 강화하다
Simon Willison이维护하는 llm CLI 도구의 Anthropic 플러그인이 0.25로 업데이트됐다. llm은 다양한 LLM 프로바이더를 통합 CLI 인터페이스로 쓸 수 있게 해주는 파이썬 도구다. OpenAI, Anthropic, Google, 로컬 모델까지 하나의 명령어 인터페이스로 추론할 수 있다.
이 업데이트가 왜 중요한지는 개발자 워크플로우 관점에서 보면 명확하다. AI 사이드 프로젝트를 할 때 가장 귀찮은 게 프로바이더마다 SDK 따로, API 스펙 따로, 인증 방식 따로 세팅하는 것이다. llm은 이걸 추상화해준다. 터미널에서 llm -m claude-3.5-sonnet "프롬프트" 한 줄이면 끝난다. 이번 0.25 업데이트에서 Anthropic 쪽 지원이 더 안정화되고 기능이 보강된 것으로 보인다.
게임 서버 개발하면서 느끼는 건데, CLI 도구의 가치는 자동화 파이프라인에서 진가를 발휘한다. 쉘 스크립트나 파이썬 서브프로세스에서 llm을 호출하면 CI/CD 파이프라인에 AI 기반 코드 리뷰나 테스트 생성을 쉽게 붙일 수 있다. 또한 JSON 출력 모드를 지원하니 파싱도 간편하다. 에이전트 체인을 구성할 때 중간 단계의 간단한 호출은 굳이 LangChain 같은 무거운 프레임워크 안 쓰고 CLI로 해결하는 게 더 빠를 때가 많다.
Simon Willison은 datasette, shot-scraper 등 개발자 도구를 꾸준히 만들어온 사람이다. 이 사람이维护하는 도구들은 보통 API가 깔끔하고 문서가 친절하다. 신뢰도 높은 오픈소스 생태계 기여자라고 볼 수 있다. llm 자체도 플러그인 아키텍처로 되어 있어서, 새로운 모델 프로바이더가 나오면 커뮤니티에서 플러그인을 만들어 붙이는 구조다. 게임 엔진의 플러그인 시스템과 발상이 같다.
앞서 언급한 Qwen3.6-35B-A3B와도 연결점이 있다. 로컬 모델을 llm에 연결해서 쓸 수 있으니까. Ollama나 llama.cpp 서버를 띄워두면 llm CLI에서 로컬 MoE 모델을 그대로 호출할 수 있다. 클라우드 API와 로컬 모델을 동일한 인터페이스로 오가며 쓸 수 있다는 건 프로토타이핑 속도를 크게 올려준다.
💡 관점
이 두 소식을 함께 보면 하나의 흐름이 보인다. 모델은 점점 더 효율적으로(MoE), 도구는 점점 더 통합적으로(CLI 추상화) 발전하고 있다. Qwen3.6-35B-A3B는 "로컬에서 돌릴 수 있는 강한 모델"이라는 오랜 숙원에 대한 하나의 답이고, llm CLI는 "어떤 모델이든 같은 방식으로 쓰기"라는 개발 경험 문제에 대한 답이다.
개인적으로 사이드 프로젝트에서 로컬 모델 활용 비중을 점점 늘리고 있다. API 비용도 문제지만, 개발 중에 네트워크 지연 때문에 피드백 루프가 느려지는 게 더 큰 문제다. 게임 개발할 때 핫 리로드가 왜 중요한지 생각해보면 답이 나온다. 빠른 반복이 핵심이다.
로컬 MoE 모델 + 통합 CLI. 개발자의 노트북이 점점 더 자급자족 가능한 AI 워크스테이션이 되고 있다.