Un quota est une limite configurable ou allouée sur la quantité d'une ressource que vous pouvez utiliser, comme les créations d'agents ou les requêtes quotidiennes. Pour les abonnements basés sur le nombre de licences, les quotas sont automatiquement ajustés en fonction du nombre de licences achetées par votre organisation. Une limite est une contrainte système ou un seuil de capacité, comme la profondeur des sous-agents, la taille d'importation des fichiers ou le nombre de personnes avec lesquelles un agent peut être partagé. Les limites système sont des contraintes fixes, sauf indication explicite d'un paramètre d'administration ajustable.
Pour en savoir plus sur les quotas Gemini Enterprise globaux, la mise en commun entre les éditions et la tarification de l'utilisation avec paiement à l'usage au-delà du quota, consultez Quotas et utilisation avec paiement à l'usage.
Quotas basés sur les fonctionnalités et les éditions
La création et l'exécution d'agents dans Workflow Builder dépendent de votre édition Gemini Enterprise.
Quotas de création quotidiens
La création, la rédaction et l'enregistrement d'agents consomment un quota de création quotidien alloué par édition (discoveryengine.googleapis.com/agents_tier_enterprise_regional). Les quotas de création quotidiens sont mis en commun pour tous les utilisateurs disposant de licences pour cette édition dans un projet et un emplacement spécifiques, et sont réinitialisés tous les jours à minuit (heure du Pacifique).
Ce quota de création quotidien s'applique aux deux éléments suivants :
- Créer et rédiger des agents personnalisés dans Workflow Builder.
- Enregistrer des agents externes, personnalisés ou partenaires (tels que des agents A2A, des agents ADK ou des agents Dialogflow) auprès d'une instance d'application ou d'un moteur à l'aide de la console Google Cloud ou de l'API
agents.create.
| Édition | Quota de création quotidien | Description |
|---|---|---|
| Frontline Worker/Starter | 0 | Impossible de créer ou d'enregistrer des agents personnalisés. Les licences Frontline n'offrent aucun quota de création et ne contribuent pas au quota de création groupé du projet. Les utilisateurs ne peuvent exécuter que les agents partagés avec eux. |
| Standard | 1 agent par utilisateur et par jour (espace de stockage commun) | Mise en commun entre toutes les licences de l'édition Standard du projet et de l'emplacement. Par exemple, 100 licences permettent d'effectuer 100 opérations de création et d'enregistrement par jour pour le projet. |
| Plus | 10 agents par utilisateur et par jour (mutualisé) | Mise en commun entre tous les postes sous licence de l'édition Plus dans le projet et l'emplacement. Par exemple, 100 licences permettent d'effectuer 1 000 opérations de création et d'enregistrement par jour pour le projet. |
| Paiement à l'usage | Illimité | Aucune limite de création quotidienne. L'utilisation est facturée en fonction de la consommation des ressources sous-jacentes et du volume de requêtes. |
Pour en savoir plus sur la mise en commun, le calcul et la facturation des quotas pour l'utilisation avec paiement à l'usage au-delà du quota dans les différentes éditions, consultez Quotas et utilisation avec paiement à l'usage.
Limites de capacité des agents
Les limites suivantes régissent le nombre d'agents actifs pouvant exister dans une instance d'application :
| Ressource | Limite par défaut | Champ d'application | Description |
|---|---|---|---|
| Agents par utilisateur | 1 000 | Par compte utilisateur | Nombre maximal d'agents qu'un même utilisateur peut créer et posséder. |
| Agents par instance d'application | 10 000 | Par instance d'application | Nombre maximal total d'agents pouvant exister pour l'ensemble des utilisateurs d'une instance d'application. |
Limites de partage
Lorsque vous partagez un agent avec des collègues de votre organisation, les limites suivantes s'appliquent :
| Paramètre | Limite | Description |
|---|---|---|
| Nombre maximal de membres individuels par agent | 1 500 comptes individuels | Nombre maximal de comptes utilisateur individuels pouvant être ajoutés directement à la liste d'accès d'un agent. Appliqué par Google Cloud les stratégies d'autorisation IAM. |
| Assistance Google Groupes | Nombre total de membres illimité (1 groupe = 1 membre de la règle) | Le partage avec un groupe Google est comptabilisé comme un seul membre dans la limite de 1 500 membres de la règle. |
Comportement en cas d'erreur de limite de partage
Si vous tentez de partager un agent avec plus de 1 500 comptes utilisateur individuels, l'opération échoue et renvoie l'erreur suivante :
The number of members in the policy (1,501) is larger than the maximum allowed size 1,500.
Bonnes pratiques pour le partage à grande échelle
Pour partager un agent avec de grandes audiences (par exemple, des distributions à l'échelle d'une équipe, d'un service ou d'une organisation) sans atteindre la limite IAM de 1 500 membres :
- Demandez à l'administrateur de votre application d'activer le partage de groupe dans les commandes des fonctionnalités.
- Dans la boîte de dialogue de partage de l'agent, saisissez l'adresse e-mail d'un groupe Google ou d'un groupe Workspace (par exemple,
support-team@example.com) plutôt que des comptes utilisateur individuels. - Gérez l'appartenance à l'audience de manière dynamique dans le groupe Google. Tous les membres du groupe héritent automatiquement de l'accès sans modifier la stratégie IAM de l'agent.
Pour obtenir des instructions détaillées sur le partage et les niveaux d'autorisation, consultez Partager un agent de chat et Partager un workflow.
Limites de complexité du générateur de flux
Le canevas du générateur de flux applique des contraintes structurelles et de routage pour maintenir une faible latence d'exécution, assurer une orchestration déterministe et éviter les graphiques d'appels circulaires :
| Contrainte | Limite | Description |
|---|---|---|
| Profondeur du sous-agent | 1 niveau | Profondeur de flux à un seul niveau uniquement. Les sous-agents ne peuvent pas appeler d'autres sous-agents. Les hiérarchies imbriquées à plusieurs niveaux ne sont pas acceptées. |
| Sous-agents acheminés par la racine du chat | 50 sous-agents | Nombre maximal de sous-agents qu'un seul agent racine de chat peut évaluer et vers lesquels il peut acheminer des requêtes. |
| Nœuds par flux | 100 nœuds | Nombre total maximal de nœuds (y compris les nœuds de déclencheur, de condition, d'action, de sous-agent et human-in-the-loop) autorisés dans un même workflow. |
| Compétences par nœud | 20 compétences | Nombre maximal de compétences ou d'actions d'outil pouvant être associées à un seul nœud de flux. |
| Exécution simultanée de sous-agents | 1 sous-agent à la fois | Les exécutions de workflow évaluent et exécutent les sous-agents de manière séquentielle. L'exécution de branches parallèles sur plusieurs sous-agents n'est pas possible. |
Limites de la base de connaissances et de l'importation de fichiers
Les limites suivantes s'appliquent aux documents importés directement dans la base de connaissances d'un agent :
| Ressource | Limite | Description |
|---|---|---|
| Taille maximale du fichier | 20 Mo par fichier | Taille maximale d'un fichier individuel importé directement dans la base de connaissances d'un agent. |
| Nombre maximal de fichiers par agent | 100 fichiers | Nombre total maximal de fichiers pouvant être joints à un seul agent. |
| Nombre maximal de fichiers par lot d'importation | 10 fichiers | Nombre maximal de fichiers pouvant être sélectionnés et importés en une seule opération. |
| Nombre maximal de jetons de contexte combinés | 800 000 jetons |
Nombre maximal de jetons pour l'ensemble des fichiers de connaissances statiques associés à un agent, des fichiers importés directement dans une session de chat et de l'historique des conversations. Si vous dépassez cette limite de jetons, une erreur FILE_SIZE_TOO_LARGE ou Input too long est renvoyée, même si les fichiers individuels ne dépassent pas la limite de 20 Mo.
|
| Types de documents acceptés | PDF, DOCX, TXT, PPTX, CSV, XLSX, HTML et Markdown (.md). | |
Bonnes pratiques pour les documents volumineux et les feuilles de calcul comportant plusieurs feuilles
Lorsque vous configurez des sources de connaissances ou analysez des fichiers complexes dans votre agent, suivez ces consignes pour éviter les limites de jetons de contexte et les délais avant expiration du traitement :
- Utilisez un data store connecté (RAG) pour les grandes bibliothèques de documents statiques : Gemini Enterprise charge l'intégralité des fichiers que vous importez dans la section Connaissances d'un agent dans le contexte de la requête du modèle à chaque tour. Si vous joignez de nombreux fichiers ou des PDF denses (comme des manuels de plus de 100 pages), le nombre total de jetons peut dépasser la limite de contexte de 800 000 jetons ou entraîner des délais avant expiration de la génération. Ingérez plutôt les grandes bibliothèques de référence statiques dans un data store Gemini Enterprise connecté, qui segmente et indexe automatiquement les documents, et réservez l'importation directe de fichiers aux fichiers plus petits et spécifiques à la session.
- Divisez les PDF denses pour les importer directement : étant donné que Gemini Enterprise tokenise chaque page d'un PDF ainsi que son texte et sa présentation visuelle, un seul PDF de plusieurs centaines de pages peut consommer une grande partie du budget de jetons de session et augmenter la latence de raisonnement. Lorsque vous importez des PDF directement dans un agent ou une session de chat, divisez les documents volumineux en fichiers plus petits et spécifiques à un sujet.
- Classeurs Excel (
.xlsx) à plusieurs feuilles : lorsque vous importez un classeur.xlsxà plusieurs feuilles dans la section Connaissances d'un agent ou dans une session de chat, Gemini Enterprise convertit automatiquement chaque feuille de calcul en un tableau CSV individuel pour l'exécution de code Python. L'agent peut ainsi interroger, joindre et analyser les données de toutes les feuilles du classeur.
Capacité de stockage
Les fichiers importés et les documents indexés consomment de l'espace de stockage du pool de capacité de stockage de votre organisation. L'espace de stockage est mis en commun pour tous les utilisateurs d'un projet et d'un emplacement, quelle que soit l'édition :
- Frontline Worker/Starter : 2 Gio par utilisateur.
- Standard : 30 Gio par utilisateur.
- Plus : 75 Gio par utilisateur.
Si le contenu total stocké dépasse l'espace de stockage commun combiné pour vos licences, Google facture l'utilisation au-delà du quota selon un modèle de paiement à l'usage, à hauteur de 5 $ par Gio et par mois. Pour en savoir plus, consultez Quotas basés sur les fonctionnalités et les éditions.
Limites de planification de l'exécution
Les limites et contraintes opérationnelles suivantes s'appliquent aux planifications d'agents automatisés :
| Paramètre | Limite ou contrainte | Description |
|---|---|---|
| Compatibilité avec les emplacements | Multirégional uniquement | Les planifications d'exécution des agents ne sont disponibles que dans les déploiements multirégionaux (comme us ou eu). |
| Fréquences de récurrence | Horaire, quotidienne, hebdomadaire, mensuelle, annuelle | Intervalles configurables pour les déclencheurs d'exécution automatisés. |
| Période de validité des identifiants | 14 jours | Les agents programmés s'exécutent à l'aide des identifiants utilisateur délégués de l'auteur. Les identifiants expirent tous les 14 jours et doivent être actualisés manuellement dans Gemini Enterprise pour éviter que les programmations ne soient mises en pause. |
| Latence du délai d'exécution | Jusqu'à 5 minutes de retard | Les exécutions planifiées peuvent être retardées de cinq minutes au maximum, en fonction de la charge de la file d'attente du système. |
| Mise en pause de l'approbation (HITL) | Pause obligatoire sur les actions externes | Les exécutions programmées qui effectuent des actions affectant d'autres personnes (comme l'envoi d'e-mails ou la planification de réunions) sont automatiquement mises en pause pour examen et nécessitent l'approbation de l'utilisateur dans l'historique des discussions. |
Pour savoir comment configurer ou actualiser des planifications, consultez Planifier l'exécution d'un agent de chat.
Limites concernant les sources de données connectées et l'intégration
Les limites suivantes s'appliquent aux datastores connectés et aux intégrations tierces :
| Ressource | Limite par défaut | Description |
|---|---|---|
| Datastores par application | 100 datastores | Nombre maximal de datastores d'entreprise connectés par instance d'application. Peut être augmenté jusqu'à 500 en envoyant une demande d'augmentation de quota. |
| Connecteurs par agent | 100 connecteurs | Nombre maximal de connecteurs de données tiers associés à un seul agent. |
| Serveurs MCP par agent | 100 serveurs | Nombre maximal de serveurs MCP (Model Context Protocol) associés à un agent. |
| Agents de compétence par agent | 100 compétences | Nombre maximal d'agents de compétences modulaires référencés par un agent. |
Étapes suivantes
- Créer un workflow : créez des workflows personnalisés à l'aide du canevas du générateur de flux.
- Partager un agent de chat et Partager un workflow : gérez les autorisations d'accès et partagez des agents avec des membres de l'équipe ou des groupes Google.
- Planifier l'exécution d'un agent de chat : configurez des déclencheurs de récurrence automatisés toutes les heures, tous les jours ou toutes les semaines.
- Quotas et utilisation du paiement à l'usage : examinez les quotas de requêtes mutualisés à l'échelle de l'organisation, les limites d'indexation du stockage et la facturation du paiement à l'usage pour Gemini Enterprise.