Den 12. januar 2026 offentliggjorde Google en udvikleropdatering til Gemini API, som ændrer, hvordan du får filer ind i modellen, og hvor store de filer kan være. Kort fortalt: Gemini henter nu filer direkte fra eksterne links og cloud-lager (så du ikke altid behøver at uploade dem), og grænsen for inline-fil-størrelse er hævet markant. Disse opdateringer fjerner friktion for virkelige apps, der allerede gemmer medier eller dokumenter i cloud-buckets, og gør hurtig prototyping og produktionsarbejdsgange hurtigere og billigere.
CometAPI tilbyder Gemini API’er såsom ,Gemini 3 Pro og gemini 3 flash, og det har en attraktiv pris.
Væsentlige nyheder — hvad er nyt i Gemini API?
- Læser filer direkte fra eksterne links
— Gemini kan hente filer fra:- Offentlige HTTPS-URL’er og signerede URL’er (S3 forhåndssignerede URL’er, Azure SAS osv.).
- Google Cloud Storage (GCS) objekt-registrering (registrer et GCS-objekt én gang og genbrug det).
- Øget inline-fil-størrelse — grænserne for inline (i-forespørgsel) payload er flyttet fra 20 MB → 100 MB (bemærk: nogle filtyper, som PDF’er, kan have en lidt anderledes effektiv grænse angivet i dokumentationen).
- Files API og batch-vejledning uændret for meget store filer — For filer, du har tænkt dig at genbruge, eller filer, der er større end inline-/eksterne grænser, skal du fortsat bruge Files API (maks. 2 GB pr. fil, projekter kan have op til 20 GB Files API-lager; uploadede filer gemmes som standard i 48 timer). GCS-registrering understøtter også store filer (2 GB pr. fil) og kan registreres til genbrug.
- Bemærkninger om modelkompatibilitet — nogle ældre modelfamilier eller specialiserede varianter kan have forskellig støtte (dokumentationen nævner undtagelser som visse Gemini 2.0-familie-modeller for nogle file-URI-arbejdsgange). Bekræft altid model-specifik dokumentation, før du sender store aktiver.
Hvorfor betyder ændringerne i Gemini API’s filhåndtering noget?
Før denne opdatering, hvis du ville have Gemini API (Googles AI-model) til at analysere filer som: en PDF-rapport; en video; en lydfil; eller nogle billeder; skulle du først uploade filerne til Geminis midlertidige lager.
Og:
- uploadede filer blev slettet efter 48 timer;
- filer måtte ikke være for store (maksimalt 20 MB);
- hvis dine filer allerede var hostet i skyen (såsom GCS, S3 eller Azure), skulle du uploade dem igen — meget upraktisk.
Det fordoblede udviklerarbejdet, øgede båndbreddeomkostningerne, introducerede latenstid og gjorde nogle virkelige use cases (lange optagelser, manualer med mange sider, billeder i høj opløsning) upraktiske. Kombinationen af større inline-payloads plus muligheden for at pege Gemini mod eksisterende lager (via offentlige eller signerede URL’er eller registrerede GCS-objekter) forkorter dramatisk vejen fra “data” til “nyttigt modeloutput”:
- Zero-copy-effektivitet: Ved at lade Gemini læse direkte fra dine eksisterende storage-buckets (GCS) eller eksterne URL’er (AWS S3, Azure) eliminerer du “ETL-skatten”. Du behøver ikke længere downloade en fil til din backendserver for derefter at uploade den til Google. Modellen kommer til dataene, ikke omvendt.
- Tilstandsløs arkitektur: Den øgede 100 MB inline-grænse muliggør mere kraftfulde “stateless” forespørgsler. Du behøver ikke administrere livscyklussen for et file ID eller bekymre dig om oprydning af gamle uploads for hver interaktion.
- Multicloud-agnosticisme: Støtten til signerede URL’er gør, at Gemini API fungerer gnidningsløst med datalakes hostet på AWS eller Azure. Det er en stor gevinst for virksomheder med multicloud-strategier, der kan udnytte Geminis ræsonneringsevner uden at migrere hele deres lagringsinfrastruktur til Google Cloud.
- Velegnet til multimodale AI-applikationer (såsom video, tale og dokumentforståelse).
Disse opdateringer forenkler markant dataindsamlingsprocessen og gør det muligt for udviklere at tilgå eksisterende data direkte fra skyen eller netværket til Gemini uden ekstra uploadtrin.
Hvem har mest gavn?
- Produktteams, der bygger dokumentcentriske funktioner (resuméer, Q&A over manualer, kontraktgennemgang).
- Medie-/underholdningsapps, der analyserer billeder, lyd eller videoaktiver, som allerede er gemt i skyen.
- Virksomheder med store datalakes i GCS, som ønsker, at modellen refererer til kanoniske kopier i stedet for at duplikere dem.
- Forskere og ingeniører, der vil prototype med større, realistiske datasæt uden at bygge komplicerede lagerpipelines.
Kort sagt: fra prototype til produktion bliver nemmere og billigere.
Hvor stor en fil kan du uploade til Gemini API nu?
Det fremhævede tal er en femdobling af den umiddelbare kapacitet, men den virkelige historie ligger i den fleksibilitet, det giver.
Hvor stor en fil kan du uploade til Gemini API nu via forskellige metoder?
- Inline i en forespørgsel (base64 eller Part.from_bytes): op til 100 MB (50 MB for nogle PDF-specifikke arbejdsgange). Brug dette, når du vil have et simpelt flow i én forespørgsel, og filen er ≤100 MB.
- Ekstern HTTP / signerede URL’er hentet af Gemini: op til 100 MB (Gemini henter URL’en under behandlingen). Brug dette for at undgå genupload af indhold fra eksterne skyer.
- Files API (upload): op til 2 GB pr. fil, projektets Files-lager op til 20 GB, filer gemmes i 48 timer. Brug dette til store filer, som du vil genbruge, eller som overskrider 100 MB inline-/ekstern-grænsen.
- GCS-objektregistrering: understøtter op til 2 GB pr. objekt og er beregnet til store filer, der allerede er hostet i Google Cloud; registrering muliggør genbrug uden gentagne uploads. Engangsregistrering kan give adgang i en begrænset periode.
(Hvilket valg du træffer, afhænger af filstørrelse, genbrugsfrekvens og om filen allerede ligger i cloud-lager.)

