Kimi K3가 출시되었습니다Kimi K3 살펴보기
속도와 비용을 비교한 Gemini 3.6 Flash와 Gemini 3.5 Flash의 프로덕션 추론 레인
비교

Gemini 3.6 Flash 대 Gemini 3.5 Flash: 프로덕션 워크로드를 옮겨야 할까?

Jacey
Jacey
Founder
2026년 7월 21일
34분 소요
최종 확인: 2026-07-21. 작성자 Jacey, 출시 당일 우리가 돌린 216번의 API 호출 포함. 측정 방법은 그 결과가 등장하는 절에서 상세히 설명합니다. EvoLink는 여기서 논의하는 두 모델을 포함한 서드파티 모델로 라우팅하는 API 게이트웨이를 운영합니다.
핵심 요약
  • 지금 옮기십시오 — 청구서에서 출력 토큰이 대부분을 차지한다면. 에이전트 루프, 긴 코드 생성, 추론 중심 작업은 26%에서 29% 더 저렴한 구간에 들어옵니다.
  • 작은 이득 — 트래픽이 입력 중심이라면. 출력 토큰 1개당 대략 입력 토큰 20개로 돌아가는 문서 파이프라인은 7.1%를 절약합니다. 입력 가격이 전혀 바뀌지 않았기 때문입니다.
  • 지능은 제자리입니다. 독립 측정은 두 모델을 같은 지수에서 50.1과 50.2로 둡니다. 움직인 것은 속도입니다. 초당 출력 토큰 165개에서 304개로, 작업당 2.7분에서 1.3분으로.
  • 먼저 테스트하십시오 — 워크로드가 지식 중심이거나 프런트엔드 UI를 생성한다면. 공개된 증거가 반대 방향을 가리키는 두 지점이 바로 그곳입니다.
  • thinking 레벨이 모델보다 청구서를 더 크게 움직입니다. 우리 자체 테스트에서 기본 medium에서 minimal로 낮추자 우리 작업 세트에서 정확도 손실 없이 패스 비용이 73.6% 줄었습니다. 어느 모델을 돌리든 의도적으로 설정하십시오.
  • 이것은 모델 문자열만 바꾸는 일이 아닙니다. temperature, top_p, top_k는 이제 받아들여진 뒤 오류 없이 무시되며, thinking_budget은 더 이상 존재하지 않습니다.

핵심 결론: 워크로드별로

이 업그레이드의 가치는 거의 전적으로 두 가지에 달려 있습니다. 트래픽에서 입력 토큰 대 출력 토큰의 비율, 그리고 지연이 현재 불만거리인지 여부입니다.

당신의 워크로드판정이유
멀티턴 에이전트, 도구 호출 루프, 긴 코드 생성옮긴다출력과 thinking 토큰이 대부분을 차지하고, 가격이 내린 것은 그 부분뿐
작업 지연이 불만인 모든 경우옮긴다독립 측정에서 작업당 시간이 대략 절반으로
지식 중심 질의응답먼저 섀도런직접 비교 가능한 유일한 세대 간 지식 점수가 하락
프런트엔드·UI 생성먼저 섀도런Google이 여기서 두 가지 구체적 퇴보를 문서화, 둘 다 프롬프트 수준의 해결책 있음
대략 20:1의 문서 처리·RAG서두를 것 없음절감은 7.1%로, 평범한 한 달의 노이즈 범위 안
당신이 실제로 던지는 질문이 '대신 Gemini 3.5 Flash-Lite를 돌려야 하나'라면, 그것은 다른 답을 가진 다른 결정이며 Gemini 3.6 Flash 대 3.5 Flash-Lite에서 다룹니다. Flash-Lite는 지금 돌리는 모델의 최신 버전이 아니라 한 단계 낮은 능력 등급이므로, 아래 숫자들은 어느 것도 그것에 적용되지 않습니다.

실제로 무엇이 바뀌었나

