Gemini 4 Carbon vs Argon: 어떤 Gemini 4 모델을 써야 할까요?
Gemini 4 Carbon과 Argon은 요청 형식과 요금이 같습니다. 같은 프롬프트 세 개를 API로 실행해 사고 토큰, 지연 시간 및 답변을 비교했습니다.
Markdown으로 읽기대화형 코딩과 빠른 반복 작업에는 Gemini 4 Argon을 쓰고, Argon의 답변이 중요한 부분을 놓치면 해당 작업을 Gemini 4 Carbon으로 옮기세요. Google도 같은 조언을 합니다. 두 모델은 같은 요청을 받고 컨텍스트 크기도 1,048,576 토큰으로 같으며, 같은 도입 가격으로 출시됐습니다. 차이는 Carbon이 답변 전에 얼마나 사고하느냐입니다.
검색으로 찾는 비교 글 대부분은 10월 28일 발표 당시 작성됐습니다. 그때는 소수의 사이버 방어 담당자만 Carbon을 쓸 수 있었습니다. 2026년 11월 10일 상황이 바뀌었습니다. Google이 Gemini API를 쓰는 모든 유료 개발자에게 Carbon을 공개했습니다. 그래서 저희는 직접 실행한 뒤, 같은 프롬프트를 Argon에도 보냈습니다.
두 모델의 공통 사양
Google의 마이그레이션 가이드는 명확합니다. 이미 gemini-4-argon을 쓰고 있다면 “gemini-4-carbon으로 업그레이드할 때 요청 스키마를 변경할 필요가 없습니다.” 모델 문자열만 바꾸면 됩니다.
| Gemini 4 Carbon | Gemini 4 Argon | |
|---|---|---|
| 모델 ID | gemini-4-carbon | gemini-4-argon |
| 컨텍스트 창 | 입력, 사고 및 출력이 공유하는 1,048,576 토큰 | 동일 |
| 응답 한 회당 출력 | 스트리밍 65,536, 비스트리밍 32,768 | 동일 |
| 긴 답변 분할 생성 | 이어서 생성하면 최대 1M 토큰 | 동일 |
| 사고 수준 | low, medium(기본값), high | 동일 |
| 입력 | 텍스트, 이미지, 오디오, 동영상 및 PDF | 동일 |
| 도구 | Search, Maps, 코드 실행, URL 컨텍스트, 파일 검색, 컴퓨터 사용 및 함수 | 동일 |
| 명시적 컨텍스트 캐싱 | 미지원, 암시적 캐싱만 지원 | 동일 |
두 모델 모두 temperature, topP 및 topK를 무시하며, 어느 쪽도 minimal 사고 수준을 명시하지 않습니다(Carbon에 보내자 HTTP 400을 반환했습니다). 한 모델에서 작동하는 코드는 다른 모델에도 유효한 요청을 보냅니다.
Google이 설명하는 차이
Google은 Carbon을 “추론 깊이의 한계에 도전하는 작업을 위해 설계된” 모델이라고 설명합니다. 같은 가이드에서는 Carbon이 “충분히 탐색하고 자신의 작업을 검증하기 위해 턴마다 더 많은 사고 토큰을 사용하므로, Argon보다 턴당 토큰 사용량과 지연 시간이 늘어납니다”라고 설명합니다. Google이 Carbon에 권하는 작업은 근본 원인 디버깅, 아키텍처 작업, 정보 밀도가 높은 멀티모달 정보의 종합, 증명 및 보안 감사입니다. Argon에는 “대화형 코딩, 일상적인 기능 개발 및 빠른 프로덕션 반복 작업”을 권합니다.
나머지 차이는 Google 자체 발표에 나와 있습니다. Carbon은 사이버 보안 성적이 더 좋고, 근거 없는 주장이 더 적으며, 에이전트로서 더 정직하게 행동한다고 합니다. 저희는 해당 벤치마크를 재현하지 않았으므로 직접 측정한 것처럼 수치를 반복하지 않겠습니다. 이 점을 염두에 두고 Google의 Carbon 발표를 읽어 보세요.
같은 프롬프트로 두 모델을 실측한 결과
2026년 11월 11일, 정답을 아는 프롬프트 세 개를 SeedRouter의 네이티브 Gemini 엔드포인트를 통해 두 모델에 보냈습니다. 모든 요청은 thinkingLevel: "medium"과 maxOutputTokens: 8192를 사용했고, 각각 한 번만 시도했으며 재시도하지 않았습니다. 출력은 눈에 보이는 답변의 토큰 수이고, 사고는 thoughtsTokenCount가 보고한 값입니다.
| 프롬프트 | 모델 | 정답 여부 | 출력 토큰 | 사고 토큰 | 초 |
|---|---|---|---|---|---|
| 1000! 끝에 붙는 영의 개수 | Carbon | 맞음(249) | 66 | 71 | 5.2 |
| 1000! 끝에 붙는 영의 개수 | Argon | 맞음(249) | 107 | 249 | 8.9 |
| x² − y² = 2026의 정수해 | Carbon | 맞음(없음, 홀짝성으로 증명) | 220 | 224 | 9.0 |
| x² − y² = 2026의 정수해 | Argon | 맞음(없음, 두 가지 증명) | 313 | 0 | 7.3 |
Python의 top_k 버그 수정 | Carbon | 맞음 | 37 | 392 | 18.4 |
Python의 top_k 버그 수정 | Argon | 맞음 | 32 | 0 | 7.0 |
눈에 띈 점은 세 가지였습니다.
Carbon이 항상 더 많이 사고하지는 않았습니다. 팩토리얼 문제에서는 Argon이 사고 토큰 249개, Carbon이 71개를 썼습니다. 나머지 두 문제에서 Argon은 사고 토큰이 전혀 보고되지 않은 채 답했고, Carbon은 각각 224개와 392개를 사고에 썼습니다. 세 프롬프트를 합친 과금 대상 출력 토큰(답변과 사고)은 Carbon이 1,010개, Argon이 701개였습니다. 이 작은 표본에서는 약 44% 더 많았습니다. Google의 설명과 방향은 같지만, 모든 경우에 해당하지는 않습니다.
이번에는 사고가 답변을 바꾸지 않았습니다. 두 모델 모두 세 문제를 전부 맞혔습니다. 함수도 같은 방식으로 고쳤습니다. 내림차순으로 정렬한 뒤 [:k]로 슬라이싱했습니다. 원래의 ranked[-k:]가 k가 0일 때도 잘못 작동한다는 점은 어느 모델도 짚지 않았습니다. -0은 그냥 0이므로 리스트 전체를 반환하기 때문입니다. 수정된 코드는 결과적으로 이 경우도 처리합니다. 이런 쉬운 프롬프트로는 Carbon의 추가 확인이 어디서 효과를 내는지 알 수 없습니다. 드는 비용만 알 수 있습니다.
지연 시간은 모델 이름보다 사고량을 따랐습니다. Carbon이 가장 늦게 답한 것은 코드 수정(18.4초)이었고, 가장 오래 사고한 문제이기도 했습니다. 팩토리얼 프롬프트에서는 Argon보다 빨랐습니다.
프롬프트 세 개로 품질에 관해 증명할 수 있는 것은 없습니다. 다만 직접 테스트할 방법은 알 수 있습니다. 현재 Argon이 실패하거나 한 번 더 작업해야 하는 과제 다섯 개나 열 개를 골라 같은 설정으로 두 모델에 보내세요. 답변당 토큰 수가 아니라 달러당 정답 수를 비교하세요.
요금: 같은 토큰 단가, 다른 답변당 토큰 수
두 모델은 같은 Gemini API 도입 가격으로 출시됐으므로 실제 지불액의 차이는 토큰 수에서 나오며, 주로 사고 토큰 때문입니다. Google이 명시한 1M 토큰당 도입 요금은 다음과 같습니다(2026년 11월 11일 확인). 2026년 11월 30일까지 적용됩니다.
| 2026년 11월 30일까지 | 2026년 12월 1일부터 | |
|---|---|---|
| 입력 | US$2.00 | US$4.00 |
| 출력(사고 포함) | US$10.00 | US$20.00 |
| 캐시 입력 | US$0.10 | US$0.20 |
Google의 요금 페이지에 나오는 정가입니다. 저희 플랫폼의 현재 토큰 단가는 아래와 같으며, 같은 그룹에 속한 두 모델에 동일하게 적용됩니다.
Gemini 4 Carbon
100만 토큰당 USD
| 항목 | 100만 토큰당 USD |
|---|---|
| 입력 | US$0.90 |
| 출력(사고 포함) | US$4.50 |
| 캐시 입력 | US$0.045 |
Standard 처리 요율이며 컨텍스트 길이에 따른 요금 단계는 없습니다. 캐시 입력은 캐시 요율로 한 번만 과금됩니다. Search 및 Maps 그라운딩은 이 토큰 요율과 별도로 과금됩니다.
Gemini 4 Argon
100만 토큰당 USD
| 100만 토큰당 USD | googlellm | googlellm-vertext |
|---|---|---|
| 입력 | US$0.90 | US$1.00 |
| 출력(사고 포함) | US$4.50 | US$5.00 |
| 캐시 입력 | US$0.045 | US$0.05 |
캐시된 토큰은 입력의 일부이며 추가 입력이 아닙니다. 이어서 생성하는 각 요청에는 개별 사용량이 있으며, 실패한 요청에는 요금이 부과되지 않습니다.
사고 토큰에는 출력 단가가 적용되므로, Carbon이 400개 토큰을 사고에 쓰고 Argon은 전혀 쓰지 않는 작업이라면 단가가 같아도 Carbon의 비용이 더 높습니다. 전체 작업을 Carbon으로 옮긴다면 출력 사용량 증가를 예산에 반영하고, 사고 때문에 답변이 잘리지 않도록 maxOutputTokens를 충분히 높게 설정하세요. Google은 최소 32,768을 권합니다.
요청을 Argon에서 Carbon으로 전환하는 방법
URL의 모델을 바꾸세요.
curl "https://api.seedrouter.ai/v1beta/models/gemini-4-carbon:streamGenerateContent?alt=sse" \
-H "Authorization: Bearer $SEEDROUTER_API_KEY" \
-H "Content-Type: application/json" \
-d '{"contents":[{"role":"user","parts":[{"text":"Review this migration plan for ordering mistakes."}]}],"generationConfig":{"thinkingConfig":{"thinkingLevel":"medium"},"maxOutputTokens":32768}}'프로덕션 테스트에서 얻은 실용적인 주의 사항은 두 가지입니다. 먼저 오래 걸릴 수 있는 작업에는 스트리밍을 쓰세요. 저희가 보낸 비스트리밍 오디오 요청은 약 두 분간 실행된 뒤, 답변이 도착하기 전에 네트워크 에지의 대기 시간이 초과되어 HTTP 524로 끝났습니다. 같은 요청은 스트리밍으로 84초 만에 정상 완료됐습니다. 다음으로 작업에 high가 필요하지 않다면 thinkingLevel을 medium으로 유지하세요. 작은 인수분해 문제에서 확인해 보니 high 사고는 사고 토큰 493개, medium은 193개를 썼고 답변은 같았습니다.
전체 요청 레퍼런스는 Gemini 4 Carbon API 문서에 있습니다. Gemini 4 Carbon 페이지와 Gemini 4 Argon 페이지에서 직접 작성한 프롬프트로 두 모델을 시험할 수 있습니다.
자주 묻는 질문
Gemini 4 Carbon이 Argon보다 더 좋은가요?
Google 벤치마크에서는 그렇습니다. 특히 긴 에이전트 작업과 보안 작업에서 앞섭니다. 저희의 간단한 프롬프트 세 개에서는 둘 다 정답을 냈고, 그중 두 개에서 Carbon이 더 많은 출력 토큰을 썼습니다. 어려운 작업에서 차이가 드러나므로 Argon이 틀리는 문제를 테스트하세요.
Gemini 4 Carbon과 Argon의 차이는 무엇인가요?
사고에 들이는 노력입니다. 요청 형식, 컨텍스트 창, 도구, 모달리티 및 도입 가격은 같습니다. Carbon은 자신의 작업을 검증하기 위해 턴마다 더 많이 사고하므로, 어려운 프롬프트에서는 더 느리고 출력 토큰도 더 많이 씁니다.
Gemini 4 Carbon 요금이 Argon보다 비싼가요?
토큰당 요금은 같습니다. 출시 시 Google 정가는 두 모델 모두 1M 토큰당 입력 US$2, 출력 US$10이었습니다. Carbon이 출력으로 과금되는 사고 토큰을 더 많이 쓰므로 답변당 비용은 대개 더 높습니다.
코드 변경 없이 Gemini 4 Argon에서 Carbon으로 전환할 수 있나요?
네. Google 가이드는 요청 스키마 변경이 필요 없다고 설명합니다. gemini-4-argon을 gemini-4-carbon으로 바꾸고 출력 한도와 타임아웃을 검토하세요.
Gemini 4 Carbon이 Argon을 대체하나요?
아닙니다. Google은 대부분의 소프트웨어 및 지식 작업에서 더 빠른 선택지로 Argon을 유지하고, 가장 어려운 문제를 위한 모델로 Carbon을 제시합니다. 두 모델 모두 계속 이용할 수 있습니다.
