안녕하세요 여러분, 오랫동안 눈팅만 하던 독자입니다. 이번에는 이 스레드의 공지 게시물을 보고 조심스럽게 낙관적인 전망을 품어왔던 이 모델에 대한 제 경험을 공유하고자 합니다.

---

제 설정:
AMD Ryzen 5 (AM5 칩셋) (정확한 CPU 모델은 기억나지 않습니다. GPU 구매 후 예산에 맞춰 적당한 것을 골랐습니다)
32GB DDR5 (6000MT/s로 작동)
4060Ti 16GB
LLM 제공자 백엔드: llama-swap 뒤에서 실행되는 llamacpp의 PrismML 포크 (PrismML fork of llamacpp)
하네스 (Harness): 커스텀 제작된 확장 기능 세트를 갖춘 Pi agent

---

사용 사례:
지식 베이스 (KB) 관리: AGENTS.md가 포함된 Obsidian vault와, Pi agent가 쿼리를 수행하고, 소스 노트를 생성하며, 참조를 위해 소스 노트를 위키 문서로 합성하도록 돕고 안내하는 일련의 기술(skills) 및 확장 기능(extensions) 세트. 이 에이전트는 비록 arXiv만을 데이터 소스로 사용한다는 한계가 있지만, 체계적인 문헌 매핑 (systematic literature mapping)도 수행할 수 있습니다.
생산성 어시스턴트: Pi agent는 제가 직접 구축한 프로젝트 관리 시스템에 연결할 수 있는 확장 기능을 가지고 있습니다. 또한 Pi agent는 Gmail에 대한 읽기 전용 액세스 권한과, 일별로 정리되어 매일 밤 압축되는 마크다운 파일로 구성된 메모리 시스템을 보유하고 있습니다.

---

저는 보통 위의 사용 사례들을 minimax-m3 구독을 통해 실행하며, 물론 이 모델은 작업을 훌륭하게 처리합니다. 하지만 이는 클라우드 모델이며, 더 중요한 점은 최근 minimax가 약간의 인프라 문제를 겪고 있다는 것입니다. 무작위적인 속도 저하, 스트림 중간에 갑자기 중단되는 요청, 매우 느린 프롬프트 처리(prompt processing) 등이 발생했습니다. 그래서 로컬 모델 중 이 복잡한 설정을 실행할 수 있는 것이 있을지 궁금했습니다. 결과는 가능했습니다. 실제로 꽤 잘 작동합니다. 이 모델들은 이번 포스트의 핵심이 아니므로, 제가 테스트한 내용을 짧게 공유하겠습니다:

Gemma 4 12B QAT (MTP 없음), 전체 262k 컨텍스트: ~1000tk/s 프리필 (prefill), 깊은 컨텍스트(65k 이상)에서 ~20tk/s 디코드 (decode): 1000tk/s의 프리필 속도 덕분에 속도 측면에서 사용하기 가장 쾌적했습니다. 기술(skills)을 정확하게 로드하고 대부분의 작업을 완료하지만, 합성(synthesis)을 작성할 때 게을러질 수 있으며, 도구 호출 (tool calls) 시 환각 (hallucinate)을 일으킬 수 있습니다 (아무것도 하지 않고 작업을 완료했다고 말하는 경우).

Gemma 4 26B QAT (MTP 없음), 전체 262k 컨텍스트, 20개 전문가 레이어 오프로드 시: 프리필(prefill) 약 400tk/s, 디코드(decode) 약 40tk/s. 12B와 매우 유사한 동작을 보이지만 느립니다. Qwen 3.6 35B A3B, 전체 262k 컨텍스트, 모든 전문가 레이어 오프로드 시: 프리필 약 300tk/s, 디코드 약 30tk/s. minimax-m3가 작동하는 방식과 매우 유사하며 고품질의 종합(synthesis)을 작성하지만, 300tk/s의 프리필 때문에 다소 느릴 수 있습니다. 27B를 좋은 컨텍스트와 함께 VRAM에 완전히 구동할 잠재력을 보니 기대됩니다. 저의 주관적인 경험은 다음과 같습니다: 장점: 작동합니다. 도구 호출(tool calls)이 잘못된 JSON이나 누락된 파라미터 때문에 무작위로 실패하지 않습니다. 모델은 장애물을 우회하여 추론하고 대체 도구를 찾을 수 있습니다. 비전 기능도 괜찮게 작동합니다 (IEM의 FR 차트를 읽도록 주었더니, iEM 사운드 시그니처를 잘 읽고 분석했습니다). 전반적으로, LLM이 무엇을 하는지에 대해 너무 제한적이지 않고 계획 조정하라고 반박하지 않는 '행복한' 경로에서는 꽤... 괜찮습니다. 아쉬운 점: KV 캐시가 여전히 상당한 공간을 차지합니다. f16으로 컨텍스트를 100k만 맞출 수 있었습니다. Q8_0 KV 캐시를 사용하면 최대 150k까지 맞출 수 있습니다. 속도: 프리필은 약 600-700tk/s에 불과합니다. 디코드는 dspark 추측 디코딩(speculative decoding) 없이 20tk/s입니다. 저는 1000tk/s에 가까운 프리필을 기대했습니다. dspark가 PrismML llamacpp 포크의 현재 버전과 문제가 있습니다. 어떤 이유에서인지, dspark의 예측 크기가 메인 모델의 최대 컨텍스트와 연결되어 있습니다. 따라서, 만약 제가 메인 모델의 -c를 150k로 설정하면, dspark도 4k가 아닌 150k 컨텍스트를 원하게 되어 CUDA 메모리 할당이 폭발합니다. dspark가 작동할 때는 디코드를 40tk/s에 가깝게 끌어올립니다. 단점: 이 모델은 지침의 미묘한 차이나 세부 사항에서 문제가 있습니다. 예를 들어, 제 시스템 프롬프트에는 모델이 생산성 관련 워크로드를 처리할 때마다 특정 기술을 먼저 로드해야 한다는 점을 강조하는 부분이 몇 군데 있습니다. 10번 중 아마 한 번 정도만 모델이 스스로 그 기술을 활성화했습니다.