Gemini 3.6 Flash는 새로운 모델 세대가 아닙니다. 모델 카드는 이것이 Gemini 3.5 Flash 위에 지어졌다고 명시하며, 이는 같은 베이스에 대한 사후 학습(post-training) 업데이트임을 뜻합니다. 이 한 가지 사실이 뒤따르는 대부분을 설명합니다. 능력은 옆으로 움직였고, 사후 학습과 서빙이 움직일 수 있는 것들, 즉 속도와 토큰 효율은 크게 움직였습니다.
아래는 Google의 모델 문서에서 가져온 실용적 세부입니다.
  • 모델 ID: gemini-3.6-flash. 안정 버전 하나, preview 접미사도 날짜 표기도 없으므로 별칭을 정할 일이 없습니다.
  • 컨텍스트: 입력 1,048,576 토큰, 출력 65,536 토큰으로 변동 없음. 입력은 텍스트·이미지·비디오·오디오·PDF, 출력은 텍스트만.
  • 기본 thinking 레벨: medium. minimal, low, medium, high 중 선택 가능.
  • 가격: 입력은 100만 토큰당 $1.50으로 유지. 출력은 $9.00에서 $7.50으로, 16.67% 인하. 캐시 읽기는 100만당 $0.15. 배치 및 우선 등급은 Google 가격 페이지를 참고.
위는 이 페이지의 결정에 중요한 필드들입니다. 전체 능력 매트릭스와 새 모델 ID에 대한 첫 동작 요청은 Gemini 3.6 Flash 가이드를 참고하십시오.
떠돌고 있어 바로잡을 만한 것이 하나 있습니다: 입력 가격은 오르지 않았습니다. gemini-3.5-flashgemini-3.6-flash 모두 입력 100만 토큰당 $1.50을 청구합니다. '숨은 인상'이라는 주장은 더 이른 Flash 세대의 가격과 비교한 데서 나옵니다.

청구서에는 어떤 일이 벌어지나

비용을 줄여 준다는 것이 두 가지 따로 있습니다. 출력 가격이 16.67% 낮고, 같은 작업에서 모델이 더 적은 출력 토큰을 쓴다고 보고됩니다. 둘을 곱하면 출력 측 지출은 30.8% 줄어듭니다.

그 숫자는 실제입니다. 그리고 이번 출시에 대한 많은 보도가 절감을 과장하는 이유이기도 합니다. 입력 가격은 움직이지 않았습니다. 그래서 트래픽이 입력 중심에 가까울수록, 그 30.8% 중 실제로 보는 몫은 줄어듭니다.
입력 중심 파이프라인보다 출력 중심 AI 워크로드가 더 많은 절감을 얻는 이유를 보여 주는 Gemini 3.6 Flash 워크로드 비용 비교
입력 중심 파이프라인보다 출력 중심 AI 워크로드가 더 많은 절감을 얻는 이유를 보여 주는 Gemini 3.6 Flash 워크로드 비용 비교
Gemini 3.6 Flash의 절감은 출력 측에 집중되므로, 워크로드의 토큰 비율이 프로덕션 비용 영향을 결정합니다.
입력:출력 비율대표 워크로드3.5 Flash3.6 Flash변화
20:1문서 처리, RAG$39.00$36.237.1% 저렴
5:1일반 질의응답$16.50$13.7216.8% 저렴
1:1thinking 켠 멀티턴 에이전트$10.50$7.7226.4% 저렴
1:3추론 중심 작업, 긴 코드 생성$28.50$20.1729.2% 저렴

이 표는 이렇게 읽으십시오. 각 행은 하나의 워크로드를 3.5 Flash에서 출력 토큰 100만 개로 정규화하고, 입력 토큰은 명시된 비율로 설정하여, 표준 등급 가격으로 계산합니다. 신규 모델에서 출력 토큰 17% 감소, 입력 토큰 동일을 가정합니다.

그 17% 가정은 조건을 따로 밝힐 만합니다. 표의 모든 것이 그 위에 서 있기 때문입니다. Google은 이 수치를 직접 측정한 것이 아니라 인용했으며, 출처는 Artificial Analysis입니다. 같은 페이지에 실린 절대 토큰 수, 즉 5,900만 대 7,500만은 계산하면 21.3%가 됩니다. 두 수치는 공개적으로 조정된 적이 없습니다. 우리는 전 구간에서 더 보수적인 17%를 사용했으므로, 이 표를 약속이 아니라 절감 범위의 하단으로 취급하십시오.
또 한 가지: thinking 토큰은 출력 요율로 청구됩니다. 그래서 에이전트 행들이 가장 많이 움직입니다. 멀티턴 에이전트에서 thinking 예산은 청구서의 반올림 오차가 아니라 큰 몫입니다.
그다음 우리가 이 표를 실측했더니, 표는 낙관적이었습니다. 우리 작업 세트는 대략 청구 출력 토큰 1.5개당 입력 토큰 1개꼴로, 표의 1:1과 1:3 행 사이에 위치하며 표는 26%에서 29% 절감을 예측합니다. 우리는 medium thinking 레벨에서 13.6%, high에서 20.1%를 측정했습니다.
격차는 전부 토큰 효율 가정에 있습니다. medium에서 신규 모델은 이전 모델보다 출력 토큰을 17% 덜 쓴 것이 아니라 1.7% 더 청구했으므로, 우리가 얻은 절감은 거의 전부 토큰 효율이 아니라 출력 단가가 16.67% 내린 데서 왔습니다. high에서는 감소가 일부 나타나, 출력 토큰이 6.4% 줄었습니다. 측정 방법과 전체 숫자는 다음 절에 있습니다.

