Planificar las implementaciones de agentes de Copilot Studio en función de la capacidad de procesamiento y los límites de tasa

Los agentes de Copilot Studio preparados para producción necesitan más que las licencias y la planificación del volumen total de mensajes. También necesitan planeamiento del rendimiento. La planificación de la capacidad abarca la rapidez con la que llega el tráfico, qué servicios de la plataforma invoca la solución y qué límites se aplican al conjunto de la solución.

Este artículo ayuda a los arquitectos de soluciones, creadores y administradores de Power Platform a preparar implementaciones de Copilot Studio de gran volumen para el tráfico de producción, las pruebas de aceptación de usuario (UAT), las pruebas de carga, los escenarios de negocio a cliente (B2C) y las cargas de trabajo autónomas.

El aprovisionamiento de tarifas es independiente del aprovisionamiento de licencias

La planificación de producción de Copilot Studio tiene dos líneas de trabajo relacionadas pero separadas:

  • El aprovisionamiento de licencias abarca los derechos de uso comerciales y el consumo, como licencias, créditos, capacidad prepagada, paquetes de mensajes y facturación por consumo.
  • El aprovisionamiento de tasa se refiere a la rapidez con la que se puede procesar el tráfico antes de que se apliquen controles de limitación o de protección del servicio.

Note

Microsoft usa el término quotas para los límites de velocidad de Copilot Studio. En la terminología más amplia del sector, esta actividad de planificación a menudo se denomina aprovisionamiento de tasa. Revise los límites publicados, calcule las tasas de solicitud máximas y planee antes de que llegue el tráfico de producción.

El pago por uso puede aumentar los límites disponibles en comparación con las configuraciones de menor capacidad, pero el rendimiento no es infinito. Compruebe los límites actuales de Copilot Studio, las asignaciones de solicitudes de Power Platform, los límites de Power Automate, los límites de protección del servicio Dataverse, las reglas de limitación de los conectores y los límites de las API subyacentes.

¿Qué ocurre cuando se aplica una limitación de velocidad?

La limitación de velocidad es un mecanismo de protección del servicio. Protege los servicios compartidos de los patrones de tráfico que superan los límites publicados, los controles de ráfaga o la capacidad del servicio. El síntoma exacto depende del servicio limitado.

Cuando se alcanza un límite, la consecuencia es más que un problema de planificación. Las solicitudes se pueden limitar, retrasar, bloquear o rechazar. En los chats orientados al usuario, este comportamiento puede aparecer como una interrupción temporal del servicio. Por ejemplo, es posible que el usuario no pueda enviar el siguiente mensaje, no pueda recibir un mensaje de agente no disponible o de límite de uso, o que se produzca un error en un paso porque un flujo, un conector, una llamada a Dataverse, un servicio de inteligencia artificial o una API posterior alcanzó su límite.

Obtenga más información sobre los síntomas y mensajes de error específicos de Copilot Studio en Resolver errores de límite de uso en agentes.

Cómo se miden los límites de velocidad

Los límites de velocidad miden cuánto tráfico puede aceptar un servicio durante un período de tiempo específico. Piense en estas ventanas pormenorizadasmente: por minuto, por cinco minutos, por 10 minutos, por hora, por día, por semana y por mes. El volumen mensual o semanal permite estimar la demanda total, pero los intervalos más cortos son importantes para dimensionar la tasa, ya que la limitación de caudal suele deberse a picos de tráfico concentrado.

Por ejemplo, una empresa B2C podría recibir la mayoría del tráfico de agentes durante una única hora concreta de campaña. Su promedio semanal puede parecer bajo, pero esa única hora aun así puede generar suficiente presión sobre la capacidad de procesamiento como para provocar limitación del caudal o interrupciones del servicio. Un diseño que se ve seguro en el nivel semanal o mensual puede seguir superando los límites durante un pico de una hora.

Descripción del ámbito de los límites

Los límites no solo se aplican en el nivel de agente individual. Según el servicio, pueden aplicarse a nivel de entorno, de herramienta, de API, de conector, de canal o de servicio posterior.

