AI & OpenClaw – 2026.5.12 소식

오늘은 Local AI 모델 사용 후기입니다. 12GB VRAM에서 Qwen3.6-35B-A3B Q5_K_M 모델 실행하기 위한 llama.cpp 옵션, 7900 XTX 에서 TurboQuant + MTP 를 위한 llama.cpp 옵션, Pi coding agent 사용 후기입니다.

Qwen3.6-35B-A3B Q5_K_M on 12GB VRAM – llama.cpp 설정

하드웨어·소프트웨어

• GPU: NVIDIA RTX A2000 12GB
• RAM: 128 GB
• OS: Oracle Linux Server 9.7, llama.cpp CUDA 빌드 (CUDA 13.2), 드라이버 버전 595.71.05
• CPU: Intel Xeon Silver 4314 (언급: 16코어·32스레드), DDR4 2666 MT/s — MoE 오프로드 때문에 메모리 대역폭이 병목 요인일 수 있음.

모델 특성·핵심 아이디어

• Qwen3.6-35B-A3B는 MoE(혼합 전문가) 모델 — 전체는 35B이나 토큰당 활성 파라미터는 약 3B.
• 핵심 트릭: MoE 전문가 블록들을 CPU RAM으로 오프로드해 12GB VRAM에 맞춤. (-ncmoe 플래그로 GPU에 남길 MoE 블록 수 조절)
• MoE 블록당 GPU 비용: Q5_K_M에서 대략 ~500 MiB.

권장 설정(주요 llama.cpp/llama-server 플래그)

• 모델 지정: -hf / -hff (HuggingFace 리포/파일 — 모델 자동 다운로드)
• 모든 레이어를 GPU에 올리고, 그 후에 남길 MoE 블록 수 지정: -ngl 999 및 -ncmoe 26 (예시)
  • 컨텍스트: -c 32768 (32K)
  • KV 캐시 양자화: -ctk q8_0 -ctv q8_0 (KV 캐시 VRAM 절반 절감)
  • 플래시 어텐션: –flash-attn on (명시적으로 on 필요)
  • CPU 스레드: -t 16 (물리 코어/스레드 수에 맞춤)
  • 안정성/로딩: –no-mmap (전체 모델을 RAM에 로드), –jinja (Qwen3 계열의 채팅 템플릿 사용)
  • 모델의 ‘사고 모드’ 제어: /no_think 로 끌 수 있음

성능 및 자원 사용

• 프롬프트 처리: 약 79 tok/s
• 생성(생성 속도): 약 35 tok/s
• VRAM 사용량: 약 10.3 GB
• RAM(주기억) 상주: 약 18.4 GB (그중 ~13.3 GB가 CPU에 고정된 MoE 전문가 가중치)

결론: Q5에서 35B 모델을 35 tok/s로 돌리는 것은 에이전트 파이프라인 백엔드로 실용적임.

Llama.cpp Turboquant + MTP on 7900 XTX

모델 / 설정

• 대상 모델 예: Qwen3.6-27B의 MTP 형식 및 Non-MTP(Quantized) 형식 사용.
• 긴 컨텍스트(예: 256k, 196k, 196608 등)와 4k/8k 같은 짧은 컨텍스트 설정으로 다수 실험.
• GPU 오프로드(n-gpu-layers=999 등), 다양한 캐시 타입(k/v: f16, q4_0, q8_0, turbo2/3/4, turbo3 등) 실험.

주요 성능 관찰

• ROCm(f16)과 Q4_0의 프롬프트 처리 성능(평가 기준에 따라 거의 동일): 예로 ROCm f16 ≈ 904 token/s (PP), TG ≈ 29 token/s.
• Vulkan 표준 빌드에서 q4_0 프롬프트 처리 ≈ 770 token/s, TG ≈ 37 token/s.
• TurboQuant(Vulkan) 프롬프트 처리 속도(특정 설정에서) 최고 약 193 token/s(단, 이는 prompt 처리에 해당) — generation 속도(토큰 생성)는 대체로 ~21–24 token/s 범위.
• MTP(다단 초안 생성)는 생성 속도를 크게 향상시킴: 예) Vulkan에서 Non-MTP(f16) ≈ 39.5 token/s → MTP(q4_0) ≈ 81.2 token/s (대략 +100% 수준). ROCm에서도 Non-MTP 29.4 → MTP(q4_0) ≈ 53.6 token/s 등.
• Q4_0 성능은 f16에 근접(ROCm 환경), Q8_0는 프롬프트 처리에서 느리지만 생성 속도는 유사한 경우가 많음.

백엔드별 문제 및 한계

• Vulkan + TurboQuant: GPU 활용률이 낮음(약 30%) — CPU 측의 양자화/복원 비용이 병목으로 의심됨.
• ROCm + MTP: 대화 시작 시 VRAM이 약 5GB 급증하는 이상 증상 보고. 이로 인해 실제 최대 사용 가능한 컨텍스트 길이가 약 ~8k 수준으로 제한되는 문제 있음(긴 컨텍스트에서 불안정, 크래시 또는 프리즈 발생).
• MTP의 제약: 현재는 단일 세션(단일 대화 흐름) 위주이며 병렬 요청을 처리하지 못함(초안 모델이 순차적으로 실행되어 처리량 제약).

