Skip to main content

모델 카드

전체 가격 비교, 요청당 과금과 token 기반 과금의 차이, token 선택 조언은 Nano Banana Series Pricing를 참고하십시오.

크기 제어

  • 원본 이미지 비율을 따르려면: aspectRatio를 단순히 생략하십시오. 여러 이미지 편집 시나리오에서는 마지막 이미지의 크기가 우선합니다
  • 해상도 imageSize: 1K / 2K / 4K를 지원합니다
    • Nano Banana (Gen 1)은 1K만 지원합니다
    • Nano Banana 2는 512px를 추가합니다
    • Nano Banana 2 Lite는 1K만 지원합니다 (2K/4K/512px 미지원)
동일한 코드를 사용해 1세대 gemini-2.5-flash-image를 호출할 때는 반드시 imageSize 파라미터를 제거해야 합니다(2K / 4K를 지원하지 않기 때문입니다), 그렇지 않으면 호출이 실패합니다.

통합 방법

공식 문서

  • Google 공식 문서: ai.google.dev/gemini-api/docs/image-generation
  • APIYI와 통합하려면 request URL + KEY를 APIYI의 것으로만 바꾸면 됩니다. 나머지 모든 파라미터는 공식 문서와 동일합니다.

공식 상태 확인(업스트림 문제 진단)

Nano Banana 시리즈는 Google의 AIStudio / Gemini API 위에서 동작합니다. 드물게 흐릿한 2K / 4K 출력 실패는 통합 계층이 아니라 Google 측 문제일 수 있습니다. Google의 공식 상태 페이지를 직접 복사해서 방문해 보세요: aistudio.google.com/status. 예를 들어 2026년 6월 19일에 해당 페이지에는 “Issues with Nano Banana”가 표시되었습니다. Gemini API 및 AI Studio의 Nano Banana 2 / Pro에서 2K 또는 4K 해상도에서 문제가 있었습니다. 비슷한 증상이 보이면 먼저 공식 상태 페이지와 비교해서 업스트림 장애인지 빠르게 확인하십시오.
APIYI는 안정성을 위해 Nano Banana 시리즈를 이중 AIStudio + Vertex 채널로 운영합니다. 한쪽 공식 채널에 문제가 생기면 다른 쪽이 대신 서비스를 계속 제공할 수 있습니다.

엔드포인트 지원

  • 권장 엔드포인트(Gemini 네이티브): https://api.apiyi.com/v1beta/models/gemini-3-pro-image-preview:generateContent
  • OpenAI 호환 모드를 통한 호출을 지원합니다(참고: URL 업로드는 지원되지 않으며, 대신 Base64를 사용하십시오)
  • 지원하지 않습니다 /v1/image/generations

개발 형식(기본 권장)

  • [권장] Google 네이티브 엔드포인트 형식을 사용하십시오
  • 이미지: Base64로 업로드하고, 다운로드 후 재호스팅
  • 호출 방식: 동기식 멀티스레드 호출; 비동기 호출은 아직 지원되지 않습니다

입력 이미지 요구사항

  • 단일 이미지는 7MB를 초과할 수 없습니다(Google 규칙입니다). Google Cloud Storage를 통해 가져오는 경우 파일당 제한은 30MB입니다
  • 프롬프트당 최대 14개 이미지
  • 지원되는 MIME 유형: image/png, image/jpeg, image/webp, image/heic, image/heif (jpg 형식은 이미 APIYI에서 지원됩니다)
  • Base64 크기 증가: 이미지를 Base64로 변환하면 크기가 약 33.3% 증가합니다(7MB 이미지는 약 9.3MB가 됩니다)
  • APIYI 제한: 단일 요청에 업로드되는 이미지의 총 용량은 100MB 미만이어야 합니다. 모든 호출은 동기식이며, 과도하게 큰 페이로드는 메모리 급증을 유발할 수 있습니다
Google Gemini 3 Pro Image 공식 기술 사양 표: 단일 이미지 제한 7MB, 프롬프트당 최대 14개 이미지, 지원되는 가로세로 비율 및 MIME 유형

Google official technical specs: inline / console upload per-file limit is 7MB, supporting png/jpeg/webp/heic/heif

Base64 크기 계산: 7MB 원본 이미지는 4/3 비율로 인코딩하면 약 9.33MB입니다

Base64 encoding increases size by about 33.3%: a 7MB image is roughly equal to 9.3MB

모범 사례: API로 보내기 전에 이미지에 무손실 압축을 적용하여, 과도한 해상도로 인해 요청이 느려지는 것을 방지합니다. Google 공식 사양 참고 자료(직접 복사하여 방문하시기 바랍니다): docs.cloud.google.com/vertex-ai/generative-ai/docs/models/gemini/3-pro-image

URL 이미지 입력

