Gemma 4는 최대 256K 토큰의 컨텍스트 윈도우 (context window)를 탑재하여 출시되었습니다. 모델이 놀라운 컨텍스트 수치를 내세우며 등장할 때마다 항상 똑같은 일이 반복됩니다. 사람들은 프롬프트에 전체 코퍼스 (corpus)를 통째로 붙여넣고, 지연 시간 (latency)과 메모리가 폭발하는 것을 지켜보며, 평범한 답변을 얻은 뒤, 긴 컨텍스트는 "작동하지 않는다"라고 결론을 내립니다.

윈도우는 목표치가 아니라 한계치 (ceiling)입니다. 그 기계적인 이유와 제가 대신 사용하는 방법은 다음과 같습니다.

비용이 발생하는 지점: 어텐션 (attention) vs KV 캐시 (KV cache)

시퀀스 길이 (sequence length)에 따라 두 가지 서로 다른 비용이 확장되며, 사람들은 이를 끊임없이 혼동합니다.

**어텐션 연산 (Attention compute)**은 모두가 인용하는 $O(n^2)$의 비용입니다. 길이가 $n$인 시퀀스의 경우, 전체 셀프 어텐션 (full self-attention)은 모든 토큰을 다른 모든 토큰과 비교합니다. 입력이 두 배가 되면 어텐션 작업은 네 배가 됩니다. 이것이 모델이 프롬프트를 흡수하는 단계인 프리필 (prefill) 단계에서 지배적인 역할을 합니다.

**KV 캐시 메모리 (KV cache memory)**는 $O(n)$이며, 실제 운영 환경에서 당신을 힘들게 하는 것은 바로 이것입니다. 처리하는 모든 토큰은 생성(generation)이 끝날 때까지 상주해야 하는 키 (key) 및 값 (value) 텐서를 남깁니다. 대략적인 형태는 다음과 같습니다:

kv_bytes ≈ 2 (K and V)
         × n_layers
         × n_kv_heads × head_dim
...

여기에 포함되지 않은 것에 주목하십시오: 전체 값을 곱하게 되는 배치 크기 (batch size)입니다. 200K 토큰을 사용하는 8개의 동시 요청이 있다면, 해당 할당량이 8개 동시에 존재해야 함을 의미합니다. 이것이 8K에서는 잘 작동하던 모델이 사용자가 3명만 되어도 128K에서 무너지는 이유입니다. 가중치 (weights) 메모리가 부족해진 것이 아니라, 캐시 (cache)가 부족해진 것입니다.

Gemma 4의 아키텍처는 이에 대한 직접적인 대응책입니다. 워크스테이션급 모델들은 로컬 슬라이딩 윈도우 어텐션 (local sliding-window attention)과 주기적인 풀-글로벌 어텐션 (full-global attention) 레이어를 교차하여 배치하며, 마지막 레이어는 항상 글로벌 (global)입니다. 이 결과는 반드시 숙지할 가치가 있습니다: 오직 글로벌 레이어만이 전체 $O(n^2)$ 비용을 지불하고 전체 길이의 KV 캐시를 보유합니다. 슬라이딩 윈도우 레이어는 제한된 윈도우 내에서 어텐션을 수행하므로, 입력이 아무리 길더라도 해당 캐시는 윈도우 크기로 제한됩니다.

따라서 비용 곡선은 단순하지 않습니다. 만약 $k$개 레이어마다 하나가 글로벌 레이어라면, 레이어당 캐시 길이는 다음과 같습니다:

def kv_len_per_layer(layer_idx, seq_len, window, global_every):
    if (layer_idx + 1) % global_every == 0:
        return seq_len              # 제한 없음, 입력과 함께 증가
...

이것은 진정으로 훌륭한 엔지니어링이며, 256K가 실질적으로 가능하게 만드는 이유입니다. 이것이 256K를 사용해도 된다는 면허증은 아닙니다.

OOM(Out of Memory)이 발생하기 전에 긴 컨텍스트의 성능이 저하되는 이유

메모리 문제가 해결되더라도, 윈도우(window)를 채울수록 품질이 일정하게 유지되지는 않습니다. 잘 알려진 두 가지 효과가 있습니다.

위치적 저하 (Positional degradation). 검색 정확도는 윈도우 전체에 걸쳐 균일하지 않습니다. 긴 프롬프트의 맨 처음과 맨 끝에 있는 정보는 안정적으로 회복되지만, 중간에 묻혀 있는 내용은 눈에 띄게 회복 성능이 떨어집니다. 이는 사실상 모든 긴 컨텍스트 모델 제품군에서 관찰되는 "중간에서 길을 잃는 (lost in the middle)" 현상입니다. 이는 특정 모델의 버그가 아니라 어텐션 (attention)이 질량을 분배하는 방식의 특성입니다.

