Gemini 3.6 Flash הוא מודל מהיר, חסכוני ומתקדם ממשפחת Gemini 3. המודל הזה נועד לספק יכולות אג'נטיות שקרובות לאלה של Pro, בלי להתפשר על הביצועים או על הערך. עכשיו הוא זמין לכלל המשתמשים (GA) – למפתחים שמשתמשים ב-Gemini API ולארגונים שמשתמשים ב-Gemini Enterprise Agent Platform.
במסמך הזה נסביר מה חדש ב-3.6 Flash, איך הוא משתלב במשפחת מודלי Gemini ואיך עוברים ל-3.6 Flash, וניתן מדריך למתחילים לשימוש ב-3.6 Flash.
איך הוא משתלב במשפחת Gemini?
Gemini 3.6 Flash הוא המודל העיקרי במשפחת Gemini 3 שמבוסס על סוכנים. הוא מגשר על הפער בין מודלים של Pro עם יכולות נימוק מעמיקות לבין מודלים של Flash-Lite עם תפוקה גבוהה. בהשוואה ל-Gemini 3.5 Flash, Gemini 3.6 Flash מספק איכות גבוהה משמעותית בתזמור כלים בכמה שלבים, בשכתוב קוד פול סטאק ובחשיבה חזותית, תוך שימוש בפחות טוקנים וסבבי חשיבה. הוא מציע יכולות שקרובות לרמת Pro, במהירות ובמחיר של Flash.
מפרטים והשוואות של מודלים
בטבלה הבאה מוצגת השוואה של חלק מהמפרטים בין 3.6 Flash, 3.5 Flash ו-3.1 Pro:
| Gemini 3.6 Flash | Gemini 3.5 Flash | Gemini 3.1 Pro | |
|---|---|---|---|
| מזהה המודל | gemini-3.6-flash |
gemini-3.5-flash |
gemini-3.1-pro-preview |
| שלב ההשקה | GA | GA | תצוגה מקדימה |
| סוגי קלט | טקסט, תמונה, אודיו, וידאו | טקסט, תמונה, אודיו, וידאו | טקסט, תמונה, אודיו, וידאו |
| סוגי הפלט | טקסט | טקסט | טקסט |
| חלון ההקשר | 1,048,576 | 1,048,576 | 1,048,576 |
| האורך המקסימלי של טוקן הפלט | 65,536 | 65,536 | 65,536 |
| אזורים נתמכים | גלובלי, מספר אזורים | גלובלי, מספר אזורים, אמריקה, אירופה, אסיה והאוקיינוס השקט | עולמי |
| רמות ההעמקה הנתמכות |
MINIMAL, LOW, MEDIUM, HIGH(ברירת מחדל: MEDIUM)
|
MINIMAL, LOW, MEDIUM, HIGH(ברירת מחדל: MEDIUM)
|
LOW, MEDIUM, HIGH(ברירת המחדל: HIGH)
|
| מיקוד ראשי | תהליכי עבודה אג'נטיים יעילים, תזמור מרובה שלבים ותכנות פול סטאק | משימות מאוזנות, קריאה לכלי וחשיבה בינונית | חשיבה מעמיקה, משימות מורכבות מאוד |
בדף של מודל 3.6 Flash מפורטת הרשימה המלאה של היכולות, הכלים ואפשרויות השימוש הנתמכים.
מה חדש ב-Gemini 3.6 Flash?
3.6 Flash עבר אופטימיזציה לתזמור בכמה שלבים, ארגון הקוד מחדש של פול סטאק והסקת מסקנות כללית, עם יעילות טוקנים משופרת משמעותית בהשוואה לגרסאות הקודמות.
עדכונים לגבי יכולות וביצועים
בהמשך מופיעה רשימת השינויים ביכולות ובביצועים של גרסה 3.6 Flash לעומת דגמים קודמים:
- הפחתה במספר הטוקנים והתורות: צורך פחות טוקנים ומשלים תהליכי עבודה בכמה שלבים בפחות שלבי חשיבה ותורות בשיחה בהשוואה ל-3.5 Flash.
- יצירת קוד משופרת: יצירת קוד נקי יותר עם שיעורים נמוכים יותר של כשלים בהידור ושינויים בסביבות של פיתוח אפליקציות, אב טיפוס וסוכני IDE.
- הטיה מופחתת לפעולה: פותר משימות אבחון לקריאה בלבד בלי לבצע עריכות לא רצויות בסביבת העבודה או לשנות את המצב לפני הזמן.
- חשיבה מרחבית ומולטי-מודאלית: ביצועים משופרים בפירוש תרשימים, בהמרת שרטוטים חזותיים וביצירת פריסות של אתרים עם כמה רכיבים.
- תמיכה בשימוש במחשב: נתמכת ככלי מובנה לאוטומציה של ממשק משתמש מבוסס-סוכן.
- העדפות לגבי סגנון ממשק המשתמש: המודל טוב יותר ביצירת קוד פונקציונלי, אבל בודקים אנושיים ציינו שהם מעדיפים את המודלים הקודמים להצגה של חזית האתר ולפריסה חזותית. כדי לצמצם את הבעיה הזו, אפשר לספק הנחיות עיצוב מפורשות.
שינויים בהתנהגות ובפרמטרים של ה-API
בהמשך מופיעה רשימה של שינויים בהתנהגות ובפרמטרים של API בגרסה 3.6 Flash לעומת דגמים קודמים:
- תמציתיות השלבים: משתמש בפחות שלבי נימוק בהשוואה ל-3.5 Flash. ההגדרה הזו מפחיתה את זמן האחזור ואת העלות של תהליכי עבודה של כלים ושל ארגון הקוד מחדש, אבל היא יכולה לגרום ליציאות מוקדמות במעקבים מורחבים של שיחות רב-שלביות, שבהן נדרשות שרשראות ארוכות יותר של איטרציות.
- בדיקה פרוגרמטית מראש: מעדיף להריץ סקריפטים של קוד אבחון (
execute_code) כדי לבדוק בעיות לפני שינוי המצב בתדירות גבוהה יותר מאשר ב-3.5 Flash. השינוי הזה משפר את הדיוק של האבחון בפעולות מורכבות של ארגון הקוד מחדש בקצה העורפי, אבל לפעמים הוא עלול לגרום להרצת שלבים נוספים של בדיקה ראשונית במשימות פשוטות של קוד אינטרנט וכתיבת סקריפטים בקצה הקדמי, שבהן הגרסה הקודמת הייתה יוצרת קוד ישירות. - מאמץ ברירת מחדל: ממשיך את רמת המאמץ הבינונית שמוגדרת כברירת מחדל ב-3.5 Flash.
- אין שינוי של ברירת המחדל לדגימה: ערכים מותאמים אישית לפרמטרים
temperature,top-kאוtop-pלא נתמכים יותר. הגדרת ערכים מותאמים אישית תתעלם מהם בממשק ה-API. במקום זאת, אפשר להשתמש ב-thinking_levelאו בסכימות JSON מובנות כדי לשלוט בדטרמיניזם של הפלט. - הגבלות על תדירות ועונש על נוכחות: אין יותר תמיכה בערכים מותאמים אישית לפרמטרים האלה. אם תגדירו אותם, תופיע שגיאת API פעילה.
- אין תמיכה בבקשות API שבהן התפקיד של תור הקלט האחרון הוא "מודל".
- תורות ריקים בהיסטוריית השיחות נמחקים.
- מעכשיו, חתימות מחשבה לא תקינות יגרמו לשגיאות.
- בקשה מחמירה להפעלת פונקציה:
FunctionResponseחייב להתאים באופן מחמיר ל-id, ל-nameולמספר ההפעלות שלFunctionCallהקודם. מוסיפים את ההוראות ישירות בתוך טקסט התגובה של הפונקציה, ומוודאים שהן מופרדות באמצעות שתי שורות חדשות (\n\n).
מדריך למתחילים
לפני שמתחילים, צריך לבצע אימות ב-Agent Platform באמצעות Application Default Credentials (ADC) או מפתח API. מידע נוסף זמין במאמר תחילת העבודה עם Gemini Enterprise Agent Platform.
בבלוקי הקוד הבאים, מחליפים את PROJECT_ID במזהה הפרויקט.
התקנה
חשוב לוודא שאתם משתמשים בגרסה העדכנית ביותר של ה-SDK של google-genai:
pip install --upgrade google-genai
בקשה בסיסית
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?" },
},
}'
מעבר ל-3.6 Flash מ-3.5 Flash או מ-3.1 Pro
כדי לעבור ל-3.6 Flash מ-3.5 Flash או מ-3.1 Pro, פועלים לפי השלבים הבאים:
- עדכון מזהה המודל: משנים את מחרוזת המודל בקריאות ל-API ל-
gemini-3.6-flash. - התאמת הקוד לכללי ה-API החדשים של משפחת Gemini 3:
Gemini 3.6 Flash אוכף באופן מחמיר את כללי הפרמטרים ואת מוסכמות ה-API שנקבעו בכל משפחת Gemini 3:
- הסרת הטמפרטורה, Top-K ו-Top-P: מסירים את הפרמטרים המותאמים אישית האלה מהמטען הייעודי (payload). המודל לא יציג שגיאה, אבל הוא יתעלם מהם לגמרי. במקום זאת, השתמשו בפרמטר
thinking_levelאו בפלט מובנה שלjson_schemaכדי לשלוט בדטרמיניזם של הפלט. - הסרת עונשים על תדירות ונוכחות: צריך להסיר את כל ההגדרות המותאמות אישית של עונשים על תדירות ונוכחות כדי למנוע שגיאות בזמן ריצה בקריאות ל-API.
- ודאו שהשילוב של הצ'אט לא מנסה למלא מראש את המודל:
בדקו את המערכים של היסטוריית ההודעות כדי לוודא שהמטען הייעודי (payload) של ה-API לא מסתיים בתור ריק של המשתמש או של המודל. אם האובייקט האחרון במערך ההיסטוריה הוא תפקיד "
model" (GenerateContent API) או סוג "model_output" (Interactions API), צריך לשנות את מבנה הרצף כדי למנוע שגיאת אימות מחמירה. - שימוש ב-
thinking_level: צריך להסיר מופעים של הפרמטרthinking_budgetשהוצא משימוש ולהשתמש ב-thinking_levelבמקומו. - החלת כללים מחמירים להפעלת פונקציות:
FunctionResponseחייב להתאים בדיוק ל-id, ל-nameולמספר הביצועים שלFunctionCallהקודם. אם אתם צריכים להוסיף הוראות בתוך השורה, הציבו אותן ישירות בתוך טקסט התגובה של הפונקציה, והפרידו ביניהן באמצעות שני מעברי שורה (\n\n).
- הסרת הטמפרטורה, Top-K ו-Top-P: מסירים את הפרמטרים המותאמים אישית האלה מהמטען הייעודי (payload). המודל לא יציג שגיאה, אבל הוא יתעלם מהם לגמרי. במקום זאת, השתמשו בפרמטר
- התאמה לשינויים בתהליכי העבודה:
- אם האפליקציה שלכם מסתמכת על לולאות שיחה מרובות, כדאי לבדוק את תהליכי העבודה כדי לוודא שהתמציתיות של השלב החדש במודל לא גורמת ליציאות מוקדמות.
- אם אתם בונים סוכנים של frontend או סוכנים בסיסיים של סקריפטים, כדאי לעקוב אחרי קריאות מיותרות של
execute_codeלצורך בדיקה, בגלל ההטיה החדשה של המודל כלפי בדיקה תוכניתית מראש.
פתרונות עקיפים לדרישות הטקסט שלפני הכלי
אם ההנחיה דורשת מהמודל להפיק טקסט מובנה (XLM, YAML, Json וכו') (לדוגמה, <UPDATE>...</UPDATE>) מיד לפני קריאה לפונקציה, יכול להיות שהקריאה לפונקציה תיכשל מדי פעם עם השגיאה Malformed_Function_Call. כדי לפתור את הבעיה, אפשר להשתמש באחד מהפתרונות החלופיים הבאים:
- (מומלץ) מנחים את המודל להוסיף את ההערות שלו לפני השימוש בכלי בתוך
update()בקשה להפעלת פונקציה ייעודית במקום בטקסט גולמי. בקטע הבא מפורטות הוראות להטמעה. - מנחים את המודל לכתוב הערות ככותרות Markdown (לדוגמה,
# UPDATE,## PLAN) במקום טקסט מובנה. - אל תדרשו מהמודל להפיק טקסט לפני קריאות לפונקציות.
הפתרון המומלץ: להוסיף את ההערות לפונקציה ייעודית
במקום ההוראה המקורית:
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>`.
משתמשים בהוראה המעודכנת הזו:
Before calling any other tool, in every response you MUST first call `update`
with all required parameters (previous_step, plan, next_step, external).
לעדכן את כל ההפניות לפורמט ה-XML הישן של <UPDATE> בבקשת הלקוח.
לאחר מכן, מוסיפים את הצהרת הפונקציה המתאימה לפונקציית העדכון:
{
"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"
]
}
}
המודל יבצע שתי קריאות באותו השלב: הקריאה update() שמחליפה את ה-XML המובנה, וקריאת הפונקציה בפועל שהוא רוצה לבצע.