평균에 가려진 토큰을 되찾는 법, RBS-Attention이 프리필을 푸는 방식

오늘 다루는 논문은 RBS-Attention: Radius-Bounded Sparse Prefill for Long-Context Large Language Models로, arXiv 2609.20971 번호로 공개된 연구입니다. 제목 아래에는 원문으로 이어지는 링크가 걸려 있으니, 수치의 출처가 궁금하신 분은 그곳에서 바로 확인하시면 됩니다. 이 논문이 내세우는 주장은 한 문장으로 정리할 수 있는데, 긴 컨텍스트의 프리필 단계에서 블록 평균값에 가려져 과소평가되는 블록을 반경이라는 기하 신호로 되찾으면, 학습 없이도 정확도를 거의 유지하면서 프리필을 크게 가속할 수 있다는 것입니다.

안녕하세요, 패트릭입니다.

저는 요즘 긴 문서를 모델에 넣을 때마다 첫 토큰이 나오기까지의 그 짧은 정적을 먼저 봅니다. 스트리밍이 시작되면 토큰이 술술 나오는데, 그 전의 몇 초는 유독 길게 느껴지니까요. 100페이지짜리 보고서를 올리고 요약을 부탁했을 때나 코드베이스 전체를 붙여 넣고 질문했을 때, 바로 그 기다림이 찾아옵니다. 그렇다면 그 정체의 정체는 무엇일까요. 오늘은 그 질문에서 출발하는 논문을 함께 읽어보겠습니다.

첫 토큰이 늦어지는 밤은 왜 길게 느껴질까

긴 컨텍스트 모델을 쓰다 보면 묘한 대비를 경험합니다. 생성이 시작된 뒤에는 속도가 나쁘지 않은데, 생성이 시작되기 전까지는 유독 오래 걸리니까요. 밤늦게 12만 토큰짜리 자료를 올리고 질문 하나를 던졌다고 상상해 보세요. 화면은 멈춰 있고 커서만 깜빡이는데, 그 몇 초가 체감으로는 몇십 초처럼 늘어집니다. 저는 이 논문에서 가장 흥미롭게 본 부분이 바로 그 기다림을 정면으로 다룬다는 점이었습니다.

이 기다림의 이름은 프리필입니다. 모델이 프롬프트 전체를 처음부터 끝까지 읽으면서 키와 밸류를 만들고 어텐션 행렬을 계산하는 단계인데, 한 토큰씩 이어가는 디코딩과 달리 전체 프롬프트를 한꺼번에 처리해야 합니다. 그래서 컨텍스트가 길어질수록 이 단계의 계산량이 이차에 가깝게 불어나는데, 논문이 진단하는 지점도 바로 여기입니다. 긴 컨텍스트 추론이 점점 프리필에 막히고 있다는 것이죠.

저희가 새로운 AI 아키텍처를 볼 때도 벤치마크 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 보니까요. 그런 눈으로 보면 프리필은 단순한 대기 시간이 아니라, GPU를 오래 붙잡아두는 구간이자 동시 요청이 몰리면 큐가 길어지는 구간이며, 결국 서비스의 첫인상을 결정하는 time-to-first-token으로 이어지는 구간입니다. 그렇다면 프리필의 어텐션을 통째로 계산하지 않고 건너뛸 수는 없을까요. 그 질문이 바로 희소 프리필 연구의 출발점입니다.

어텐션을 덜 계산하고 싶은 마음은 오래됐다

희소 어텐션이라는 발상 자체는 새롭지 않습니다. 모든 토큰이 모든 토큰을 봐야 한다는 전제를 깨고 정말 봐야 할 곳만 보자는 것인데, 말처럼 쉽지는 않습니다. 어떤 블록이 중요한지 알려면 결국 어텐션을 계산해야 하고, 어텐션을 계산하려면 다시 전체를 봐야 하는 모순에 빠지기 때문입니다. 그래서 많은 방법이 블록 단위의 근사를 쓰는데, 키 벡터들을 블록으로 묶고 각 블록을 대표하는 중심값 하나를 뽑은 뒤 쿼리와의 내적으로 블록 점수를 매기는 방식입니다.

