Gemini API: jakie rozmiary plików i metody wprowadzania są obecnie obsługiwane?

12 stycznia 2026 r. Google opublikowało aktualizację deweloperską Gemini API, która zmienia sposób wprowadzania plików do modelu oraz ich dopuszczalne rozmiary. W skrócie: Gemini potrafi teraz pobierać pliki bezpośrednio z zewnętrznych linków i chmur (więc nie zawsze musisz je przesyłać), a limit rozmiaru plików przesyłanych inline został znacząco podniesiony. Te aktualizacje usuwają tarcia w realnych aplikacjach, które już przechowują multimedia lub dokumenty w zasobnikach chmurowych, oraz przyspieszają i obniżają koszty krótkich procesów prototypowania i produkcyjnych.

CometAPI udostępnia Gemini API, m.in. Gemini 3 Pro i gemini 3 flash, i oferuje atrakcyjne ceny.

Kluczowe aktualizacje — co nowego w Gemini API?

Bezpośrednie odczytywanie zewnętrznych linków do plików
— Gemini może pobierać pliki z:
- Publicznych adresów HTTPS oraz podpisanych adresów URL (S3 presigned URLs, Azure SAS itd.).
- Rejestracji obiektów w Google Cloud Storage (GCS) (zarejestruj obiekt GCS raz i używaj wielokrotnie).
Zwiększony rozmiar plików inline — limity ładunku przesyłanego inline (w żądaniu) wzrosły z 20 MB → 100 MB (uwaga: niektóre typy plików, jak PDF, mogą mieć nieco inne efektywne limity podane w dokumentacji).
Files API i wytyczne wsadowe bez zmian dla bardzo dużych plików — dla plików przeznaczonych do ponownego użycia lub większych niż limity inline/zewnętrzne nadal używaj Files API (maks. 2 GB na plik, projekty mogą przechowywać do 20 GB w Files API; przesłane pliki są domyślnie przechowywane przez 48 godzin). Rejestracja GCS również obsługuje duże pliki (2 GB na plik) i może być zarejestrowana do ponownego użycia.
Uwagi dot. kompatybilności modeli — niektóre starsze rodziny modeli lub wyspecjalizowane warianty mogą mieć różne wsparcie (dokumentacja wskazuje wyjątki, np. niektóre modele rodziny Gemini 2.0 dla pewnych przepływów z URI plików). Zawsze sprawdzaj dokumentację modelu przed wysyłaniem dużych zasobów.

Dlaczego zmiany w obsłudze plików przez Gemini API mają znaczenie?

Przed tą aktualizacją, jeśli chciałeś, aby Gemini API (model Google) analizował pliki, takie jak: raport PDF, wideo, plik audio lub obrazy, najpierw musiałeś przesłać te pliki do tymczasowej pamięci Gemini.

przesłane pliki były usuwane po 48 godzinach;
pliki nie mogły być zbyt duże (maksimum 20 MB);
jeśli Twoje pliki były już hostowane w chmurze (takiej jak GCS, S3 lub Azure), musiałeś je ponownie przesyłać — bardzo niewygodne.

To podwajało wysiłek dewelopera, zwiększało koszty transferu, wprowadzało opóźnienia i czasem czyniło realne przypadki użycia (długie nagrania, wielostronicowe instrukcje, obrazy wysokiej rozdzielczości) niepraktycznymi. Połączenie większych ładunków inline oraz możliwości skierowania Gemini do istniejących zasobów (przez publiczne lub podpisane URL-e albo zarejestrowane obiekty GCS) dramatycznie skraca drogę od „danych” do „użytecznego wyniku modelu”:

Zero-Copy Efficiency: Pozwalając Gemini czytać bezpośrednio z istniejących zasobników (GCS) lub zewnętrznych URL-i (AWS S3, Azure), eliminujesz „podatek ETL”. Nie musisz już pobierać pliku na backend, by następnie przesyłać go do Google. Model podchodzi do danych, a nie odwrotnie.
Bezstanowa architektura: Zwiększony limit 100 MB dla danych inline umożliwia potężniejsze, „bezstanowe” żądania. Nie musisz zarządzać cyklem życia identyfikatora pliku ani sprzątać starych uploadów przy każdej interakcji.
Agnostyczność multi‑cloud: Obsługa podpisanych URL-i pozwala Gemini API dobrze współpracować z jeziorami danych hostowanymi na AWS lub Azure. To ogromna korzyść dla przedsiębiorstw z podejściem multi‑cloud, umożliwiająca korzystanie z możliwości rozumowania Gemini bez migracji całej infrastruktury storage do Google Cloud.
Odpowiednie dla multimodalnych aplikacji AI (takich jak wideo, głos i rozumienie dokumentów).