운영/실행 관련 메모

• TurboQuant(특정 빌드)만 일부 turbo 타입(turbo2/3/4)을 제공.
• 벤치 커맨드와 서버 실행 예시가 게시되어 있으며, 로컬 서버를 통해 API 형태로 운영하는 설정 사용.
• Hipfire(DFlash) 등 다른 프로젝트나 PR(예: ggml/llama.cpp 관련 PR)도 테스트 및 참조됨.

커뮤니티 코멘트(주요 피드백)

• 일부 사용자가 ROCm + MTP 환경에서 VRAM 손상/그래픽 글리치 및 크래시 현상을 보고함.
• Q8 모델에서 더 빈번하게 발생한다고 함 — VRAM 할당/스파이크가 문제의 원인으로 추정.

요약 결론 (권장 관점)

• 성능 관점에서 MTP와 TurboQuant은 특정 시나리오에서 큰 이득을 줌(특히 prompt→generation 처리 속도 개선).
• 그러나 현재 구현(특히 ROCm+MTP, Vulkan+TurboQuant)에는 안정성·병목 문제가 있어, 긴 컨텍스트 처리나 병렬 요청이 필요한 워크로드에는 제약이 있음.
• 실사용 전에는 사용하려는 조합(백엔드, 캐시 타입, MTP 유무)에 대해 짧은 테스트를 먼저 권장(특히 VRAM 사용/스파이크, GPU 활용률 체크).

OpenCode 대체 Pi coding agent 사용 후기

• 작성자는 OpenCode에서 Pi 코딩 에이전트로 전환해 본 경험을 공유함. 결과적으로 Pi가 더 빠르고 정확하며 신뢰할 만하다고 평가.
• 환경: M4 MacBook Pro(64GB), oMLX 백엔드로 jundot가 만든 qwen3.6(약 35B) 양자화 모델 사용. 토큰 처리 속도 및 메모리 사용량 언급.
• 간단한 비교 예시: 같은 작업(보드게임 커버 이미지로 3×3 콜라주 생성)을 OpenCode와 Pi에 각각 시켰을 때 Pi는 처음에 정확하게 처리했으나 OpenCode는 여러 번 수정이 필요했음.
• 더 복잡한 작업: 라이브 필터링 검색 기능 추가를 단계별로 계획하고 구현하도록 시켰더니 Pi가 계획-확인-구현-디버깅 순으로 잘 수행. 발생한 오류도 빠르게 수정함.
• 흥미로운 점: Pi가 자체적으로 사용자 세션에서 부족한 기능을 식별하고(예: 자동 축약, 컨텍스트 복구 등) 스스로 개선 기능을 추가하도록 하여, 사용하면서 Pi를 점진적으로 맞춤화함.
• 결론: 작성자는 로컬 모델 환경에서 Pi가 OpenCode보다 더 효율적이고 실용적이라 판단해 전환했다고 밝힘.

댓글(토론)에서 나온 주요 논점

• 하네스(에이전트 프레임워크)의 중요성: 단순한 래퍼가 아니라 메모리·컨텍스트 관리, 툴 노출 방식, 세션 관리 등으로 모델 성능에 큰 차이를 만듦.
• 시스템 프롬프트/컨텍스트 오염: OpenCode 등 일부 하네스는 시스템 프롬프트가 크고 많은 지침·툴을 넣어 컨텍스트가 오염될 수 있음. Pi는 매우 최소주의적(짧은 프롬프트, 적은 기본 툴)이라서 모델의 추론 능력을 깔끔하게 활용할 수 있다는 주장.
• 숫자 비교(댓글에서 제시된 근사값): 여러 하네스의 기본 시스템 프롬프트 토큰 수가 다르며, 큰 프롬프트가 성능 저하를 야기할 수 있다는 의견이 제시됨.
• 다른 하네스/도구 비교: Claude Code, Hermes 등과의 차이(“배터리 포함” 대 “미니멀/확장형”) 논의.
• 백엔드 추천·비판: Ollama를 쓰는 것에 대한 비판과 vLLM 같은 더 빠른 백엔드 추천이 언급됨(작성자·댓글러들 사이에서 의견 교환).
• 실용 조언: Pi는 기본 툴이 적지만 필요하면 확장해서 쓰는 철학이며, 로컬 모델을 토큰·컨텍스트 비용 절약 관점에서 효율적으로 쓰기 좋다는 평.

※ 지난 게시글:

• AI & OpenClaw – 2026.5.11 소식
• AI & OpenClaw – 2026.5.6 소식
• AI & OpenClaw – 2026.5.4 소식
• AI & OpenClaw – 2026.4.29 소식
• AI & OpenClaw – 2026.4.24 소식

※ 출처: r/LocalLLM, r/openclaw, r/unsloth, r/opencode, r/claude