Gemini 3.5 Flash의 장문 컨텍스트와 경량 추론 아키텍처

속도와 장문 처리를 함께 겨냥한 Flash 설계

2026년 Google I/O에서 정식 출시된 Gemini 3.5 Flash는 프론티어 모델 대비 4배 빠른 응답 속도와 동급 추론 성능을 1M 토큰 컨텍스트 윈도우에서 구현한 경량 모델이다. 같은 해 6월 GA 상태로 전환됐으며 Google AI Studio와 Gemini API, Google Antigravity, Android Studio, Gemini Enterprise Agent Platform에서 프로덕션 규모로 사용할 수 있다. Gemini 앱과 Search의 AI Mode에도 기본 모델로 채택됐다. 입력 $1.50/출력 $9 per 1M 토큰의 가격도 기업이 대규모 LLM 워크로드를 운영할 때의 비용 문턱을 낮춘다.

이 모델은 Gemini 2.0 Flash가 택했던 속도 중심의 방향을 이어가면서 추론 품질을 프론티어급 모델에 가깝게 끌어올렸다. 컨텍스트 윈도우는 정확히 1,048,576 토큰이며 코드베이스 전체, 수백 페이지 문서, 긴 대화 이력을 한 요청에서 다룰 수 있다. 복잡한 추론 작업의 TTFT(Time to First Token)는 평균 180ms 이하이고, 텍스트뿐 아니라 이미지·오디오·비디오 입력도 네이티브로 처리한다.

⤢✕

1M 토큰이 바꾸는 작업 범위

1M 토큰은 영어 약 75만 단어, 한국어 약 50만 어절에 해당한다. 표준 A4 용지로 환산하면 약 1,500~~2,000장이고, 파일 수 200~~300개인 중규모 Python 코드베이스 전체를 단일 컨텍스트에 담을 수 있는 규모다.

코드 작업에서는 모노레포 전체를 입력해 의존성을 분석하고 버그 탐지와 리팩토링, 아키텍처 개선 제안을 함께 수행할 수 있다. 법률 계약서나 의료 연구 논문, 기술 사양서처럼 수백 페이지에 이르는 문서도 별도 청킹 없이 분석 대상에 넣을 수 있다.

수천 턴의 이력을 유지해야 하는 장기 대화 에이전트에도 이 컨텍스트 용량이 쓰인다. 멀티미디어 파이프라인에서는 고해상도 이미지 수백 장이나 장시간 영상에서 추출한 프레임을 일괄 분석하는 배치 처리에 활용할 수 있다.

멀티모달 요청을 하나의 파이프라인에서 다루기

Gemini 3.5 Flash는 텍스트, 이미지, 오디오, 비디오, PDF를 단일 API 엔드포인트에서 처리한다. 입력 인터페이스가 하나여도 토큰 비용과 전처리 방식까지 같은 것은 아니다.

이미지는 해상도와 타일 분할 방식에 따라 수백~수천 토큰을 사용한다. 오디오의 소비량은 초당 약 32토큰이며, 비디오는 샘플링하는 프레임 수에 비례한다. 따라서 비용 모니터링에서는 전체 토큰만 합산하지 말고 모달리티별 사용량도 따로 기록해야 한다.

입력이 길어지면 첫 토큰 응답 지연인 TTFT(Time To First Token)도 늘어난다. 실제 파이프라인에서는 청킹과 프리픽스 캐싱을 조합해 이 문제를 다룬다.

가격 구조와 반복 컨텍스트의 비용

Gemini 3.5 Flash의 토큰 가격은 입력 $1.50/1M, 출력 $9/1M이다. Gemini 2.5 Pro의 입력 $3.50/출력 $10.50과 비교하면 입력 비용은 57%, 출력 비용은 14% 절감된다. Claude Sonnet 4.6은 입력 $3/출력 $15, GPT-5.5 Instant는 입력 $2.50/출력 $12로, Flash보다 높은 비용 구조를 가진다.