Te aktualizacje znacząco upraszczają proces wprowadzania danych, umożliwiając deweloperom bezpośredni dostęp do istniejących danych z chmury lub sieci w Gemini bez dodatkowych kroków uploadu.

Kto skorzysta najbardziej?

Zespoły produktowe budujące funkcje skupione na dokumentach (podsumowania, Q&A na podstawie instrukcji, przegląd umów).
Aplikacje media/rozrywka, które analizują obrazy, audio lub wideo już przechowywane w chmurze.
Przedsiębiorstwa z dużymi jeziorami danych w GCS, które chcą, by model odwoływał się do kanonicznych kopii zamiast je dublować.
Badacze i inżynierowie, którzy chcą prototypować na większych, rzeczywistych zbiorach danych bez budowania skomplikowanych potoków storage.

W skrócie: przejście od prototypu do produkcji staje się łatwiejsze i tańsze.

Jak duży plik możesz teraz przesłać do Gemini API?

Najważniejsza liczba to pięciokrotny wzrost natychmiastowej pojemności, ale prawdziwą historią jest elastyczność, którą to daje.

Jak duży plik możesz teraz przesłać do Gemini API różnymi metodami?

Inline w żądaniu (base64 lub Part.from_bytes): do 100 MB (50 MB dla niektórych przepływów specyficznych dla PDF). Użyj tego, gdy chcesz prostego, jednokrokowego przepływu i plik ma ≤100 MB.
Zewnętrzny HTTP / podpisany URL pobierany przez Gemini: do 100 MB (Gemini pobierze URL podczas przetwarzania). Użyj tego, aby uniknąć ponownego przesyłania zawartości z zewnętrznych chmur.
Files API (upload): do 2 GB na plik, pamięć plików w projekcie do 20 GB, pliki przechowywane 48 godzin. Użyj tego dla dużych plików, które będziesz ponownie wykorzystywać lub przekraczają limit 100 MB dla inline/URL zewnętrznego.
Rejestracja obiektu GCS: obsługuje do 2 GB na obiekt i jest przeznaczona dla dużych plików już hostowanych w Google Cloud; rejestracja pozwala na ponowne użycie bez powtórnych uploadów. Jednorazowa rejestracja może przyznać dostęp na ograniczony czas.

(Jaki dokładnie wybór podjąć zależy od rozmiaru pliku, częstotliwości ponownego użycia oraz tego, czy plik już znajduje się w storage w chmurze).

google-flie

Nowy standard 100 MB

Ze skutkiem natychmiastowym Gemini API zwiększa limit rozmiaru danych inline z 20 MB do 100 MB.

Wcześniej deweloperzy pracujący z obrazami wysokiej rozdzielczości, złożonymi umowami PDF czy średniej długości klipami audio często uderzali w sufit 20 MB. Zmuszało to do wdrażania złożonych obejść, takich jak dzielenie danych, obniżanie jakości mediów czy zarządzanie oddzielnym przepływem uploadu przez Files API nawet dla relatywnie niewielkich interakcji.

Dzięki nowemu limitowi 100 MB możesz teraz wysyłać znacznie większe ładunki bezpośrednio w żądaniu API (zakodowane base64). To kluczowe usprawnienie dla:

Aplikacji czasu rzeczywistego: Przetwarzanie 50‑megabajtowego wideo przesłanego przez użytkownika do natychmiastowej analizy sentymentu bez czekania na zakończenie asynchronicznego uploadu.
Szybkiego prototypowania: wrzucenie złożonego zbioru danych lub pełnej książki w PDF do kontekstu, by natychmiast przetestować strategię promptów.
Złożonej multimodalności: Wysyłanie kombinacji obrazów 4K i wysokiej jakości segmentów audio w jednej turze bez obaw o przekroczenie restrykcyjnego limitu.

