Gemini 3.1 Ultra의 초장문 컨텍스트와 네이티브 멀티모달 아키텍처
Gemini 3.1 Ultra의 2M 토큰 컨텍스트 서빙, 통합 멀티모달 추론, 병렬 도구 호출 구조와 플래그십 모델 경쟁 구도를 분석한다.
2026-08-14 · 최초 발행 2026-06-10
2M 토큰을 서빙하려면 메모리 구조부터 달라져야 한다
Google I/O 2026에서 공개된 Gemini 3.1 Ultra의 핵심은 2M 토큰 네이티브 컨텍스트 윈도우다. 텍스트·이미지·오디오·비디오를 하나의 추론 경로에서 다루는 통합 멀티모달 아키텍처도 함께 제시됐다. GPT-5.5 Instant가 512K, Claude Opus 4.7이 1M 토큰 컨텍스트를 제공하는 구도에서 가장 긴 컨텍스트를 확보해 장문 코드베이스 분석, 멀티 문서 연구, 대규모 과학 데이터 처리에 초점을 맞춘다.
문제는 입력 길이를 늘리는 것만으로 해결되지 않는다. Transformer의 KV(Key-Value) 캐시는 각 레이어와 어텐션 헤드에 대해 토큰 수 × 헤드 차원 크기의 float16 텐서를 유지한다. 2M 토큰 × 128 레이어 × 64 헤드 × 128 차원 × 2바이트(float16)를 단순 계산하면 수십 TB 규모다. Multi-Query Attention(MQA)이나 Grouped-Query Attention(GQA)으로 KV 헤드 수를 크게 줄여도 단일 GPU HBM에 모두 담을 수는 없다.
Gemini 3.1 Ultra는 캐시를 메모리 특성에 따라 나눈다. 현재 디코딩 스텝과 직전 수십만 토큰에 해당하는 핫 캐시는 HBM(High Bandwidth Memory)에 둔다. 중간 범위의 캐시는 DRAM에 배치하고 INT8 양자화를 적용해 메모리 풋프린트를 절반으로 줄인다. 접근 빈도가 낮은 장기 컨텍스트 캐시는 NVMe SSD 또는 원거리 고대역폭 스토리지에 저장한 뒤 필요할 때 비동기로 프리페치한다. 물리적으로 제한된 HBM 위에 논리적인 대규모 KV 캐시를 구성하는 방식이다.
긴 프리필(prefill)은 입력을 청크로 나눠 여러 TPU/GPU 노드에서 병렬 인코딩한다. 각 노드가 만든 KV 캐시는 ICI, Infiniband급 고속 인터커넥트로 집약된다. 프리필 전용 노드와 디코딩 전용 노드를 분리하는 Disaggregated Prefill-Decode 구조도 적용해, 장문 입력을 처리하는 동안 디코딩 자원이 비효율적으로 묶이는 문제를 줄인다.
청크와 압축 어텐션으로 전역 관계를 보존한다
2M 토큰 전체에 일반 어텐션을 적용하면 시간 복잡도는 O(n²)으로 증가하고 수백 테라플롭스의 연산량이 필요하다. Gemini 3.1 Ultra는 로컬 범위를 담당하는 슬라이딩 윈도우 청크 어텐션과 전체 문맥을 연결하는 글로벌 압축 어텐션을 계층적으로 결합한다.
입력은 서로 일부가 겹치는 청크(overlapping chunk)로 분할된다. 각 청크 안에서는 로컬 슬라이딩 윈도우 어텐션을 수행하고, 인접 청크와 일정 비율의 영역을 공유해 경계 손실(boundary loss)을 막는다. 청크 크기는 HBM 용량과 처리 레이턴시 사이에서 결정되며, 일반적으로 32K~128K 토큰 범위가 실용적이다.
긴 입력 전체의 의미 관계는 압축 어텐션(Compressed Attention)이 맡는다. 각 청크의 인코딩 결과를 요약 토큰(summary token) 집합으로 줄인 뒤, 이 토큰들 사이에서 글로벌 어텐션을 수행한다. 요약 토큰을 만드는 방법으로는 의미 밀도가 높은 토큰을 중요도 점수(token importance scoring)에 따라 선별하는 방식과 선형 어텐션 기반 풀링으로 집약하는 방식이 쓰인다.
Ring Attention 변형은 여러 디바이스에 걸친 계산과 통신을 겹쳐 실행한다. 각 디바이스가 자신이 보유한 KV 캐시 샤드에 어텐션을 수행하는 동안 인접 디바이스의 샤드를 링 토폴로지로 전달한다. 호스트 간 통신을 별도 단계로 두지 않고 연산 파이프라인 안에 중첩하는 구조다.
긴 프리필의 TTFT와 비용을 다루는 방식
초장문 컨텍스트에서는 첫 번째 토큰까지의 시간인 TTFT(Time-To-First-Token)와 토큰 생성 처리량인 TPS(Tokens-Per-Second)가 사용자 경험을 좌우한다. 프리필 시간이 길어지면 TTFT가 수십 초 수준까지 늘어날 수 있어 인터랙티브 작업에는 치명적이다.
Gemini 3.1 Ultra는 입력 길이에 맞춰 프리필 노드 수를 동적으로 확장하고, 병렬 스케일아웃으로 프리필 시간을 거의 일정하게 유지한다. 동일한 컨텍스트 접두어가 반복되는 요청에는 Prefix Caching을 사용한다. 시스템 프롬프트나 장문 문서, 코드베이스처럼 재사용되는 접두어를 다시 인코딩하지 않아 90% 이상의 TTFT 절감 효과를 제공한다. Streaming Prefill은 모든 청크의 프리필이 끝날 때까지 기다리지 않고, 처리가 끝난 청크부터 디코딩을 시작해 인지적 TTFT를 줄인다.
과금 구조도 컨텍스트 길이와 사용 형태를 구분한다. 처음 128K 토큰 이하에는 일반 플래그십 요금이 적용된다. 128K~1M 구간에는 할인율을 반영한 롱컨텍스트 요금이, 1M 초과 구간에는 배치 처리 할인이 포함된 별도 요금 티어가 설정된다. 짧은 요청이 롱컨텍스트 비용을 부담하지 않게 하면서 2M 토큰 전체를 사용하는 작업의 단위 토큰 비용도 조정하는 설계다.
모든 입력을 하나의 멀티모달 시퀀스로 만든다
Gemini 3.1 Ultra는 모달리티마다 독립 인코더를 거친 결과를 마지막에 결합하는 Late Fusion 대신, 토크나이저 단계에서 입력을 하나의 토큰 시퀀스로 구성하는 Early Fusion 방식을 채택한다. 텍스트와 시각·음성 정보의 관계가 일부 융합 레이어에 한정되지 않고 어텐션 레이어 전반에서 형성된다.
텍스트는 서브워드 토크나이저로 변환된다. 이미지는 ViT(Vision Transformer) 기반 패치 임베딩을 거쳐 256~1024개의 시각 토큰으로 압축된다. 오디오는 Mel-spectrogram 특징을 오디오 인코더에 전달해 언어 모델과 호환되는 연속 임베딩으로 바꾼다. 비디오는 시간 차원이 포함된 3D 패치 인코딩을 사용하며 프레임 수와 해상도에 따라 토큰 수가 달라진다. 이렇게 만들어진 토큰은 모두 하나의 컨텍스트 시퀀스로 연결돼 Transformer 백본으로 들어간다.
2M 토큰 윈도우는 긴 텍스트에만 쓰이지 않는다. 30분 분량의 고해상도 비디오는 약 600K800K 시각 토큰을 차지하고, 대화 오디오 한 시간은 약 200K400K 오디오 토큰을 만든다. 장시간 영상과 음성을 문서 컨텍스트와 함께 분석하려면 멀티모달 입력 자체가 상당한 토큰 예산을 요구한다.
시공간 정렬과 병렬 도구 호출
크로스모달 어텐션(Cross-Modal Attention)은 서로 다른 입력 사이의 의미 연결을 만든다. 비디오 속 오브젝트를 설명하는 텍스트와 해당 시각 토큰에 강한 어텐션 가중치가 형성되면, 특정 장면의 인물과 발언을 함께 분석하는 질의에서 영상·음성·텍스트 정보를 결합할 수 있다.
이 연결은 모달리티 인식 포지셔널 인코딩(Modality-Aware Positional Encoding)으로 보강된다. 텍스트 토큰에는 시퀀스 위치, 이미지 패치에는 2D 공간 좌표가 들어간다. 비디오 토큰은 프레임 인덱스와 2D 공간 좌표를 결합한 3D 위치 정보를 사용하고, 오디오 토큰에는 타임스탬프가 인코딩된다. 각 입력의 위치 체계가 유지되므로 모달리티 사이의 시공간 정렬이 가능하다.
에이전트 워크플로우에서는 독립적인 도구 호출을 한 응답에서 동시에 발행할 수 있다. Gemini 3.1 Ultra는 최대 32개의 동시 함수 호출을 지원한다. 지난 30일간의 웹 검색 결과와 내부 데이터베이스 조회 결과를 합쳐 시장 분석 보고서를 만드는 작업이라면 두 조회를 순서대로 실행하지 않고 병렬 처리해 전체 에이전트 루프 시간을 줄일 수 있다.
과학 데이터 분석에는 Code Execution Sandbox가 결합된다. 모델이 Python 코드를 만들고 샌드박스에서 실행한 다음, 수치와 시각화 이미지, 오류 트레이스를 다시 컨텍스트로 받아 후속 추론에 반영한다. 생성과 실행, 결과 해석을 하나의 추론 세션에서 반복하는 구조다.
함수 명세와 구조화 출력이 처리되는 경로
도구 명세는 JSON Schema 형식으로 정의되고 어텐션 컨텍스트에 직접 포함된다. 함수 시그니처와 파라미터 타입, 설명 텍스트가 토큰으로 인코딩되기 때문에 모델은 이를 일반 자연어 컨텍스트와 같은 어텐션 메커니즘으로 처리한다.
구조화 출력(Structured Output)은 JSON 스키마 강제 디코딩(Constrained Decoding)으로 보장한다. Greedy 또는 Sampling 디코딩과 달리, 현재 생성 상태에서 스키마를 위반하는 토큰은 어휘 마스킹(vocabulary masking)을 거친다. 해당 토큰의 로짓(logit)을 음의 무한대로 설정해 스키마에 맞는 JSON을 100% 확률로 생성하고 파싱 실패에 따른 재시도를 없앤다.
도구가 수백수천 개로 늘어나면 모든 명세를 컨텍스트에 넣는 방식은 토큰을 지나치게 많이 쓴다. Tool Retrieval은 현재 쿼리와 의미적으로 관련된 상위 N개 도구만 골라 주입한다. 도구 임베딩을 벡터 데이터베이스에 미리 인덱싱하고 쿼리 임베딩과 코사인 유사도를 비교해, 수천 개 가운데 상위 2050개만 컨텍스트에 포함한다.
플래그십 모델 사이에서 생기는 선택 기준
2026년 플래그십 LLM의 컨텍스트 윈도우는 Gemini 3.1 Ultra 2M, Claude Opus 4.7 1M, GPT-5.5 Instant 512K 토큰으로 나뉜다. Gemini 3.1 Ultra는 가장 긴 윈도우를 제공한다. Claude Opus 4.7은 장문 문서 추론과 코딩 품질에, GPT-5.5 Instant는 함수 호출 생태계와 ChatGPT 통합 플랫폼의 폭넓은 분포에 강점이 있다.
컨텍스트가 길다는 사실만으로 정보 활용 품질까지 보장되지는 않는다. 긴 문맥의 중간에 있는 정보를 제대로 회상하지 못하는 “Lost in the Middle” 현상은 장문 컨텍스트 모델이 공통으로 풀어야 할 문제다. Gemini 3.1 Ultra에는 위치와 관계없이 균등한 어텐션 품질을 유지하기 위한 Position-Invariant Attention 훈련 기법이 적용됐다. 1M 및 2M 토큰 NIAH(Needle-in-a-Haystack) 벤치마크에서 98% 이상의 회상 정확도를 달성했다고 보고된다.
비용과 레이턴시까지 포함하면 선택은 달라진다. Gemini 3.1 Ultra의 입력 토큰 단가는 플래그십 3사 중 중간 수준으로 예상되지만, 2M 토큰을 모두 사용하는 요청의 절대 비용은 상당하다. GPT-5.5 Instant는 상대적으로 낮은 레이턴시와 비용이 필요한 인터랙티브 에이전트에 적합하다. Claude Opus 4.7은 코딩·수학 추론 벤치마크에서 일관된 상위권 성능을 보인다.
작업의 성격에 따라 모델의 강점이 갈린다
장문 코드베이스를 한꺼번에 분석해야 한다면 Gemini 3.1 Ultra의 컨텍스트 용량이 직접적인 이점이 된다. 수십만 줄 규모의 모노레포를 단일 컨텍스트에 넣고 아키텍처 패턴 분석, 의존성 그래프 추출, 여러 파일에 걸친 리팩터링 계획을 수행할 수 있다. 이는 128K~512K 범위의 모델에서는 물리적으로 불가능한 작업이다. 대규모 오픈소스 프로젝트 분석, 레거시 코드베이스 마이그레이션 계획, 전사 API 표준화 검토가 해당한다.
멀티 문서 연구에서는 Gemini 3.1 Ultra와 Claude Opus 4.7이 경쟁한다. 수십 편의 논문이나 규제 문서, 계약서를 동시에 넣고 교차 참조하는 법률 리서치, 규제 컴플라이언스 검토, 학술 문헌 종합 분석에 두 모델을 활용할 수 있다. Gemini 3.1 Ultra의 2M 윈도우는 컨텍스트 여유 용량과 회상 품질 측면에서 우위를 제공한다.
반면 인터랙티브 에이전트에는 낮은 TTFT와 빠른 도구 응답이 더 중요할 수 있다. 이 경우 GPT-5.5 Instant의 레이턴시 특성이 유리하게 작용할 수 있지만, 복잡한 오케스트레이션에서는 Gemini 3.1 Ultra가 지원하는 32개 병렬 도구 호출이 차별점이 된다.
과학 데이터 분석에서는 통합 멀티모달 처리와 코드 실행이 함께 쓰인다. 실험 데이터 CSV, 현미경 이미지, 오디오 인터뷰 녹음, 관련 논문 텍스트를 하나의 컨텍스트에서 분석하고 Python 코드로 시각화까지 만드는 엔드투엔드 파이프라인이 Gemini 3.1 Ultra의 강점 영역이다.
모델 경쟁은 인프라와 생태계로 이동한다
Google I/O 2026의 Gemini 3.1 Ultra 공개는 플래그십 LLM 경쟁의 축이 벤치마크 점수에서 서빙 인프라와 생태계 통합으로 넓어지고 있음을 보여준다.
2024년 128K가 주류였던 컨텍스트 윈도우는 20252026년에 1M2M으로 빠르게 확장됐다. 하드웨어 메모리 용량 증가와 KV 캐시 압축 기술의 발전에 따라 이 흐름은 계속될 전망이다. 2027년에는 10M 토큰급 모델 발표가 예상되며, 전통적인 RAG(Retrieval-Augmented Generation) 아키텍처가 언제 필요한지 다시 검토하게 만들 수 있다.
멀티모달 처리도 텍스트 모델에 시각·음성 어댑터를 덧붙이는 방식에서 훈련 단계부터 모든 모달리티를 동등하게 다루는 네이티브 통합으로 이동한다. 이 변화는 실시간 비디오 분석, 음성 기반 에이전트, 다감각 환경 인식 애플리케이션의 품질을 높인다.
2M 토큰을 실용적인 비용과 수용 가능한 레이턴시로 서빙하는 능력은 Google TPU 인프라와 수직 통합된 Gemini에 구조적 이점을 준다. AWS, Azure, GCP 위에서 API로 운영되는 순수 모델 레이어 기업은 같은 수준의 서빙 품질을 확보하려면 클라우드 파트너 의존도를 높여야 한다. 인프라를 직접 보유한 Google의 TCO 경쟁력은 장기적으로 시장 점유율 확대의 기반이 될 전망이다.
Gemini 3.1 Ultra의 포지션은 2M 토큰 네이티브 컨텍스트, 통합 멀티모달 인코딩, 32개 병렬 도구 호출에 기반한다. 분산 KV 캐시 계층화와 압축 어텐션은 초장문 서빙의 물리적 제약을 다루며, 장문 코드베이스 분석과 멀티 문서 연구, 과학 데이터 처리로 활용 범위를 연결한다. 모델을 고를 때는 컨텍스트 최대치만 비교할 것이 아니라 실제 회상 품질, TTFT, 도구 호출 방식, 전체 비용까지 같은 기준에서 봐야 한다.
Sources
- https://blog.google/technology/google-deepmind/google-gemini-updates-io-2026/
- https://deepmind.google/technologies/gemini/ultra/
- https://ai.google.dev/gemini-api/docs/long-context
- https://arxiv.org/abs/2307.02738 (Ring Attention with Blockwise Transformers)
- https://arxiv.org/abs/2205.14135 (Efficient Long-Sequence Transformers)
- https://arxiv.org/abs/2309.17453 (Lost in the Middle: LLM Long Context)
- https://cloud.google.com/vertex-ai/generative-ai/docs/multimodal/overview
- https://ai.google.dev/gemini-api/docs/function-calling