동일한 컨텍스트 접두사가 반복되는 RAG 파이프라인이나 시스템 프롬프트 재사용 환경에서는 Google의 암시적 컨텍스트 캐싱(Implicit Context Caching)을 적용할 수 있다. 이때 실질 입력 비용은 $0.375/1M 수준까지 낮아진다. 하루 10억 토큰을 처리한다고 가정하면 GPT-5.5 Instant 대비 연간 약 $400K의 비용 절감 효과가 발생한다.

초안을 먼저 만들고 한 번에 검증한다

스펙큘레이티브 디코딩(Speculative Decoding)은 Gemini 3.5 Flash의 속도를 지탱하는 핵심 기법이다. 소형 드래프트 모델(Draft Model)이 k개의 토큰을 빠르게 생성하면, 대형 검증 모델(Verifier Model)이 해당 토큰들을 병렬로 검사해 수락 여부를 결정한다.

검증을 통과한 토큰은 그대로 출력된다. 검증 모델 입장에서는 여러 토큰을 단일 포워드 패스에서 처리하는 셈이다. 속도 이득은 수락률(Acceptance Rate)에 좌우되며, 패턴이 규칙적인 코드 생성 작업에서는 수락률이 85~90%에 이른다. 그 결과 속도 향상이 이론적 최대 k배에 가까워진다.

드래프트 모델도 작업에 맞춰 달라진다. 태스크 어웨어 드래프팅(Task-Aware Drafting)은 코드 완성에는 코드 특화 소형 LM을, 자연어 생성에는 범용 소형 LM을 배정해 도메인별 수락률을 높이는 방식이다.

⤢✕

1M 토큰에서 KV 캐시를 감당하는 방법

KV 캐시(Key-Value Cache)는 이미 처리한 토큰의 어텐션 키·밸류 벡터를 메모리에 보관해 반복 계산을 피한다. 컨텍스트가 1M 토큰까지 늘어나면 이 캐시의 크기 자체가 배포 구조를 좌우한다.

레이어 수 L, 헤드 수 H, 헤드 차원 D, 배치 크기 B, 시퀀스 길이 S일 때 필요한 메모리는 2 × B × L × H × D × S × dtype_bytes로 계산된다. 1M 토큰과 bfloat16(2바이트), L=32, H=16, D=128을 가정하면 배치 크기 1에서도 약 134GB가 필요하다. 단일 H100 GPU의 VRAM 80GB를 넘어서는 크기다.

GQA(Grouped Query Attention)는 MHA(Multi-Head Attention)보다 KV 헤드 수를 1/4~1/8로 줄여 캐시 메모리를 낮춘다. Gemini 3.5 Flash는 GQA를 기본으로 사용해 전체 KV 캐시 풋프린트를 MHA 대비 75% 수준으로 줄인다.

모든 레이어에 전체 시퀀스 어텐션을 적용하지 않는 것도 중요하다. 하위 레이어에서는 4096 토큰과 같은 지역 윈도우를 사용하고 상위 레이어에서만 글로벌 어텐션을 수행하면 계산량과 KV 캐시 크기를 함께 줄일 수 있다.

메모리 할당에는 PagedAttention과 유사한 비연속 방식을 쓴다. GPU 메모리를 고정 크기 블록으로 나누고 KV 캐시를 페이지 단위로 관리해, 길이가 다른 시퀀스가 섞일 때 생기는 내부 단편화를 줄이는 구조다.

연속 배칭과 지연 SLO의 조율

정적 배칭에서는 배치 안에서 가장 긴 시퀀스가 끝날 때까지 다른 슬롯도 기다려야 한다. 연속 배칭(Continuous Batching), 또는 Iteration-Level Scheduling은 디코딩 스텝마다 완료된 슬롯을 새 요청으로 즉시 교체한다. GPU 활용률은 고정 배칭 대비 40~60% 향상되고 실효 처리량도 그에 따라 증가한다.

