UiPath Documentation
document-understanding
2024.10
false
Importante :
La localización de contenidos recién publicados puede tardar entre una y dos semanas en estar disponible.
UiPath logo, featuring letters U and I in white

Document Understanding user guide

Última actualización 6 de abr. de 2026

Implantación de modelos de alto rendimiento

A medida que los modelos de aprendizaje automático (ML) mejoran en precisión a lo largo del tiempo, sus requisitos de recursos también cambian. Para obtener el mejor rendimiento, es importante que al implementar modelos ML a través de AI Center, las habilidades tengan el tamaño adecuado con respecto al tráfico que deben gestionar. En su mayor parte, la infraestructura se dimensiona con respecto al número de páginas por unidad de tiempo (minuto u hora). Un documento puede tener una sola página o varias.

Introducción al rendimiento del modelo de ML

Para implementar infraestructura a través de AI Center, hay algunos aspectos importantes que se deben tener en cuenta para obtener un rendimiento óptimo.

GPU

Solo hay un tipo de infraestructura de GPU disponible. Esto lo resalta la casilla de verificación para habilitar GPU. Cada habilidad se ejecuta en una sola máquina virtual (VM) o nodo que tiene una GPU. En este caso, la CPU y la memoria no son relevantes, ya que la habilidad puede utilizar todos los recursos de CPU y memoria disponibles en esos nodos. Además del rendimiento, la GPU es mucho más rápida. Debido a esto, si la latencia es crítica, se recomienda utilizar GPU.

CPU

La CPU y la memoria pueden estar fraccionadas, lo que significa que varias habilidades ML pueden ejecutarse en el mismo nodo. Para evitar cualquier perturbación de una habilidad vecina, cada habilidad ML se limita a la cantidad de memoria y CPU que puede consumir, dependiendo del nivel seleccionado. Mayor CPU conduce a un procesamiento más rápido (para una página), mientras que mayor memoria conduce a un mayor número de documentos que se pueden procesar.

Número de réplicas

El número de réplicas determina el número de contenedores que se utilizan para servir solicitudes del modelo ML. Un número más alto conduce a una mayor cantidad de documentos que pueden procesarse en paralelo, sujetos a los límites de ese nivel en particular. El número de réplicas está directamente vinculado al tipo de infraestructura (número de CPU por réplica o si se utiliza una GPU), en el sentido de que tanto las réplicas como el tamaño de la infraestructura pueden afectar directamente el rendimiento (páginas/minuto).

Nota:

Multiple replicas multiply the throughput.

Número De Robots

El número de robots afecta al rendimiento. Para obtener un rendimiento eficiente, el número de robots debe dimensionarse de tal manera que no sobrecargue las habilidades ML. Esto depende de la propia automatización y debeComo pauta general, puedes utilizar de uno a tres robots como punto de partida para cada réplica que tenga la habilidad ML. Dependiendo del tiempo total del proceso (excluyendo el Extractor ML), el número de robots puede ser mayor o menor (o el número de réplicas).

Si la infraestructura no se dimensiona correctamente, los modelos pueden colocarse bajo una carga muy alta. En algunos casos, esto puede provocar una acumulación de solicitudes, un largo tiempo de procesamiento o incluso fallos al procesar documentos.

Memoria insuficiente

Insufficient memory most commonly encountered on the lower CPU tiers (0.5 CPU or 1 CPU). If you need to process a very large payload (one or several large documents), it can lead to an out of memory exception. This is related to the document size in terms of pages and text density (how much text there is per page). Since the requirements are very specific to each use case, it is not possible to provide exact numbers. You can check the guidelines in the Sizing the infrastructure correctly section for more detailed information. If you encounter an insufficient memory situation, the general recommendation is to go to the next tier.

Cálculo insuficiente

El cálculo insuficiente se refiere tanto a la CPU como a la GPU, aunque se encuentra más comúnmente en la CPU. Cuando la habilidad ML recibe demasiadas páginas relacionadas con su capacidad disponible, las solicitudes pueden superar el tiempo de espera (códigos de estado 520 y 499), producir acumulación de pedidos o incluso provocar que el modelo se bloquee (códigos de estado 503 y 500). Si te encuentras con una situación de cálculo insuficiente, recomendamos ir al siguiente nivel, o incluso al nivel de la GPU.

Dimensionar la infraestructura correctamente

Directrices generales

Esta sección ofrece directrices generales sobre cómo se comportan los modelos en cada tamaño de habilidad diferente.