이 방식은 얼핏 보면 합리적으로 보입니다. 블록 안에 비슷한 내용이 모여 있다면 평균값도 그 블록의 성격을 잘 보여줄 테니까요. 실제로 많은 경우에는 그렇게 동작해서, 문서의 어느 대목이 질문과 관련 있는지나 코드의 어느 함수가 호출 관계와 얽혀 있는지를 평균만 보고도 대충 가려낼 수 있습니다. 문제는 그다음입니다. 평균이 항상 정직하지는 않다는 것인데요. 저는 여기서 조금 멈칫했습니다. 평균이 거짓말을 하는 순간이, 길어진 컨텍스트에서는 생각보다 자주 오기 때문입니다.

그렇다면 평균이 실패하는 순간은 어떤 모습일까요. 다음 장면에서 논문이 정의한 실패 모드를 직접 들여다보겠습니다.

평균 하나가 중요한 토큰을 삼킬 때

논문은 이 실패에 mean dilution이라는 이름을 붙입니다. 우리말로 풀면 평균 희석 정도가 되겠는데요. 블록 안에 관련 없는 토큰이 잔뜩 섞여 있고 그사이에 정말 중요한 토큰이 하나만 들어 있는 상황을 떠올려 보세요. 블록 전체의 중심값을 구하면 그 하나의 뾰족한 신호가 주변의 무던한 값들에 묻혀 버리니까요. 그래서 블록 점수가 낮게 나오고, 결국 그 블록은 버려집니다.

생각해 보면 사람도 비슷한 실수를 합니다. 회의실에서 아홉 명이 고개를 끄덕이고 한 명만 작게 반대 의견을 말할 때, 전체 분위기만 보면 반대는 없었던 것처럼 느껴지니까요. 그런데 나중에 알고 보면 그 한마디가 프로젝트의 운명을 가른 경우가 있습니다. 블록 중심값도 마찬가지라서, 다수결로 평균을 내는 순간 소수의 날카로운 신호가 사라집니다. 그리고 긴 컨텍스트에서는 이런 블록이 곳곳에 숨어 있으니, 바늘 찾기 문제에서 바늘이 있는 건초더미를 평균 색깔만 보고 버리는 셈입니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. 평균이 나쁘다는 이야기가 아니라, 대부분의 경우에 빠르고 쓸만한 근사라는 것이기 때문입니다. 다만 평균만 믿으면 놓치는 종류의 오류가 분명히 있고, 그 오류가 긴 문서나 긴 코드, 긴 영상 문맥에서는 치명적일 수 있습니다. 그렇다면 평균을 버리지 않으면서도 그 blind spot을 메울 수는 없을까요. 논문의 답은 평균을 버리는 것이 아니라, 평균을 의심할 줄 아는 두 번째 눈을 다는 것이었습니다.

버리는 게 아니라 되찾는 방법이라고 봅니다

제가 이 논문에서 가장 흥미롭게 본 부분은 문제의 프레이밍입니다. 많은 희소 어텐션 연구가 어떻게 더 버릴지를 묻는다면, 이 논문은 어떻게 되찾을지를 묻기 때문입니다. 기본 예측은 평균에 맡기되, 평균이 과소평가했을 가능성이 큰 블록을 따로 구조하는 구조인데요. 저는 이 숫자보다 그 뒤의 태도가 더 중요하다고 봅니다. 희소를 절약이 아니라 복구에 가깝게 바라보기 때문입니다.