Por ejemplo, en Copilot Studio, los límites de mensajes a agente se aplican por entorno de Dataverse. Al estimar el tráfico, incluye todas las fuentes que envían mensajes a los agentes en ese entorno, incluyendo canales orientados al usuario, integraciones, cargas de trabajo autónomas y habilidades de Azure Bot Service. Compruebe los valores y el ámbito actuales en Copilot Studio cuotas y límites.

Decida si el aprovisionamiento de tarifas se aplica a su agente

No todos los agentes necesitan un aprovisionamiento detallado de tarifas. Es poco probable que un agente interno de preguntas frecuentes, con una audiencia pequeña, un uso predecible y pocas o ninguna llamada a servicios posteriores, alcance los límites de tasa. El aprovisionamiento de capacidad cobra importancia cuando un agente podría superar los límites de solicitudes por minuto o por hora, incluso si su volumen mensual parece modesto.

Piense en el tráfico esperado al principio del proyecto, junto con el diseño de la solución. Antes de que comiencen las pruebas de aceptación de usuario (UAT) y las pruebas de carga, el equipo debe estar seguro de que el diseño del agente, el entorno, los servicios conectados y los sistemas de bajada pueden admitir el perfil de rendimiento esperado.

Esta guía es importante para los agentes de nivel empresarial más grandes y intensivos en los que el tráfico puede llegar a ráfagas, muchos usuarios o eventos pueden invocar al agente al mismo tiempo, o cada interacción depende de varios servicios de plataforma. También se puede aplicar a agentes más pequeños con patrones de uso concentrados, como una ventana de inicio breve, un evento de todo el departamento, un proceso programado o un flujo de trabajo que crea muchas solicitudes en unos minutos.

B2C y los agentes autónomos requieren una configuración anticipada de tarifas

Los agentes B2C orientados al cliente pueden recibir tráfico de campañas, sitios web públicos, portales de clientes, comunicaciones de incidentes, lanzamientos de productos o demanda estacional. Los agentes autónomos pueden generar tráfico de alta frecuencia a partir de programaciones, eventos, procesos en segundo plano o cuando llaman a varias herramientas y flujos de trabajo.

Tip

Considerar los casos de uso B2C y de uso autónomo como escenarios de aprovisionamiento de tarifas de primer nivel. Pueden generar tráfico de ráfaga, varias solicitudes simultáneas y actividad en segundo plano de alta frecuencia más rápido que muchas experiencias de chat orientadas a los empleados.

Utiliza periodos punta, no solo totales mensuales

Pregunte si el agente puede crear solicitudes concentradas en un minuto o hora. Un escenario más pequeño aún puede necesitar aprovisionamiento de capacidad si una prueba de carga, una campaña, una respuesta ante una interrupción o un desencadenador automatizado genera demasiados mensajes, llamadas a la IA generativa, acciones de flujo de trabajo, llamadas a conectores o solicitudes de Dataverse en el entorno en un breve intervalo de tiempo.

El volumen mensual es útil para estimar la demanda total, pero no es suficiente para el aprovisionamiento de capacidad. Convierta el uso esperado en ventanas de tiempo más pequeñas para poder comparar el diseño con solicitudes actuales por minuto (RPM), solicitudes por hora (RPH), ráfagas y límites diarios de las páginas vinculadas.

Cree un perfil de tráfico promedio y un perfil de tráfico máximo. Por ejemplo, si la mayoría del tráfico se produce cada día entre las 5 p. m. y las 6 p. m., el pico por hora debe reflejar esa concentración. La estimación diaria no necesita ser 24 veces la hora punta si el tráfico se concentra en una ventana.

Utiliza estas estimaciones para dimensionar y validar el diseño. Las estimaciones no bastan para justificar una solicitud para aumentar el rendimiento. Las solicitudes se revisan en relación con el tráfico observado de una fase piloto, tal y como se describe en Ejecutar una fase piloto antes de solicitar un aumento de rendimiento de capacidad.