Importante:

The calculations provided in this section are intended to be used only as general guidelines and should not be interpreted as exact specifications. Performance outcomes can vary and are influenced by different factors such as the size of the document, number of pages, and the specific model being utilized.

Nota:

Each model generation (2022.10, 2023.4, or 2023.10) behaves differently in relation to resources required and throughput. As models become better in terms of accuracy, this can also impact the performance and demand more resources.

Table 1. 2022.10 Extractor

NivelPáginas/documento máximasRendimiento esperado (páginas/hora)Unidades de IA/hora
0,5 CPU/2 GB de memoria25300-6001
1 CPU/4 GB de memoria50400-8002
2 CPU/8 GB de memoria100600-10004
4 CPU/16 GB de memoria100800-12008
6 CPU/24 GB de memoria100900-130012
GPU200-2501350-160020

Table 2. 2023.4 Extractor

NivelPáginas/documento máximasRendimiento esperado (páginas/hora)Unidades de IA/hora
0,5 CPU/2 GB de memoria2540-1001
1 CPU/4 GB de memoria5070-1402
2 CPU/8 GB de memoria75120-2204
4 CPU/16 GB de memoria100200-3008
6 CPU/24 GB de memoria100250-40012
GPU200-2501400-220020

Table 3. 2023.7 and later versions of extractors

NivelPáginas/documento máximasRendimiento esperado (páginas/hora)Unidades de IA/hora
0,5 CPU/2 GB de memoria2560-2001
1 CPU/4 GB de memoria50120-2402
2 CPU/8 GB de memoria75200-2804
4 CPU/16 GB de memoria100250-4008
6 CPU/24 GB de memoria100350-50012
GPU200-2501000-200020

El rendimiento esperado se expresa para cada réplica, en página/hora y un rendimiento esperado mínimo y máximo, dependiendo del propio documento. La habilidad ML debe dimensionarse para el rendimiento más alto esperado (pico) y no el rendimiento medio en un día, semana o mes.

Nota:

When sizing the infrastructure, make sure to start from the largest document the skill needs to handle and the expected throughput.

Ejemplos

Ejemplo 1

La habilidad ML debe procesar lo siguiente utilizando un extractor 2023.10:

  • Documentos que contienen un máximo de cinco páginas.
  • Un pico máximo de 300 páginas por hora.

Dado que el rendimiento está en la parte inferior y el tamaño del documento es pequeño, no se necesita una GPU en este ejemplo. De dos a cuatro réplicas del nivel 0,5 de CPU o 1 de CPU son suficientes.

Ejemplo 2

La habilidad ML debe procesar lo siguiente utilizando un extractor 2023.4:

  • Documentos que contienen un máximo de 80 páginas.
  • Un pico máximo de 900 páginas por hora.

Para este ejemplo, son suficientes tres réplicas del nivel de 4 CPU o un solo nivel de GPU.

Nota:

A single replica does not have high availability, so it is always recommended to use at least two replicas for critical production workflows.

Ejemplo 3

La habilidad ML debe procesar lo siguiente utilizando un extractor 2023.10:

  • Documentos que contienen un máximo de 50 páginas.
  • Un pico máximo de 3000 páginas por hora.

Hay dos formas de cumplir con estos requisitos:

  • Usar 3 réplicas de GPU.
  • Usar 12-15 réplicas del nivel de 4 CPU o 6 CPU.

Ambas opciones tienen alta disponibilidad porque hay más de dos réplicas para la habilidad ML.

Tamaño de la infraestructura para una réplica

You can check the tables from the General guidelines section for the expected throughput from a single extraction replica, depending on the model version and the tier.

Nota:

To achieve maximum throughput potential, you must keep the extraction replica under constant load.

Para asegurarse de que la réplica está constantemente ocupada, se deben cumplir los siguientes criterios:

  • Idealmente, debe haber un tiempo de inactividad mínimo entre el momento en que la réplica envía la respuesta a una solicitud y el momento en que la réplica recibe los datos para la siguiente solicitud.
  • La réplica no debe sobrecargarse. Las solicitudes se procesan una tras otra (en serie). Esto significa que siempre hay una solicitud activa en proceso y una cola de solicitudes pendientes. Si esta cola se vuelve demasiado larga, la réplica rechaza las nuevas solicitudes entrantes, mostrando un código de estado 429 (too many requests) HTTP.

