요즘 모델 소개에서 1M context라는 숫자가 자주 등장합니다.
문서 수백 개, 전체 코드베이스, 긴 대화를 한 번에 넣을 수 있다는 의미는 매력적입니다.
하지만 중요한 질문이 하나 빠져 있습니다.
모델이 100만 토큰을 받을 수 있다는 것과, 100만 토큰을 싸고 빠르게 처리할 수 있다는 것은 같은가?
아닙니다.
그래서 Qwen4 계열에서 다시 Sparse Attention이 중요한 키워드로 등장하고 있습니다.
Full Attention은 무엇이 비쌀까?
아주 단순한 self-attention을 생각해봅시다.
각 token이 다른 token과 관계를 계산한다면 sequence length가 n일 때 attention score의 규모는 대략 n × n 방향으로 커집니다.
1K tokens
→ 약 1M 관계
10K tokens
→ 약 100M 관계
100K tokens
→ 약 10B 관계
실제 구현에서는 FlashAttention, KV Cache, GQA 같은 여러 최적화가 있기 때문에 이 숫자가 그대로 비용이 되는 것은 아닙니다.
하지만 핵심 문제는 남습니다.
문맥이 길어질수록 모든 위치를 똑같이 자세히 보는 방식은 점점 부담이 커집니다.
Sparse Attention의 생각은 단순합니다
대부분의 질문에서 모든 과거 token이 같은 중요도를 갖지는 않습니다.
예를 들어 500페이지짜리 코드 문서를 읽고:
payment_service.py에서 retry가 두 번 실행되는 원인을 찾아줘.
라고 물었다면 실제로 중요한 부분은 전체 문맥 중 일부일 가능성이 높습니다.
Sparse Attention은 대략 이런 질문을 합니다.
전체 context를 모두 정밀하게 볼 필요가 있을까?
↓
먼저 중요한 위치를 찾고
↓
그 부분에 더 많은 Attention을 쓰면 어떨까?
Qwen Sparse Attention은 token이 아니라 block을 먼저 봅니다
Qwen3.8-Flash-Next에 들어간 Qwen Sparse Attention(QSA)은 긴 sequence를 micro-block으로 압축합니다.
가벼운 indexer가 block 수준에서 중요도를 추정한 뒤, 관련성이 높은 영역을 선택합니다.
긴 sequence
↓
[block][block][block][block][block]...
↓
lightweight indexer
↓
중요 block 선택
↓
선택된 구간에 Attention
기존 sparse 방식에서 "어떤 token을 선택할지 찾는 비용" 자체가 커질 수 있는데, QSA는 이 indexing도 block 단위로 줄이려는 접근입니다.
Qwen은 Gated DeltaNet과 QSA를 함께 사용합니다.
공식 설명을 이해하기 쉽게 줄이면:
GDN
→ 전체 과거를 압축된 상태로 계속 기억
QSA
→ 정확히 다시 봐야 할 구간을 검색
에 가깝습니다.
Vendor benchmark에서는 얼마나 차이가 났을까?
Qwen이 공개한 실험에서는 1M-token 조건에서 QSA Attention Kernel이 기존 비교 대상으로부터 prefill 최대 7.6배, decode 최대 4.9배의 speedup을 보였다고 설명합니다.
또 90% prefix-cache hit를 가정한 serving 실험에서는 Qwen3.8-Flash-Next가 Qwen3.7-Plus보다 1M context prefill throughput이 8.6배 높았다고 보고합니다.
다만 이 숫자는 Qwen이 설정한 특정 benchmark와 serving 조건에서 나온 vendor result입니다.
따라서:
Sparse Attention이면 항상 8.6배 빨라진다
라고 일반화하면 안 됩니다.
실제 속도는 hardware, batch, cache hit, prompt 길이, framework에 따라 크게 달라집니다.
CodeBridge Mini Lab: Full과 Sparse의 규모 차이를 숫자로 느껴보기
아래는 실제 QSA 구현이 아닙니다.
Sparse Attention의 아이디어를 이해하기 위한 toy calculation입니다.
Full Attention은 모든 token pair를 본다고 가정하고, sparse 방식은 token마다 최대 2,048개의 관련 위치만 본다고 가정해봅니다.
lengths = [8_192, 32_768, 131_072, 1_000_000]
budget = 2_048
for n in lengths:
full = n * n
sparse = n * min(n, budget)
ratio = full / sparse
print(
f"{n:>10,} tokens | "
f"full={full:>15,} | "
f"sparse={sparse:>15,} | "
f"ratio={ratio:>8.1f}x"
)
이 코드는 실제 latency를 예측하지 않습니다.
대신 길이가 커질수록 모든 pair를 보는 것과 제한된 후보만 보는 것의 규모 차이가 얼마나 빠르게 벌어지는지 보여줍니다.
Sparse Attention에도 대가가 있습니다
중요한 token을 일부만 본다는 것은 잘못 고르면 정보를 놓칠 수도 있다는 뜻입니다.
그래서 sparse architecture에는 새로운 문제가 생깁니다.
무엇이 중요한가?
어떻게 빠르게 찾을까?
중요한 위치를 놓치면 어떻게 할까?
레이어마다 선택 기준을 공유할까?
QSA가 별도의 lightweight indexer를 두는 이유도 여기 있습니다.
즉 Sparse Attention의 어려움은 "적게 본다"가 아니라 정확히 골라서 적게 본다입니다.
1M Context가 있어도 RAG가 사라지지 않는 이유와 연결됩니다
Long-context 모델과 RAG는 종종 경쟁 관계처럼 보입니다.
1M context가 있으니
문서를 전부 넣으면 되지 않을까?
하지만 context window가 커져도 다음 문제는 남습니다.
- 입력 token 비용
- prefill latency
- 중요 정보 검색 정확도
- 문서 업데이트
- 접근 권한
- 출처 추적
Sparse Attention은 모델 내부에서 긴 context 비용을 줄이는 기술입니다.
RAG는 모델에 무엇을 넣을지 외부에서 선택하는 시스템 설계입니다.
문제를 해결하는 층이 다릅니다.
그래서 둘은 대체 관계보다 함께 사용될 가능성이 높습니다.
결론: 긴 Context 경쟁은 '얼마나 많이 넣나'에서 '얼마나 싸게 찾나'로 이동하고 있습니다
Context window 숫자는 계속 커지고 있습니다.
하지만 백만 토큰을 지원한다고 해서 항상 백만 토큰을 넣는 것이 좋은 설계는 아닙니다.
앞으로 더 중요한 질문은 다음입니다.
긴 문맥 속에서 필요한 정보를 얼마나 적은 계산으로 정확하게 다시 찾을 수 있는가?
QSA 같은 Sparse Attention이 흥미로운 이유가 바로 여기에 있습니다.