Warto zauważyć, że choć limit danych inline wynosi 100 MB, zdolność Gemini API do przetwarzania ogromnych zbiorów danych (terabajty danych) pozostaje dostępna poprzez Files API i nowe wsparcie dla External Link, co w praktyce usuwa górną granicę dla ciężkich obciążeń.

Zalecany schemat decyzyjny

Jeśli plik ≤ 100 MB i preferujesz prostotę jednego żądania: użyj inline (Part.from_bytes lub dostarcz base64). Dobre do szybkich dem i funkcji bezserwerowych.
Jeśli plik ≤ 100 MB i już jest hostowany publicznie lub przez pre‑signed URL: przekaż file_uri (HTTPS lub podpisany URL). Nie wymaga uploadu.
Jeśli plik > 100 MB (i ≤ 2 GB) lub planujesz go wielokrotnie używać: zalecane Files API lub rejestracja obiektu GCS — ogranicza powtarzające się uploady i poprawia opóźnienia przy wielokrotnych generacjach.

Jak działa nowe wsparcie dla zewnętrznych linków do plików?

Najistotniejsza zmiana architektoniczna to możliwość „pobierania” danych przez samo Gemini API. Ta funkcja to bezpośrednie odczytywanie zewnętrznych linków do plików, obsługujące wbudowane źródła danych.

API może teraz pobierać dane bezpośrednio z URL-i. To wsparcie obejmuje dwa odrębne scenariusze:

(1) Wsparcie dla zewnętrznych URL-i (publiczne / podpisane):

Możesz teraz przekazać standardowy adres HTTPS wskazujący na plik (np. PDF, obraz lub wideo) bezpośrednio w żądaniu generacji.

Publiczne URL-e: Idealne do analizy treści już dostępnej w sieci, np. artykułu w PDF lub publicznie hostowanego obrazu.

Podpisane URL-e: To most dla przedsiębiorstw. Jeśli Twoje dane znajdują się w prywatnej kubie AWS S3 lub Azure Blob Storage, możesz wygenerować Pre‑Signed URL (tymczasowy link przyznający dostęp do odczytu). Gdy przekażesz ten URL Gemini, API bezpiecznie pobierze zawartość podczas przetwarzania. Oznacza to, że możesz użyć Gemini do analizy wrażliwych dokumentów przechowywanych w AWS bez trwałego przenoszenia ich na serwery Google.

Szanuje role Google Cloud IAM, co oznacza, że możesz kontrolować dostęp przy użyciu standardowych uprawnień „Storage Object Viewer”.

Korzyści: Brak pośrednich plików, lepsze bezpieczeństwo i wydajność, odpowiednie do pobierania danych między chmurami.

(2) Bezpośrednie połączenie z Google Cloud Storage (GCS):

Dla danych już znajdujących się w ekosystemie Google integracja jest jeszcze ściślejsza. Możesz teraz wykonać Rejestrację obiektu dla plików GCS.

Zamiast przesyłać, po prostu „rejestrujesz” URI gs:// obiektu.

Proces jest niemal natychmiastowy, ponieważ między Twoim klientem a API nie dochodzi do rzeczywistego transferu danych.

Jak korzystać z nowych funkcji? — Przykłady użycia (Python SDK)

Poniżej trzy praktyczne przykłady w Pythonie (synchroniczne), ilustrujące typowe wzorce: (A) bajty inline (z pliku lokalnego), (B) zewnętrzny HTTPS lub podpisany URL oraz (C) odwołanie do URI GCS (zarejestrowany obiekt). Fragmenty używają oficjalnego Google Gen AI Python SDK (google-genai). Dostosuj nazwy modeli, uwierzytelnianie i zmienne środowiskowe do swojego środowiska. Możesz użyć klucza API CometAPI, aby uzyskać dostęp do Gemini API — agregatora API AI oferującego tańsze ceny wywołań dla deweloperów.

Wymagania wstępne: pip install --upgrade google-genai oraz ustaw poświadczenia/zmienne środowiskowe (dla Developer API API_KEY, dla Vertex AI ustaw GOOGLE_GENAI_USE_VERTEXAI, GOOGLE_CLOUD_PROJECT, GOOGLE_CLOUD_LOCATION).

Przykład A: Bajty inline (plik lokalny → wysyłka do 100 MB)