오해하기 쉬운 지점이 있어서 먼저 짚고 넘어가겠습니다. 이 방법은 모델 가중치를 다시 학습시키는 방법이 아니라, 학습 없이 추론 단계에만 얹는 프리필 가속 기법입니다. 그래서 기존 모델을 그대로 두고 쓸 수 있다는 장점이 있습니다. 또한 무작정 어텐션을 생략하는 방법도 아니라서, 두 개의 브랜치가 각자 점수를 매기고 각자 임계값을 넘은 블록만 살려서 마스크를 합치는 방식입니다. 버리고 보는 게 아니라, 살릴 근거가 있는 블록을 남기는 쪽에 가깝습니다.

그렇다면 두 번째 눈은 무엇을 볼까요. 답은 어텐션 점수 자체가 아니라 블록의 모양, 즉 블록 안에 벡터들이 얼마나 흩어져 있고 그 흩어짐이 어느 정도까지 벌어져 있는지를 재는 것입니다. 이 발상이 왜 먹히는지, 다음 장면에서 조금 더 천천히 풀어보겠습니다.

반경이라는 낯선 자를 데려온 이유

구조 브랜치가 보는 신호는 최대 키 블록 반경입니다. 말이 조금 어려운데, 직관은 단순합니다. 블록 중심에서 가장 멀리 떨어진 키 벡터까지의 거리를 재는 것인데요. 블록 안의 토큰들이 서로 비슷하면 반경이 작고, 누군가 튀는 토큰이 있으면 반경이 커집니다. 방금 본 평균 희석 상황에서는 바로 그 튀는 토큰이 중요한 토큰일 가능성이 있으니, 반경이 큰 블록일수록 평균 점수를 의심해야 한다는 이야기가 됩니다.

여기서 재미있는 질문이 생깁니다. 반경이 크면 무조건 위험한 걸까요. 그렇지는 않습니다. 어떤 레이어에서는 토큰 표현이 원래 넓게 퍼져 있고, 어떤 헤드에서는 좁게 모여 있으며, 프롬프트가 바뀌면 분포도 바뀌기 때문입니다. 그래서 논문은 고정된 임계값 하나로 모든 경우를 재단하지 않고, 프롬프트와 레이어와 헤드에 따라 달라지는 반경의 분포를 보고 그 맥락 안에서 유난히 큰 반경을 가진 블록을 고릅니다. 저는 이 대목을 읽고 고개를 끄덕였는데요. 절대값이 아니라 맥락 안에서의 상대값으로 위험을 판단한다는 점이, 실제 시스템에서 일하는 사람의 감각과 닮아 있기 때문입니다.

예를 들어 새벽에 로그를 볼 때를 생각해 보세요. 평소에도 노이즈가 많은 서비스에서는 에러 한 줄이 튀어도 곧 묻히지만, 평소 조용한 서비스에서는 같은 한 줄이 바로 눈에 들어옵니다. 반경을 해석하는 일도 비슷해서, 전체 분포가 어떤지를 먼저 보고 그 안에서 유난히 벌어진 블록을 의심합니다. 그래서 이 브랜치를 저는 일종의 의심 목록 생성기라고 이해했습니다. 평균이 낮게 평가했는데 반경이 유난히 크다면, 일단 살려서 다시 보자는 쪽으로 표시해 두는 것입니다.

두 개의 체를 겹치면 남는 것은 무엇일까

이제 두 브랜치가 어떻게 합쳐지는지 볼 차례입니다. 기본 브랜치는 평균 관련도를 보고, 구조 브랜치는 과소평가 위험을 보는데, 각 브랜치는 자기 나름의 임계값으로 블록을 고른 뒤 두 마스크를 합집합으로 합칩니다. 어느 한쪽에서 살리기로 한 블록은 어텐션 계산에 포함되는 것이죠. 합집합이라는 선택이 은근히 중요한데, 교집합이었다면 조건이 더 깐깐해져서 놓치는 블록이 늘어났을 테지만, 합집합은 놓침을 줄이는 쪽으로 기울어 있기 때문입니다.

