ollama 0.22.0 버전까지 해당하는 보안 취약점 발견 보고입니다. Gemma 4 MTP(Multi-token Prediction) 사용이 가능한 llama.cpp MTP 신규 옵션 관련 소식들이 늘어나고 있습니다. ollama도 MTP 지원 모델을 발표했고, llama.cpp는 mtp-branch를 이용해서 MTP 옵션 사용이 가능해졌습니다.
Ollama 보안 취약점 발견 – 원격 프로세스 메모리 누출 위험
원격의 인증되지 않은 공격자가 이를 성공적으로 악용할 경우 전체 프로세스 메모리를 유출시킬 수 있는 ollama의 치명적인 보안 취약점을 공개했습니다. ollama 0.12.10 ~ 0.22.0 버전은 이 취약점을 가지고 있으니 최신 버전인 0.23.2로 업그레이드하시기 바랍니다. Windows/MAC은 자동 업데이트 기능으로도 업데이트 가능하고, Linux는 재설치하시면 됩니다.
Ollama MAC/Cloud에서 Gemma4-MTP 모델 지원
지난 주 부터 Google Gemma 4 모델에 MTP(Multi-Token Prediction)적용해서 TPS 성능 향상했다는 소식이 많아지고 있습니다. Ollama에서도 Mac과 Ollama cloud 에서 MTP 적용한 모델을 사용할 수 있게 되었다고 합니다.
Ollama Cloud:
ollama run gemma4:31b-cloud
Mac용 Ollama w/ MLX:
ollama run gemma4:31b-coding-mtp-bf16
StrixHalo Linux에서 MTP 실행을 위한 llama.cpp 신규 옵션
기존 llama.cpp에 MTP(Multi-token Prediction)를 위한 신규 옵션이 추가되었습니다. 다만 아직 Main에 합쳐진 것은 아니고 별도의 mtp-branch로 나누어져 있는 상태입니다. 바로 MTP 사용해 보고 싶으신 분들은 mtp-branch llama.cpp 이용해서 신규 build 하시기 바랍니다.
12gb VRAM에서 llama.cpp MTP버전과 Qwen3.6 35B A3B로 80 tps & 128 context 달성
llama.cpp의 MTP(speculative decoding) PR을 적용해 12GB VRAM 환경(RTX 4070 Super 12GB, CPU Ryzen 7 9700X, 48GB RAM)에서 128K 토큰 컨텍스트를 유지하면서 약 80 토큰/초를 달성한 설정을 공유함.
하드웨어/OS: CachyOS 권장, CPU: Ryzen 7 9700X, RAM: 48GB DDR5, GPU: RTX 4070 Super 12GB.
필요 조건: llama.cpp를 소스에서 빌드하고 MTP 관련 PR을 적용. Qwen3.6-35B-A3B MTP GGUF 모델 사용(모델명 언급).
핵심 실행 옵션(대표 항목들):
- -fitt 1536 (GPU/CPU 오프로드 밸런싱을 위해 중요)
- -c 131072 (context 131,072)
- -n 32768, -fa on, -np 1
- –no-mmap, –mlock (디스크 I/O 회피, 안정성)
- –spec-type mtp, –spec-draft-n-max 2 (MTP와 드래프트 수)
- –chat-template-kwargs ‘{“preserve_thinking”: true}’ 등 생성 파라미터(temperature/top-p/top-k 등) 설정
-fitt 설명: 모델 일부가 CPU로 오프로드되므로 GPU/CPU 메모리·연산 밸런스를 맞추기 위해 남겨둘 VRAM 크기(예: 1536MB)를 지정. dGPU가 주 GPU로 사용 중이면 값 조정 필요.
벤치마크 결과(대표값):
- 여러 작업별로 측정했으며 tok/s 대략 69–82 범위(예: code_python ~80.8, code_cpp ~81.8, explain_concept ~70.0 등).
- 전반적 드래프트 수용률(accept rate) 높음(많은 작업에서 70%~95% 범위).
튜닝 팁: –spec-draft-n-max 값(2 vs 3 등)으로 속도와 수용률 간 트레이드오프 존재. –no-mmap + –mlock은 지속 처리량에 유리.
커뮤니티 반응:
- 여러 사용자가 다양한 하드웨어(예: GTX 1070, 3060 12GB, 4080 등)에서 재현 벤치 결과 공유 — 성능은 하드웨어와 설정에 따라 넓게 변동.
- –no-mmap이 디스크 I/O 제거, 일정한 메모리 사용, 약간의 속도 향상 및 표준편차 감소에 기여한다는 실험 보고.
turboquant / turbo KV 캐시 등 추가 최적화(특히 K/V 캐시 압축)를 함께 쓰는 사례 다수. - 컨텍스트가 커질수록(예: 0→125K) 생성 속도 저하(어텐션 O(n) 비용) 관찰 — MTP는 긴 컨텍스트에서 이점을 크게 줌.
- 일부 사용자는 hallucination(허위 응답), 오버사고(반복적·불필요한 ‘thinking’) 문제를 보고했고, 해결책으로 thinking 비활성화나 파라미터 조정 제안.
- 시각(vision) 관련 MTP 이슈 보고 및 관련 깃허브 이슈/PR 참조(문제 존재).
- OpenCode 등 에이전트 워크플로우에서 루프 문제나 프리프로세싱 지연을 겪었다는 사례도 있음.
전반적 결론: 적절히 튜닝하면 12GB VRAM 환경에서도 MTP + llama.cpp로 대형 모델(아주 일부 파라미터 오프로드) 기반의 긴 컨텍스트/합리적 토큰 속도를 얻을 수 있으며, 사용자 환경에 따라 세부 설정(특히 -fitt, 드래프트 수, mmap/mlock, KV 캐시 방식 등)을 맞춰야 함.
qwen3.6, qwen3-coder, deepseek-coder 코딩 성능 비교
테스트한 모델
- qwen3.6:27b
- qwen3.6:35b-a3b
- qwen3-coder:30b
- deepseek-coder:33b
결과 요약
- deepseek-coder:33b
- 단일 함수 코드 생성에서 최고 성능(코드 생성 90%).
- 그러나 다단계 에이전트 작업에서는 매우 낮은 성능(10%). (코드 완성에 최적화되어 계획/중간 결과 관리가 약함)
- qwen3.6:27b
- 코드 생성 약 80%, 도구 호출 84%, 에이전트 작업 100%.
- 전체적으로 균형이 좋고 하나만 유지해야 한다면 추천되는 모델.
- qwen3-coder:30b
- 무난한 중간형(특정 분야 최고는 아님).
- qwen3.6:35b-a3b
- 에이전트·도구 작업은 27b와 비슷하지만 코드 생성 성능은 떨어짐.
실행상 팁/주의점
- qwen3.6은 응답 전에 긴 ‘생각(think)’ 블록을 출력함 → 기본 Ollama num_predict(2048)로는 생각에 예산을 다 소모하고 코드 출력이 잘리는 문제 발생.
- 해결: num_predict를 8192로 올리고 think 블록을 제거해서 파싱하면 qwen3.6:27b의 코드 생성 성능이 40% → 80%로 개선됨.
- 타임아웃 조정: dense qwen3.6은 CPU에서 1200초, MoE 모델은 600초로 설정.
Strix Halo Clustering 논의
상황: Strix Halo (bosgame m5)를 한 대 보유 중이며, 가격 상승을 이유로 동일 기기 한 대를 더 구입해 두 대를 클러스터링해 더 큰 모델(특히 400B급 등)을 로컬에서 돌리고자 함. 기업 환경이라 로컬 호스팅이 필수.
목표: 노드를 2대로 구성해 RAM을 128GB → 256GB로 늘리고 그에 따라 더 높은 정밀도(quant) 모델과 큰 컨텍스트를 돌리려고 함.
주요 관점과 권장사항
- RDMA 중요성: 25Gbps 이상 영역에서는 대역폭보다 지연(latency)이 성능에 큰 영향을 미치므로 RDMA(예: RoCE)를 지원하는 NIC과 직접 CPU에 연결되는 구성(PCIe 직결)이 권장됨.
- Oculink / M.2 NVMe → 외부 NIC: Oculink를 통해 PCIe NIC를 외부로 연결하면 RDMA 지원 NIC 사용이 가능하며, 실사용에서 저비용으로 2×25GbE 구성 가능하다는 경험담(중고 Broadcom 카드 + 어댑터 조합 언급).
- Thunderbolt / USB-C 네트워킹: 일부가 USB/Thunderbolt 네트워크로 묶는 실험을 말하지만, Thunderbolt 계층으로 인한 추가 지연이나 RDMA 부재를 지적하는 의견이 있음. USB 이더넷 바인딩(포트 본딩) 방식도 논의됨.
- 예상 실속 대역폭: PCIe 4×4 레인 제한 때문에 이론적 한계는 있어도 실제로는 4×4 대역폭(수십 Gbps, 현실적으론 50~64Gbps 영역) 수준이라는 언급.
- eGPU(외부 GPU) 활용: NVMe eGPU를 통해 prefill(키/컨텍스트 전처리) 성능을 크게 끌어올릴 수 있고, CUDA 기반 외부 GPU(예: 3090 듀얼 등)를 붙이면 생성/프리필 성능이 상당히 개선된다는 실벤치 사례가 다수 존재. 다만 대형 모델에서는 VRAM 비율 때문에 이득이 제한적일 수 있음.
- 소프트웨어·토폴로지:
- vLLM, llama.cpp + rpc 등으로 분산 가능. vLLM은 서버형 워크로드(동시 요청)에서 유리하며, 설치·툴박스(커뮤니티 스크립트)가 존재함.
- 텐서 병렬은 prefill 가속에 유리하다는 의견. 파이프라인 병렬은 토큰/초 관점에서의 이득이 모델·구성에 따라 제한적일 수 있음.
- Exo는 MAC 클러스터 관련 사례가 많아 Strix Halo에서의 범용성은 불확실.
- 클러스터링을 RDMA 없이 구성하면 매우 느리다는 경고.
- 모델/정밀도 관련: 128GB에서 가능한 모델(예: Minimax 2.7 q3, GLM 4.7 q1/q2, Qwen 3.5 q3-ish)과 256GB에서 기대 가능한 업그레이드(예: Minimax q4 2.7, GLM 4.7 q4, GLM 5.1 q1/2 가능성, Qwen 3.5 q4) 예시를 OP가 제시함.
- 벤치마크·경험담: 여러 사용자가 Strix 단독 vs eGPU 조합의 PP(프리필)/TG(토큰 생성) 성능 수치를 공유. 전반적으로 Strix 단독은 대형 모델에 느리다는 의견, eGPU·듀얼 GPU 조합은 큰 개선을 보였음.
- 커뮤니티/리소스: Strix Halo 전용 디스코드와 커뮤니티 툴박스(여러 GitHub 리포지토리·툴박스 이름들이 댓글에서 언급됨)를 추천.
결론(요약)
- 핵심 결론: RDMA 가능한 NIC + 직접 PCIe 연결(예: Oculink 통한 NIC)이 두 대 클러스터에서 실용적이고 비용 효율적인 방법으로 추천된다.
- Thunderbolt/USB 네트워킹은 대안이지만 RDMA 부재나 지연 문제 때문에 최선은 아님.
- eGPU는 prefill을 크게 개선해 실제 에이전트 작업에 큰 도움을 줄 수 있음.
- 소프트웨어 측면에선 vLLM, llama.cpp(및 분산 RPC), 텐서 병렬 기법을 조합해 실험하는 것이 일반적이며, 커뮤니티 툴박스가 설치·셋업 난이도를 낮춰줌.
- 리스크: 클러스터링은 하드웨어 인터커넥트·RDMA 지원·PCIe 레인 제약 때문에 기대한 만큼 선형적 성능 향상이 안 될 수 있음(특히 PP 성능은 병렬화 한계가 존재).
8gb vram/32gb ram에서 Qwen3.6 35b a3b를 ~190k context 실행하기
lllama.cpp의 TurboQuant 적용 버전을 이용해서 Q5 모델 성능 비교해 보았다고 합니다. 동일 설정에서 Windows보다 Linux에서의 성능이 좀 더 좋았다고 하고, Q4가 Q5 보다 낮은 성능을 보였다고 합니다. 자세한 시험 내용은 출처에서 확인하시기 바랍니다.
※ 지난 게시글:
- AI & OpenClaw – 2026.5.6 소식
- AI & OpenClaw – 2026.5.4 소식
- AI & OpenClaw – 2026.4.29 소식
- AI & OpenClaw – 2026.4.24 소식
- AI & OpenClaw – 2026.4.23 소식
※ 출처: r/LocalLLM, r/openclaw, r/unsloth, r/opencode, r/claude