¿Cuándo más puede producirse la limitación de velocidad?

La limitación también puede ocurrir cuando:

  • Un gran número de empleados usa el agente durante una ventana máxima predecible, como un evento o entrenamiento en todo el departamento.
  • Una campaña de marketing, interrupción, lanzamiento o evento empresarial programado crea un pico de tráfico corto.
  • Los flujos de Power Automate incluyen bucles, reintentos, paginación o flujos secundarios que aumentan el volumen de solicitudes.
  • La generación de informes, la auditoría, la exportación de telemetría o la captura de transcripciones se ejecuta sincrónicamente en la ruta de acceso de turno del usuario.
  • Varios agentes o cargas de trabajo comparten el mismo entorno, identidad, conector o capacidad de API de bajada.
  • Las pruebas de carga aumentan más rápido de lo que la arquitectura de producción o el proceso de soporte estaban preparados para soportar.

Dónde buscar los límites de velocidad pertinentes

Copilot Studio tiene sus propios límites y la ruta de acceso en tiempo de ejecución del agente puede incluir otros servicios con sus propios límites. Revise todos los límites pertinentes para los servicios que usa el agente.

límites de Copilot Studio

Área de aprovisionamiento de tarifa Qué buscar Dónde comprobar los valores actuales Cómo usarlo
Mensajes a un agente Límites actuales de RPM y RPH y alcance para los mensajes enviados al agente. Copilot Studio cuotas y límites Compare los mensajes esperados por minuto y por hora para el entorno de Dataverse de destino.
Mensajes de IA generativas Límite actual para la orquestación generativa, las acciones del agente, las herramientas de IA, las acciones de flujo de trabajo del agente y las respuestas generativas. Mensajes de IA generativos a un agente Modele escenarios con mucha inteligencia artificial y autónomos frente a los límites publicados actuales.
Nodos de desencadenador autónomos Límites actuales que se aplican cuando un agente autónomo se desencadena mediante eventos, programaciones o procesos en segundo plano. Copilot Studio cuotas y límites Modele cargas de trabajo programadas y controladas por eventos de forma independiente del tráfico de chat interactivo.
límites de solicitudes de suscripción de Copilot Studio Límites de solicitud actuales de Power Platform que se aplican al uso de Copilot Studio. límites de suscripción de Copilot Studio Use estos valores junto con el planeamiento del límite de velocidad para flujos, Dataverse y servicios conectados.

Otros límites de plataforma que se deben tener en cuenta

El límite más bajo de la ruta de acceso en tiempo de ejecución determina la experiencia del usuario. Un agente de Copilot Studio puede estar dentro de sus propios límites mientras se limita un flujo, un conector, una llamada a Dataverse, un servicio de lenguaje o una API externa.

Note

Otras limitaciones de la plataforma podrían afectar a su agente si utiliza otros componentes en la ruta de la solicitud del agente. Tenga en cuenta también estos límites, como los de Power Platform, Power Automate, Dataverse, los conectores, los servicios lingüísticos y los sistemas posteriores.