문제는 그다음입니다. 구조 브랜치가 너무 많은 블록을 살리면 가속 효과가 사라지기 때문입니다. 그래서 구조 비용을 제어하는 장치가 필요한데, 논문은 두 브랜치를 독립적으로 임계값 처리한다고 설명합니다. 이 분리가 바로 비용 조절의 손잡이 역할을 해서, 평균 쪽 체의 눈금을 조이면 기본 선택이 달라지고 구조 쪽 체의 눈금을 조이면 추가로 되살리는 양이 달라집니다. 정확도와 속도 사이에서 원하는 지점을 고를 수 있는 다이얼이 두 개 생긴 셈입니다.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 이렇게 마스크를 합쳐도 실행은 여전히 규칙적으로 돌아갈까요. 희소 패턴이 들쭉날쭉하면 GPU가 좋아하지 않기 때문입니다. 이 질문에 대한 답이 다음 장면에 있습니다.

규칙적인 희소가 GPU를 설득하는 방식

논문이 강조하는 실행 측면의 미덕은 규칙적인 블록 희소 FlashAttention 실행을 그대로 유지한다는 점입니다. 합쳐진 마스크는 결국 블록 단위의 선택이고, 그 선택 위에 기존의 빠른 어텐션 커널이 올라갑니다. 토큰 단위로 송송 구멍을 뚫는 불규칙한 희소와 달리, 블록 단위로 도려내면 메모리 접근이 정돈되고 커널 효율이 살아나니까요. 저는 이 대목에서 논문의 태도가 꽤 실용적이라고 느꼈습니다. 수학적으로 예쁜 선택을 하고 나서 실행은 나중에 생각하는 게 아니라, 실행 가능한 모양 안에서 선택을 설계했기 때문입니다.

이 차이는 생각보다 중요합니다. 이론상 FLOPs가 줄어도 벽시계 시간이 줄지 않으면 서비스에서는 소용이 없기 때문입니다. 커널이 좋아하는 패턴으로 희소를 만들면 FLOPs 감소가 실제 시간 감소로 이어질 가능성이 커지는데, 특히 프리필처럼 행렬 곱이 지배적인 구간에서는 메모리 대역폭과 타일링이 병목을 좌우합니다. 블록 희소는 바로 그 지점과 잘 맞아서, 논문이 별도 커널의 마법이 아니라 기존 FlashAttention 흐름 위에서 이득을 본다는 점이 눈에 들어옵니다.

그렇다면 이제 남은 것은 증명입니다. 규칙적인 희소로 정확도를 지켰는지, 그리고 벽시계가 실제로 줄었는지 봐야겠죠.

88.65라는 숫자보다 그 뒤의 구조가 궁금했습니다

정확도 측면에서 논문이 전면에 내세운 숫자는 RULER 전체 점수입니다. 밀집 어텐션이 89.52를 받을 때, RBS-Attention은 같은 밀집 모델인 Qwen3-32B 위에서 88.65를 기록해서, 차이는 1점 안쪽에 머뭅니다. 긴 컨텍스트에서 블록을 솎아내면서 이 정도면 선방이라고 읽히는데요. 저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 평균만 쓰면 놓쳤을 블록을 구조 브랜치가 얼마나 메웠는지가 이 점수에 녹아 있기 때문입니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. 단일 벤치마크 점수 하나로 일반화하기는 어렵기 때문입니다. 논문은 RULER 외에도 LongBench-v2와 InfiniteBench, 그리고 영상 문맥을 보는 Video-MME로 평가를 넓혔다고 밝히고 있습니다. 괄호 안의 사족 하나를 덧붙이자면, 텍스트만 보는 평가와 영상을 보는 평가를 함께 가져간 구성이 개인적으로는 마음에 들었습니다. 긴 컨텍스트라는 말이 텍스트에만 갇히지 않는다는 신호니까요. 다양한 길이와 과제에서 무너지지 않는지가 희소 프리필의 진짜 시험대인데, 평가 축을 여러 개 깔아둔 것은 그 시험을 피하지 않겠다는 뜻으로 읽힙니다.