El punto clave a recordar al dimensionar la infraestructura para una única réplica es garantizar que la carga de trabajo esté equilibrada. La carga de trabajo no debe ser tan ligera que la réplica permanezca inactiva, o tan pesada que comience a rechazar tareas.

Determinar el número de réplicas necesario

Para determinar el número de réplicas necesarias, debes:

  • Identifica el período de tiempo relevante más ocupado para las réplicas. Por ejemplo, debes identificar la hora más ocupada de actividad, no el intervalo máximo de un minuto o un tramo de 12 horas. Después de identificar este período de tiempo, estima la demanda (número de páginas o solicitudes) durante ese tiempo.
  • Divide the estimate by the throughput per replica, described in the Size the infrastructure for one replica section.
  • Añade algo de capacidad adicional como medida de seguridad.

Ten en cuenta que el uso del período de tiempo más ocupado puede provocar un sobreaprovisionamiento cuando la demanda es significativamente menor. Para solucionar esto, puedes aumentar o disminuir manualmente el tamaño de una implementación, dependiendo de la demanda. Esto puede ser útil si, por ejemplo, hay un intervalo de una hora muy ocupado que requiere 10 réplicas, seguidas de 23 horas de actividad baja donde solo se necesitan 2 réplicas. Esto puede resultar en un tiempo considerable en el que el sistema está sobreaprovisionado.

Medir la demanda y la oferta: páginas o solicitudes

El número de páginas y la densidad de esas páginas son factores clave. El recuento de páginas es más relevante que el número de solicitudes. Sin embargo, en términos prácticos, las solicitudes son más fáciles de contar.

Consejo:

You can use historical data to make this conversion easier. For a particular skill with a recorded history, you can check the metering telemetry to identify the distribution of page counts for requests made to that skill. For example, if a skill received mostly documents with two or three pages in the last month, you can assume the future trend will continue with an average of 2.5 pages per document.

Determinar si una implementación está subaprovisionada

Al determinar si una implementación está subaprovisionada, la utilización de la CPU no es relevante, ya que cada réplica maximizará el uso de CPU/GPU mientras se procesa una solicitud, independientemente de la cola de solicitudes pendiente.

El factor importante es el tiempo de principio a fin, que es la suma del tiempo de espera y el tiempo de procesamiento real.

Por ejemplo, si has elegido un nivel con un rendimiento de aproximadamente 900 páginas/hora, o unos 4 segundos/página, y envías documentos de 5 páginas, normalmente tardarás unos 30 segundos por documento.

A continuación, puedes aproximar un tiempo de espera de unos 10 segundos. Esto significa que hay un tiempo de espera (lo que significa que la solicitud no fue tomada instantáneamente por la réplica porque estaba ocupada manejando solicitudes preexistentes). Esto también indicó que este tiempo de espera era de unos 10 segundos.

Si la diferencia entre el tiempo real de principio a fin (el tiempo medido) y el tiempo esperado de principio a fin (estimado en función del nivel) es superior a cero, significa que la réplica está funcionando sin parar. Además, si el tiempo de espera aumenta a medida que aumenta la demanda, está claro que la implementación está bajo un estrés sostenido. Además, cualquier código de estado 429 (demasiadas solicitudes) es un signo de subaprovisionamiento.

Determinar si una implementación está sobreaprovisionada

Las secciones anteriores pueden ayudar a determinar que la implementación está aprovisionada de forma efectiva, pero te recomendamos que sigas estos pasos para un análisis preciso de tu implementación:

  • Identifica el período de tiempo más ocupado. Para este ejemplo, supongamos que es una hora, o 3600 segundos.
  • Tomemos el número actual de réplicas, supongamos que son 10. Esto da como resultado 36 000 "réplica-segundos" (concepto similar a "persona-hora").
  • Suma la duración total de las solicitudes (suma de tiempos de principio a fin). Supongamos que son 10 000 segundos.

En este ejemplo, dado que 10 000 es inferior a 36 000, significa que tu infraestructura actual es más de lo que necesitas. Puedes intentar reducir la implementación a ocho réplicas, supervisar el rendimiento y, si funciona sin problemas, reducir a seis réplicas. Razona el rendimiento con cada ajuste.

¿Te ha resultado útil esta página?

Conectar

¿Necesita ayuda? Soporte

¿Quiere aprender? UiPath Academy

¿Tiene alguna pregunta? Foro de UiPath

Manténgase actualizado