Área de tiempo de ejecución Qué revisar Preguntas sobre el aprovisionamiento de tarifas Dónde comprobar los límites actuales
Plano de solicitud de Power Platform Solicitudes en Power Automate, llamadas de flujo de trabajo de Copilot Studio, uso de Dataverse, Power Apps y Dynamics 365. ¿Qué usuario, conexión, usuario de aplicación o entidad de servicio genera las solicitudes? ¿Las asignaciones de solicitudes son suficientes para la carga de trabajo diaria y de pico esperada? Asignaciones y límites de solicitudes
Flujos de Power Automate Desencadenadores, acciones, bucles, flujos secundarios, acciones HTTP, acciones del conector, reintentos, paginación y simultaneidad. ¿Cuántas acciones se crean por turno de agente? ¿Se incluyen los límites de ráfaga, concurrencia, disparadores y conectores? Comprender los límites de la plataforma y evitar la reducción de velocidad
Límites de flujos automatizados, programados e instantáneos
Dataverse Operaciones CRUD, complementos, flujos de trabajo, operaciones de asignación o uso compartido, llamadas de conector y operaciones del sistema necesarias para completar transacciones. ¿Qué usuarios, usuarios de aplicaciones o entidades de servicio generan llamadas a Dataverse? ¿Es probable que se apliquen los límites de protección del servicio o el comportamiento de reintento? Límites de la API de protección de servicio
Información general sobre los límites de API de Dataverse
Connectors Conectores estándar, conectores prémium, conectores personalizados, limitación por conector y API posteriores. ¿Qué conector es el cuello de botella? ¿Aplica el servicio de bajada su propio límite de velocidad? Límites de rendimiento de API en conectores
Referencia del conector de Power Automate
Comprensión del lenguaje conversacional (CLU) y servicios de IA Llamadas CLU, avisos de IA, operaciones de búsqueda y resumen, herramientas respaldadas por modelos, tamaño de carga y límites específicos del servicio. ¿Cada intervención del usuario invoca un servicio lingüístico o de IA? ¿Se repiten esas llamadas durante los reintentos o la orquestación? Límites de la comprensión del lenguaje conversacional
Copilot Studio cuotas y límites
API externas y sistemas de línea de negocio API de proveedor, API internas, bases de datos, middleware, puertas de enlace y servicios personalizados. ¿Qué límite impone el propietario descendente? ¿Existe una estrategia de reintentos, una cola o una estrategia de retropresión? Utilice los límites actuales, el acuerdo de nivel de servicio (SLA) y el proceso de soporte del propietario del servicio dependiente.

Diseñar para reducir la presión sobre la capacidad de procesamiento

No haga de las subidas de tarifas su primera opción de diseño. En primer lugar, revise el diseño del agente y optimice la eficacia. Si el agente necesita buscar algo, mantenga las llamadas externas deliberadas, optimice las llamadas a la API y evite un volumen innecesario de solicitudes en Copilot Studio, Power Automate, Dataverse, conectores y sistemas posteriores.

Después de que el diseño sea eficaz, controle el rendimiento para que el tráfico llegue a la plataforma de una manera predecible:

  • En el caso de los límites de nivel de entorno, considere la posibilidad de dividir agentes en varios entornos si ese enfoque coincide con el diseño operativo. Este enfoque puede ayudar a evitar que los agentes de alto volumen, las unidades de negocio, las regiones o las cargas de trabajo autónomas compitan con cargas de trabajo no relacionadas por los mismos límites definidos para el entorno.
  • Para los agentes autónomos, utilice colas, procesamiento por lotes, filtros de activación, procesamiento programado, controles de reintento y supervisión para que el trabajo en segundo plano no se acumule en una ráfaga descontrolada.
  • Traslade las tareas programadas, la generación de informes, la exportación de auditorías y la telemetría fuera del flujo del chat interactivo siempre que sea posible.
  • Revise los resultados de las pruebas de carga y la telemetría de producción para identificar dónde se concentran las solicitudes y, a continuación, optimizar el agente, los flujos, los conectores y las API de bajada antes de solicitar límites más altos.

Los agentes autónomos están especialmente bien situados para maximizar el uso de la capacidad que tienen asignada, con una sólida capacidad de predicción y observabilidad, poniendo en cola las solicitudes y controlando su frecuencia de activación.

Realiza una fase piloto antes de solicitar un aumento de rendimiento

Los límites por defecto se adaptan a la mayoría de los agentes de producción, incluidos los agentes que atienden a miles de usuarios activos mensuales. Antes de planificar un aumento de rendimiento, confirma que el agente realmente lo necesita.

Ir directamente a un lanzamiento a gran escala no es un patrón de despliegue soportado. Libera primero al agente a un subconjunto del público objetivo, observa el uso real y utiliza esas medidas para planificar el despliegue completo. Una fase piloto reduce el riesgo de lanzamiento y produce la evidencia que requiere una solicitud de aumento de rendimiento de producción.