방해 요소 희석 (Distractor dilution). 정답 구절과 함께 무관하지만 그럴듯한 텍스트를 추가하면 답변의 품질이 측정 가능한 수준으로 저하됩니다. 만약 실제 증거가 2K 토큰인데 이를 의미론적으로 인접한 노이즈로 180K까지 채운다면, 모델에게 틀릴 수 있는 지점을 더 많이 제공하는 셈이 됩니다.

그다음은 지연 시간 (latency)입니다. 매우 긴 프롬프트에 대한 프리필 (prefill)은 첫 번째 토큰이 나타나기 전 완전히 완료되어야 하는 커다란 일회성 연산 비용이며, 사용자는 이를 앱이 멈춘 것으로 경험하게 됩니다. 프리필 이후의 디코드 (decode) 속도는 거의 영향을 받지 않는데, 이를 직접 경험해보지 않았다면 매우 혼란스러운 프로필일 것입니다. 일단 시작되면 빠르다고 느껴지지만, 시작하는 데 영겁의 시간이 걸립니다.

내가 실제로 하는 일

먼저 검색하고, 큰 윈도우를 여유분(slack)으로 사용합니다. 256K의 목적은 검색을 건너뛰는 것이 아닙니다. 검색기가 더 이상 정밀할 필요가 없다는 뜻입니다. 4K 예산 하에서는 상위 3개의 청크 (chunks)가 필요했고 정밀도가 매우 중요했습니다. 이제는 상위 40개를 가져올 수 있고, 잘려 나간 512토큰 조각 대신 주변 섹션 전체를 포함할 수 있으며, 정교한 리랭커 (re-ranker)를 구축하는 일을 멈출 수 있습니다. 긴 컨텍스트는 검색 정밀도에 있어 여유를 사는 것이지, 검색을 생략할 권한을 주는 것이 아닙니다.

글자 수가 아니라 구조를 기준으로 청킹(Chunking)하세요. 고정 크기 청킹(Fixed-size chunking)은 논증의 중간이나 표의 중간에서 내용을 끊어버립니다. 헤딩(Heading), 섹션(Section), 그리고 함수의 경계(Function boundaries)를 기준으로 나누고, 각 청크에 헤딩 경로(Heading path)를 포함시켜 검색된 파편이 어디에서 왔는지 알 수 있게 하세요.

지시사항(Instructions)은 마지막에 배치하세요. 위치에 따른 성능 저하(Positional degradation)를 고려할 때, 제가 지속적으로 효과를 보았던 레이아웃은 다음과 같습니다:

[system / role]
[long retrieved context]      <- 중간에 위치하는 대량의 데이터
[the actual question]
...

100K 토큰 프롬프트의 상단에 있는 지시사항은 100K 토큰의 최신성(Recency)과 경쟁하게 됩니다. 모델이 바라보고 있는 곳에 지시사항을 두세요.

안정적인 접두사(Prefix)를 캐싱(Cache)하세요. 만약 많은 요청이 스키마(Schema), 정책 문서, 코드베이스 인덱스(Codebase index)와 같이 크고 고정된 서문을 공유한다면, 해당 블록이 바이트 단위로 동일한 접두사(Byte-identical prefix)가 되도록 프롬프트 순서를 조정하여 KV 캐시(KV cache)를 재사용하세요. 이는 모델을 교체하는 것보다 지연 시간(Latency) 측면에서 더 큰 이득을 주는 경우가 많습니다. 또한 이는 다음을 의미합니다: 프롬프트 상단에 타임스탬프나 요청 ID(Request ID)를 절대 두지 마세요. 0번 위치에 있는 단 하나의 가변적인 토큰이 접두사 전체를 무효화합니다.

예산을 명시적으로 설정하고 실제 길이에 맞춰 측정하세요.

BUDGET = 32_000   # 256_000이 아님

def build_prompt(question, chunks, budget=BUDGET):
...

그 다음, 실제로 서비스하는 길이에 맞춰 평가하세요. 4K에서의 벤치마크(Benchmark)는 120K에서의 동작에 대해 아무것도 알려주지 않으며, 건더기 찾기(Needle-in-a-haystack) 점수는 흩어진 증거를 가로지르는 다단계 추론(Multi-hop reasoning)에 대해 아무것도 알려주지 않습니다. 크기별 아키텍처 사양에 대해 자신의 하드웨어에서 직접 계산이 필요한 경우, Gemma 4 model hub에서 제품군별 상세 정보를 한곳에서 확인할 수 있습니다.

저의 작업 기본값은 다음과 같습니다: 8~32K에서 시작하고, 평가(Evals)를 통해 추가적인 컨텍스트가 지연 시간을 감수할 만큼의 가치가 있다고 증명될 때만 상한선을 높입니다. 컨텍스트 윈도우(Window)의 절반 이상을 채우는 프롬프트는 설계 결함(Design smell)으로 간주하세요. 이는 대개 검색(Retrieval)이 제 역할을 하지 못하고 있으며, 당신이 직접 수행했어야 할 필터링 작업을 모델에게 비용을 지불하며 시키고 있다는 것을 의미합니다.