Agens Volundr 32B Preview 공개: 자체 하이브리드 아키텍처 기반 소규모 팀의 첫 모델, 72개 레이어 중 18개만 KV 캐시 유지 (Apache-2.0)
원문 제목 — Agens Volundr 32B Preview: our small team's first model on our own hybrid architecture. Only 18 of 72 layers keep a KV cache (Apache-2.0)
📄 전문 번역
r/LocalLLaMA에 홍콩 소재 소규모 팀 Blockway 소속 개발자가 자체 하이브리드 아키텍처로 구축한 첫 번째 모델 Agens Volundr 32B Preview를 공개했다(자체 모델임을 공개적으로 밝힘). 제한된 컴퓨트로 학습해 완벽하지 않다는 점을 인정하며, 부족한 부분을 미리 솔직히 알리겠다고 밝혔다.
구축 배경은 고객들이 자체 머신에서 모델을 구동하는 환경에서는 긴 컨텍스트에서 가중치가 아닌 KV 캐시가 수용 가능한 크기를 결정하기 때문이다. 아키텍처는 총 72개 레이어(dense 약 32B, 모든 레이어가 모든 토큰에서 실행)로, 54개 KDA(Kimi Delta Attention) 레이어는 고정 크기 순환 상태를 갖는 선형 어텐션으로 KV 캐시가 없고, 17개 BCSA 레이어(자체 압축 스파스 어텐션)는 마지막 4,096 토큰에 대한 정확한 윈도우를 유지하며 더 오래된 컨텍스트는 4:1로 블록 풀링한 뒤 학습된 인덱서가 상위 512개 블록을 읽는다. 72번 레이어 1개는 풀 어텐션이며, 호스트 RAM에 저장된 해시 n-gram 메모리인 Engram이 72개 레이어 중 2개에 연결되고, mHC는 잔차 스트림을 1개 대신 4개로 사용한다. 결과적으로 72개 레이어 중 18개만 KV 캐시를 유지하며, 컨텍스트 윈도우는 262K이다.
속도 측정(단일 사용자, 자체 sglang 빌드)에서 48GB GPU 2장 BF16 디코드는 1K에서 25.1 tok/s, 8K에서 24.1, 32K에서 24.1, 64K에서 24.0, 128K에서 23.9 tok/s를 기록했고, BF16 프리필은 1K부터 128K까지 각각 2,122 / 2,180 / 1,916 / 1,679 / 1,297 tok/s였다. 48GB GPU 1장 INT4(31.7GiB) 디코드는 1K에서 31.0 tok/s, 8K에서 29.3, 32K에서 29.1 tok/s이며, 집계 처리량은 BF16 기준 8명 사용자에서 127 tok/s, 16명에서 130 tok/s, INT4 기준 8명에서 117 tok/s이다. 별도 저장소로 공개된 DFlash2 드래프터는 단일 사용자 기준 같은 서버에서 켜기와 끄기를 비교했을 때 JSON/도구 출력에서 최대 3.6배, 코드에서 2.0배, thinking 모드에서 약 1.6배의 속도 향상을 보이지만, 대략 8명을 넘는 동시 사용자 환경에서는 가치가 없다고 밝혔다.
벤치마크는 비교 모델을 포함해 모두 동일한 설정의 단일 하네스에서 직접 실행했으며(전체 표와 각주는 모델 카드 참조), Qwen3.8-27B 대비 LiveCodeBench v6에서 +4.2, HumanEval에서 +4.3, AIME 2025에서 +2.9, MATH-500에서 +1.6 앞서고 MMLU-Pro, IFEval, GPQA Diamond에서는 대체로 비슷한 수준이다. 반면 에이전트 작업에서는 tau2-bench 74.2 vs 79-80, SWE-bench Verified(50개 작업 부분집합) 44 vs 58-64로 뒤처지며, 이 격차를 줄이는 것이 약 10B 토큰까지 사전 학습을 이어가고 긴 에이전틱 세션 학습을 추가하는 정식 v1의 주요 목표다.
알려진 제한 사항으로 자체 sglang 빌드가 필요하며 정식 sglang과 vLLM은 아직 로드할 수 없고, GGUF/llama.cpp 지원은 계획 중으로 현재는 사용할 수 없다. 긴 에이전틱 세션이 이 Preview에서 가장 약한 부분이며 아직 학습 중이므로 최종 모델이 아닌 Preview로 취급해야 한다. 실행은 48GB Ada GPU용과 H100/H200용 Docker 이미지를 제공하며 전체 실행 명령은 모델 카드에 있다. BF16, INT4, DFlash2 드래프터 모델은 Hugging Face에서, 프로젝트 페이지와 서빙 코드는 GitHub에서 공개했으며 라이선스는 Apache-2.0이다. 소규모 팀으로서 사용자가 직접 사용해 보고 이슈, 실패하는 프롬프트, 실행을 원하는 벤치마크 등을 알려주는 것이 가장 큰 도움이 된다고 덧붙였다.
💬 주요 댓글 번역 (5)
🔍 루키 분석
홍콩 소재 소규모 팀 Blockway가 자체 하이브리드 아키텍처 기반 첫 모델 Agens Volundr 32B Preview를 Apache-2.0 라이선스로 공개했다. 72개 레이어 중 54개를 KV 캐시가 없는 KDA 선형 어텐션으로 구성해 KV 캐시를 유지하는 레이어를 18개로 줄였으며, 컨텍스트 윈도우는 262K에 이른다. 코딩과 수학 벤치마크에서는 Qwen3.8-27B를 앞서지만 에이전트 작업에서는 뒤처지며, 자체 sglang 빌드가 필요하고 GGUF/llama.cpp는 아직 미지원이라는 제약도 함께 밝혔다.
— 루키 · glm-5.3-flash:cloud
KDA 레이어에서 프리픽스 캐싱은 어떻게 동작하나요? KV는 잘라서 재사용할 수 있지만 순환 상태는 스냅샷을 찍어야 하고, 긴 멀티턴 세션에서는 그 스냅샷들이 절약한 메모리를 다시 잠식할 수 있습니다. 어떤 세분성으로 체크포인트를 생성하는지, 그리고 드래프터 거절 시 재프리필이 강제되는지 궁금합니다.
그건 모델보다 추론 엔진에 더 좌우되는 문제라고 생각합니다(llama.cpp의 Qwen3.5 아키텍처처럼요).
엔진이 구현 품질을 좌우하는 것은 맞지만, 레이어 배치는 런타임 선택이 아니라 가중치에 박혀 있습니다. 18개 캐시 보유 레이어는 학습으로 고정되어 있으며, 엔진은 이를 따르거나 아니면 72개 전체를 할당해 약 4배의 메모리를 낭비하는 수밖에 없습니다. llama.cpp 지원은 진행 중이며 vLLM은 오늘부터 동작합니다.
무슨 말인지 모르겠습니다. 캐싱은 추론 최적화입니다. 레이어 배치가 고정된 것은 당연하지만, 여기서 선형 어텐션 레이어(KDA)는 Qwen 3.5 아키텍처 배치와 크게 다르지 않습니다. 기억이 맞다면 그냥 해당 레이어의 상태를 여기저기(모든 KDA 레이어에 대해 특정 시점에만) 저장하고, 부족한 부분은 약간의 프리필로 메꾸면 됩니다. 압축 어텐션 레이어에 대한 이야기라면 표준 KV 캐시보다 약간만 복잡하므로 캐싱이 어렵지 않을 것입니다.
요청 내 KV가 아니라 요청 간 프리픽스 캐싱을 말한 것입니다. KDA 상태는 고정 크기 순환 상태라 청크 경계에서 스냅샷을 찍을 수는 있지만 KV처럼 잘라내거나 부분 재사용할 수 없어, 프리픽스가 조금이라도 어긋나면 마지막 체크포인트부터 재생해야 합니다. 제가 지적한 것이 바로 그 부분입니다.