Den nye 100 MB-standard
Med øjeblikkelig virkning har Gemini API øget filstørrelsesgrænsen for inline-data fra 20 MB til 100 MB.
Tidligere ramte udviklere, der arbejdede med billeder i høj opløsning, komplekse PDF-kontrakter eller lydklip af moderat længde, ofte 20 MB-loftet. Det tvang dem til at implementere komplekse workarounds, såsom at chunk’e data, nedskalere medier eller administrere et separat upload-flow via Files API, selv for relativt små interaktioner.
Med den nye 100 MB-grænse kan du nu sende betydeligt større payloads direkte i API-forespørgslen (base64-kodet). Det er en væsentlig forbedring for:
- Realtidsapplikationer: Behandle en 50 MB brugeruploadet video til øjeblikkelig sentimentsanalyse uden at vente på, at et asynkront uploadjob fuldføres.
- Hurtig prototyping: smide et komplekst datasæt eller en hel bog i PDF-format ind i kontekstvinduet for straks at teste en promptstrategi.
- Kompleks multimodalitet: Sende en kombination af 4K-billeder og højfidelitets-lydsegmenter i et enkelt turn uden at bekymre sig om at ramme en restriktiv grænse.
Det er vigtigt at bemærke, at mens den inline grænse er 100 MB, forbliver Gemini API’s kapacitet til at behandle massive datasæt (terabytes af data) tilgængelig via Files API og den nye eksterne link-understøttelse, hvilket i praksis fjerner den øvre grænse for tunge workloads.
Anbefalet beslutningsflow
- Hvis filen er ≤ 100 MB, og du foretrækker enkelhed i en enkelt forespørgsel: brug inline (Part.from_bytes eller angiv base64). Godt til hurtige demoer eller serverløse funktioner.
- Hvis filen er ≤ 100 MB og allerede er hostet et sted offentligt eller via en forhåndssigneret URL: videregiv file_uri (HTTPS eller signerede URL’er). Ingen upload nødvendig.
- Hvis filen er > 100 MB (og ≤ 2 GB), eller du forventer at genbruge den: Files API-upload eller GCS-objektregistrering anbefales — det reducerer gentagne uploads og forbedrer latenstid ved gentagne generationer.
Hvordan fungerer den nye understøttelse af eksterne fillinks?
Den mest betydningsfulde arkitektoniske ændring er, at Gemini API kan “hente” data på egen hånd. Denne funktionalitet er at læse eksterne fillinks direkte og understøtter indbyggede datakilder
API’en kan nu indtage data direkte fra URL’er. Denne understøttelse dækker to forskellige scenarier:
(1) Understøttelse af eksterne URL’er (offentlige / signerede URL’er):
Du kan nu videregive en standard HTTPS-URL, der peger på en fil (som en PDF, et billede eller en video) direkte i din genereringsforespørgsel.
Offentlige URL’er: Ideelt til at analysere indhold, der allerede ligger på det åbne web, såsom en nyhedsartikel-PDF eller et offentligt hostet billede.
Signerede URL’er: Dette er broen for virksomheder. Hvis dine data ligger i en privat AWS S3-bucket eller Azure Blob Storage, kan du generere en forhåndssigneret URL (et midlertidigt link, der giver læseadgang). Når du videregiver denne URL til Gemini, henter API’et sikkert indholdet under behandlingen. Det betyder, at du kan bruge Gemini til at analysere følsomme dokumenter, der er gemt i AWS, uden permanent at flytte dem til Googles servere.
Den respekterer Google Cloud IAM-roller, hvilket betyder, at du kan kontrollere adgang ved hjælp af standardtilladelserne “Storage Object Viewer”.
Fordele: Ingen behov for mellemliggende filer, hvilket forbedrer sikkerhed og ydeevne og er velegnet til datahentning på tværs af cloudenviroments.
(2) Direkte forbindelse til Google Cloud Storage (GCS):
For data, der allerede er i Googles økosystem, er integrationen endnu tættere. Du kan nu udføre Object Registration for GCS-filer.
I stedet for at uploade “registrerer” du blot filens gs://-URI.
Denne proces er næsten øjeblikkelig, fordi der ikke foregår nogen egentlig dataoverførsel mellem din klient og API’et.
Hvordan bruger du de nye funktioner? — Eksempler på brug (Python SDK)
Nedenfor er tre praktiske Python-eksempler (synkrone), der illustrerer de almindelige mønstre: (A) inline bytes (fra en lokal fil), (B) ekstern HTTPS eller signerede URL’er, og (C) reference til en GCS-URI (registreret objekt). Disse snippets bruger det officielle Google Gen AI Python SDK (google-genai). Justér modelnavne, godkendelse og miljøvariabler, så de passer til din opsætning. Du kan bruge CometAPI's API-nøgle til at tilgå Gemini API, en AI-API-aggregationsplatform, der tilbyder billigere API-kaldspriser for at hjælpe udviklere.
Forudsætning:
pip install --upgrade google-genaiog sæt dine legitimationsoplysninger / miljøvariabler (for Developer APIAPI_KEY, for Vertex AI sætGOOGLE_GENAI_USE_VERTEXAI,GOOGLE_CLOUD_PROJECT,GOOGLE_CLOUD_LOCATION).
Example A: Inline bytes (local file → send up to 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()
Bemærkninger: dette bruger Part.from_bytes(...) til at indlejre filbytes. Inline-payloads er nu tilladt op til ~100 MB. Hvis du overskrider dette, skal du bruge en GCS- eller Files API-tilgang.
Example B: External HTTPS / signed URL (Gemini fetches the payload)
# 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()
Bemærkninger: Gemini henter external_url på forespørgselstidspunktet. Brug signerede URL’er til private cloud-lagerudbydere (AWS/Azure). Eksterne hentninger har praktiske størrelses-/formatbegrænsninger (se dokumentationen).
Example C: Reference a GCS object (gs://) directly
# 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 = "gs://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()
Bemærkninger: GCS-adgang kræver korrekt IAM- og servicekonto-opsætning (object viewer-tilladelser, korrekt godkendelse). Når du registrerer eller refererer til GCS-objekter, skal du sikre, at runtime-miljøet (Vertex / ADC / servicekonto) har de nødvendige tilladelser.
Begrænsninger og sikkerhedsovervejelser
Størrelses- og content-type-begrænsninger
Størrelse for eksterne hentninger: hentning via ekstern URL er underlagt de dokumenterede grænser (i praksis 100 MB pr. hentet payload) og understøttede MIME-/indholdstyper. Hvis du skal videregive meget store aktiver (flere GB), skal du bruge Files API eller en anden behandlingspipeline.
Files API vs inline vs ekstern URL: hvornår bruger man hvad
- Inline (from_bytes) — det simpleste til enkeltstående filer, hvor din applikation allerede har bytes og størrelsen er ≤100 MB. Godt til eksperimenter og små tjenester.
- Ekstern URL / signerede URL’er — bedst når filen ligger et andet sted (S3, Azure, det offentlige web); undgår flytning af bytes og reducerer båndbredde. Brug signerede URL’er til private aktiver.
- GCS / registrerede objekter — bedst når dine data allerede er på Google Cloud, og du vil have et produktionsmønster med stabile referencer og IAM-kontroller.
- Files API — brug til vedvarende eller meget store filer, som du vil genbruge på tværs af flere forespørgsler; bemærk per-fil- og projektkvoter samt politikker for opbevaring/ephemeralitet.
Sikkerhed og privatliv
- Signerede URL’er: forhåndssignerede URL’er bør genereres med begrænset levetid og snævre tilladelser. Indsæt ikke langtidslevende hemmeligheder i forespørgsler.
- IAM & OAuth: for direkte adgang til GCS skal du sætte servicekonti op efter princippet om mindst privilegium (objectViewer for læseadgang). Følg din organisations bedste praksis for nøglerotation og logging.
- Dataophold & compliance: når du lader API’et hente eksternt indhold, skal du sikre, at det er i overensstemmelse med din datahåndtering og regulatoriske krav (nogle regulerede data må ikke sendes til en ekstern tjeneste, selv midlertidigt). Udbyderen kan persistere metadata om forespørgsler i logfiler — indregn det i din privatlivsanalyse.
Driftsmæssige forbehold
- Midlertidigt Files API-lager: filer, der uploades til Files API, kan være flygtige (historisk 48 timer); til langtidsopbevaring skal du bruge GCS eller andre holdbare lagre og referere dem direkte.
- Gentagne hentninger: hvis en fil refereres via URL i hver forespørgsel og bruges hyppigt, kan du få gentagen hentningsoverhead; overvej caching eller at registrere en GCS-kopi til hyppigt genbrug.
Hvordan dette ændrer app-arkitektur — praktiske eksempler
Use-case — dokumenttung vidensassistent
Hvis du kører en intern vidensassistent, der læser produktmanualer gemt i GCS, skal du registrere disse GCS-objekter én gang (eller pege med gs://-URI’er) og forespørge dem dynamisk. Det undgår at uploade de samme PDF’er igen og igen og gør din backend enklere. Brug Files API/GCS-registrering til meget store manualer (>100 MB).
Use-case — forbrugermobilapp, der sender fotos
For en mobilapp, der sender billeder til enkel billedtekstgenerering, skal du bruge inline bytes til små billeder (<100 MB). Det holder brugeroplevelsen enkel og undgår et ekstra uploadtrin. Hvis brugere vil genbruge eller dele det samme billede ofte, skal du gemme det i GCS og videregive en gs://- eller signerede URL i stedet.
Use-case — lydtranskriptionspipelines
Korte talebeskeder (<100 MB / < ~1 minut afhængigt af codec) kan videregives inline eller via signerede URL’er. For lange optagelser skal du uploade via Files API og referere til filen i efterfølgende generate-kald for effektiv genbrug. Video-/lydarbejdsgange har ofte yderligere bedste praksis i mediedokumentationen.
Konklusion
Googles Gemini API-opdatering gør det langt nemmere at bringe “eksisterende” data ind i generative AI-arbejdsgange: direkte hentning fra offentlige eller signerede URL’er og GCS-registrering fjerner et almindeligt operationelt friktionspunkt, og springet fra 20 MB → 100 MB for inline-payloads giver ingeniører mere fleksibilitet til enkle flows i én forespørgsel. For langlivede, meget store eller ofte genbrugte filer gælder stadig Files API (2 GB pr. fil, 48 timers standardopbevaring)
Kom i gang ved at udforske Gemini API via CometAPI ,Gemini 3 Pro og gemini 3 flash's funktioner i Playground, og konsulter API guide for detaljerede instruktioner. Før adgang skal du sikre, at du er logget ind på CometAPI og har fået en API-nøgle. CometAPI tilbyder en pris, der er langt lavere end den officielle pris, for at hjælpe dig med at integrere.
Klar til at komme i gang?→ Gratis prøve af Gemini 3 Pro !