Gemini 3.5 Flash의 서빙 인프라는 이 스케줄링 방식과 스펙큘레이티브 디코딩을 함께 사용한다. 드래프트 모델의 k-토큰 예측과 검증 모델의 병렬 검증을 연속 배칭 스케줄러가 조정하며 GPU 점유율을 유지한다.

양자화는 속도와 메모리 효율을 동시에 다루는 수단이다. INT8 활성화와 bfloat16 가중치를 결합한 혼합 정밀도(Mixed Precision)를 사용하면 품질 손실을 최소화하면서 fp32 대비 연산 속도를 약 2~3배 높일 수 있다.

지연 목표 방법론(Latency Target Methodology)은 SLO(Service Level Objective)에 맞춰 배치 크기를 동적으로 조정한다. 인터랙티브 요청과 배치 요청에 각각 목표 TTFT와 TBT(Time Between Tokens)를 설정하고, 부하 상태에 따라 배치 크기와 스펙큘레이티브 디코딩의 k 값을 바꾼다. 인터랙티브 요청은 TBT 50ms와 TTFT 200ms를 목표로 하며, 목표를 넘길 가능성이 생기면 배치 크기를 줄여 지연 SLO를 우선한다.

장문 입력을 지역 단위로 처리하는 구조

1M 토큰 전체에 표준 자기 회귀 어텐션을 적용하면 계산 복잡도는 O(N²)이다. N=1M에서는 1조 번의 연산이 필요하다. 슬라이딩 윈도우 어텐션(SWA)과 청크 분할(Chunking)은 이 비용을 현실적인 수준으로 낮추기 위한 조합이다.

SWA에서는 각 토큰이 전체 컨텍스트 대신 W=4096과 같은 로컬 윈도우 안의 토큰만 참조한다. 복잡도는 O(N×W)로 줄어들고, 로컬 언어 패턴은 이 범위에서 처리한다. 장거리 의존성(Long-range Dependency)은 일부 레이어나 어텐션 헤드에 남겨둔 글로벌 어텐션으로 보완한다.

청크 처리에서는 1M 토큰을 32K 토큰 같은 고정 크기로 나눠 순차 처리한다. 청크 사이에는 KV 캐시 상태를 공유하고, 경계에서 컨텍스트가 끊기는 문제를 줄이기 위해 인접 청크에 2K 토큰과 같은 오버랩을 둔다.

⤢✕

계층적 KV 캐시와 RAG의 결합

최근 토큰의 KV 벡터는 GPU HBM(High Bandwidth Memory)에 두고, 오래된 청크는 CPU DRAM으로 내리는 계층적 KV 캐시를 사용할 수 있다. 이전 청크가 다시 필요하면 CPU에서 GPU로 전송한다. 이 전송 비용은 프리페치(Prefetch) 스케줄링으로 어텐션 계산 시간 뒤에 숨긴다.

1M 토큰을 지원한다고 해서 모든 문서를 항상 컨텍스트에 넣을 필요는 없다. RAG(Retrieval Augmented Generation)에서는 벡터 검색으로 관련 청크를 선별해 전체 문서의 10~20%만 원문으로 넣고, 나머지는 요약으로 포함하는 하이브리드 구성이 효율적이다. 평균 입력은 1M의 20% 수준인 200K 이하로 관리하면서 필요한 요청만 1M까지 확장할 수 있다.

호출 전에 예산을 통제하는 계층

장문 컨텍스트는 입력 크기의 변동 폭이 크기 때문에 호출 전에 비용을 계산할 수 있어야 한다. 먼저 tiktoken이나 Google 공식 토크나이저로 입력 토큰 수를 세고 예상 비용을 산정한다. 예산 한도를 넘는 요청은 API 호출 전에 가드레일에서 차단한다.