# Example A: send a local file's bytes inline (suitable up to 100 MB)from google import genaifrom google.genai import types# Create client (Developer API)client = genai.Client(api_key="YOUR_GEMINI_API_KEY")MODEL = "gemini-2.5-flash"  # choose model; production models may differfile_path = "large_document.pdf"  # local file <= ~100 MBmime_type = "application/pdf"# Read bytes and create an inline Partwith open(file_path, "rb") as f:    data = f.read()part = types.Part.from_bytes(data=data, mime_type=mime_type)# Send the file inline with a textual promptresponse = client.models.generate_content(    model=MODEL,    contents=[        "Please summarize the attached document in one paragraph.",        part,    ],)print(response.text)client.close()

Uwagi: ten przykład używa Part.from_bytes(...), by osadzić bajty pliku. Ładunki inline są teraz dozwolone do ok. 100 MB. Jeśli przekroczysz ten limit, użyj podejścia z GCS lub Files API.

Przykład B: Zewnętrzny HTTPS / podpisany URL (Gemini pobiera ładunek)

# Example B: reference a public HTTPS URL or a signed URL (Gemini fetches it)from google import genaifrom google.genai import typesclient = genai.Client(api_key="YOUR_API_KEY")MODEL = "gemini-2.5-flash"# Public or signed URL to a PDF/image/audio/etc.external_url = "https://example.com/reports/quarterly_report.pdf"# or a pre-signed S3/Azure URL:# external_url = "https://s3.amazonaws.com/yourbucket/obj?X-Amz-..."part = types.Part.from_uri(file_uri=external_url, mime_type="application/pdf")response = client.models.generate_content(    model=MODEL,    contents=[        "Give me the three key takeaways from this report.",        part,    ],)print(response.text)client.close()

Uwagi: Gemini pobierze external_url w czasie obsługi żądania. Używaj podpisanych URL-i dla prywatnych dostawców chmur (AWS/Azure). Zewnętrzne pobieranie ma praktyczne limity rozmiaru/formatu (patrz dokumentacja).