모델은 여전히 작업을 수행할 방법을 찾아내지만, 제가 원하는 방식이나 제가 설정한 기술(skill)로 작성되지는 않습니다. 저에게 가장 큰 문제는 Gemma 4와 Qwen 3.6 35B 모두 요청하지 않아도 일관되게 해당 기술을 활성화한다는 점입니다. 이러한 미묘한 차이(nuance)의 부족과 지시 이행(instruction following) 능력의 결여는 다양한 미세한 방식으로 나타납니다. 이 모델은 확실히 일을 해내기는 하지만, 올바른 방식으로 하지는 못합니다. Bonsai 27B의 작동 방식에 대한 인상을 가장 잘 설명하는 방법은, 40단계의 전체 Qwen Image 2512 출력물과 터보(turbo) 4단계 출력물을 비교하는 것과 같다고 생각합니다. 네, 40단계 모델이 가진 주요한 "장점"들을 모두 유지하고 있으며, 결과물도 이전의 거대 모델들보다 뛰어나지는 않더라도 진심으로 좋을 수 있습니다. 하지만 터보 모델을 한동안 사용하다 보면, 지시 사항을 잘 따르지 않고, 텍스트 렌더링 오류가 더 많으며, 다양성이 부족하고, 약간 인위적인(plasticky) 느낌이 든다는 것을 알게 될 것입니다. 즉, 전체 크기 모델의 미묘한 차이가 적고 정밀도가 떨어지는 버전인 셈입니다. 이러한 트레이드오프(trade-off)가 충분히 괜찮은지는 사용 사례에 따라 다릅니다.

---

나의 결론: 저는 약간 실망했습니다. 왜냐하면 제 사양(rig)에서 Gemma 4 12B의 프리필(prefill) 속도를 가지면서도, 35B A3B만큼 신뢰할 수 있는 무언가를 기대했기 때문입니다. Bonsai 27B는 둘 중 어느 것도 제공하지 못했습니다. 현재 저에게 가장 좋은 옵션은 여전히 300tk/s의 프리필 속도를 감수하고 35B A3B를 사용하는 것이며, 모델의 게으른 "에지 케이스(edge case)" 동작을 수정하겠다고 약속한 Google의 새로운 프롬프트 템플릿으로 Gemma 4 모델들을 업데이트하는 것입니다. 하지만, 이 모델이 사기라거나 가짜 기술 같은 것이라고 말하는 것은 아닙니다. 이 모델은 실제로 작동하며, 단순히 채팅을 하거나 작은 작업들을 시키는 용도라면 괜찮습니다. 지능 면에서 12B보다 나은지는 확실하지 않지만, 괜찮은 수준입니다. 예를 들어, 적절한 도구 세트(tool set)가 있다면 저는 이 모델에게 여러 개의 유튜브 영상 링크를 줄 수 있고, 모델은 백그라운드에서 즐겁게 작동하며 스크립트를 가져와 주요 포인트와 제가 해당 영상을 더 자세히 시청해야 할지 여부에 대한 추천을 작성해 줄 것입니다.

이러한 클릭베이트 (clickbait) AI 영상들에 실질적인 내용이 있는지 확인하는 좋은 방법입니다. 이 긴 글이 누군가에게 도움이 되기를 바랍니다! /u/o0genesis0o 제출 [link] [comments]