Base64 외에도 Gemini 네이티브 엔드포인트는 이미지 URL(이미지 호스트 / OSS 주소)을 fileData.fileUri를 통해 직접 전달하는 것을 지원하므로, 로컬 인코딩이 필요하지 않습니다.
URL 업로드는 이미지 호스트와 OSS 주소에 대한 요구 사항이 엄격합니다: 주소가 글로벌 CDN에 있지 않으면(예: Tencent Cloud Object Storage는 기본적으로 중국 전용 CDN을 사용합니다), Google의 서버가 이미지에 접근하지 못할 가능성이 매우 높아 요청이 실패합니다(일반적인 증상: 출력에 이미지가 참조되지 않습니다).가능하면 더 안정적인 Base64 업로드를 우선 사용하십시오 — 플랫폼 관점에서 이는 가장 운영 투자가 많이 이루어진, 가장 신뢰할 수 있는 경로입니다.
URL 업로드는 Gemini 네이티브 엔드포인트에서만 작동합니다; OpenAI 호환 모드에서는 URL 업로드를 지원하지 않으며 Base64가 필요합니다.

Curl 예시 (파일 URI)

Python 예제 (fileUri)

fileData, mimeType, 및 fileUricamelCase여야 합니다(file_data / file_uri 아님); 그렇지 않으면 매개변수가 무시되고 이미지가 참조되지 않습니다.

과금 기본 사항 (중요)

  • 동기식 호출 지속 시간: Pro / 2 at 4K는 합리적인 생성 시간으로 약 30–150초가 소요됩니다
  • 타임아웃으로 연결이 끊겨도 과금됩니다: 예를 들어 생성에 120초가 걸리지만 클라이언트가 타임아웃을 100초로 설정하고 연결을 끊어도 여전히 과금됩니다
  • 429 / 503은 과금되지 않습니다: 실패한 요청은 과금되지 않습니다(저희는 고객이 너무 오래 기다리거나 이미지 없이 막혀 있지 않도록 하려고 합니다)
  • 콘텐츠 안전성 거부도 과금됩니다: 고객 입력에 콘텐츠 안전성 문제가 있어 Google이 이미지 생성을 거부하는 경우에도 status code 200은 여전히 과금됩니다 — 아래의 오류 처리와 보장 플랜을 참고하십시오

타임아웃 설정(중요)

4K 이미지 생성은 이미지 업로드, API 처리, Base64 이미지 다운로드와 같은 단계를 거치므로 전체적으로 더 오래 걸립니다(백엔드는 API 처리 시간 기준으로 과금합니다). 정상 조건에서는 4K에 약 50초(폴링 제외)가 걸리지만, 클라이언트가 타임아웃을 너무 짧게 설정하면 생성이 완료되기 전에 연결이 조기에 끊기며 오류를 보고합니다:
호출 로그: gemini-3-pro 4K 생성의 첫 바이트까지의 시간은 43초에서 61초입니다

Call logs: time-to-first-byte for 4K generation is about 43–61s, so the default 120s timeout is too tight

더 안전하게 사용하려면 해상도별로 타임아웃을 설정하는 것을 권장합니다:

멀티턴 대화형 편집(네이티브는 지원하지만 역방향 모델은 지원하지 않습니다)

Nano Banana 시리즈는 Gemini 네이티브 형식을 사용하며 진정한 대화형 멀티턴 편집을 지원합니다: 각 턴에서 생성된 이미지를 contents에 다시 추가하여 **role: "model" inlineData**로 만든 뒤, 다음 사용자 지시를 보냅니다. 모델은 전체 대화 기록을 바탕으로 편집하고 변경 사항을 누적합니다(예: 먼저 소파 색을 바꾸고, 그다음 액세서리를 추가하면 — 앞선 변경은 유지됩니다). 이는 “역방향” 이미지 모델과 근본적으로 다릅니다 — 통합하기 전에 이 점을 분명히 이해해야 합니다:
테스트 결과: 이전 이미지를 model 역할의 턴으로 다시 채워 넣으면 Nano Banana 2(gemini-3.1-flash-image-preview)가 편집을 계속 이어가고 변경 사항을 정확히 누적합니다. 반면 역방향 모델은 마지막 사용자 메시지의 참조 이미지만 읽으므로, 대화 기록을 유지해도 멀티턴에는 동작하지 않습니다.
최소 예제(각 출력을 동일한 contents에 다시 채워 넣기):
전체 자세한 내용(history-backfill 방식과 re-feed 방식, 기존 이미지에서 멀티턴을 시작하는 방법)은 이미지 편집 API · 멀티턴 대화형 편집에 있습니다.

응답에 가끔 여러 이미지가 포함되는 이유

