제가 잘못 생각하고 있을 수도 있다는 점은 열려 있지만, 제가 발견한 내용들은 공유할 가치가 있다고 느낍니다. [IMG:N] 에이전트 8개가 각각 코드베이스를 병렬로 설명하는 UI의 짧은 비디오입니다. 긴 산문(long prose) 형식으로요: https://imgur.com/JSqlXIi 얼마 전 Stanford/Berkeley TokenGate 논문을 읽었습니다. 이 아이디어는 토큰을 미리 가지치기(pruning)하여 긴 컨텍스트를 저렴하게 만드는 것입니다. 제가 이것을 시도해 보았습니다. 하나의 질문에는 괜찮지만, 에이전트들이 계속해서 새로운 질문을 던지면서 필요한 토큰들은 사라지고, 그 결과 코드 회상력(code recall)이 급격히 떨어집니다. 그래서 저는 반대 방향으로 갔습니다. 아무것도 버리지 않고, 다만 모든 것을 한 번에 보지 않는 것입니다. 전체 컨텍스트를 시스템 RAM에 유지하고, 각 단계마다 현재 필요한 약 1%만 가져오는 방식입니다. 며칠 후, 두 개의 3090을 사용하여 8개의 코딩 에이전트를 동시에 실행했고, 각각은 자체적인 250K 토큰 컨텍스트를 보유했습니다: 디코딩(decode) 단계마다 각 어텐션 레이어는 작은 rank-64 "키 스케치(key sketch)"로만 약 1%의 토큰을 읽습니다. 전체 KV cache는 시스템 RAM에 존재합니다 (제 80GB RAM VM에서는 int4를 사용했지만, int8이면 128gb에 들어갈 것입니다). GPU는 이 스케치와 작은 '핫 세트(hot set)'만 유지합니다. 선택된 토큰만이 PCIe를 가로지릅니다. 이를 위해 필요한 것들은 다음과 같습니다: 스케치를 구축하고 모든 토큰을 점수화하며, 상위 약 2K개를 선택하여 표준 int8 어텐션 커널에 패킹하는 Triton kernels. CUDA-graph 안전성을 확보했습니다. 짧은 채팅이 최대 속도를 유지하도록 밀집(dense)/희소(sparse) 방식을 단계별로 전환하는 vLLM patches. 접두사 캐시와 순환 상태 체크포인트가 있는 KV cache를 위한 RAM 계층 구조(RAM tier). 따라서 후속 질문을 할 때 재계산을 하지 않습니다. 후속 질문은 선택된 행(rows)만 가져옵니다. 한 에이전트가 거대한 프롬프트를 읽는 동안 나머지 에이전트들이 멈추지 않도록 하는 스케줄러 수정(scheduler fix). 고정된 스케치 베이스(하나의 파일)와 이를 재조정하는 스크립트입니다. 이 모든 것은 포크(fork)가 아닌 패치 형태로 레포에 포함되어 있습니다. HyperQwen @ ce9615c (공개 vLLM fork) 위에 적용하고 설치 스크립트를 실행하면 됩니다. 테스트 및 모든 벤치마크 스크립트와 결과도 포함되어 있습니다. 모델: dbirks/Qwen3.8-27B-W4A16-AutoRound + HyperQwen의 prepare/fetch_fast_variant.py 입니다. 모든 수치는 gpu-unlock이 로드된 상태(3090 BF16 텐서 처리량을 대략 두 배로 늘리는 커널 모듈이며, 주로 더 빠른 프롬프트 읽기 속도를 제공함)에서 측정되었습니다.
측정 결과 (Qwen3.8-27B W4A16, MTP-7, 3090 Ti + 3090을 250W에서 사용): 8개 에이전트 × 250K 컨텍스트 길이: 설명 스타일 출력 시 총 약 545 토큰/초(tok/s), 복사 위주 작업 시 약 790 토큰/초. 176K205K에서 8개 에이전트가 6분 동안 중단 없이 생성한 결과: 박스 평균 657 토큰/초(tok/s), 에이전트당 6990 토큰/초. 250K에서의 재현율(Recall): 31/32. 후속 질문은 약 5초 만에 시작됨. 단일 장문 채팅도 더 빠름: 밀집(dense) 방식 대비 약 113K에서 +15~41%. 주의사항: 어텐션 메커니즘이 근사치(approximate)이므로, 거의 중복되는 코드 라인이 가끔 섞일 수 있음. 코드는 서빙 (패치 및 커널): https://github.com/bradj00/sparsekv-hyperqwen 시스템 구성(Rig): i9-12900K, Z790 마더보드, 96GB DDR5 RAM, 3090 Ti + 3090 (전력 제한 250W). 수정: — 많은 분들이 포괄적인 벤치마크를 요청하셔서 현재 작업 중입니다. 아이디어는 언제나 환영합니다! KLD 테스트는 eval/kld에 있으며, 추가된 드리프트(drift)가 동일한 모델을 다른 카드에서 실행할 때 본질적으로 얻게 되는 약 4%에 비해 무시할 만함을 시사합니다. 제출자: /u/o2beast [링크] [댓글]