물론 아쉬운 지점도 있습니다. 공개된 자료만으로는 과제별 세부 점수의 굴곡까지는 다 들여다보기 어렵기 때문입니다. 어떤 길이에서 먼저 흔들리는지, 어떤 과제 유형에서 구조 브랜치가 가장 바쁘게 일하는지는 원문을 더 파고들어야 보이는 이야기입니다. 그럼에도 전체 점수가 밀집에 바짝 붙어 있다는 사실은, 반경이라는 신호가 헛다리를 짚은 게 아니라는 정도의 확신은 줍니다. 평균의 blind spot을 메우는 방향이 틀리지 않았다는 것이죠.

128K에서 체감되는 시간의 차이

속도 이야기로 넘어오면 숫자가 훨씬 선명해집니다. H100 GPU에서 128K 컨텍스트, Qwen3-30B-A3B-Instruct-2507-FP8 모델 위에서 잰 결과인데요. 독립 실행 환경의 프리필 어텐션 가속이 20.65배, vLLM 위에서의 프리필 어텐션 가속이 11.92배, 그리고 종단간 첫 토큰까지 시간 단축이 5.97배로 보고됐습니다. 같은 모델에 같은 질문을 던졌는데 기다림의 길이가 이렇게 달라진다는 것은, 운영 관점에서 꽤 크게 다가옵니다.

이 세 숫자를 겹쳐 읽으면 이야기가 더 또렷해집니다. 어텐션 커널만의 가속이 가장 크고, 서빙 스택 위에 올리면 그 이득이 조금 옅어지며, 토큰 생성까지 포함한 종단간 시간에서는 다시 현실적인 값으로 수렴하기 때문입니다. 당연한 흐름인데, 실제 서비스에서는 어텐션 말고도 통신과 스케줄링과 메모리 움직임이 함께 시간을 먹기 때문입니다. 그럼에도 첫 토큰까지 시간이 6배 가까이 줄었다는 것은, 프리필이 병목이던 워크로드에서는 체감이 확 바뀐다는 뜻입니다. 밤사이 쌓인 긴 문서를 아침에 요약하는 배치 작업이라면 처리량이 달라지고, 사용자가 붙잡고 기다리는 대화형 서비스라면 이탈률이 달라지니까요.

다만 이 숫자는 그대로 믿기 전에 조건을 봐야 합니다. 하드웨어가 H100이고 길이가 128K이며 모델이 특정 Qwen3 변형일 때의 측정이기 때문입니다. 길이가 짧아지면 희소의 이득도 줄어들 테고, 하드웨어가 바뀌면 커널 효율도 달라질 수 있습니다. 저는 그래서 이 결과를 만능 가속 선언이 아니라 조건부 성취로 읽습니다. 프리필이 지배적인 구간, 그러니까 컨텍스트가 길고 어텐션이 무거운 구간에서 이 방법은 제값을 합니다. 짧은 프롬프트에서는 굳이 꺼낼 필요가 없는 카드일 수 있으니까요.

그래서 엔지니어는 무엇을 가져가면 될까

그렇다면 이 논문을 읽은 엔지니어는 무엇을 손에 쥐고 돌아가면 될까요. 저는 세 가지를 꼽고 싶습니다. 먼저 학습 없이 얹을 수 있다는 점인데, 모델을 다시 학습시키거나 가중치를 손댈 필요가 없으니 기존 서빙 스택에 실험적으로 붙여보기가 상대적으로 가볍습니다. 다음으로 비용 조절 다이얼이 두 개라는 점인데, 평균 쪽 임계값과 구조 쪽 임계값을 따로 만지면서 정확도와 속도의 교환 관계를 매끄럽게 탐색할 수 있습니다. 마지막으로 실행 모양이 단정하다는 점인데, 블록 희소 위에 FlashAttention 흐름을 그대로 쓰니 커널을 처음부터 새로 짜야 하는 부담이 적습니다.