Przykład C: Odwołanie bezpośrednio do obiektu GCS (gs://)

# Example C: reference a GCS file (ensure service account has storage access)from google import genaifrom google.genai import types# For Vertex AI usage, standard practice is to use ADC (Application Default Credentials)client = genai.Client(vertexai=True, project="your-project-id", location="us-central1")MODEL = "gemini-3-pro"  # example model idgcs_uri = "gcs://my-bucket/path/to/manual.pdf"part = types.Part.from_uri(file_uri=gcs_uri, mime_type="application/pdf")response = client.models.generate_content(    model=MODEL,    contents=[        "Extract the section titles from the attached manual and list them.",        part,    ],)print(response.text)client.close()

Uwagi: dostępy do GCS wymagają poprawnej konfiguracji IAM i konta usługi (uprawnienia viewer do obiektu, właściwe uwierzytelnienie). Gdy rejestrujesz lub referencjonujesz obiekty GCS, upewnij się, że środowisko uruchomieniowe (Vertex / ADC / konto usługi) ma niezbędne uprawnienia.

Ograniczenia i kwestie bezpieczeństwa

Ograniczenia rozmiaru i typu zawartości

Rozmiar pobierania zewnętrznego: pobieranie z zewnętrznych URL-i podlega opisanym limitom (w praktyce 100 MB na pobierany ładunek) oraz obsługiwanym typom MIME/treści. Jeśli potrzebujesz przekazać bardzo duże zasoby (wiele GB), użyj Files API lub innego potoku przetwarzania.

Files API vs inline vs zewnętrzny URL: kiedy czego używać

Inline (from_bytes) — najprostsze w przypadku pojedynczych, jednorazowych plików, gdy aplikacja ma już bajty i rozmiar ≤100 MB. Dobre do eksperymentów i małych usług.
Zewnętrzny URL / podpisany URL — najlepsze, gdy plik znajduje się gdzie indziej (S3, Azure, publiczna sieć); unikasz przenoszenia bajtów i redukujesz transfer. Używaj podpisanych URL-i dla prywatnych zasobów.
GCS / zarejestrowane obiekty — najlepsze, gdy dane są już w Google Cloud i potrzebujesz wzorca produkcyjnego ze stabilnymi referencjami i kontrolą IAM.
Files API — używaj do trwałych lub bardzo dużych plików, które chcesz ponownie wykorzystywać w wielu żądaniach; zwróć uwagę na limity na plik/projekt oraz zasady retencji/efemeryczności.

Bezpieczeństwo i prywatność

Podpisane URL-e: generuj je z ograniczonym czasem życia i zawężonymi uprawnieniami. Nie umieszczaj w żądaniach sekretów o długim czasie życia.
IAM i OAuth: dla bezpośredniego dostępu do GCS ustaw konta usług zgodnie z zasadą najmniejszych uprawnień (object viewer do odczytu). Przestrzegaj organizacyjnych praktyk rotacji kluczy i logowania.
Rezydencja danych i zgodność: gdy pozwalasz API pobierać treści zewnętrzne, upewnij się, że jest to zgodne z zasadami przetwarzania danych i wymaganiami regulacyjnymi (niektóre dane regulowane nie mogą być wysyłane do zewnętrznej usługi, nawet tymczasowo). Dostawca modelu może utrwalać metadane o żądaniach w logach — uwzględnij to w analizie prywatności.

Uwagi operacyjne

Tymczasowość Files API: pliki przesłane do Files API mogą być efemeryczne (historycznie 48 godzin); do długoterminowego przechowywania używaj GCS lub innych trwałych storage i odwołuj się do nich bezpośrednio.
Powtarzające się pobieranie: jeśli plik jest referencjonowany przez URL przy każdym żądaniu i używany często, możesz ponosić koszty powtórnych pobrań; rozważ cache’owanie lub zarejestrowanie kopii w GCS dla intensywnego użytku.

Jak to zmienia architekturę aplikacji — praktyczne przykłady

Przypadek użycia — asystent wiedzy pracujący na dokumentach

Jeśli prowadzisz wewnętrznego asystenta wiedzy, który czyta instrukcje produktów przechowywane w GCS, zarejestruj te obiekty GCS raz (lub odwołuj się przez gs://) i odpytuj je dynamicznie. Unikniesz ponownego przesyłania tych samych PDF-ów i uprościsz backend. Dla bardzo dużych instrukcji (>100 MB) użyj Files API/rejestracji GCS.

Przypadek użycia — mobilna aplikacja konsumencka wysyłająca zdjęcia

Dla aplikacji mobilnej, która wysyła obrazy do jednorazowego opisu, używaj bajtów inline dla małych obrazów (<100 MB). Utrzymasz prosty UX i unikniesz drugiego kroku uploadu. Jeśli użytkownicy będą ponownie używać lub udostępniać to samo zdjęcie, przechowaj je w GCS i przekaż gs:// lub podpisany URL.

Przypadek użycia — potoki transkrypcji audio

Krótkie notatki głosowe (<100 MB / < ~1 minuta w zależności od kodeka) można przekazać inline lub przez podpisany URL. Dla długich nagrań przesyłaj przez Files API i referencjonuj plik w kolejnych wywołaniach generate dla efektywnego ponownego użycia. Przepływy wideo/audio często mają dodatkowe najlepsze praktyki opisane w dokumentacji multimediów.

Podsumowanie

Aktualizacja Gemini API sprawia, że znacznie łatwiej jest włączać „istniejące” dane do przepływów generatywnej AI: bezpośrednie pobieranie z publicznych lub podpisanych URL-i oraz rejestracja GCS usuwa powszechny punkt tarcia operacyjnego, a skok z 20 MB → 100 MB dla ładunków inline daje inżynierom większą elastyczność w prostych, jednorazowych żądaniach. Dla długotrwałych, bardzo dużych lub wielokrotnie używanych plików nadal służy Files API (2 GB na plik, domyślnie 48 godzin przechowywania)

Aby zacząć, poznaj możliwości Gemini API przez CometAPI, Gemini 3 Pro i gemini 3 flash w Playground i zapoznaj się ze szczegółową instrukcją w API guide. Przed dostępem upewnij się, że zalogowałeś się do CometAPI i uzyskałeś klucz API. CometAPI oferuje ceny znacznie niższe niż oficjalne, aby ułatwić integrację.

Gotowy do działania?→ Bezpłatny okres próbny Gemini 3 Pro !