Important

Las solicitudes de aumento de rendimiento se revisan en función del uso observado. Los volúmenes proyectados, las estimaciones producidas durante el diseño, las pequeñas pruebas de aceptación (UAT) y las pruebas de carga sintética no se aceptan como justificación por sí solos. Haz una fase piloto y envía los resultados medidos.

El uso real difiere rutinariamente de las estimaciones previas al lanzamiento. La duración de la sesión, los mensajes por sesión, la frecuencia con la que los usuarios acceden a respuestas o acciones generativas, el comportamiento de reintentos y el número de llamadas a flujo, conectores, Dataverse y API externas por turno son difíciles de predecir antes de que el agente esté en manos de usuarios reales. Un piloto pone de manifiesto los límites que importan y los patrones de tráfico que son difíciles de estimar de antemano.

Diseñar un piloto eficaz

Atributo piloto Guía
Público Lanzarlo a una gran sección representativa del público objetivo en lugar de a un proyecto o equipo de pruebas. El grupo piloto debería incluir los roles, regiones y casos de uso esperados a gran escala.
Duration Manténgalo en funcionamiento durante al menos una semana para que el piloto cubra un ciclo operativo completo, incluidos periodos punta conocidos, como cambios de turno, procesamiento de fin de mes, horarios de campaña o ejecuciones autónomas programadas.
Configuración Mantén la ruta de ejecución en producción: los mismos canales, temas, configuración de IA generativa, fuentes de conocimiento, acciones, flujos, conectores y sistemas downstream que utiliza el despliegue completo. El tráfico medido frente a un diseño reducido no extrapola de forma fiable.
Telemetry Activa los informes de analítica, Análisis de Aplicaciones y el centro de administración que necesitas antes de que comience el piloto, para que las sesiones, mensajes, llamadas de IA generativa y errores se capturen durante todo el periodo.

Medición durante el piloto

Captura los valores que se corresponden directamente con los límites de tasa publicados:

  • Mensajes por minuto y por hora, tanto en promedio como en picos.
  • Sesiones, sesiones concurrentes, duración de la sesión y mensajes por sesión.
  • Llamadas de IA generativa por turno y por sesión, incluyendo respuestas generativas, acciones de agentes y herramientas.
  • Acciones de Power Automate, llamadas de conector y solicitudes de Dataverse generadas por cada turno del agente.
  • Eventos de limitación de tasa, errores de límite de uso, reintentos y latencia durante los periodos de mayor carga del piloto.
  • El tamaño del público piloto, expresado como proporción del público objetivo total.

Extrapolar a la capacidad total

Escala las mediciones de pico observadas a toda la audiencia y documenta el método que has usado. Basa el escalado en el tráfico máximo durante el piloto, no en promedios diarios o semanales, porque el estrangulamiento se debe al tráfico concentrado. Ten en cuenta cualquier aspecto que el piloto no incluyó, como regiones adicionales, canales, cargas de trabajo autónomas o una campaña de lanzamiento que concentre más tráfico que durante el periodo piloto.

El resultado es una solicitud respaldada por datos: el tráfico medido en la prueba piloto, la proporción de la audiencia correspondiente a la prueba piloto, el método de extrapolación y el requisito máximo resultante a escala completa.

Qué hacer si los límites de velocidad predeterminados no son suficientes

Si el tráfico piloto observado muestra que el agente o cualquier servicio conectado supera los límites publicados actuales a gran escala, inicia el proceso de soporte para la provisión de tasas antes de ampliar el despliegue. No espere a que se produzca el primer error de producción.

Note

Copilot Studio es un servicio SaaS con límites de tarifa para proteger el servicio de todos los clientes. Con una justificación adecuada, la ingeniería puede habilitar límites personalizados para escenarios aprobados. Una justificación adecuada significa un uso medido desde una fase piloto, no una proyección.

Abrir una solicitud de soporte técnico

Los administradores pueden solicitar soporte técnico desde el Centro de administración de Power Platform.