그러니 표는 벤더 주장이 함의하는 산술로, 우리 수치는 하나의 실제 워크로드가 실제로 만들어낸 결과로 읽으십시오. 당신의 작업이 벤치마크 세트보다 우리 쪽을 더 닮았다면, 낮은 숫자로 계획하십시오.

같은 지능, 대략 두 배의 속도

Artificial Analysis는 출시 전 접근 권한을 받았으며, 현재 완전한 분해 데이터를 가진 유일한 독립 출처입니다. high thinking 레벨에서 측정한 그들의 수치:
지표3.6 Flash3.5 Flash
지능 지수 v4.150.150.2
Humanity's Last Exam (지식 중심)38.3%40.2%
GPQA Diamond92.8%92.2%
SciCode52.7%53.1%
장문맥 추론 (AA-LCR)69.7%69.3%
출력 속도303.6 tok/s165.4 tok/s
첫 토큰까지 시간11.54초20.22초
문항당 평균 시간1.3분2.7분
문항당 평균 비용$0.50$0.59
모든 행에 두 가지 조건이 붙습니다. 첫째, **이것은 high 레벨에서 측정되었지만 API 기본값은 medium**이므로, 기본 구성으로 돌리는 것은 같은 실험이 아닙니다. 둘째, 속도와 지연 수치는 72시간 중앙값인데 모델은 같은 날 출시되었으므로, 표본 창은 하루 미만이며 변동을 예상해야 합니다.

그 점을 밝혀 두면, 그림은 분명하며 이는 퇴보가 아니라 맞교환입니다. 지능 지수 50.1 대 50.2는 반올림 차이입니다. 추론과 장문맥 점수는 소폭 올랐습니다. 두 세대에 걸쳐 직접 비교 가능한 유일한 지식 중심 점수인 Humanity's Last Exam은 1.9포인트 하락했습니다. 한편 출력 속도는 84% 올랐고 문항당 시간은 대략 절반이 되었습니다.

그러니 이번 출시에서 원한 것이 더 똑똑한 모델이었다면, 이 업그레이드는 당신을 위해 만들어진 것이 아니며, gemini-3.5-flash에 머물러도 그 축에서는 아무것도 잃지 않습니다. 원한 것이 같은 품질의 작업을 절반의 시간에 더 낮은 단가로 끝내는 것이었다면, 출시된 것이 바로 그것입니다.

지식 중심에 관한 단서는 걱정 하나가 아니라 단계 하나를 더할 가치가 있습니다. 벤치마크 하나에서의 1.9포인트 이동은 이번 출시를 건너뛸 이유가 아니라, 당신 자신의 평가 세트를 확인하라는 신호입니다.

thinking 레벨이 모델보다 청구서를 더 크게 움직인다

위의 모든 공개 수치는 high thinking 레벨을 서술하지만, API 기본값은 medium입니다. 그 격차는 구매 결정을 바꿀 만큼 크므로, 우리는 출시 당일 자체 테스트를 돌렸습니다.
Gemini 3.6 Flash thinking 레벨은 최종 프로덕션 출력은 간결하게 유지하면서 추론 토큰을 단계적으로 더 많이 쌓아 간다
Gemini 3.6 Flash thinking 레벨은 최종 프로덕션 출력은 간결하게 유지하면서 추론 토큰을 단계적으로 더 많이 쌓아 간다
thinking 레벨은 모델 전환 자체보다 청구 출력을 더 크게 바꿀 수 있으므로, 프로덕션 팀은 이를 명시적으로 설정하고 평가해야 합니다.
설정: 세 그룹으로 나눈 9개 작업입니다. 인보이스·로그·상품 HTML에서의 구조화 추출, 시뮬레이션 도구를 상대로 3~5단계에 걸친 멀티턴 도구 호출, 그리고 버그 설명을 실행 가능한 패치로 바꿔야 하는 코드 위치 파악·수정입니다. 입력은 1,000에서 4,000 토큰 사이이므로 이 라운드는 장문맥 작업을 다루지 않습니다. 각 작업은 8개의 모델·thinking 레벨 조합 각각에 대해 3번씩, 총 216번 호출되었으며, OpenRouter를 통해 공급자를 Google AI Studio로 고정하여 직렬로 보냈습니다. 답변 토큰과 thinking 토큰은 따로 기록했고, 모든 것은 게이트웨이 자체 청구가 아니라 Google 표준 등급 정가로 계산했습니다. 샘플링 파라미터는 이제 아무 일도 하지 않으므로 설정하지 않았습니다.
구성답변 토큰thinking 토큰thinking 비중패스당 비용정답
3.6 Flash minimal1,16200%$0.01589/9
3.6 Flash low1,0561,09551%$0.02329/9
3.6 Flash medium (기본)1,0805,94485%$0.05989/9
3.6 Flash high1,0926,67986%$0.06539/9
3.5 Flash medium1,0785,82784%$0.06929/9
3.5 Flash high1,1137,18587%$0.08189/9

