직장에서는 gpt 5.4와 sonnet에 제한 없이 접근할 수 있어서, 리포지토리(repo)를 대상으로 작업을 수행하거나 업무를 분담하기 위해 서브 에이전트(sub-agents)를 생성하는 것에 꽤 익숙합니다.

집에서는 VRAM이 부족해서 개인적인 즐거움을 위해 모델을 로컬(locally)에서 실행하곤 합니다. 거의 모든 서브 에이전트(sub-agent) 확장 기능이나 구현체들은 10GB의 VRAM과 단일 KV 캐시(KV cache) 슬롯(이미 양자화된 상태)이라는 제약 사항을 전혀 고려하지 않습니다.

저는 이미 개발자로 일하고 있기 때문에, qwen3.6-35b-a3b를 활용하여 기존 서브 에이전트(sub-agent) 리포지토리를 pi 코딩 에이전트(pi coding agent)용으로 일부 바이브 코딩(vibe-coded)된 포크(fork) 버전으로 팀을 구성했습니다.

이것은 오직 다음과 같은 경우에만 유효합니다:

• pi 코딩 에이전트(pi coding agent)를 하네스(harness)로 사용하는 경우
• llama.cpp 서버를 통해 단일 슬롯(1 slot)으로 한 번에 하나의 LLM만 실행할 수 있는 경우
• 서브 에이전트(sub-agent) 작업이 끝난 후 프롬프트를 완전히 다시 처리하지 않고 서브 에이전트(sub-agents)를 사용하고 싶은 경우

리포지토리(Repo)는 여기에 있습니다. 자유롭게 사용하거나 포크(fork)하셔도 상관없습니다. 또한 이곳의 다른 분들은 순수하게 로컬(local) 환경이자 VRAM이 제한된 설정에서 서브 에이전트(sub-agents) 문제를 어떻게 해결하셨는지도 궁금합니다. 이전 컨텍스트 없이 서브 에이전트(sub-agents)를 생성하는 기능과, --slot-save-path 및 slots 엔드포인트를 통해 메인 컨텍스트(main context)를 저장하고 관리하는 기능을 추가할 계획이었습니다. 하지만 그렇게 생성되는 .bin 파일들이 꽤 크네요(lol).

마지막으로, 저는 메인 llama.cpp 브랜치의 MTP를 정말 즐겁게 사용하고 있으며, Apex Qwen 변형 모델로부터 상당히 안정적인 성능을 얻고 있습니다. q_8 kv를 사용하여 175-200k 컨텍스트(context)로 실행할 수 있습니다. 초안 적중률(draft hit rates)에 따라 200-300 pp 및 25-40 tps를 기록하고 있습니다.