# LM Studio Headless CLI와 Claude Code로 로컬에서 Google Gemma 4 실행하기 > Clean Markdown view of GeekNews topic #28265. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=28265](https://news.hada.io/topic?id=28265) - GeekNews Markdown: [https://news.hada.io/topic/28265.md](https://news.hada.io/topic/28265.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-04-07T02:33:27+09:00 - Updated: 2026-04-07T02:33:27+09:00 - Original source: [ai.georgeliu.com](https://ai.georgeliu.com/p/running-google-gemma-4-locally-with) - Points: 17 - Comments: 1 ## Summary **LM Studio 0.4.0**의 새 Headless CLI(`llmster`)로 **Gemma 4**를 로컬에 띄우고, **Claude Code의 백엔드로 연결**해서 완전 오프라인 코드 어시스턴트를 만드는 가이드입니다. Gemma 4의 MoE 구조 덕분에 26B 모델이 4B 파라미터만 활성화되어 M4 Pro MacBook에서 **초당 51토큰**이 나온다고 합니다. API 비용 없이 빠른 코드 리뷰나 프롬프트 테스트를 돌리고 싶은 분에게 실용적인 셋업 가이드입니다. ## Topic Body - **Gemma 4**는 mixture-of-experts 구조로 일부 파라미터만 활성화해 **저사양 하드웨어에서도 고성능 추론**을 지원 - **LM Studio 0.4.0**은 새로운 **Headless CLI(llmster)** 를 도입해 데스크톱 앱 없이 모델 다운로드·로드·채팅·API 서버 실행이 가능 - **OpenAI·Anthropic 호환 API**를 통해 Gemma 4를 **로컬 서버로 제공**하고, **Claude Code**를 완전 오프라인 코드 어시스턴트로 활용 가능 - **컨텍스트 길이·GPU 오프로딩·병렬 요청** 등 세밀한 하드웨어 튜닝으로 성능과 메모리 효율을 조정할 수 있음 - **MoE 모델 기반 로컬 추론**은 API 비용 없이 빠른 코드 리뷰와 프롬프트 테스트를 가능하게 하며, **개발자용 오프라인 AI 환경 구축의 핵심 기술**로 부상 --- ### 로컬에서 Google Gemma 4 실행하기 — LM Studio의 새로운 Headless CLI와 Claude Code 연동 - ## 로컬 실행의 필요성 - 클라우드 AI API는 **요금, 속도 제한, 개인정보, 네트워크 지연** 등의 제약 존재 - 코드 리뷰, 초안 작성, 프롬프트 테스트 등 빠른 반복 작업에는 **로컬 모델 실행**이 유리 - 로컬 실행은 **API 비용 0**, **데이터 외부 전송 없음**, **항상 사용 가능**이라는 장점 제공 - ### Gemma 4**는 mixture-of-experts(MoE) 구조로 26B 모델 중 4B 파라미터만 활성화되어**저사양 하드웨어에서도 고성능 실행 가능 - M4 Pro MacBook(48GB)에서 초당 51토큰 생성 속도 기록, Claude Code 내에서는 다소 느려짐 - ## Gemma 4 모델 계열 - Google은 Gemma 4를 **4가지 모델군**으로 공개, 다양한 하드웨어에 최적화 - **E 시리즈(E2B, E4B)** 는 Per-Layer Embeddings를 사용하며 **오디오 입력(음성 인식·번역)** 지원 - **31B dense 모델**은 MMLU Pro 85.2%, AIME 2026 89.2% 성능 - **26B-A4B 모델**은 128개 전문가 중 8개(3.8B 파라미터)만 활성화되어 **10B급 품질에 4B급 비용**으로 동작 - MMLU Pro 82.6%, AIME 88.3%로 31B dense 모델에 근접하며 **Elo 1441**로 400B+ 모델과 경쟁 - **256K 컨텍스트**, **비전 입력**, **함수 호출**, **추론 모드 설정** 지원으로 로컬 추론에 적합 - ## LM Studio 0.4.0의 주요 변화 - ### llmster**라는 독립형 추론 엔진 도입으로**데스크톱 앱 없이 CLI로 완전 실행 가능 - `lms` CLI를 통해 모델 다운로드, 로드, 채팅, 서버 실행 모두 수행 가능 - 주요 기능: - **llmster daemon**: 백그라운드에서 모델 로드·추론 관리 - **병렬 요청 처리**: 연속 배칭으로 여러 요청 동시 처리 - **Stateful REST API**: `/v1/chat` 엔드포인트로 대화 이력 유지 - **MCP 통합**: 로컬 Model Context Protocol 지원 - ## 설치 및 모델 다운로드 - 설치 명령: ```bash curl -fsSL https://lmstudio.ai/install.sh | bash ``` - 데몬 실행: `lms daemon up` - 런타임 업데이트: `lms runtime update llama.cpp`, `lms runtime update mlx` - Gemma 4 26B 모델 다운로드: `lms get google/gemma-4-26b-a4b` - 기본 양자화는 **Q4_K_M (17.99GB)** - 다운로드 후 `lms load google/gemma-4-26b-a4b`로 로드 - ## 로컬 모델 관리 - 설치된 모델 목록 확인: `lms ls` - 예시 출력에는 Gemma 4, Qwen 3.5, GLM 4.7 Flash 등 **MoE 모델 다수 포함** - MoE 모델은 **활성 파라미터 일부만 사용**하여 효율적 추론 가능 - ## 대화 실행 및 성능 - 대화 시작: `lms chat google/gemma-4-26b-a4b --stats` - 출력 예시: ``` Tokens/Second: 51.35 Time to First Token: 1.551s ``` - **51 tok/sec**, **1.5초 초기 응답**으로 상호작용에 충분한 속도 - ## 모델 상태 및 메모리 확인 - 로드된 모델 확인: `lms ps` - 예시: 17.99GB 메모리 사용, 48K 컨텍스트, 2개 병렬 요청, TTL 1시간 - JSON 출력(`lms ps --json | jq`)에서 확인 가능한 주요 항목: - `"architecture": "gemma4"` - `"quantization": {"name": "Q4_K_M", "bits": 4}` - `"vision": true`, `"trainedForToolUse": true` - `"maxContextLength": 262144`, `"parallel": 2` - ## 컨텍스트 길이에 따른 메모리 추정 - `--estimate-only` 옵션으로 메모리 요구량 예측 가능 - 기본 모델 약 17.6GiB, 컨텍스트 2배마다 3~4GiB 증가 - 48K 컨텍스트 시 약 21GiB 필요, 256K에서는 37.48GiB - 명령 예시: ``` lms load google/gemma-4-26b-a4b --estimate-only --context-length 48000 ``` - **컨텍스트 길이와 메모리의 선형 관계**로 용량 계획에 유용 - ## 하드웨어별 로드 튜닝 - ### 컨텍스트 길이 - OS 사용량(4~6GB)을 제외한 메모리 한도 내에서 설정 - 예: `lms load google/gemma-4-26b-a4b --context-length 128000` - ### GPU 오프로딩 - Apple Silicon은 **통합 메모리 구조**, `--gpu=1.0`으로 전체 GPU 사용 가능 - NVIDIA 시스템은 VRAM 한도 내에서 `--gpu=0.5` 등으로 분할 가능 - ### 병렬 요청 - **연속 배칭(continuous batching)** 으로 여러 요청 동시 처리 - GUI에서 **Max Concurrent Predictions** 설정 (기본 4) - Gemma 4의 경우 48GB 시스템에서 48K 컨텍스트, 병렬 2개가 적절 - ### TTL 자동 언로드 - `--ttl 1800`으로 30분 비활성 시 자동 해제 - 기본 1시간, 0 또는 -1로 비활성화 가능 - ### 모델별 기본값 저장 - 데스크톱 앱의 **My Models → 설정 아이콘**에서 GPU, 컨텍스트, Flash Attention 기본값 저장 - ### 추측 디코딩(Speculative Decoding) - MoE 모델에서는 **비효율적**, Gemma 4에서는 비활성 권장 - Mixtral 테스트 결과 코드 작업 39% 향상, 수학 작업 54% 저하 - ### Flash Attention - **KV 캐시 메모리 절감**으로 긴 컨텍스트 지원 - Apple Silicon에서 활성화 시 메모리 절약 효과 - ## LM Studio 데스크톱 앱 - GUI에서 **서버 상태, 모델 로드, API 엔드포인트, 로그 스트림** 시각화 - Anthropic 프로토콜(`POST /v1/messages`) 포함 - **비전 기능**으로 이미지 분석 가능 - 예시: Timezone Scheduler 이미지 분석 시 504토큰 생성, 54.51 tok/sec - 시스템 모니터링 결과: - 메모리 사용 46.69GB/48GB, 스왑 27.49GB - GPU 90% 활용, CPU 91°C, GPU 92°C - 전력 23.56W (CPU 11.06W, GPU 13.32W) - **통합 메모리 구조**로 CPU/GPU 간 데이터 복사 불필요 - ## API 서버로 모델 제공 - 서버 시작: `lms server start` - OpenAI 호환 API: `http://localhost:1234/v1` - Anthropic 호환 엔드포인트: `POST /v1/messages` - 포트 변경: `--port 8080` - **JIT 모델 로딩**으로 요청 시 자동 로드 및 TTL 후 자동 언로드 - 실시간 로그 스트림: `lms log stream --source model --stats` - 네트워크 내 다른 장치에서도 접근 가능, **API 토큰 인증** 지원 - ## Claude Code와의 연동 - Anthropic 호환 엔드포인트를 통해 **Claude Code를 로컬 모델로 실행 가능** - `~/.zshrc`에 `claude-lm` 함수 추가: ```bash export ANTHROPIC_BASE_URL=http://localhost:1234 export ANTHROPIC_MODEL="gemma-4-26b-a4b" ... claude "$@" ``` - 모든 Claude Code 모델 호출(Opus, Sonnet, Haiku)을 Gemma 4로 라우팅 - **48K 컨텍스트**, **8K 토큰 출력 제한**, **로컬 전용 환경** 구성 - `claude-lm` 실행 시 완전 오프라인 코드 어시스턴트 사용 가능 - 속도는 클라우드 대비 느리지만 **코드 리뷰·소규모 수정·탐색 작업에 적합** - ## 주요 교훈 - **MoE 모델이 로컬 추론의 핵심**: Gemma 4 26B-A4B는 10B급 품질에 4B급 비용 - **Headless 데몬**으로 완전 CLI 기반 워크플로우 가능 - **컨텍스트 길이**가 메모리 사용의 주요 변수 - `--estimate-only`로 **OOM 방지** - **Anthropic 호환 엔드포인트**로 Claude Code를 로컬에서 완전 오프라인 실행 가능 - ## 한계점 - `lms chat`에서 모델 이름을 직접 표시하지 않음 - 기본 48K 컨텍스트는 보수적이며, 메모리 여유 시 확장 권장 - Claude Code 로컬 실행은 **Anthropic API 완전 대체 불가**, 대규모 작업에는 제약 존재 - 48GB 시스템에서는 **메모리 압박 및 스왑 사용** 발생, 64GB 이상 권장 - ## 다음 단계 - Qwen 3.5 35B, GLM 4.7 Flash, Nemotron 3 Nano 등과의 **비교 테스트 예정** - 실행 절차 요약: ``` curl -fsSL https://lmstudio.ai/install.sh | bash lms daemon up lms get google/gemma-4-26b-a4b lms chat google/gemma-4-26b-a4b --stats ``` - Claude Code 연동: `claude-lm` 함수 추가 후 `claude-lm` 실행 - 로컬 AI 워크플로우 구축 및 웹앱·개발자 환경 통합에 활용 가능 ## Comments ### Comment 54794 - Author: neo - Created: 2026-04-07T02:33:27+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47651540) - **llama.cpp server**를 직접 사용해 로컬 LLM을 구동하고 Claude Code나 다른 CLI 에이전트에서 활용할 수 있음 M1 Max 64GB MacBook에서 Gemma4 등 최신 오픈 가중치 LLM을 테스트한 [전체 설정 가이드](https://pchalasani.github.io/claude-code-tools/integrations/)를 정리했음 26BA4B 모델이 이 하드웨어에서 가장 흥미로웠고, Qwen3.5 35BA3B보다 거의 두 배 빠른 **토큰 생성 속도(40 tok/s)** 를 보였음 하지만 tau2 벤치 결과는 Qwen 변형보다 낮아(68% vs 81%) **도구 중심의 복잡한 작업**에는 부적합할 것으로 예상함 - Claude Code에서 Anthropic과 OpenAI 간의 **사양 충돌** 문제는 없었는지 궁금함 나는 mlx_vlm과 vMLX를 사용 중인데 Claude Code에서 400 Bad Request 오류가 발생함 llama-server에서는 그런 문제가 없었는지 묻고 싶음 - 로컬 모델이 이제 단순히 “가능한 수준”을 넘어 **쾌적하게 사용 가능한 단계**로 진입했다고 느낌 특히 **headless LM Studio** 흐름이 인상적임. 실제 툴에서 로컬 추론을 활용할 수 있게 해줌 나는 [cloclo](https://www.npmjs.com/package/cloclo)라는 오픈소스 CLI 코딩 에이전트를 개발 중인데, LM Studio, Ollama, vLLM, Jan, llama.cpp 등 다양한 백엔드를 지원함 로컬 모델은 **개인적이고 저렴한 일상용**, 클라우드 모델은 고성능 작업용으로 쓰는 이상적인 조합에 가까워지고 있음 - cloclo가 **pi-mono**와 어떤 점에서 다른지 궁금함 - 이번 이야기의 핵심은 Gemma 4 자체보다 **하니스(harness)** 와 모델이 완전히 분리되었다는 점임 Claude Code, OpenCode, Pi, Codex 모두 어떤 백엔드와도 작동함 즉, 코딩 에이전트는 점점 **범용화된 계층**이 되고 있으며, 경쟁의 초점은 모델 품질과 비용으로 이동 중임 사용자에게는 좋은 일이고, 하니스에 의존하던 기업에게는 위협임 - 오히려 반대라고 생각함. 모델이 범용화되고 있고, **하니스와 툴링**이 실제 성능 향상의 핵심이 되고 있음 예를 들어 [“Improving 15 LLMs at Coding in One Afternoon”](https://news.ycombinator.com/item?id=46988596) 글에서도 하니스만 바꿔도 큰 개선이 있었다고 함 - 사실 Claude Code나 OpenCode를 로컬 HTTP 엔드포인트에 바로 연결할 수도 있었음 - `ollama launch claude --model gemma4:26b` 명령으로 간단히 실행 가능함 - **context window** 크기를 늘리지 않으면 툴 호출 기능이 작동하지 않음 - ollama와 claude만 설치되어 있으면 이렇게 간단히 작동한다는 점이 놀라움 - 하지만 내 경우에는 작동하지 않았음. claude가 무한 루프에 빠지고 응답이 없음 Nemotron, glm, qwen 3.5는 잘 되는데 **gemma만 문제**였음 - 이 접근법이 **웹 소프트웨어 테스트 자동화**에도 유용할 것 같음 Selenium이나 Puppeteer는 웹 디자인이 조금만 바뀌어도 테스트가 깨지기 쉬움 반면 이런 모델은 변화에 적응할 수 있어 더 **유연한 테스트**가 가능할 듯함 특히 소형 모델로도 충분히 활용 가능해 보임 - MoE는 실제로 (V)RAM을 절약하지 않음 모든 **가중치가 메모리에 상주**해야 하고, 단지 한 번의 추론에서 일부만 사용함 그래서 tok/s는 개선되지만 VRAM 사용량은 그대로임 - 나도 처음엔 헷갈렸음. 비활성 전문가들은 연산을 건너뛰지만 여전히 메모리에 로드되어 있음 [이 시각화 자료](https://vectree.io/c/sparse-activation-patterns-and-memory-e...)가 이해에 도움이 되었음 - 일부 추론 엔진에서는 **일부 전문가를 CPU RAM으로 오프로드**할 수 있음 예를 들어 35B 파라미터 MoE를 12GB VRAM GPU + 16GB RAM 조합으로 돌릴 수 있음 - 모든 가중치를 동시에 메모리에 둘 필요는 없음 RAM, 디스크, 네트워크 등에서 **필요한 부분만 교체 로드**할 수 있음 MoE는 다음 추론 단계에서 교체해야 할 데이터 양을 줄여줌 - 나는 Claude Code를 **데이터 파이프라인 반복 작업의 주 인터페이스**로 사용 중임 특히 정부 규제 공시(XBRL)를 표준화하고 REST와 MCP로 노출하는 작업임 MCP는 흥미로운 부분인데, 클라이언트를 직접 호출하는 대신 **도구를 선언적으로 정의**하고 모델이 호출 시점을 결정함 예를 들어 “이 회사의 10년간 레버리지 추세를 업계 평균과 비교” 같은 질의가 자동으로 적절한 도구 호출 시퀀스로 분해됨 다만 MCP 대화형 사용에서는 **지연(latency)** 이 훨씬 민감함 2초 응답은 스크립트에서는 괜찮지만 대화 흐름을 깨뜨림 그래서 자주 쓰는 테이블을 메모리에 캐싱해 100ms 이하 응답을 달성했음 다른 사람들도 이런 **지연 임계값**을 경험했는지 궁금함 - 나도 MCP를 유용하게 쓰지만 **토큰 사용량**이 많아질 수 있음 단순 구현에서는 동일한 기능 대비 수만 개의 토큰을 더 소비함 [Anthropic의 설명 글](https://www.anthropic.com/engineering/code-execution-with-mcp)이 있지만 좀 오래된 자료임 - 내 경험상 도구 호출당 300~500ms가 **자연스러운 상한선**임 그 이상이면 다단계 체인이 느려지고, 모델이 불필요한 추론을 추가해 문맥이 부풀어짐 캐싱 외에도 여러 데이터를 한 번에 반환하도록 **왕복 호출 수를 줄이는 전략**이 효과적이었음 - macOS에서 Gemma 4 26B를 Claude Code용 로컬 추론으로 설정하는 방법을 공유함 - 훌륭한 정리라고 생각함 - 앞으로 주요 AI 연구소들이 **로컬 LLM을 병행 운영**해 클라우드 부하를 줄이고, 무거운 연산만 클라우드에서 처리하는 구조로 갈 수도 있을 것 같음 - 하지만 그건 그들의 **비즈니스 모델과 상충**되지 않을까 하는 의문이 있음 - Gemma 4 모델이 **에이전트형 코딩 작업**에서 얼마나 잘 작동하는지, 실제 인상은 어떤지 궁금함