gemini-3-pro-image를 호출하면, 로그에 간헐적으로 6000개 이상의 출력 token 항목(심지어 5자리 수도 관찰됨)과 일치하는 **단일 응답 내 여러 이미지 파트(테스트에서 2–10개 관찰)**를 볼 수 있습니다. 이는 이상 현상이 아닙니다. Google의 공식 문서에 따르면 Gemini 3 이미지 모델은 기본적으로 “추론”이 활성화되어 있으며(API에서 비활성화할 수 없음), 모델은 구도와 논리를 시험하기 위해 중간 이미지를 생성하고, 이러한 초안은 최종 버전과 함께 parts에 나타나며, “추론 안의 마지막 이미지가 최종 렌더링 이미지이기도 하다”고 명시합니다(공식 문서: ai.google.dev/gemini-api/docs/image-generation). 2026년 7월에 수행한 테스트를 기준으로 하면(Google 기본 generateContent 형식): 트리거는 image editing 자체가 아니라 prompt의 작업 복잡도입니다. 여러 이미지는 여전히 단일 candidate 안에 있으며(여러 candidate가 아님), 각 이미지는 완전한 이미지입니다. 이는 동일한 디자인의 연속 초안(같은 구도, 약간 다른 세부 사항)이며, 마지막 파트가 최종 버전입니다. 이러한 초안은 일반 이미지 파트로 반환되며(thoughtSignature 필드가 있고, thought: true 플래그는 없음), Google 문서는 Thinking이 최대 두 개의 중간 이미지만 생성한다고 설명하지만, 우리는 복잡한 작업에서 최대 10개까지 관찰했습니다. 과금 영향: 각 이미지는 고정 token 수로 과금됩니다(1K/2K 해상도에서는 이미지당 1120 token, 4K에서는 2000 token). 따라서 출력 token은 이미지 수에 정확히 비례하여 증가합니다. 로그에 간헐적으로 나타나는 6000개 이상의(극단적 경우 약 13.5k까지) output-token 항목은 단순히 4–10개 이미지 응답일 뿐이며, 과금 이상 현상이 아닙니다. 권장되는 후속 코드:
  • 항상 parts를 순회하십시오 — 응답당 이미지가 1개라고 가정하지 마십시오. 이미지별 카운팅 또는 저장 로직은 실제 part 수를 기준으로 해야 합니다
  • 하나만 필요할 때는 마지막 이미지를 사용하십시오: 앞선 초안은 세부 사항이 덜 완성되어 있고 품질이 약간 낮으므로 첫 번째 이미지를 선택하지 마십시오
  • prompt로 이미지 수를 제어하는 것은 대체로 효과가 없습니다(테스트에서 “이미지 1개만 출력” 지시가 무시됨) — 코드에서 처리하십시오
  • 여러 이미지 응답은 35–142초(1K 해상도 기준이며 이미지가 많을수록 더 길어짐)가 걸리며, 단일 이미지 응답보다 눈에 띄게 더 오래 걸립니다 — 위의 timeout 권장값(5분 이상)을 유지하십시오
usageMetadata 필드의 전체 분석(세부 정보와 합계의 차이, 거부 응답에서의 계산 특이점 등)과 더 많은 내용은 Usage Fields & Output Explained을 참조하십시오.

자주 묻는 질문

오류 처리 가이드

실패한 생성, 콘텐츠 검열 정책, 친화적인 프롬프트 전략을 진단하는 세 가지 핵심 지표

반드시 읽어야 할 일반 개발 질문

실패한 생성 문제 해결과 자주 묻는 질문

실패한 생성 보장 플랜

입력으로 인해 발생하지 않은 실패에 대해서는 실패한 요청 수에 따라 크레딧이 환급됩니다
전체 오류는 다음과 같습니다:
이는 대개 대용량 이미지 업로드로 인해 발생합니다 — 요청 본문이 너무 커져 연결이 끊어집니다. 다음 모범 사례를 따르십시오:
  • 이미지 수를 제한하십시오: 공식 규칙 내에서 유지하십시오(프롬프트당 최대 14장 이미지 — 위의 공식 사양을 참조하십시오).
  • 이미지당 크기를 제한하십시오: 각 이미지를 5MB 미만으로 유지하십시오 — 공식 이미지당 상한은 7MB이며, base64 인코딩은 크기를 대략 1/3 늘리므로 여유를 두십시오.
  • 업로드 전에 프런트엔드에서 압축하십시오: API로 보내기 전에 프런트엔드(또는 서버 측 릴레이)에서 이미지를 압축하십시오 — 일반적인 방식은 긴 변의 길이를 제한하고, JPEG/WebP로 변환하며, quality 파라미터를 조정하는 것입니다.
  • URL 입력으로 전환하십시오: Gemini 기본 형식은 fileData.fileUri을 통해 이미지 URL 전달을 지원하므로, 지나치게 큰 base64 요청 본문을 완전히 피할 수 있습니다 — 위의 URL 이미지 입력을 참조하십시오.

사용 사례

  • AI 채팅 클라이언트: Cherry Studio와 같은 클라이언트는 APIYI를 통해 직접 이미지를 생성하도록 구성할 수 있습니다
  • 생성 테스트: 채팅 클라이언트나 콘솔에서 모델 성능을 빠르게 확인할 수 있습니다

고급 요구사항

  • URL을 통해 이미지를 업로드하고 싶으십니까? Gemini 네이티브 엔드포인트는 fileData.fileUri를 통해 이미지 URL을 전달할 수 있습니다. 그러나 OpenAI 호환 모드는 URL 업로드를 지원하지 않으므로, 대신 Base64를 사용하십시오. 위의 URL 이미지 입력에서 코드 예제와 주의 사항을 확인하십시오.
  • 직접 다운로드 URL을 받고 싶으십니까(대신 Base64가 아니라)? NB-OSS 그룹을 사용하십시오 — Nano Banana OSS 그룹을 참조하십시오.