반대로 오해하면 안 되는 것도 있습니다. 반경이 어텐션의 내용을 대신 알려주는 것은 아니기 때문입니다. 반경은 어디를 의심해야 할지를 알려주는 신호이지, 그 블록이 정말 중요한지를 확정하는 증거는 아닙니다. 최종 판단은 합쳐진 마스크 위에서 실제 어텐션을 계산하면서 내려집니다. 또한 구조 브랜치가 모든 과소평가를 잡아낸다는 보장도 없는데, 평균 희석이라는 특정 실패 모드를 겨냥한 장치이지 희소화의 모든 손실을 메우는 만병통치약은 아니기 때문입니다.

좋은데, 이걸 어디에 올릴까요. 저는 프리필이 긴 대화형 검색이나 문서 질의응답, 긴 코드 컨텍스트를 먹는 에이전트에 먼저 어울린다고 봅니다. 첫 토큰이 느려서 사용자가 떠나는 지점, 혹은 배치 처리에서 GPU가 하염없이 프롬프트를 읽는 지점이 바로 이 방법이 빛나는 자리이기 때문입니다. 반대로 프롬프트가 짧고 생성이 긴 워크로드라면 이득이 옅을 수 있습니다. 도구는 쓸 자리를 가려야 제맛이니까요.

다음에 보고 싶은 장면들

제가 앞으로 보고 싶은 것은 반경 분포의 얼굴들입니다. 어떤 레이어에서 반경이 넓게 퍼지고, 어떤 헤드에서 유난히 뾰족한 블록이 나오는지, 그리고 프롬프트의 종류에 따라 그 모양이 어떻게 달라지는지를 보고 싶기 때문입니다. 분포를 본다는 아이디어가 들어간 이상, 그 분포 자체가 모델의 버릇을 보여주는 거울이 될 수 있습니다. 어쩌면 긴 문서와 긴 코드와 긴 영상에서 반경의 성격이 서로 다르게 나타날지도 모르니까요.

또 하나 궁금한 것은 임계값의 운영법입니다. 두 개의 다이얼을 돌릴 때 정확도가 어느 지점에서 급하게 꺾이는지, 그 꺾이는 지점이 모델이나 길이에 따라 얼마나 안정적인지가 궁금하기 때문입니다. 실험실에서는 최적점을 찾아내도, 운영에서는 트래픽이 바뀌고 문서 길이가 들쭉날쭉합니다. 다이얼을 자동으로 따라가게 만드는 가벼운 컨트롤러가 붙는다면 이야기가 더 재밌어질 것 같습니다. 정확도를 지키면서 구조 비용을 아끼는 적응형 임계값 같은 방향입니다.

그리고 마지막으로, 평균 희석이라는 렌즈를 다른 희소 방법에도 비춰보고 싶습니다. 토큰을 버리는 많은 방법이 어딘가에서는 평균의 유혹에 기대고 있을 테니까요. 반경처럼 값의 내용이 아니라 값들의 흩어짐을 보는 신호가, 다른 압축이나 캐시 관리 문제에서도 통할지 궁금합니다. 이 논문이 남긴 가장 좋은 유산은 어쩌면 20배라는 숫자보다, 평균을 의심하는 법을 하나 알려준 것인지도 모르겠습니다.

긴 글을 닫기 전에 처음으로 돌아가 보겠습니다. 첫 토큰 전의 정적은 사라지지 않겠지만, 그 길이는 엔지니어링으로 다룰 수 있는 문제였습니다. 평균에 기대어 빠르게 가되, 평균이 놓칠 만한 곳은 모양을 보고 되찾는 것, 그 절충이 바로 이 논문이 제안한 리듬입니다. 다음에 100페이지짜리 보고서를 올리고 커서가 깜빡일 때, 그 뒤에서 어떤 블록이 살고 어떤 블록이 조용히 되살아나는지 한 번 떠올려 보셔도 좋겠습니다. 그렇다면 기다림이 조금은 덜 답답해지지 않을까요.