r/LocalLLaMA•4개월 전•40•24

집에서 쓰는 서브 에이전트

We have sub-agents at home

핵심 요약

10GB VRAM 환경에서도 원활하게 돌아가는 로컬 서브 에이전트 구현 및 공유.

VRAM 제약 해결 — 10GB VRAM 환경에서도 효율적으로 작동하는 로컬 서브 에이전트 구현함.
llama.cpp 최적화 — 단일 슬롯 및 컨텍스트 재처리 없는 방식으로 성능을 극대화함.
코드 공유 및 협업 — pi-subagent를 포크하여 로컬 환경에 맞게 최적화한 저장소를 공개함.
컨텍스트 관리 — MTP와 Apex Qwen 모델을 활용해 긴 컨텍스트에서도 안정적인 성능을 확보함.

회사에서는 GPT-5.4와 Sonnet을 마음껏 쓸 수 있어서, 리포지토리에 서브 에이전트를 여러 개 띄워 작업을 분담시키는 방식에 익숙해져 있었음.

집에서는 VRAM이 부족한 상황이라 로컬 모델을 돌리며 즐기는 편임. 그런데 시중에 나온 거의 모든 서브 에이전트 확장 기능이나 구현체들은 10GB VRAM과 (이미 양자화된) KV 캐시용 슬롯 하나라는 제약을 전혀 고려하지 않음.

나도 개발자로 일하고 있어서, 기존 서브 에이전트 리포지토리를 포크해서 qwen3.6-35b-a3b 모델로 pi coding agent를 돌릴 수 있게 만들었음.

이 내용은 다음 조건에 해당하는 사람들에게만 유용할 거임:

pi coding agent를 하네스로 사용하는 경우
llama.cpp 서버를 통해 1개의 슬롯으로 한 번에 하나의 LLM만 실행 가능한 경우
서브 에이전트 작업이 끝난 후 프롬프트를 완전히 재처리하고 싶지 않은 경우

리포지토리는 여기에 있으니 마음껏 가져다 쓰거나 포크해도 됨. 다른 사람들은 VRAM이 제한된 로컬 환경에서 서브 에이전트를 어떻게 다루고 있는지 궁금함. 서브 에이전트를 이전 컨텍스트 없이 생성하고, --slot-save-path와 slots 엔드포인트를 통해 메인 컨텍스트를 저장 및 관리하는 기능도 추가할 계획임. 근데 거기서 생성되는 .bin 파일들이 꽤 덩치가 크긴 함 ㅋㅋ

마지막으로, 최근 llama.cpp 메인 브랜치의 MTP 기능을 아주 잘 쓰고 있는데 Apex Qwen 변형 모델에서 꽤 괜찮은 성능이 나옴. q_8 kv로 175-200k 컨텍스트를 돌릴 수 있고, 드래프트 적중률에 따라 200-300 pp와 25-40 tps 정도가 나옴.

원문

커뮤니티 목록

r/LocalLLaMA•4개월 전•40•24

집에서 쓰는 서브 에이전트

We have sub-agents at home

핵심 요약

10GB VRAM 환경에서도 원활하게 돌아가는 로컬 서브 에이전트 구현 및 공유.

VRAM 제약 해결 — 10GB VRAM 환경에서도 효율적으로 작동하는 로컬 서브 에이전트 구현함.
llama.cpp 최적화 — 단일 슬롯 및 컨텍스트 재처리 없는 방식으로 성능을 극대화함.
코드 공유 및 협업 — pi-subagent를 포크하여 로컬 환경에 맞게 최적화한 저장소를 공개함.
컨텍스트 관리 — MTP와 Apex Qwen 모델을 활용해 긴 컨텍스트에서도 안정적인 성능을 확보함.

회사에서는 GPT-5.4와 Sonnet을 마음껏 쓸 수 있어서, 리포지토리에 서브 에이전트를 여러 개 띄워 작업을 분담시키는 방식에 익숙해져 있었음.

나도 개발자로 일하고 있어서, 기존 서브 에이전트 리포지토리를 포크해서 qwen3.6-35b-a3b 모델로 pi coding agent를 돌릴 수 있게 만들었음.

이 내용은 다음 조건에 해당하는 사람들에게만 유용할 거임:

pi coding agent를 하네스로 사용하는 경우
llama.cpp 서버를 통해 1개의 슬롯으로 한 번에 하나의 LLM만 실행 가능한 경우
서브 에이전트 작업이 끝난 후 프롬프트를 완전히 재처리하고 싶지 않은 경우

주요 댓글

r/localllama

로컬 환경에서 VRAM 제약 없이 서브 에이전트를 효율적으로 운영하기 위한 캐시 관리와 모델 퀀트 성능에 대한 기술적 논의가 활발함.

이거 하려고 포크 확장 기능을 써봤는데, 제일 웃긴 건 서브 에이전트가 자기가 포크된 줄 모르고 계속 스스로를 포크해서 '포크 폭탄'을 만드는 거였음. 그래도 공유해줘서 고마움, 한번 써볼게.

