Gemini 3.6 Flash è un modello potente, veloce ed economico della famiglia Gemini 3. Progettato per offrire funzionalità agentiche di livello quasi Pro senza compromettere prestazioni o valore, il modello è ora disponibile a livello generale (GA) per gli sviluppatori che utilizzano l' API Gemini e per le aziende che utilizzano la piattaforma agentica Gemini Enterprise.
Questo documento illustra le novità di 3.6 Flash, come si inserisce nella famiglia di modelli Gemini, come eseguire la migrazione a 3.6 Flash e fornisce una guida rapida per l'utilizzo di 3.6 Flash.
Come si inserisce nella famiglia Gemini?
Gemini 3.6 Flash è il modello agentico principale della famiglia Gemini 3. Colma il divario tra i modelli Pro con ragionamento approfondito e i modelli Flash-Lite con throughput elevato. Rispetto a Gemini 3.5 Flash, 3.6 Flash offre una qualità notevolmente superiore nell'orchestrazione di strumenti in più passaggi, nel refactoring del codice full-stack e nel ragionamento visivo, utilizzando al contempo meno token e turni di ragionamento. Offre funzionalità di livello quasi Pro a velocità e prezzi Flash.
Specifiche e confronti dei modelli
La seguente tabella è un confronto che copre alcune delle specifiche tra 3.6 Flash, 3.5 Flash e 3.1 Pro:
| Gemini 3.6 Flash | Gemini 3.5 Flash | Gemini 3.1 Pro | |
|---|---|---|---|
| ID modello | gemini-3.6-flash |
gemini-3.5-flash |
gemini-3.1-pro-preview |
| Fase di lancio | GA | GA | Anteprima |
| Tipi di input | Testo, immagine, audio, video | Testo, immagine, audio, video | Testo, immagine, audio, video |
| Tipo/i di output | Testo | Testo | Testo |
| Finestra contestuale | 1.048.576 | 1.048.576 | 1.048.576 |
| Lunghezza massima del token di output | 65.536 | 65.536 | 65.536 |
| Aree geografiche supportate | Globale, multi-regione | Globale, multi-regione, Americhe, Europa, Asia Pacifico | Globale |
| Livelli di ragionamento supportati |
MINIMAL, LOW, MEDIUM, HIGH(predefinito: MEDIUM)
|
MINIMAL, LOW, MEDIUM, HIGH(predefinito: MEDIUM)
|
LOW, MEDIUM, HIGH(predefinito: HIGH)
|
| Scopo principale | Agentic Workflows ad alta efficienza, orchestrazione in più passaggi e programmazione full-stack | Attività bilanciate, chiamate agli strumenti e ragionamento intermedio | Ragionamento approfondito, attività di elevata complessità |
Per l'elenco completo delle funzionalità, degli strumenti e delle opzioni di consumo supportati, consulta la pagina del modello 3.6 Flash.
Novità di Gemini 3.6 Flash
3.6 Flash è ottimizzato per l'orchestrazione in più passaggi, il refactoring del codice full-stack e il ragionamento generale con un'efficienza dei token notevolmente migliore rispetto ai modelli precedenti.
Aggiornamenti delle funzionalità e delle prestazioni
Di seguito è riportato l'elenco delle modifiche apportate alle funzionalità e alle prestazioni di 3.6 Flash rispetto ai modelli precedenti:
- Riduzione dei token e dei turni: consuma meno token e completa i flussi di lavoro in più passaggi in meno passaggi di ragionamento e turni di conversazione rispetto a 3.5 Flash.
- Generazione di codice migliorata: produce codice più pulito con tassi di errori di compilazione e revisione inferiori negli ambienti di creazione di applicazioni, prototipazione, e agenti IDE.
- Riduzione della distorsione dell'azione: risolve le attività di diagnostica di sola lettura senza apportare modifiche non richieste allo spazio di lavoro o modificare lo stato prematuramente.
- Ragionamento multimodale e spaziale: offre prestazioni migliorate nell'interpretazione dei grafici , nella conversione di progetti visivi e nella generazione di layout web multi-elemento.
- Supporto per l'utilizzo del computer: supportato come strumento integrato per l'automazione dell'interfaccia utente agentica.
- Preferenza per lo stile dell'interfaccia utente: è più efficace nella creazione di codice funzionale, anche se i valutatori umani hanno notato una preferenza per i modelli precedenti per la presentazione frontend e il layout visivo. Questo problema può essere mitigato fornendo linee guida di progettazione esplicite.
Modifiche dei parametri comportamentali e delle API
Di seguito è riportato l'elenco delle modifiche apportate ai parametri comportamentali e delle API di 3.6 Flash rispetto ai modelli precedenti:
- Concisione dei passaggi: utilizza meno passaggi di ragionamento rispetto a 3.5 Flash. Sebbene ciò riduca la latenza e il costo del refactoring del codice e dei flussi di lavoro degli strumenti, può causare uscite anticipate nei follow-up conversazionali estesi in più turni in cui sono necessarie catene di iterazione più lunghe.
- Ispezione programmatica anticipata: preferisce eseguire script di codice di diagnostica
(
execute_code) per ispezionare i problemi prima di modificare lo stato più frequentemente rispetto a 3.5 Flash. Sebbene ciò migliori l'accuratezza della diagnostica nel refactoring backend complesso, a volte può comportare l'esecuzione di passaggi di ispezione esplorativa aggiuntivi in semplici attività di scripting e web frontend in cui la versione precedente generava il codice direttamente. - Impegno predefinito: mantiene il livello di impegno predefinito medio introdotto in 3.5 Flash.
- Nessuna sostituzione del campionamento: i valori personalizzati per
temperature,top-k, otop-pparametri non sono più supportati. L'impostazione di valori personalizzati verrà ignorata nella superficie dell'API. Utilizza invecethinking_levelo schemi JSON strutturati per controllare il determinismo dell'output. - Restrizioni relative alle penalità di frequenza e presenza: i valori personalizzati per questi parametri non sono più supportati. L'impostazione di questi parametri genererà un errore API attivo.
- Le richieste API in cui l'ultimo turno di input ha il ruolo "Modello" non sono supportate.
- I turni vuoti nella cronologia delle conversazioni vengono eliminati.
- Le firme di pensiero non valide ora generano errori.
- Chiamata di funzione rigorosa:
FunctionResponsedeve corrispondere rigorosamente aid,namee al conteggio di esecuzione dellaFunctionCallprecedente. Aggiungi le istruzioni in linea direttamente all'interno del testo della risposta della funzione, separate da due nuove righe (\n\n).
Guida rapida
Prima di iniziare, devi eseguire l'autenticazione ad Agent Platform utilizzando le credenziali predefinite dell'applicazione (ADC) o una chiave API. Per ulteriori informazioni, consulta la pagina Inizia a utilizzare la piattaforma agentica Gemini Enterprise.
Nei seguenti blocchi di codice, sostituisci PROJECT_ID con il tuo ID progetto.
Installazione
Assicurati di utilizzare l'SDK google-genai più recente:
pip install --upgrade google-genai
Richiesta di base
Python
from google import genai
client = genai.Client(enterprise=True, project="PROJECT_ID", location="global")
response = client.models.generate_content(
model="gemini-3.6-flash",
contents="How does AI work?",
)
print(response.text)
REST
curl -X POST \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://aiplatform.googleapis.com/v1/projects/PROJECT_ID/locations/global/publishers/google/models/gemini-3.6-flash:generateContent \
-d '{
"contents": {
"role": "USER",
"parts": { "text": "Why is the sky blue?" },
},
}'
Eseguire la migrazione a 3.6 Flash da 3.5 Flash o 3.1 Pro
Per eseguire la migrazione a 3.6 Flash da 3.5 Flash o 3.1 Pro, segui questi passaggi:
- Aggiorna l'ID modello: modifica la stringa del modello nelle chiamate API in
gemini-3.6-flash. - Adatta il codice alle nuove regole API della famiglia Gemini 3:
Gemini 3.6 Flash applica rigorosamente le regole dei parametri e le convenzioni API
stabilite nella famiglia Gemini 3:
- Rimuovi temperatura, Top-K e Top-P: rimuovi questi parametri personalizzati
dal payload. Sebbene non generino un errore, il modello li ignorerà completamente. Utilizza invece il parametro
thinking_levelo gli output strutturatijson_schemaper controllare il determinismo dell'output. - Rimuovi le penalità di frequenza e presenza: rimuovi eventuali configurazioni personalizzate per le penalità di frequenza o presenza per evitare che le chiamate API generino errori di runtime.
- Assicurati che l'integrazione della chat non tenti di precompilare il modello:
esamina gli array della cronologia dei messaggi per assicurarti che il payload dell'API non
termini con un turno utente o un turno modello vuoto. Se l'ultimo oggetto nell'array della cronologia è un ruolo "
model" (API GenerateContent) o un tipo "model_output" (API Interactions), ristruttura la sequenza per evitare di attivare un errore di convalida rigorosa. - Utilizza
thinking_level: rimuovi le istanze del parametrothinking_budgetritirato e utilizza invecethinking_level. - Applica le convenzioni di chiamata di funzione rigorose:
FunctionResponsedeve corrispondere rigorosamente aid,namee al conteggio di esecuzione della precedenteFunctionCall. Se devi aggiungere istruzioni in linea, inseriscile direttamente all'interno del testo della risposta della funzione, separate da due nuove righe (\n\n).
- Rimuovi temperatura, Top-K e Top-P: rimuovi questi parametri personalizzati
dal payload. Sebbene non generino un errore, il modello li ignorerà completamente. Utilizza invece il parametro
- Tieni conto delle modifiche del flusso di lavoro:
- Se la tua applicazione si basa su loop conversazionali in più turni, testa i flussi di lavoro per assicurarti che la nuova concisione dei passaggi del modello non attivi uscite premature.
- Se crei agenti di scripting di base o frontend, monitora le chiamate
execute_codeesplorative non necessarie a causa della nuova distorsione del modello verso l'ispezione programmatica anticipata.
Soluzioni alternative per i requisiti di testo pre-strumento
Se il prompt richiede al modello di generare testo strutturato (XLM, YAML, JSON,
e così via) (ad esempio, <UPDATE>...</UPDATE>) immediatamente prima di effettuare una chiamata allo strumento, la chiamata allo strumento potrebbe occasionalmente non riuscire con un errore Malformed_Function_Call. Per risolvere il problema, puoi utilizzare una delle seguenti soluzioni:
- (Consigliato) Chiedi al modello di inserire le note pre-strumento all'interno di una chiamata di funzione
update()dedicata anziché nel testo non elaborato. Per istruzioni dettagliate sull'implementazione, consulta la sezione successiva. - Chiedi al modello di scrivere le note come intestazioni Markdown (ad esempio,
# UPDATE,## PLAN) anziché come testo strutturato. - Non richiedere al modello di generare testo prima delle chiamate agli strumenti.
Soluzione consigliata: racchiudi le note di lavoro in una chiamata di funzione dedicata
Invece dell'istruzione originale:
Before calling a tool, in every response you MUST first output a single
`<UPDATE>` part as specified, don't skip this part or any of required sub-tags
within `<UPDATE>`.
Utilizza questa istruzione aggiornata:
Before calling any other tool, in every response you MUST first call `update`
with all required parameters (previous_step, plan, next_step, external).
Aggiorna tutti i riferimenti al vecchio formato XML <UPDATE> nella richiesta del cliente.
Poi aggiungi la dichiarazione di funzione corrispondente per la funzione di aggiornamento:
{
"name": "update",
"description": "Update working notes (previous step analysis, plan, next step, external note).",
"parameters": {
"type": "OBJECT",
"properties": {
"previous_step": {
"type": "STRING",
"description": "Key findings and outcomes since the previous step."
},
"plan": {
"type": "STRING",
"description": "The current status of the plan."
},
"next_step": {
"type": "STRING",
"description": "Brief explanation of the immediate next action according to the plan."
},
"external": {
"type": "STRING",
"description": "A short, plain-language note shown to the User about what you are ABOUT TO DO next."
}
},
"required": [
"previous_step",
"plan",
"next_step",
"external"
]
}
}
Il modello effettuerà due chiamate nello stesso passaggio: la chiamata update() che sostituisce l'XML strutturato e la chiamata di funzione effettiva che vuole effettuare.