세 가지가 두드러집니다.

thinking 토큰이 곧 청구서입니다. mediumhigh에서 이들은 출력 측에서 지불하는 전체의 84%에서 87%를 차지합니다. 답변 길이는 표 전체에서 거의 움직이지 않습니다. 어느 모델을 고르느냐는, 어느 레벨을 고르느냐보다 비용에 훨씬 적게 영향을 줍니다.
minimal은 '덜 생각하기'가 아니라 '생각하지 않기'입니다. thinking 토큰이 정확히 0으로 돌아왔고, 패스 비용은 기본 medium보다 73.6% 낮았으며, 점수는 똑같이 9분의 9였습니다. 레벨을 한 번도 고르지 않아서 medium에 있는 것이라면, 그것이 당신이 쓸 수 있는 가장 큰 비용 레버이며, 이미 돌리고 있는 그 모델에서 작동합니다.
여기서 highmedium보다 겨우 9.3% 더 들었습니다. 추가 예산이 쓰이지 않았기 때문입니다. thinking이 5,944 토큰에서 6,679로 올랐을 뿐입니다. 이는 모델이 아니라 이 작업들에 관한 사실입니다. 더 어려운 작업에서는 이 격차가 벌어집니다.

우리 수치가 다른 독립 실측과 어긋나는 지점

aibenchy는 출시 후 22개의 짧은 벤치마크 문항을 돌려, 신규 모델이 medium에서 29.4% 더 비싸고 high에서 9.7% 더 싸다고 밝혔습니다. 우리는 두 레벨 모두에서 각각 13.6%와 20.1% 더 싸다고 봤습니다. high 결과는 방향이 일치하고, medium 결과는 정반대를 가리킵니다. 이유는 한 숫자에서 보입니다. 그들은 신규 모델이 medium에서 thinking을 66.2% 더 썼다고 측정했고, 우리는 2.0% 더 썼다고 측정했습니다.
그들의 결과가 틀렸다고 말하지는 않겠습니다. 두 작업 세트가 같은 질문에 정반대의 답을 냈고, 이것 자체가 가지고 갈 만한 발견입니다. 이 모델이 토큰을 아껴 주는지는 그것으로 무엇을 돌리는지에 달렸지, 모델 하나에 달린 것이 아닙니다. Google 자신의 '출력 토큰 17% 감소'는 thinking 레벨도 작업 세트도 지목하지 않으며, 그래서 어떤 워크로드에서는 재현되고 어떤 워크로드에서는 그렇지 않습니다.
이 테스트가 알려 줄 수 없는 것. 9개 작업은 품질로 레벨을 갈라놓을 만큼 어렵지 않았습니다. 모든 구성이 9분의 9를 기록했습니다. 그래서 이 숫자들은 어느 레벨을 돌릴지에 대한 비용 기반 권고는 뒷받침하지만, 품질이 떨어지기 시작하는 지점은 짚어 주지 못합니다. 반복 실행도 편차가 있었습니다. 같은 작업의 동일 실행 사이에서 thinking 토큰이 6%에서 51%까지 움직였고, 그래서 위 수치는 3회 평균입니다. 품질의 무릎(knee)을 찾기 위한 더 어려운 라운드가 별도로 진행 중이며, 결과가 나오면 이 페이지를 갱신하겠습니다.
실행에 옮길 부분은 간단합니다. 어느 모델을 돌리든, thinking 레벨을 명시적으로 설정하고, 벤치마크가 공개된 레벨이 아니라 실제로 돌리는 레벨로 비용을 계산하십시오.