Abre el ticket tras la fase piloto e incluye los resultados medidos junto con la extrapolación a capacidad total. Las solicitudes que solo contienen estimaciones de la fase de diseño o resultados limitados de UAT no se pueden revisar y retrasan el aumento. Cuantos más detalles medidos proporciones, más rápida será la revisión. Actualiza la solicitud a medida que se amplíe el despliegue y haya más telemetría disponible.

Información básica que se va a incluir

Información Description
ID de entorno Entorno de Dataverse donde se ejecuta el agente.
Nombre o identificador del agente Agente afectado por la solicitud.
Impacto empresarial Impacto crítico si los límites predeterminados no son suficientes.
Información conocida Lo que se conoce sobre el escenario, el canal, el contexto de inicio, la importancia empresarial y si es B2C, autónomo, orientado a los empleados o solo interno.
Instantánea del agente Una instantánea o exportación que ayuda a los revisores a comprender la configuración del agente, el diseño, los servicios conectados y los ajustes pertinentes.
Diseño del agente Descripción general de temas, uso de ia generativa, orígenes de conocimiento, acciones, flujos, conectores, llamadas a Dataverse y API externas usadas por el agente.
Resumen del proyecto piloto Fechas y duración del piloto, el tamaño de la audiencia del piloto y esa audiencia como parte del público completo al que se dirige.
Tráfico medio observado Se midió el tráfico promedio de la prueba piloto por minuto, por hora y por día.
Tráfico de picos observado Midió mensajes de pico, sesiones, llamadas de IA generativa, acciones de flujo, llamadas a conectores, solicitudes Dataverse y llamadas a API externas durante las ventanas de pico del piloto.
Requisito de pico extrapolado La demanda máxima con la audiencia completa, junto con el método de extrapolación y cualquier supuesto que hayas aplicado.

Más detalles que pueden ayudar

Información Description
Intervalo de fechas Fecha de inicio y finalización del aumento solicitado. Proporciona intervalos de fechas separados para pruebas de carga, pruebas de aceptación por usuario y producción si difieren.
Patrón de pico Periodos punta, zonas horarias, factores previstos que impulsan los picos de tráfico y si el tráfico se concentra en una breve franja diaria.
Perfil de sesión Sesiones simultáneas, duración media y máxima de la sesión, mensajes por sesión y preguntas por sesión.
Ejemplos de sesión típicos Rutas de acceso de usuario representativas, pasos típicos realizados, herramientas usadas e identificadores de sesión de ejemplo cuando están disponibles.
Ruta de tiempo de ejecución Flujos, acciones, avisos de IA, llamadas de conocimiento, solicitudes de Dataverse, conectores y API por interacción.
Picos a nivel de característica Volumen máximo por agente, característica, usuario, entorno, conector, minuto, hora y día donde se conoce.
Productos que necesitan revisión Tanto si la solicitud implica Copilot Studio, asignaciones de solicitudes de Power Platform, Power Automate, conectores, Dataverse, servicios de CLU/IA o API externas.
Evidence Telemetría de pruebas piloto, identificadores de sesión de ejemplo, errores, identificadores de correlación, registros, eventos de limitación de velocidad y observaciones en producción. Los resultados de las pruebas de carga pueden complementar la telemetría del piloto, pero no la sustituyan.
Mitigaciones Resumir lo que ya intentó hacer para reducir la presión sobre la capacidad de procesamiento. Haga referencia a la guía Diseño para reducir la presión de rendimiento , incluida la revisión de diseño, las llamadas externas optimizadas, la segmentación del entorno, el procesamiento por lotes, la cola, el filtrado de desencadenadores, la programación, la distribución de cargas de trabajo y otras optimizaciones ya vigentes.

Important

No se garantiza un aumento del rendimiento. Soporte técnico de Microsoft revisa las solicitudes en función del escenario, entorno, rango de fechas solicitadas, tráfico piloto observado, elegibilidad, límites actuales y capacidad de servicio.

  • Se actualizó por última vez el