I’m hitting consistent 429 RESOURCE_EXHAUSTED errors using
gemini-3.1-flash-image-preview on Vertex AI via the global endpoint on a new
GCP project with billing enabled.
Environment:
Model: gemini-3.1-flash-image-preview
Endpoint: global
Auth: service account with roles/aiplatform.user
SDK: google-genai with vertexai=True, location=‘global’
Load: 4 sequential generate_content requests per batch (image generation)
Problem:
The model works - I can get a successful response occasionally - but under
normal operation (4 requests in quick succession) I consistently hit 429 errors.
The errors appear immediately, not after sustained load, which suggests the
default DSQ allocation for this model on a new project is very low.
In the GCP Console Quotas page (IAM & Admin → Quotas, filtered by aiplatform.googleapis.com), there is no editable quota row for
gemini-3.1-flash-image-preview. The only row that appears for this model is a
System limit marked Unlimited for image input requests. There is no
generate_content RPM row I can edit.
This is a production-grade image generation pipeline for a commercial application. The quota limitation makes it impossible to operate even at minimal load - 4 sequential image generation requests per batch is the minimum viable throughput for this product. The current DSQ allocation effectively blocks any production use of this model on Vertex AI.
Questions:
What is the default DSQ allocation for gemini-3.1-flash-image-preview on
the global endpoint for new projects?
What is the correct process to request a guaranteed RPM allocation for this
preview model when no editable quota row is visible?
Is there a minimum billing threshold or project age requirement before an
editable quota row appears?
I have tried filtering by generate_content_requests_per_minute_per_project_per_base_model
and by image - no rows appear for this model.
What you are seeing is consistent with Dynamic Shared Quota, not necessarily a missing IAM permission or a quota-page bug.
DSQ does not give a documented fixed per-project RPM. The Unlimited system-limit row means there is no editable fixed quota for that metric; it does not mean reserved capacity. On pay-as-you-go, a 429 can simply mean that the shared pool had no capacity for that burst. I would not expect project age or additional billing spend by itself to make an editable RPM row appear.
I would handle it in this order:
Test the current gemini-3.1-flash-image model ID instead of the older -preview ID. Treat that as a migration check, not a capacity guarantee.
Keep the global endpoint, but queue the four jobs instead of sending them as one burst. Start with concurrency 1 or 2, retry only 429/5xx responses with truncated exponential backoff plus full jitter, cap the retry count, and keep an application-level idempotency key so an image job cannot be duplicated after a timeout.
Log the exact model ID, request ID, timestamp, input/output size and attempt number. That gives Cloud Support enough information to distinguish capacity exhaustion from a request-specific problem.
A quota-increase request applies only when the model uses an editable fixed quota. For guaranteed capacity, check Provisioned Throughput support and the estimator for the exact model/version. If that exact image model is not listed, there is no guaranteed RPM that can be unlocked merely by waiting for the project to age; use a supported model/version or contact Google Cloud sales/support about a supported reservation.
Google’s 429 guide makes the same distinction between pay-as-you-go shared capacity and Provisioned Throughput.
If the operational requirement is a separate provider path while you test Vertex capacity, this Nano Banana 2 integration page documents a third-party LaoZhang API route using OpenAI-compatible and Gemini-native requests. Its currently displayed rate is $0.055/call; verify the live docs and console charge before use. It is not Google, does not fix a Vertex quota, and does not guarantee upstream capacity.
Disclosure: I maintain the LaoZhang API documentation; Codex assisted with source checking and preparation of this reply.