반복되는 시스템 프롬프트나 문서 전문은 명시적 캐시 항목으로 등록할 수 있다. 캐시 히트가 발생하면 입력 비용이 75% 절감된다. API 클라이언트에서는 캐시 키를 해시로 관리하고 TTL(Time to Live)을 설정하는 계층이 필요하다.

대화 이력이 계속 길어진다면 초기 턴을 요약 토큰으로 압축하는 롤링 요약(Rolling Summary)을 적용할 수 있다. 오래된 이력의 크기를 줄이면서 대화에 필요한 맥락을 남겨, 전체 토큰 예산을 일정한 범위에서 관리하는 방식이다.

경쟁 모델과 비교한 속도·비용·품질

2026년 중반 경량 고성능 LLM 시장에서는 Gemini 3.5 Flash, Claude Sonnet 4.6, GPT-5.5 Instant가 각각 Google, Anthropic, OpenAI의 모델로 경쟁하고 있다.

내부 벤치마크에서 Gemini 3.5 Flash의 출력 속도는 Claude Sonnet 4.6보다 약 3.2배, GPT-5.5 Instant보다 약 2.8배 빠르다. TTFT와 출력 속도(tokens/sec) 모두에서 앞서는 결과이며, 스펙큘레이티브 디코딩과 Google TPU v5e 전용 최적화 커널의 결합이 이 차이를 만든다.

입력 가격은 Flash가 $1.50, Sonnet 4.6이 $3.00, GPT-5.5 Instant가 $2.50이다. Flash는 Sonnet 4.6보다 50%, GPT-5.5 Instant보다 40% 저렴하다. 출력 가격은 각각 $9, $15, $12이며 Flash가 Sonnet 4.6보다 40%, GPT-5.5 Instant보다 25% 낮다.

추론 품질에서도 경량 모델과 프론티어 모델의 격차가 줄었다. MMLU, HumanEval, GSM8K에서 Flash는 Gemini 3.5 Pro, Claude Opus 4, GPT-5.5 같은 프론티어 모델 성능의 92~95% 수준을 기록한다.

에이전트 벤치마크가 보여주는 위치

Terminal-Bench는 터미널에서 자율적으로 코드를 실행하고 오류를 복구하며 멀티스텝 작업을 끝내는 능력을 측정한다. Gemini 3.5 Flash의 점수는 76.2%로 Claude Sonnet 4.6의 72.4%, GPT-5.5 Instant의 69.8%보다 높다.

MCP(Model Context Protocol) 환경에서 멀티툴 오케스트레이션을 평가하는 MCP Atlas에서는 83.6%를 기록하였다. 1M 토큰 컨텍스트가 긴 도구 실행 이력과 복잡한 시스템 프롬프트를 수용하는 데 이점을 준다는 해석이 유력하다.

워크로드에 따라 Flash와 Pro를 나눈다

Gemini 3.5 Flash는 지연에 민감한 인터랙티브 애플리케이션, 비용 제약이 큰 대규모 배치 처리, 장문 문서를 반복하는 RAG 파이프라인, 멀티스텝 에이전트 작업에 맞는다.

복잡한 수학 증명이나 고도의 창의적 글쓰기, 복잡한 코드 설계처럼 단일 요청에서 가장 깊은 추론이 필요하면 Gemini 3.5 Pro나 Claude Opus 4 같은 프론티어급 모델이 여전히 우선된다.

실제 배포에서는 태스크 라우터(Task Router)가 요청 복잡도를 분류한 뒤 Flash와 Pro를 동적으로 선택하는 계층적 모델 앙상블을 구성할 수 있다. 1M 토큰 컨텍스트, 프론티어 모델 대비 4배 빠른 응답, Terminal-Bench 76.2%, MCP Atlas 83.6%라는 특성을 모든 요청에 일괄 적용하기보다 워크로드별로 배치하는 접근이다. 비용 구조와 속도 우위를 고려하면 기업 환경에서 Flash를 포함한 멀티모델 라우팅 전략의 채택이 가속화될 것으로 전망된다.