Google이 신규 모델이 더 못한다고 말하는 두 가지

Google은 출시 게시물에서 두 가지 구체적 약점을 공개하며, 둘 다 같은 곳에 집중됩니다.
고치기 전에 탐색합니다. 이 모델은 3.5 Flash보다 코드를 바꾸기 전에 진단 패스를 먼저 돌리는 경향이 강합니다. 복잡한 작업에서는 이것이 정확도를 높입니다. 단순한 프런트엔드 작업에서는, 필요하지도 않았고 비용을 치르고 싶지도 않았던 여분의 탐색 단계를 만들어냅니다.
인간 평가자들은 구형 모델의 시각적 출력을 더 선호했습니다. 구체적으로 시각적 레이아웃과 스타일링 항목에서, 평가자들은 이전 모델을 더 좋아했습니다. Google이 밝힌 완화책은 스타일링을 모델의 기본값에 맡기지 말고 디자인 규칙을 프롬프트에 적어 넣으라는 것입니다.

모델 카드는 알려진 한계로 환각, 그리고 이따금 발생하는 느린 응답이나 타임아웃도 나열합니다.

이 중 어느 것도 업그레이드에 반대하는 근거가 아닙니다. 표면(surface)별로 결정을 나누라는 근거입니다. 에이전트 계층과 UI 생성 계층이 있다면, 그것들은 서로 다른 증거를 가진 서로 다른 워크로드이며, 같은 모델 ID를 돌려야 한다는 규칙은 어디에도 없습니다.

전환은 모델 문자열을 바꾸는 일이 아니다

이것이 팀들이 걸려 넘어지는 부분이며, 출시 당일의 '모델 이름만 바꾸면 된다'는 권고가 이제 틀린 이유입니다. 이번 출시부터, 그리고 명시적으로 그 이후의 모든 모델에 대해, 여러 파라미터의 동작이 바뀌었습니다. 전체 목록은 Google의 API 변경 로그에 있습니다. 프로덕션을 조용히 망가뜨리는 것은 아래와 같습니다.
temperature, top_p, top_k는 무시되며, 오류는 발생하지 않습니다. Google 문서는 향후 모델 세대가 HTTP 400을 반환할 것이라고 명시하지만, 오늘은 그 값들이 그냥 버려집니다. 추출이나 분류 파이프라인을 결정론적으로 유지하려고 temperature=0에 의존한다면, 그 보장은 로그 한 줄도, 예외도, 알림도 없이 사라집니다. 대체 방법은 규칙을 system instruction에 넣는 것입니다.
확인할 만한 2차적 버전이 있습니다. OpenRouter의 모델 메타데이터는 여전히 temperature, top_p, seed를 지원 파라미터로 나열하므로, 게이트웨이는 당신의 값을 받아 전달하고 모델은 그것을 무시합니다. 오늘 출력 품질을 개선하려고 temperature를 튜닝하는 사람은 no-op을 튜닝하고 있는 것입니다.
thinking_budgetthinking_level로 대체됩니다. 예전의 숫자형 예산이 문자열 열거형이 됩니다. 한 요청에 둘 다 보내면 400을 반환합니다.
더 작은 셋. candidate_count는 Gemini 3.x에서 지원되지 않습니다. 마지막 메시지가 model 역할을 지닌 요청은 이제 400을 반환하며, 이로써 응답 프리필이 사라집니다. 그리고 이제 모든 FunctionResponsecall_idname을 모두 지녀야 합니다.
한 줄 한 줄 버전, 즉 Google 자체의 자동 마이그레이션 도구와 이 모델이 대체하는 모델들의 은퇴 일정을 포함한 내용은 Gemini 3.6 Flash 마이그레이션 가이드를 참고하십시오. 직접 검색한다면 한 가지 주의사항: 더 이른 Gemini 업그레이드를 위해 쓰인 가이드들은, 우리 자신의 Gemini 3 Flash Preview에서 Gemini 3.5 Flash로 이전 글을 포함해, 여전히 샘플링 파라미터가 동작한다고 서술합니다. 그 모델 쌍에서는 실제로 동작했기 때문입니다. 위의 폐기들은 이 세대부터 시작됩니다.
두 모델을 나란히 테스트하는 것에 대한 실용적 메모: 두 모델 ID 모두 EvoLink의 하나의 OpenAI 호환 엔드포인트를 통해 노출되므로, base_url을 하나의 게이트웨이로 지정하고 모델 문자열만 바꿔 두 번째 통합을 먼저 세우지 않고도 당신의 프롬프트로 A/B 할 수 있습니다. 그것이 위의 지식 중심·UI 질문을 당신 자신의 트래픽에 대해 답하는 가장 저렴한 방법입니다.

