Esta publicación está coescrita con Jad Chamoun, director de ingeniería de Forethought Technologies, Inc. y Salina Wu, ingeniera sénior de aprendizaje automático de Forethought Technologies, Inc.
Previsión es una suite de inteligencia artificial generativa líder para el servicio al cliente. En el centro de su suite se encuentra el innovador SoporteGPT™ tecnología que utiliza el aprendizaje automático para transformar el ciclo de vida de la atención al cliente, aumentando la desviación, mejorando el CSAT y aumentando la productividad de los agentes. SupportGPT™ aprovecha los sistemas de recuperación de información (IR) de última generación y los modelos de lenguaje extenso (LLM) para potenciar más de 30 millones de interacciones con clientes al año.
El caso de uso principal de SupportGPT es mejorar la calidad y la eficiencia de las interacciones y operaciones de atención al cliente. Mediante el uso de sistemas IR de última generación impulsados por incrustaciones y modelos de clasificación, SupportGPT puede buscar rápidamente información relevante y brindar respuestas precisas y concisas a las consultas de los clientes. Forethought utiliza modelos ajustados por cliente para detectar las intenciones de los clientes a fin de resolver las interacciones con los clientes. La integración de grandes modelos de lenguaje ayuda a humanizar la interacción con agentes automatizados, creando una experiencia de soporte más atractiva y satisfactoria.
SupportGPT también ayuda a los agentes de atención al cliente ofreciendo sugerencias de autocompletar y elaborando respuestas adecuadas a los tickets de los clientes que se alinean con las de la empresa en función de las respuestas anteriores. Mediante el uso de modelos de lenguaje avanzados, los agentes pueden abordar las inquietudes de los clientes de manera más rápida y precisa, lo que resulta en una mayor satisfacción del cliente.
Además, la arquitectura de SupportGPT permite detectar brechas en las bases de conocimiento de soporte, lo que ayuda a los agentes a brindar información más precisa a los clientes. Una vez que se identifican estas brechas, SupportGPT puede generar automáticamente artículos y otro contenido para llenar estos vacíos de conocimiento, asegurando que la base de conocimiento de soporte permanezca centrada en el cliente y actualizada.
En esta publicación, compartimos cómo Forethought usa Amazon SageMaker terminales multimodelo en casos de uso de IA generativa para ahorrar más del 66 % en costos.
Desafíos de infraestructura
Para ayudar a llevar estas capacidades al mercado, Forethought escala de manera eficiente sus cargas de trabajo de ML y proporciona soluciones hiperpersonalizadas adaptadas al caso de uso específico de cada cliente. Esta hiperpersonalización se logra mediante el ajuste fino de modelos y clasificadores integrados en los datos del cliente, lo que garantiza resultados de recuperación de información precisos y conocimiento del dominio que se adapta a las necesidades únicas de cada cliente. Los modelos de autocompletado personalizados también se ajustan con precisión a los datos del cliente para mejorar aún más la precisión y la relevancia de las respuestas generadas.
Uno de los desafíos importantes en el procesamiento de IA es la utilización eficiente de los recursos de hardware, como las GPU. Para hacer frente a este desafío, Forethought utiliza puntos finales multimodelo (MME) de SageMaker para ejecutar varios modelos de IA en un único punto final de inferencia y escala. Debido a que la hiperpersonalización de los modelos requiere que se entrenen e implementen modelos únicos, la cantidad de modelos aumenta linealmente con la cantidad de clientes, lo que puede resultar costoso.
Para lograr el equilibrio adecuado de rendimiento para la inferencia en tiempo real y el costo, Forethought optó por utilizar MME de SageMaker, que admiten la aceleración de GPU. Los MME de SageMaker permiten que Forethought brinde soluciones rentables, escalables y de alto rendimiento con una latencia inferior a un segundo, para abordar múltiples escenarios de soporte al cliente a escala.
SageMaker y previsión
SageMaker es un servicio completamente administrado que brinda a los desarrolladores y científicos de datos la capacidad de crear, entrenar e implementar modelos ML rápidamente. Los MME de SageMaker proporcionan una solución escalable y rentable para implementar una gran cantidad de modelos para la inferencia en tiempo real. Los MME usan un contenedor de servicio compartido y una flota de recursos que pueden usar instancias aceleradas, como GPU, para alojar todos sus modelos. Esto reduce los costos de hospedaje al maximizar la utilización de puntos finales en comparación con el uso de puntos finales de modelo único. También reduce la sobrecarga de implementación porque SageMaker administra la carga y descarga de modelos en la memoria y los escala en función de los patrones de tráfico del extremo. Además, todos los terminales en tiempo real de SageMaker se benefician de capacidades integradas para administrar y monitorear modelos, como incluir variantes de sombra, escalado automáticoe integración nativa con Reloj en la nube de Amazon (para más información, consulte Métricas de CloudWatch para implementaciones de terminales de varios modelos).
A medida que Forethought creció para albergar cientos de modelos que también requerían recursos de GPU, vimos la oportunidad de crear una arquitectura más rentable, confiable y manejable a través de SageMaker MME. Antes de migrar a SageMaker MME, nuestros modelos se implementaron en Kubernetes en Servicio Amazon Elastic Kubernetes (Amazon EKS). Aunque Amazon EKS proporcionó capacidades de administración, fue evidente de inmediato que estábamos administrando una infraestructura que no estaba diseñada específicamente para la inferencia. La previsión tuvo que administrar la inferencia del modelo en Amazon EKS nosotros mismos, lo que supuso una carga para la eficiencia de la ingeniería. Por ejemplo, para compartir los costosos recursos de la GPU entre varios modelos, éramos responsables de asignar fracciones de memoria rígidas a los modelos que se especificaron durante la implementación. Queríamos abordar los siguientes problemas clave con nuestra infraestructura existente:
- Alto costo – Para asegurarnos de que cada modelo tuviera suficientes recursos, seríamos muy conservadores en cuanto a la cantidad de modelos que caben por instancia. Esto resultó en costos mucho más altos para el hospedaje de modelos de lo necesario.
- Baja confiabilidad – A pesar de ser conservadores en nuestra asignación de memoria, no todos los modelos tienen los mismos requisitos y, ocasionalmente, algunos modelos generarían errores de falta de memoria (OOM).
- Gestión ineficiente – Tuvimos que administrar diferentes manifiestos de implementación para cada tipo de modelo (como clasificadores, incrustaciones y autocompletar), lo que requería mucho tiempo y era propenso a errores. También teníamos que mantener la lógica para determinar la asignación de memoria para diferentes tipos de modelos.
En última instancia, necesitábamos una plataforma de inferencia para asumir el trabajo pesado de administrar nuestros modelos en tiempo de ejecución para mejorar el costo, la confiabilidad y la administración del servicio de nuestros modelos. Los MME de SageMaker nos permitieron abordar estas necesidades.
A través de su carga y descarga inteligente y dinámica de modelos, y sus capacidades de escalado, los MME de SageMaker brindaron una solución significativamente menos costosa y más confiable para hospedar nuestros modelos. Ahora podemos adaptar muchos más modelos por instancia y no tenemos que preocuparnos por los errores de OOM porque los MME de SageMaker manejan la carga y descarga de modelos de forma dinámica. Además, las implementaciones ahora son tan simples como llamar a las API de Boto3 SageMaker y adjuntar las políticas de escalado automático adecuadas.
El siguiente diagrama ilustra nuestra arquitectura heredada.
Para comenzar nuestra migración a SageMaker MME, identificamos los mejores casos de uso para MME y cuáles de nuestros modelos se beneficiarían más de este cambio. Los MME se utilizan mejor para lo siguiente:
- Modelos que se espera que tengan una latencia baja pero que pueden soportar un tiempo de arranque en frío (cuando se carga por primera vez)
- Modelos que son llamados a menudo y consistentemente
- Modelos que necesitan recursos de GPU parciales
- Modelos que comparten requisitos comunes y lógica de inferencia
Identificamos nuestros modelos de incrustaciones y modelos de lenguaje de autocompletar como los mejores candidatos para nuestra migración. Para organizar estos modelos bajo MME, crearíamos un MME por tipo de modelo o tarea, uno para nuestros modelos de incrustaciones y otro para modelos de lenguaje de autocompletar.
Ya teníamos una capa de API sobre nuestros modelos para la gestión e inferencia de modelos. Nuestra tarea actual era reelaborar cómo esta API se implementaba y manejaba la inferencia en los modelos bajo el capó con SageMaker, con cambios mínimos en la forma en que los clientes y los equipos de productos interactuaban con la API. También necesitábamos empaquetar nuestros modelos y la lógica de inferencia personalizada para que fueran compatibles con NVIDIA Triton Inference Server usando SageMaker MME.
El siguiente diagrama ilustra nuestra nueva arquitectura.
Lógica de inferencia personalizada
Antes de migrar a SageMaker, el código de inferencia personalizado de Forethought (preprocesamiento y posprocesamiento) se ejecutaba en la capa API cuando se invocaba un modelo. El objetivo era trasladar esta funcionalidad al propio modelo para aclarar la separación de responsabilidades, modularizar y simplificar su código, y reducir la carga sobre la API.
incrustaciones
Los modelos integrados de Forethought constan de dos artefactos de modelo de PyTorch, y la solicitud de inferencia determina a qué modelo llamar. Cada modelo requiere texto preprocesado como entrada. Los principales desafíos fueron integrar un paso de preprocesamiento y acomodar dos artefactos de modelo por definición de modelo. Para abordar la necesidad de varios pasos en la lógica de inferencia, Forethought desarrolló un modelo de conjunto Triton con dos pasos: un proceso de preprocesamiento de back-end de Python y una llamada de modelo de back-end de PyTorch. Los modelos de conjunto permiten definir y ordenar pasos en la lógica de inferencia, con cada paso representado por un modelo Triton de cualquier tipo de back-end. Para garantizar la compatibilidad con el backend Triton PyTorch, los artefactos del modelo existente se convirtieron al formato TorchScript. Se crearon modelos Triton separados para cada definición de modelo, y la capa API de Forethought fue responsable de determinar el TargetModel
para invocar en función de la solicitud entrante.
autocompletar
Los modelos de autocompletar (secuencia a secuencia) presentaron un conjunto distinto de requisitos. Específicamente, necesitábamos habilitar la capacidad de recorrer múltiples llamadas de modelo y almacenar en caché entradas sustanciales para cada llamada, todo mientras mantenemos una latencia baja. Además, estos modelos requerían pasos de preprocesamiento y posprocesamiento. Para abordar estos requisitos y lograr la flexibilidad deseada, Forethought desarrolló modelos MME de autocompletado utilizando el backend Triton Python, que ofrece la ventaja de escribir el modelo como código Python.
Evaluación comparativa
Después de que se determinaron las formas del modelo Triton, implementamos modelos en puntos finales de prueba y realizamos evaluaciones comparativas de recursos y rendimiento. Nuestro objetivo principal era determinar la latencia para el arranque en frío frente a los modelos en memoria, y cómo la latencia se veía afectada por el tamaño de la solicitud y la concurrencia. También queríamos saber cuántos modelos cabrían en cada instancia, cuántos modelos harían que las instancias se escalaran con nuestra política de escalado automático y qué tan rápido ocurriría el escalado. De acuerdo con los tipos de instancias que ya estábamos usando, hicimos nuestra evaluación comparativa con instancias ml.g4dn.xlarge y ml.g4dn.2xlarge.
Resultados
La siguiente tabla resume nuestros resultados.
Tamaño de solicitud | Latencia de arranque en frío | Latencia de inferencia en caché | Latencia simultánea (5 solicitudes) |
Pequeño (30 fichas) | 12.7 segundos | 0.03 segundos | 0.12 segundos |
Medio (250 fichas) | 12.7 segundos | 0.05 segundos | 0.12 segundos |
Grande (550 fichas) | 12.7 segundos | 0.13 segundos | 0.12 segundos |
Notablemente, la latencia para las solicitudes de inicio en frío es significativamente más alta que la latencia para las solicitudes de inferencia en caché. Esto se debe a que el modelo debe cargarse desde el disco o Servicio de almacenamiento simple de Amazon (Amazon S3) cuando se realiza una solicitud de arranque en frío. La latencia de las solicitudes simultáneas también es mayor que la latencia de las solicitudes individuales. Esto se debe a que el modelo debe compartirse entre solicitudes simultáneas, lo que puede generar conflictos.
La siguiente tabla compara la latencia de los modelos heredados y los modelos de SageMaker.
Tamaño de solicitud | Modelos heredados | Modelos de SageMaker |
Pequeño (30 fichas) | 0.74 segundos | 0.24 segundos |
Medio (250 fichas) | 0.74 segundos | 0.24 segundos |
Grande (550 fichas) | 0.80 segundos | 0.32 segundos |
En general, los modelos de SageMaker son una mejor opción para hospedar modelos de autocompletar que los modelos heredados. Ofrecen menor latencia, escalabilidad, confiabilidad y seguridad.
El uso de recursos
En nuestra búsqueda para determinar la cantidad óptima de modelos que podrían caber en cada instancia, realizamos una serie de pruebas. Nuestro experimento consistió en cargar modelos en nuestros endpoints usando un tipo de instancia ml.g4dn.xlarge, sin ninguna política de escalado automático.
Estas instancias en particular ofrecen 15.5 GB de memoria y nuestro objetivo era lograr un uso de memoria de GPU de aproximadamente el 80 % por instancia. Teniendo en cuenta el tamaño de cada artefacto del modelo de codificador, logramos encontrar la cantidad óptima de codificadores Triton para cargar en una instancia para alcanzar nuestro uso de memoria GPU objetivo. Además, dado que cada uno de nuestros modelos de incrustaciones corresponde a dos modelos de codificador Triton, pudimos albergar una cantidad determinada de modelos de incrustaciones por instancia. Como resultado, calculamos la cantidad total de instancias requeridas para servir todos nuestros modelos de incrustaciones. Esta experimentación ha sido crucial para optimizar nuestro uso de recursos y mejorar la eficiencia de nuestros modelos.
Realizamos una evaluación comparativa similar para nuestros modelos de autocompletar. Estos modelos tenían alrededor de 292.0 MB cada uno. Mientras probamos cuántos modelos cabrían en una sola instancia de ml.g4dn.xlarge, notamos que solo podíamos incluir cuatro modelos antes de que nuestra instancia comenzara a descargar modelos, a pesar de que los modelos tenían un tamaño pequeño. Nuestras principales preocupaciones eran:
- Causa del aumento de la utilización de la memoria de la CPU
- Causa por la que los modelos se descargan cuando intentamos cargar un modelo más en lugar del modelo usado menos recientemente (LRU)
Pudimos identificar la causa raíz del pico de utilización de la memoria que se originó al inicializar nuestro entorno de tiempo de ejecución de CUDA en nuestro modelo de Python, que fue necesario para mover nuestros modelos y datos dentro y fuera del dispositivo GPU. CUDA carga muchas dependencias externas en la memoria de la CPU cuando se inicializa el tiempo de ejecución. Debido a que el backend de Triton PyTorch maneja y abstrae los datos que se mueven dentro y fuera del dispositivo GPU, no nos encontramos con este problema en nuestros modelos integrados. Para solucionar esto, intentamos usar instancias ml.g4dn.2xlarge, que tenían la misma cantidad de memoria de GPU pero el doble de memoria de CPU. Además, agregamos varias optimizaciones menores en nuestro código de back-end de Python, incluida la eliminación de tensores después de su uso, el vaciado de la memoria caché, la desactivación de gradientes y la recolección de elementos no utilizados. Con el tipo de instancia más grande, pudimos adaptar 10 modelos por instancia, y la utilización de memoria de CPU y GPU se alineó mucho más.
El siguiente diagrama ilustra esta arquitectura.
Escalado automático
Adjuntamos políticas de escalado automático a nuestras incrustaciones y MME de autocompletado. Nuestra política para nuestro punto final de incrustaciones apuntaba a una utilización promedio de memoria de GPU del 80 % mediante métricas personalizadas. Nuestros modelos de autocompletar vieron un patrón de alto tráfico durante el horario comercial y tráfico mínimo durante la noche. Debido a esto, creamos una política de escalado automático basada en InvocationsPerInstance
para que pudiéramos escalar de acuerdo con los patrones de tráfico, ahorrando costos sin sacrificar la confiabilidad. Con base en nuestra evaluación comparativa del uso de recursos, configuramos nuestras políticas de escalamiento con un objetivo de 225 InvocationsPerInstance
.
Implementar lógica y canalización
Crear un MME en SageMaker es sencillo y similar a crear cualquier otro punto final en SageMaker. Después de crear el punto final, agregar modelos adicionales al punto final es tan simple como mover el artefacto del modelo a la ruta de S3 a la que apunta el punto final; en este punto, podemos hacer solicitudes de inferencia a nuestro nuevo modelo.
Definimos la lógica que tomaría los metadatos del modelo, formatearía el punto final de forma determinista en función de los metadatos y verificaría si el punto final existía. Si no fuera así, creamos el punto final y agregamos el artefacto del modelo Triton al parche de S3 para el punto final (también con formato determinista). Por ejemplo, si los metadatos del modelo indicaran que se trata de un modelo de autocompletado, crearía un punto final para los modelos de autocompletado y una ruta de S3 asociada para los artefactos del modelo de autocompletado. Si existiera el punto final, copiaríamos el artefacto del modelo en la ruta S3.
Ahora que teníamos nuestras formas de modelo para nuestros modelos MME y la funcionalidad para implementar nuestros modelos en MME, necesitábamos una forma de automatizar la implementación. Nuestros usuarios deben especificar qué modelo quieren implementar; nos encargamos del empaquetado y despliegue del modelo. El código de inferencia personalizado empaquetado con el modelo se versiona y se envía a Amazon S3; en el paso de empaquetado, extraemos el código de inferencia según la versión especificada (o la última versión) y usamos archivos YAML que indican las estructuras de archivos de los modelos de Triton.
Un requisito para nosotros era que todos nuestros modelos MME se cargaran en la memoria para evitar cualquier latencia de arranque en frío durante las solicitudes de inferencia de producción para cargar modelos. Para lograr esto, aprovisionamos suficientes recursos para adaptarse a todos nuestros modelos (de acuerdo con la evaluación comparativa anterior) y llamamos a cada modelo en nuestro MME con una cadencia por hora.
El siguiente diagrama ilustra la canalización de implementación del modelo.
El siguiente diagrama ilustra la canalización de calentamiento del modelo.
Modelo de invocación
Nuestra capa de API existente proporciona una abstracción para que las personas que llaman hagan inferencias en todos nuestros modelos de ML. Esto significaba que solo teníamos que agregar funcionalidad a la capa API para llamar a SageMaker MME con el modelo de destino correcto según la solicitud de inferencia, sin ningún cambio en el código de llamada. El código de inferencia de SageMaker toma la solicitud de inferencia, formatea las entradas de Triton definidas en nuestros modelos de Triton e invoca los MME mediante Boto3.
Beneficios de costos
La previsión logró avances significativos en la reducción de los costos de hospedaje del modelo y la mitigación de los errores de OOM del modelo, gracias a la migración a los MME de SageMaker. Antes de este cambio, las instancias ml.g4dn.xlarge se ejecutaban en Amazon EKS. Con la transición a MME, descubrimos que podía albergar 12 modelos de incrustaciones por instancia mientras lograba una utilización de memoria GPU del 80 %. Esto condujo a una disminución significativa en nuestros gastos mensuales. Para ponerlo en perspectiva, nos dimos cuenta de un ahorro de costes de hasta el 80%. Además, para administrar un mayor tráfico, consideramos ampliar las réplicas. Suponiendo un escenario en el que empleamos tres réplicas, descubrimos que nuestros ahorros de costos seguirían siendo sustanciales incluso en estas condiciones, rondando el 43 %.
El viaje con SageMaker MME ha demostrado ser económicamente beneficioso, reduciendo nuestros gastos y asegurando un rendimiento óptimo del modelo. Anteriormente, nuestros modelos de idioma de autocompletado se implementaban en Amazon EKS, lo que requería una cantidad variable de instancias ml.g4dn.xlarge según la asignación de memoria por modelo. Esto resultó en un costo mensual considerable. Sin embargo, con nuestra reciente migración a SageMaker MME, hemos podido reducir estos costos sustancialmente. Ahora alojamos todos nuestros modelos en instancias ml.g4dn.2xlarge, lo que nos permite empaquetar modelos de manera más eficiente. Esto ha recortado significativamente nuestros gastos mensuales y ahora hemos obtenido ahorros de costos en el rango de 66 a 74%. Este movimiento ha demostrado cómo la utilización eficiente de los recursos puede conducir a ahorros financieros significativos utilizando SageMaker MME.
Conclusión
En esta publicación, revisamos cómo Forethought usa puntos finales de varios modelos de SageMaker para reducir el costo de la inferencia en tiempo real. SageMaker asume el trabajo pesado indiferenciado, por lo que Forethought puede aumentar la eficiencia de la ingeniería. También permite que Forethought reduzca drásticamente el costo de la inferencia en tiempo real mientras mantiene el rendimiento necesario para las operaciones críticas del negocio. Al hacerlo, Forethought puede brindar una oferta diferenciada para sus clientes utilizando modelos hiperpersonalizados. Utilice SageMaker MME para hospedar sus modelos a escala y reducir los costos de hospedaje al mejorar la utilización de los terminales. También reduce los gastos generales de implementación porque Amazon SageMaker administra la carga de modelos en la memoria y los escala en función de los patrones de tráfico a su punto final. Puede encontrar ejemplos de código para alojar varios modelos con SageMaker MME en GitHub.
Acerca de los autores
Jad Chamon es Director de Ingeniería Central en Forethought. Su equipo se centra en la ingeniería de plataformas que cubre la ingeniería de datos, la infraestructura de aprendizaje automático y la infraestructura de la nube. Puedes encontrarlo en Etiqueta LinkedIn.
Salina Wu es ingeniero sénior de infraestructura de aprendizaje automático en Forethought.ai. Trabaja en estrecha colaboración con el equipo de Machine Learning para construir y mantener sus infraestructuras de datos, servicio y capacitación de extremo a extremo. Está particularmente motivada por la introducción de nuevas formas de mejorar la eficiencia y reducir los costos en todo el espacio de ML. Cuando no está en el trabajo, a Salina le gusta el surf, la cerámica y estar en la naturaleza.
James Park es arquitecto de soluciones en Amazon Web Services. Trabaja con Amazon.com para diseñar, crear e implementar soluciones tecnológicas en AWS y tiene un interés particular en la IA y el aprendizaje automático. En su tiempo libre le gusta buscar nuevas culturas, nuevas experiencias y mantenerse al día con las últimas tendencias tecnológicas. Puede encontrarlo en Etiqueta LinkedIn.
Sunil Padmanabhan es Arquitecto de Soluciones para Startups en AWS. Como ex fundador de una startup y CTO, le apasiona el aprendizaje automático y se enfoca en ayudar a las nuevas empresas a aprovechar AI/ML para sus resultados comerciales y diseñar e implementar soluciones de ML/AI a escala.
Patel Dhawal es Arquitecto Principal de Aprendizaje Automático en AWS. Ha trabajado con organizaciones que van desde grandes empresas hasta empresas emergentes medianas en problemas relacionados con la computación distribuida y la inteligencia artificial. Se enfoca en el aprendizaje profundo, incluidos los dominios de NLP y Computer Vision. Ayuda a los clientes a lograr una inferencia de modelos de alto rendimiento en SageMaker.
- Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
- EVM Finanzas. Interfaz unificada para finanzas descentralizadas. Accede Aquí.
- Grupo de medios cuánticos. IR/PR amplificado. Accede Aquí.
- PlatoAiStream. Inteligencia de datos Web3. Conocimiento amplificado. Accede Aquí.
- Fuente: https://aws.amazon.com/blogs/machine-learning/how-forethought-saves-over-66-in-costs-for-generative-ai-models-using-amazon-sagemaker/
- :posee
- :es
- :no
- :dónde
- $ UP
- 1
- 10
- 100
- 12
- 13
- 15%
- 24
- 250
- 30
- 32
- 7
- 80
- a
- capacidad
- Poder
- Nuestra Empresa
- abstracción
- enviados
- acelerado
- Conforme
- la exactitud
- preciso
- precisamente
- Lograr
- alcanzado
- el logro de
- a través de
- add
- adicional
- la adición de
- adición
- Adicionales
- Adicionalmente
- dirección
- direccionamiento
- avanzado
- Ventaja
- Después
- Agente
- agentes
- AI
- casos de uso de ia
- AI / ML
- Dirigido
- alinear
- alineado
- Todos
- asignación
- permitir
- permite
- ya haya utilizado
- también
- Aunque
- Amazon
- Amazon SageMaker
- Amazon Web Services
- Amazon.com
- cantidad
- an
- y
- Anualmente
- Otra
- respuestas
- cualquier
- abejas
- API
- aparente
- adecuado
- aproximadamente
- arquitectura
- somos
- en torno a
- artificial
- inteligencia artificial
- AS
- asistencias
- asociado
- At
- auto
- automatizado
- Confirmación de Viaje
- automáticamente
- promedio
- evitar
- lejos
- AWS
- Backend
- Balance
- bases
- basado
- BE
- se convirtió en
- porque
- a las que has recomendado
- esto
- antes
- comenzar
- "Ser"
- evaluación comparativa
- beneficioso
- es el beneficio
- MEJOR
- mejores
- entre
- impulsar
- ambas
- llevar
- build
- incorporado
- carga
- pero
- by
- cache
- calculado
- llamar al
- , que son
- llamar
- Calls
- PUEDEN
- candidatos
- capacidades
- case
- cases
- abastece
- Causa
- Reto
- retos
- el cambio
- Cambios
- comprobar
- manera?
- eligió
- clientes
- de cerca
- Soluciones
- infraestructura de nube
- código
- frío
- El cobro
- COM
- viniendo
- Algunos
- De la empresa
- en comparación con
- compatibilidad
- compatible
- computadora
- Visión por computador
- informática
- Inquietudes
- competidor
- condiciones
- llevado a cabo
- configurado
- Conservador
- considerable
- considerado
- en vista de
- Envase
- contenido
- convertido
- Core
- correcta
- corresponde
- Cost
- ahorro de costes
- rentable
- costoso
- Precio
- podría
- cubierta
- Para crear
- creado
- Creamos
- crucial
- CTO
- personalizado
- cliente
- datos de los clientes
- Satisfacción del cliente
- Servicio al Cliente
- Atención al cliente
- Clientes
- se adaptan
- datos
- Fecha
- Rechazar
- disminuir
- profundo
- deep learning
- se define
- definir
- entregamos
- entregar
- demostrado
- Dependiente
- desplegar
- desplegado
- Desplegando
- despliegue
- Despliegues
- Diseño
- deseado
- A pesar de las
- Determinar
- determina
- determina
- determinar
- desarrollado
- desarrolladores
- dispositivo
- HIZO
- una experiencia diferente
- diferenciado
- Director
- descubierto CRISPR
- distinto
- distribuidos
- Computación distribuída
- "Hacer"
- dominio
- dominios
- No
- dramáticamente
- durante
- lugar de trabajo dinámico
- dinamicamente
- cada una
- eficiencia
- eficiente
- eficiente.
- incrustación
- habilitar
- permite
- de extremo a extremo
- Punto final
- interactuando
- ingeniero
- Ingeniería
- mejorar
- mejorar
- suficientes
- garantizar
- asegurando que
- empresas
- Entorno
- Errores
- Incluso
- Cada
- ejemplo
- existente
- esperado
- gastos
- costoso
- experience
- Experiencias
- experimento
- externo
- más rápida
- Archive
- archivos
- llenar
- financiero
- financialmente
- Encuentre
- Nombre
- cómodo
- FLOTA
- Flexibilidad
- se centra
- siguiendo
- formato
- Ex
- encontrado
- fundador
- Digital XNUMXk
- Desde
- completamente
- a la fatiga
- promover
- Además
- lagunas
- generar
- generado
- generativo
- IA generativa
- conseguir
- gif
- dado
- Diezmos y Ofrendas
- objetivo
- GPU
- GPU
- gradientes
- tenido
- mano
- encargarse de
- Manijas
- Manejo
- suceder
- Materiales
- Tienen
- es
- he
- pesado
- levantar objetos pesados
- ayuda
- ayudando
- ayuda
- Alta
- Alto rendimiento
- más alto
- su
- capucha
- fortaleza
- hosting
- costos de hospedaje
- HORAS
- Hogar
- Cómo
- Sin embargo
- HTML
- http
- HTTPS
- Cientos
- no haber aun identificado una solucion para el problema
- if
- ilustra
- inmediatamente
- mejorar
- la mejora de
- in
- Inc.
- Incluye
- Entrante
- aumente
- indicar
- indicado
- información
- EN LA MINA
- infraestructura
- originales
- Las opciones de entrada
- entradas
- ejemplo
- Integración
- integración
- Intelligence
- interacción
- interacciones
- intereses
- dentro
- Presentamos
- invocado
- invoca
- involucra
- IT
- SUS
- sí mismo
- jpg
- solo
- acuerdo
- Clave
- Saber
- especialistas
- idioma
- large
- Grandes empresas
- mayores
- Estado latente
- más reciente
- .
- Lead
- líder
- aprendizaje
- menos
- LED
- Legado
- menos
- Apalancamiento
- apalancamientos
- cirugía estética
- Etiqueta LinkedIn
- carga
- carga
- cargas
- lógica
- Baja
- inferior
- máquina
- máquina de aprendizaje
- hecho
- Inicio
- mantener
- Mantener los
- para lograr
- gestionan
- gestionado
- Management
- gestiona
- administrar
- muchos
- Mercado
- maximizando
- significó
- Salud Cerebral
- metadatos
- Métrica
- migrar
- migración
- millones
- mínimo
- menor de edad
- mitigar
- ML
- modelo
- modelos
- Monitorear
- mensual
- más,
- Por otra parte
- MEJOR DE TU
- motivado
- movimiento
- emocionante
- mucho más
- Punto final multimodelo
- múltiples
- debe
- nativo
- Naturaleza
- necesario
- ¿ Necesita ayuda
- Nuevo
- nlp
- ahora
- número
- Nvidia
- objetivo
- of
- off
- LANZAMIENTO
- que ofrece
- Ofertas
- a menudo
- on
- una vez
- ONE
- , solamente
- Operaciones
- Oportunidad
- óptimo
- optimizando
- or
- solicite
- para las fiestas.
- Otro
- "nuestr
- nosotros mismos
- salir
- resultados
- Más de
- durante la noche
- .
- paquete
- empaquetado
- embalaje
- particular
- particularmente
- apasionado
- Patch
- camino
- Patrón de Costura
- .
- actuación
- la perspectiva
- industrial
- plataforma
- Platón
- Inteligencia de datos de Platón
- PlatónDatos
- punto
- políticas
- política
- Publicación
- industria
- alimentado
- presentó
- anterior
- previamente
- primario
- Director de la escuela
- Anterior
- problemas
- tratamiento
- Producto
- Producción
- productividad
- apropiado
- probado
- proporcionar
- previsto
- proporciona un
- provisión
- empujó
- poner
- Python
- piñón
- calidad
- consultas
- búsqueda
- con rapidez
- distancia
- que van
- Clasificación
- en comunicarse
- en tiempo real
- realizado
- reciente
- recientemente
- reducir
- reduce
- la reducción de
- relacionado
- la relevancia
- fiabilidad
- confianza
- permanece
- representado
- solicita
- solicitudes
- Requisitos
- requisito
- Requisitos
- requiere
- Recurso
- Recursos
- respuestas
- responsabilidades
- responsable
- resultado
- resultante
- Resultados
- revisado
- Derecho
- rígido
- raíz
- Ejecutar
- correr
- sacrificando
- sabio
- Inferencia de SageMaker
- mismo
- satisfacción
- Guardar
- ahorro
- Ahorros
- Sierra
- Escalabilidad
- escalable
- Escala
- aumentar proporcionalmente
- escamas
- la ampliación
- guión
- escenarios
- los científicos
- Buscar
- EN LINEA
- la búsqueda de
- mayor
- separado
- Secuencia
- Serie
- ayudar
- de coches
- Servicios
- servicio
- set
- Varios
- Shadow
- formas
- Compartir
- compartido
- ella
- importante
- significativamente
- similares
- sencillos
- simplificar
- soltero
- Tamaño
- chica
- inteligente
- So
- a medida
- Soluciones
- RESOLVER
- algo
- Espacio
- soluciones y
- específicamente
- especificado
- espiga
- puesta en escena
- comienzo
- fundó
- inicio
- Startups
- el estado de la técnica
- paso
- pasos
- Sin embargo
- STORAGE
- sencillo
- zancadas
- sustancial
- tal
- suite
- SOPORTE
- Todas las funciones a su disposición
- mesa
- entrada
- adaptado
- ¡Prepárate!
- toma
- Target
- afectados
- tiene como objetivo
- Tarea
- equipo
- equipos
- Tecnologías
- Tecnología
- probado
- pruebas
- que
- Muchas Gracias
- esa
- La
- su
- Les
- Estas
- ellos
- así
- Tres
- A través de esta formación, el personal docente y administrativo de escuelas y universidades estará preparado para manejar los recursos disponibles que derivan de la diversidad cultural de sus estudiantes. Además, un mejor y mayor entendimiento sobre estas diferencias y similitudes culturales permitirá alcanzar los objetivos de inclusión previstos.
- entradas
- equipo
- prolongado
- a
- Tokens
- parte superior
- Total
- tráfico
- Entrenar
- entrenado
- Formación
- transferir
- Transformar
- transición
- Tendencias
- probado
- Tritón
- Twice
- dos
- tipo
- tipos
- bajo
- único
- us
- Uso
- utilizan el
- caso de uso
- usado
- usuarios
- usos
- usando
- Utilizando
- versión
- muy
- visión
- vs
- quieres
- deseado
- fue
- Camino..
- formas
- we
- web
- servicios web
- tuvieron
- cuando
- sean
- que
- mientras
- sin
- Actividades:
- trabajado
- funciona
- preocuparse
- se
- la escritura
- wu
- yaml
- Usted
- tú
- zephyrnet