맞음, LLM한테 시스템 프롬프트로 흐름을 설명하느라 시간 좀 썼음. 아예 이름을 '서브 에이전트'에서 '포커스 태스크'나 '원샷 모드'로 바꿀까도 고민했음. 대부분의 LLM이 서브 에이전트 관련 데이터로 학습돼서, 자기가 서브 에이전트라는 가능성 자체를 헷갈려하더라고 ㅋㅋ. 포함된 시스템 프롬프트로 꽤 잘 돌아가고 있고, 서브 에이전트 안에서 또 다른 서브 에이전트를 생성하는 호출은 아예 막아버렸음.

이런 건 LLM에만 의존하면 안 됨. 서브 에이전트가 실행될 때는 익스텐션이 스스로 비활성화되게 만들어야 함.

좋네요. 제 주말 프로젝트는 낡은 게이밍 노트북(32GB RAM, 8GB VRAM)에 Ubuntu 서버를 올리고, pi를 핵심으로 Qwen35b Q4 모델을 사용하는 로컬 에이전트 플랫폼을 만드는 거였어요. pp/s는 150 정도, tg/s는 15~20 정도 나오네요. 작업 큐에 밤새 돌릴 작업들 넣어두고 아침에 일어나서 확인해보면, 제대로 구현된 것도 있고 그냥 다 망가뜨려 놓은 것도 있고 그래요. 이거 완전 중독성 있네요.

긴 컨텍스트 에이전트 작업할 때 KV 캐시를 q8이나 q4로 퀀타이즈하는 거 얼마나 안전해? 메모리 꼬임이나 할루시네이션, 아니면 잘못된 툴 호출 같은 거 겪고 있어?

q4 kv cache는 안 써보고 q8만 써봄. 거의 풀 컨텍스트에서도 잘못된 툴 콜을 한 적이 없음. 끝부분에서 메모리 오류가 좀 있긴 한데, 다시 상기시켜주면 복구는 깔끔함. 에이전트 작업에는 q8로도 충분히 만족함. Qwen은 200k 컨텍스트 밀어붙여도 진짜 괴물임. 난 코딩할 때 기술적인 내용이랑 '승리 조건'을 명확히 적은 상세한 task.md 파일을 많이 활용함. 지시사항만 잘 넣어주면 Qwen은 진짜 최고임.

길이 제한으로 뒷부분이 생략된 댓글입니다 · 원문에서 전체 보기 →

내 델리게이트 확장 기능을 만들 때, 메시지 ID를 '고정(anchor)'해서 에이전트를 생성하는 기능을 넣었음. 트리 시작부터 현재 메시지까지 아무 메시지나 지정할 수 있어서, 서브 에이전트의 접두사가 캐시 내용과 정확히 일치하게 만들 수 있음. 생성할 때 저장된 앵커 메시지까지의 컨텍스트를 쓰거나, 전체 컨텍스트를 서브 에이전트에 넘길 수도 있고.

그거 똑똑하네. 근데 뒤로 갈수록 효율성 이득이 줄어들지 않나? 예를 들어 메시지 0에서 10까지 써서 에이전트를 만들었는데 실제로는 메시지가 100개 있는 경우임. 에이전트가 끝나면 메시지 0 -> 메시지 100 -> 에이전트 결과가 되는 거지. llama가 이전 프리픽스를 램에 저장했는지(-cram이었나?)에 따라 메시지 100까지의 이전 프리픽스나 상태를 불러와서 프롬프트 재처리를 안 할 수도 있겠지만, 확실하진 않음. 그래도 선택한다는 개념 자체는 마음에 듦.

공유 감사합니다. 저처럼 VRAM 부족한 환경에서 사는 사람들에겐 탐구해 볼 가치가 있네요. APEX 퀀트 관련해서 질문 하나만 할게요. 저도 써보려 했는데, unsloth에서 여러 퀀트 방식의 KLD를 비교한 차트를 냈더라고요. 보니까 APEX가 비슷한 크기의 UD 퀀트랑 비교했을 때 KLD에서 손실이 꽤 크던데, 그래서 그냥 안 써보기로 했거든요. 작성자님 워크플로우에서는 직접 비교해 보셨나요?

솔직히 MTP가 좀 멍청하게 굴어서 UD q_6로 고생한 뒤로 1~2일밖에 안 써봄. llama.cpp 서버 플래그 4개 값을 수정하는 그리드 서치 기반 서브 프로세스 스포너를 파티클 스웜으로 바꾸는 작업이었는데, 얘가 짠 코드가 그냥 틀려서 작동을 안 했음. 같은 입력 프롬프트로 Apex도 테스트해 볼 예정임. 아직 구체적인 수치나 예시는 없는데, unsloth MTP 퀀트는 어때?

원문r/LocalLLaMA