스위치를 넘기기 전에

공개된 숫자들은 질문을 좁혀 줍니다. 네 가지 측정이 그것을 닫습니다.

  1. 답변 토큰과 thinking 토큰을 따로 기록하십시오. 총 토큰 지표는 청구서가 왜 움직였는지 알려 주지 못합니다. 두 구성요소 중 이 모델들 사이에서 다르게 행동하는 것은 하나뿐이기 때문입니다.
  2. thinking 레벨을 명시적으로 고정하십시오. 실수로 medium을 물려받지 말고, 공개 벤치마크가 쓴 high 레벨이 아니라 실제로 돌리는 레벨로 비용을 계산하십시오. 우리 작업 세트에서는 이것이 모델 변경보다 값어치가 있었습니다. minimal은 같은 정확도에서 기본 medium보다 73.6% 저렴했습니다. 같은 결과를 가정하기 전에, 당신 자신의 작업이 그것을 견디는지 확인하십시오.
  3. 벤치마크 세트가 아니라 당신의 실제 프롬프트 조합으로 섀도런하십시오. 트래픽이 지식 중심이라면 이것이 가장 중요합니다. 비교 가능한 점수가 하락한 유일한 축이 바로 그것이기 때문입니다.
  4. 전환하기 전에 grep 하십시오. 코드베이스에서 temperature, top_p, top_k, thinking_budget, candidate_count를 검색하십시오. 앞의 셋은 조용히 실패하므로, 테스트는 통과하고 출력은 드리프트합니다.

FAQ

Gemini 3.6 Flash는 이름만 바꾼 Gemini 3.5 Pro인가요? 출시 후 그런 추측이 돌았습니다. 커뮤니티에서 가장 많은 표를 받은 답변은, Pro 모델의 이름을 바꿨다는 어떤 징후도 없으며 이것은 Flash 업그레이드라고 주장하며 그것을 부정했습니다. 모델 카드도 그 해석을 뒷받침합니다. 모델이 Gemini 3.5 Flash 위에 지어졌다고 명시하기 때문입니다. 우리는 이 추측을 기록할 뿐, 지지하지는 않습니다.
gemini-3.5-flash는 종료되나요? Google이 공지한 은퇴 날짜는 gemini-2.5-flashgemini-2.5-flash-lite가 2026-10-16, gemini-3.1-flash-lite가 2027-05-07입니다. 2026-07-21에 출시된 모델들에는 은퇴 날짜가 공지되지 않았습니다. 이 결정을 강제하는 공지된 마감일이 없으므로, 시간을 들여 측정할 수 있습니다.
입력 가격이 올랐나요? 아니요. 두 모델 모두 표준 등급에서 입력 100만 토큰당 $1.50을 청구합니다. 바뀐 것은 출력 가격뿐으로, $9.00에서 $7.50이 되었습니다.
결정론적 출력을 위해 temperature=0을 계속 쓸 수 있나요? 아니요. 그리고 이것이 주시해야 할 실패 방식입니다. 이 파라미터는 오류 없이 받아들여진 뒤 무시됩니다. 제약을 system instruction으로 옮기고, 요청이 아니라 출력을 검증하십시오.
3.6 Flash는 RAG에서 의미 있게 더 저렴한가요? 출력 토큰 1개당 대략 입력 토큰 20개에서, 공개 수치는 7.1% 절감을 함의합니다. 실제이지만 작습니다. 청구서의 입력 쪽이 바뀌지 않았기 때문입니다. 그것을 추정치가 아니라 상한으로 취급하십시오. 우리 자신의 작업에서는 실효 절감이 같은 산술이 예측한 것보다 낮게 나왔고, 우리 테스트는 장문맥 검색을 전혀 다루지 않았습니다. RAG 팀은 이번 출시를 우선 지연 개선으로, 그다음에야 비용 개선으로 취급해야 합니다.
어떤 모델 ID를 써야 하나요? gemini-3.6-flash입니다. 안정 버전이 하나뿐이며, preview 접미사도, 골라야 할 날짜 표기 변형도 없습니다.

출처

AI 비용을 89% 절감할 준비가 되셨나요?

오늘 EvoLink를 시작하고 지능형 API 라우팅의 힘을 경험해보세요.