Esta publicación está coescrita por los miembros del equipo de AI Platform de Salesforce, Srikanta Prasad, Utkarsh Arora, Raghav Tanaji, Nitin Surya, Gokulakrishnan Gopalakrishnan y Akhilesh Deepak Gotmare.
El equipo de la plataforma de Inteligencia Artificial (IA) de Salesforce ejecuta modelos de lenguaje grande (LLM) personalizados (versiones ajustadas de Llama, Qwen y Mistral) para aplicaciones de IA agentes como Agentforce. La implementación de estos modelos genera gastos operativos: los equipos pasan meses optimizando familias de instancias, dando servicio a motores y configuraciones. Este proceso lleva mucho tiempo, es difícil de mantener con lanzamientos frecuentes y es costoso debido a las reservas de capacidad de la GPU para el uso máximo.
Salesforce resolvió esto adoptando la importación de modelos personalizados de Amazon Bedrock. Con Amazon Bedrock Custom Model Import, los equipos pueden importar e implementar modelos personalizados a través de una API unificada, minimizando la administración de infraestructura mientras se integran con características de Amazon Bedrock como Amazon Bedrock Knowledge Bases, Amazon Bedrock Guardrails y Amazon Bedrock Agents. Este cambio permite a Salesforce centrarse en modelos y lógica empresarial en lugar de infraestructura.
Esta publicación muestra cómo Salesforce integró la importación de modelos personalizados de Amazon Bedrock en su flujo de trabajo de operaciones de aprendizaje automático (MLOps), reutilizó los puntos finales existentes sin cambios en las aplicaciones y comparó la escalabilidad. Compartimos métricas clave sobre eficiencia operativa y optimización de costos, y ofrecemos información práctica para simplificar su estrategia de implementación.
Enfoque de integración
La transición de Salesforce de Amazon SageMaker Inference a Amazon Bedrock Custom Model Import requirió una integración cuidadosa con su canal MLOps existente para evitar interrumpir las cargas de trabajo de producción. El objetivo principal del equipo era mantener sus puntos finales API actuales y sus interfaces de servicio de modelos, manteniendo cero tiempo de inactividad y sin necesidad de cambios en las aplicaciones posteriores. Con este enfoque, podrían utilizar las capacidades sin servidor de Amazon Bedrock y al mismo tiempo preservar la inversión en su infraestructura y herramientas existentes. La estrategia de integración se centró en crear un puente transparente entre sus flujos de trabajo de implementación actuales y los servicios administrados de Amazon Bedrock, permitiendo una migración gradual sin riesgos operativos adicionales.
Como se muestra en el siguiente diagrama de flujo de implementación, Salesforce mejoró su proceso de entrega de modelos existente con un único paso adicional para utilizar Amazon Bedrock Custom Model Import. Después de que su proceso de integración continua y entrega continua (CI/CD) guarda los artefactos del modelo en su tienda de modelos (un depósito de Amazon Simple Storage Service (Amazon S3)), ahora llaman a la API de importación de modelos personalizados de Amazon Bedrock para registrar el modelo en Amazon Bedrock. Esta operación del plano de control es liviana porque Amazon Bedrock extrae el modelo directamente de Amazon S3, lo que agrega una sobrecarga mínima (5 a 7 minutos, según el tamaño del modelo) a su cronograma de implementación; su proceso general de lanzamiento del modelo permanece en aproximadamente 1 hora. La integración brindó un beneficio de rendimiento inmediato: SageMaker ya no necesita descargar pesos al iniciar el contenedor porque Amazon Bedrock precarga el modelo. Los principales cambios de configuración implicaron otorgar permisos a Amazon Bedrock para permitir el acceso entre cuentas a su depósito modelo S3 y actualizar las políticas de AWS Identity and Access Management (IAM) para permitir que los clientes de inferencia invoquen puntos finales de Amazon Bedrock.
El siguiente diagrama de flujo de inferencia ilustra cómo Salesforce mantuvo sus interfaces de aplicaciones existentes mientras utilizaba las capacidades sin servidor de Amazon Bedrock. Las solicitudes de los clientes fluyen a través de su capa de preprocesamiento establecida para la lógica empresarial, como el formateo rápido, antes de llegar a Amazon Bedrock, con el posprocesamiento aplicado a la salida del modelo sin procesar. Para manejar requisitos de procesamiento complejos, implementaron contenedores de CPU SageMaker livianos que actúan como servidores proxy inteligentes, ejecutando su lógica model.py personalizada mientras reenvían la inferencia real a los puntos finales de Amazon Bedrock. Esta arquitectura híbrida preserva su marco de herramientas existente: su servicio de predicción continúa llamando a los puntos finales de SageMaker sin cambios de enrutamiento, y conservan el monitoreo y el registro maduros de SageMaker para la lógica de preprocesamiento y posprocesamiento. La compensación implica un salto de red adicional que agrega una latencia de 5 a 10 milisegundos y el costo de las instancias de CPU siempre activas, pero este enfoque ofrece compatibilidad con versiones anteriores con integraciones existentes y al mismo tiempo mantiene la inferencia intensiva de GPU completamente sin servidor a través de Amazon Bedrock.
Evaluación comparativa de escalabilidad
Para validar las capacidades de rendimiento de Amazon Bedrock Custom Model Import, Salesforce realizó pruebas de carga integrales en varios escenarios de simultaneidad. Su metodología de prueba se centró en medir cómo el comportamiento transparente de escalado automático de Amazon Bedrock (donde el servicio genera automáticamente copias de modelos bajo demanda y se escala bajo carga pesada) afectaría el rendimiento en el mundo real. Cada prueba implicó enviar cargas útiles estandarizadas que contenían ID de modelo y datos de entrada a través de sus contenedores proxy a los puntos finales de Amazon Bedrock, midiendo la latencia y el rendimiento bajo diferentes patrones de carga. Los resultados (consulte la siguiente tabla) muestran que con baja simultaneidad, Amazon Bedrock logró una latencia un 44 % menor que la línea base ml.g6e.xlarge (precisión bf16). Bajo cargas más altas, Amazon Bedrock Custom Model Import mantuvo un rendimiento constante con una latencia aceptable (menos de 10 milisegundos), lo que demuestra la capacidad de la arquitectura sin servidor para manejar cargas de trabajo de producción sin escalamiento manual.
Simultaneidad (recuento) P95 Latencia (en segundos) Rendimiento (solicitud por minuto) 1 7,2 11 4 7,96 41 16 9,35 133 32 10,44 232
Los resultados muestran la latencia P95 y el rendimiento del modelo ApexGuru (QWEN-2.5 13B ajustado) en diferentes niveles de concurrencia. La importación de modelos personalizados de Amazon Bedrock se escaló automáticamente de una a tres copias a medida que la simultaneidad alcanzó 32. Cada copia del modelo utilizó 1 unidad de modelo.
Resultados y métricas
Más allá de las mejoras de escalabilidad, Salesforce evaluó la importación de modelos personalizados de Amazon Bedrock en dos dimensiones comerciales críticas: eficiencia operativa y optimización de costos. Las ganancias en eficiencia operativa fueron sustanciales: el equipo logró una reducción del 30 % en el tiempo para iterar e implementar modelos en producción. Esta mejora surgió al aliviar la compleja toma de decisiones en torno a la selección de instancias, el ajuste de parámetros y la elección entre motores de servicio como vLLM y TensorRT-LLM. El proceso de implementación simplificado permitió a los desarrolladores centrarse en el rendimiento del modelo en lugar de en la configuración de la infraestructura.
La optimización de costos arrojó resultados aún más espectaculares: Salesforce logró una reducción de costos de hasta un 40 % a través de Amazon Bedrock. Este ahorro se debió principalmente a sus diversos patrones de tráfico en aplicaciones de IA generativa, que van desde tráfico de producción bajo hasta alto, donde anteriormente tenían que reservar capacidad de GPU para cargas de trabajo máximas. El modelo de pago por uso resultó especialmente beneficioso para entornos de desarrollo, pruebas de rendimiento y preparación que solo requerían recursos de GPU durante los ciclos de desarrollo activos, evitando la necesidad de capacidad reservada las 24 horas del día que a menudo permanecía inactiva.
Lecciones aprendidas
El viaje de Salesforce con Amazon Bedrock Custom Model Import reveló varios conocimientos clave que pueden guiar a otras organizaciones que estén considerando un enfoque similar. En primer lugar, aunque Amazon Bedrock Custom Model Import admite arquitecturas de modelos de código abierto populares (Qwen, Mistral, Llama) y amplía su cartera con frecuencia según la demanda, es posible que los equipos que trabajan con arquitecturas de vanguardia deban esperar para obtener soporte. Sin embargo, las organizaciones que realizan ajustes con las arquitecturas de los últimos modelos deben verificar la compatibilidad antes de comprometerse con el cronograma de implementación.
Para el procesamiento previo y posterior a la inferencia, Salesforce evaluó enfoques alternativos utilizando Amazon API Gateway y funciones AWS Lambda, que ofrecen escalamiento completo sin servidor y precios de pago por uso de hasta milisegundos de ejecución. Sin embargo, encontraron que este enfoque era menos compatible con las integraciones existentes y observaron impactos del arranque en frío al usar bibliotecas más grandes en su lógica de procesamiento.
La latencia de arranque en frío surgió como una consideración crítica, particularmente para modelos más grandes (más de 7B de parámetros). Salesforce observó retrasos en el arranque en frío de un par de minutos con modelos de 26B de parámetros, con una latencia que variaba según el tamaño del modelo. Para las aplicaciones sensibles a la latencia que no pueden tolerar tales retrasos, recomiendan mantener los puntos finales calientes manteniendo activa al menos una copia del modelo mediante invocaciones de verificación de estado cada 14 minutos. Este enfoque equilibra la rentabilidad con los requisitos de rendimiento para las cargas de trabajo de producción.
Conclusión
La adopción por parte de Salesforce de Amazon Bedrock Custom Model Import muestra cómo simplificar la implementación de LLM sin sacrificar la escalabilidad o el rendimiento. Lograron implementaciones un 30 % más rápidas y un ahorro de costos del 40 % mientras mantenían la compatibilidad con versiones anteriores a través de su arquitectura híbrida utilizando contenedores proxy de SageMaker junto con la inferencia sin servidor de Amazon Bedrock. Para modelos altamente personalizados o arquitecturas no compatibles, Salesforce continúa utilizando SageMaker AI como una solución de aprendizaje automático administrada.
Su éxito se debió a una ejecución metódica: pruebas de carga exhaustivas y migración gradual comenzando con cargas de trabajo no críticas. Los resultados demuestran que la implementación de IA sin servidor funciona para la producción, especialmente con patrones de tráfico variables. ApexGuru ahora está implementado en su entorno de producción.
Para los equipos que gestionan LLM a escala, este estudio de caso proporciona un modelo claro. Verifique la compatibilidad de la arquitectura de su modelo, planifique arranques en frío con modelos más grandes y conserve las interfaces existentes. Amazon Bedrock Custom Model Import ofrece una ruta comprobada hacia la IA sin servidor que puede reducir los gastos generales, acelerar la implementación y reducir los costos al mismo tiempo que cumple con los requisitos de rendimiento.
Para obtener más información sobre los precios de Amazon Bedrock, consulte Optimización del costo para usar modelos fundamentales con Amazon Bedrock y precios de Amazon Bedrock.
Para obtener ayuda para elegir entre Amazon Bedrock y SageMaker AI, consulte ¿Amazon Bedrock o Amazon SageMaker AI?
Para obtener más información sobre la importación de modelos personalizados de Amazon Bedrock, consulte Cómo configurar la implementación del modelo entre cuentas mediante la importación de modelos personalizados de Amazon Bedrock.
Para obtener más detalles sobre ApexGuru, consulte Obtenga información impulsada por IA para su código Apex con ApexGuru.
Sobre los autores
Srikanta Prasad es gerente sénior en gestión de productos y se especializa en soluciones de inteligencia artificial generativa en Salesforce. Lidera iniciativas de alojamiento e inferencia de modelos, centrándose en el servicio de inferencia LLM, LLMOps e implementaciones escalables de IA.
Utkarsh Arora es miembro asociado del personal técnico de Salesforce y combina una sólida base académica del IIIT Delhi con contribuciones iniciales en ingeniería e investigación de aprendizaje automático.
Raghav Tanaji es miembro principal del personal técnico de Salesforce y se especializa en aprendizaje automático, reconocimiento de patrones y aprendizaje estadístico. Tiene un M.Tech del IISc Bangalore.
Akhilesh Deepak Gotmare es miembro sénior del personal de investigación en Salesforce Research, con sede en Singapur. Es un investigador de IA que se centra en el aprendizaje profundo, el procesamiento del lenguaje natural y las aplicaciones relacionadas con el código.
Gokulakrishnan Gopalakrishnan es ingeniero de software principal en Salesforce, donde dirige los esfuerzos de ingeniería en ApexGuru. Con más de 15 años de experiencia, incluso en Microsoft, se especializa en la creación de sistemas de software escalables.
Nitin Surya es miembro principal del personal técnico de Salesforce con más de 8 años en ingeniería de software/ML. Tiene una licenciatura en tecnología en informática de la Universidad VIT y una maestría en informática (enfoque en IA/ML) de la Universidad de Illinois en Chicago.
Hrushikesh Gangur es arquitecto principal de soluciones en AWS con sede en San Francisco, California. Se especializa en IA generativa y agente, ayudando a empresas emergentes e ISV a crear e implementar aplicaciones de IA.