Las empresas buscan desbloquear rápidamente el potencial de la IA generativa brindando acceso a modelos básicos (FM) a diferentes líneas de negocio (LOB). Los equipos de TI son responsables de ayudar a la LOB a innovar con velocidad y agilidad, al mismo tiempo que brindan gobernanza y observabilidad centralizadas. Por ejemplo, es posible que necesiten realizar un seguimiento del uso de FM entre equipos, los costos de contracargo y brindar visibilidad al centro de costos relevante en el LOB. Además, es posible que necesiten regular el acceso a diferentes modelos por equipo. Por ejemplo, si solo se puede aprobar el uso de FM específicos.

lecho rocoso del amazonas es un servicio totalmente administrado que ofrece una selección de modelos básicos de alto rendimiento de empresas líderes en IA como AI21 Labs, Anthropic, Cohere, Meta, Stability AI y Amazon a través de una única API, junto con un amplio conjunto de capacidades para construir IA generativa. aplicaciones con seguridad, privacidad e IA responsable. Como Amazon Bedrock no tiene servidor, no es necesario administrar ninguna infraestructura y puede integrar e implementar de forma segura capacidades de IA generativa en sus aplicaciones utilizando los servicios de AWS con los que ya está familiarizado.

Una capa de software como servicio (SaaS) para modelos básicos puede proporcionar una interfaz simple y consistente para los usuarios finales, manteniendo al mismo tiempo la gobernanza centralizada del acceso y el consumo. Las puertas de enlace API pueden proporcionar un acoplamiento flexible entre los consumidores del modelo y el servicio de punto final del modelo, y flexibilidad para adaptarse a los cambios en el modelo, las arquitecturas y los métodos de invocación.

En esta publicación, le mostramos cómo crear una capa SaaS interna para acceder a modelos básicos con Amazon Bedrock en una arquitectura multiinquilino (equipo). Nos centramos específicamente en el seguimiento del uso y los costos por inquilino y también en controles como la limitación del uso por inquilino. Describimos cómo la solución y los planes de consumo de Amazon Bedrock se corresponden con el marco general de viaje de SaaS. El código de la solución y un Kit de desarrollo en la nube de AWS (AWS CDK) está disponible en la Repositorio GitHub.

Desafios

Un administrador de plataforma de IA debe proporcionar acceso fácil y estandarizado a los FM a múltiples equipos de desarrollo.

Los siguientes son algunos de los desafíos para brindar acceso gobernado a los modelos de fundaciones:

• Seguimiento de costos y uso – Realice un seguimiento y audite los costos de inquilinos individuales y el uso de modelos básicos, y proporcione costos de contracargo a centros de costos específicos
• Controles de presupuesto y uso – Administre la cuota de API, el presupuesto y los límites de uso para el uso permitido de modelos básicos con una frecuencia definida por inquilino
• Control de acceso y gobernanza del modelo. – Definir controles de acceso para modelos listados permitidos específicos por inquilino
• API estandarizada multiinquilino – Proporcionar acceso consistente a modelos de cimentación con OpenAPI estándares de salud
• Gestión centralizada de API – Proporcionar una única capa para gestionar las claves API para acceder a los modelos.
• Versiones y actualizaciones de modelos. – Manejar implementaciones de versiones de modelos nuevas y actualizadas

Resumen de la solución

En esta solución nos referimos a un multiinquilino Acercarse. UNA inquilino aquí puede variar desde un usuario individual, un proyecto específico, un equipo o incluso un departamento completo. Cuando analizamos el enfoque, utilizamos el término equipo, porque es el más común. Usamos claves API para restringir y monitorear el acceso a la API para los equipos. A cada equipo se le asigna una clave API para acceder a los FM. Puede haber diferentes mecanismos de autenticación y autorización de usuarios implementados en una organización. Por simplicidad, no los incluimos en esta solución. También puede integrar proveedores de identidad existentes con esta solución.

El siguiente diagrama resume la arquitectura de la solución y los componentes clave. Los equipos (inquilinos) asignados a centros de costos separados consumen Amazon Bedrock FM a través de un servicio API. Para realizar un seguimiento del consumo y el costo por equipo, la solución registra datos para cada invocación individual, incluido el modelo invocado, la cantidad de tokens para los modelos de generación de texto y las dimensiones de la imagen para los modelos multimodales. Además, agrega las invocaciones por modelo y costos por cada equipo.

Puede implementar la solución en su propia cuenta utilizando AWS CDK. AWS CDK es un marco de desarrollo de software de código abierto para modelar y aprovisionar los recursos de sus aplicaciones en la nube utilizando lenguajes de programación familiares. El código AWS CDK está disponible en el Repositorio GitHub.

En las siguientes secciones, analizamos los componentes clave de la solución con más detalle.

Capturar el uso del modelo básico por equipo

El flujo de trabajo para capturar el uso de FM por equipo consta de los siguientes pasos (como se enumeran en el diagrama anterior):

1. La aplicación de un equipo envía una solicitud POST a Puerta de enlace API de Amazon con el modelo a invocar en el model_id parámetro de consulta y el mensaje de usuario en el cuerpo de la solicitud.
2. API Gateway enruta la solicitud a un AWS Lambda función (bedrock_invoke_model) que es responsable de registrar la información de uso del equipo en Reloj en la nube de Amazon e invocando el modelo Amazon Bedrock.
3. Amazon Bedrock proporciona un punto final de VPC impulsado por Enlace privado de AWS. En esta solución, la función Lambda envía la solicitud a Amazon Bedrock mediante PrivateLink para establecer una conexión privada entre la VPC de su cuenta y la cuenta de servicio de Amazon Bedrock. Para obtener más información sobre PrivateLink, consulte Utilice AWS PrivateLink para configurar el acceso privado a Amazon Bedrock.
4. Después de la invocación de Amazon Bedrock, Amazon CloudTrail genera un Evento CloudTrail.
5. Si la llamada de Amazon Bedrock se realiza correctamente, la función Lambda registra la siguiente información según el tipo de modelo invocado y devuelve la respuesta generada a la aplicación:
   • equipo_id – El identificador único del equipo que emite la solicitud.
   • ID de solicitud – El identificador único de la solicitud.
   • modelo_id – El ID del modelo que se va a invocar.
   • tokens de entrada – La cantidad de tokens enviados al modelo como parte del mensaje (para generación de texto y modelos incrustados).
   • tokens de salida – El número máximo de tokens que generará el modelo (para modelos de generación de texto).
   • altura – La altura de la imagen solicitada (para modelos multimodales y modelos de incrustaciones multimodales).
   • anchura – El ancho de la imagen solicitada (solo para modelos multimodales).
   • pasos – Los pasos solicitados (para modelos Stability AI).

Seguimiento de costos por equipo

Un flujo diferente agrega la información de uso y luego calcula y guarda los costos bajo demanda por equipo diariamente. Al tener un flujo separado, garantizamos que el seguimiento de costos no afecte la latencia y el rendimiento del flujo de invocación del modelo. Los pasos del flujo de trabajo son los siguientes:

1. An Puente de eventos de Amazon La regla desencadena una función Lambda (bedrock_cost_tracking) diariamente.
2. La función Lambda obtiene la información de uso de CloudWatch del día anterior, calcula los costos asociados y almacena los datos agregados por team_id y model_id in Servicio de almacenamiento simple de Amazon (Amazon S3) en formato CSV.

Para consultar y visualizar los datos almacenados en Amazon S3, tiene diferentes opciones, que incluyen S3 Seleccionary Amazon Athena y Amazon QuickSight.

Controlar el uso por equipo

Un plan de uso especifica quién puede acceder a una o más API implementadas y, opcionalmente, establece la tasa de solicitudes objetivo para comenzar a limitar las solicitudes. El plan utiliza claves API para identificar clientes API que pueden acceder a la API asociada para cada clave. Puedes usar API Gateway planes de uso para acelerar las solicitudes que superan los umbrales predefinidos. También puedes usar Claves API y límites de cuota, que le permiten establecer la cantidad máxima de solicitudes por clave API que cada equipo puede emitir dentro de un intervalo de tiempo específico. Esto es además de Cuotas de servicio de Amazon Bedrock que se asignan únicamente a nivel de cuenta.

Requisitos previos

Antes de implementar la solución, asegúrese de tener lo siguiente:

Implemente la pila de CDK de AWS

Siga las instrucciones del README archivo del repositorio de GitHub para configurar e implementar la pila de AWS CDK.

La pila implementa los siguientes recursos:

• Entorno de red privado (VPC, subredes privadas, grupo de seguridad)
• Rol de IAM para controlar el acceso al modelo
• Capas Lambda para los módulos Python necesarios
• función lambda invoke_model
• función lambda list_foundation_models
• función lambda cost_tracking
• API de descanso (puerta de enlace API)
• Plan de uso de API Gateway
• Clave API asociada al plan de uso

A bordo de un nuevo equipo

Para brindar acceso a nuevos equipos, puede compartir la misma clave API entre diferentes equipos y realizar un seguimiento de los consumos del modelo proporcionando una clave diferente. team_id para la invocación de API, o cree claves de API dedicadas utilizadas para acceder a los recursos de Amazon Bedrock siguiendo las instrucciones proporcionadas en el README.

La pila implementa los siguientes recursos:

• Plan de uso de API Gateway asociado a la API REST creada previamente
• Clave API asociada al plan de uso para el nuevo equipo, con configuraciones reservadas de aceleración y ráfaga para la API

Para obtener más información sobre las configuraciones de aceleración y ráfaga de API Gateway, consulte Acelere las solicitudes de API para mejorar el rendimiento.

Después de implementar la pila, puede ver que la nueva clave API para team-2 también se crea.

Configurar el control de acceso al modelo

El administrador de la plataforma puede permitir el acceso a modelos básicos específicos editando la política de IAM asociada a la función Lambda. invoke_model.

Los permisos de IAM se definen en el archivo configuración/stack_constructs/iam.py. Ver el siguiente código:

self.bedrock_policy = iam.Policy(
            scope=self,
            id=f"{self.id}_policy_bedrock",
            policy_name="BedrockPolicy",
            statements=[
                iam.PolicyStatement(
                    effect=iam.Effect.ALLOW,
                    actions=[
                        "sts:AssumeRole",
                    ],
                    resources=["*"],
                ),
                iam.PolicyStatement(
                    effect=iam.Effect.ALLOW,
                    actions=[
                        "bedrock:InvokeModel",
				“bedrock:ListFoundationModels",

                    ],
                    resources=[
  	"arn:aws:bedrock:*::foundation-model/anthropic.claude-v2.1",
	"arn:aws:bedrock:*::foundation-model/amazon.titan-text-express-v1",
	"arn:aws:bedrock:*::foundation-model/amazon.titan-embed-text-v1"
],
                )
            ],
        )

…

self.bedrock_policy.attach_to_role(self.lambda_role)

Invocar el servicio

Una vez que haya implementado la solución, puede invocar el servicio directamente desde su código. La siguiente

es un ejemplo en Python para consumir el invoke_model API para generación de texto mediante una solicitud POST:

api_key=”abcd1234”

model_id = "amazon.titan-text-express-v1" #the model id for the Amazon Titan Express model
 
model_kwargs = { # inference configuration
    "maxTokenCount": 4096,
    "temperature": 0.2
}

prompt = "What is Amazon Bedrock?"

response = requests.post(
    f"{api_url}/invoke_model?model_id={model_id}",
    json={"inputs": prompt, "parameters": model_kwargs},
    headers={
        "x-api-key": api_key, #key for querying the API
        "team_id": team_id #unique tenant identifier 
    }
)

text = response.json()[0]["generated_text"]

print(text)

Resultado: Amazon Bedrock es una plataforma tecnológica interna desarrollada por Amazon para ejecutar y operar muchos de sus servicios y productos. Algunas cosas clave sobre Bedrock...

El siguiente es otro ejemplo en Python para consumir el invoke_model API para generación de incrustaciones mediante una solicitud POST:

model_id = "amazon.titan-embed-text-v1" #the model id for the Amazon Titan Embeddings Text model

prompt = "What is Amazon Bedrock?"

response = requests.post(
    f"{api_url}/invoke_model?model_id={model_id}",
    json={"inputs": prompt, "parameters": model_kwargs},
    headers={
        "x-api-key": api_key, #key for querying the API
        "team_id": team_id #unique tenant identifier,
	"embeddings": "true" #boolean value for the embeddings model 
    }
)

text = response.json()[0]["embedding"]

Salida: 0.91796875, 0.45117188, 0.52734375, -0.18652344, 0.06982422, 0.65234375, -0.13085938, 0.056884766, 0.092285156, 0.06982422, 1.03125, 0.8515625, 0.16308594, 0.079589844, -0.033935547, 0.796875, -0.15429688, -0.29882812, -0.25585938, 0.45703125, 0.044921875 0.34570312, XNUMX…

Acceso denegado a los modelos de fundación

El siguiente es un ejemplo en Python para consumir el invoke_model API para generación de texto a través de una solicitud POST con respuesta de acceso denegado:

model_id = " anthropic.claude-v1" #the model id for Anthropic Claude V1 model
 
model_kwargs = { # inference configuration
    "maxTokenCount": 4096,
    "temperature": 0.2
}

prompt = "What is Amazon Bedrock?"

response = requests.post(
    f"{api_url}/invoke_model?model_id={model_id}",
    json={"inputs": prompt, "parameters": model_kwargs},
    headers={
        "x-api-key": api_key, #key for querying the API
        "team_id": team_id #unique tenant identifier 
    }
)

print(response)
print(response.text)

"Rastreo (última llamada más reciente): n Archivo "/var/task/index.py", línea 213, en lambda_handlern respuesta = _invoke_text(bedrock_client, model_id, body, model_kwargs)n Archivo "/var/task/index.py ”, línea 146, en _invoke_textn rise en Archivo “/var/task/index.py”, línea 131, en _invoke_textn respuesta = bedrock_client.invoke_model(n Archivo “/opt/python/botocore/client.py”, línea 535, en _api_calln devuelve self._make_api_call(nombre_operación, kwargs)n Archivo "/opt/python/botocore/client.py", línea 980, en _make_api_calln genera error_class(parsed_response, nombre_operación)nbotocore.errorfactory.AccessDeniedException: Se produjo un error (AccessDeniedException) al llamar a la operación InvokeModel: Su cuenta no está autorizada para invocar esta operación API.

Ejemplo de estimación de costos

Al invocar modelos de Amazon Bedrock con precios según demanda, el costo total se calcula como la suma de los costos de entrada y salida. Los costos de entrada se basan en la cantidad de tokens de entrada enviados al modelo y los costos de salida se basan en los tokens generados. Los precios son por 1,000 tokens de entrada y por 1,000 tokens de salida. Para obtener más detalles y precios de modelos específicos, consulte Precios de Amazon Bedrock.

Veamos un ejemplo en el que dos equipos, equipo1 y equipo2, acceden a Amazon Bedrock a través de la solución de esta publicación. Los datos de uso y costos guardados en Amazon S3 en un solo día se muestran en la siguiente tabla.

Las columnas input_tokens y output_tokens almacene el total de tokens de entrada y salida en las invocaciones de modelos por modelo y por equipo, respectivamente, para un día determinado.

Las columnas input_cost y output_cost almacenar los costos respectivos por modelo y por equipo. Estos se calculan utilizando las siguientes fórmulas:

input_cost = input_token_count * model_pricing["input_cost"] / 1000
output_cost = output_token_count * model_pricing["output_cost"] / 1000

Vista de extremo a extremo de un entorno SaaS funcional sin servidor multiinquilino

Entendamos cómo sería un entorno SaaS funcional de extremo a extremo, multiinquilino y sin servidor. El siguiente es un diagrama de arquitectura de referencia.

Este diagrama de arquitectura es una versión reducida del diagrama de arquitectura anterior explicado anteriormente en la publicación, donde el diagrama de arquitectura anterior explica los detalles de uno de los microservicios mencionados (servicio modelo fundamental). Este diagrama explica que, además del servicio modelo fundamental, también necesita tener otros componentes en su plataforma SaaS multiinquilino para implementar una plataforma funcional y escalable.

Repasemos los detalles de la arquitectura.

Solicitudes de inquilinos

Las aplicaciones inquilino son las aplicaciones front-end que interactúan con el entorno. Aquí, mostramos varios inquilinos que acceden desde diferentes entornos locales o de AWS. Las aplicaciones de front-end se pueden ampliar para incluir una página de registro para que los nuevos inquilinos se registren y una consola de administración para los administradores de la capa de servicio SaaS. Si las aplicaciones del inquilino requieren la implementación de una lógica personalizada que necesita interacción con el entorno SaaS, pueden implementar las especificaciones del microservicio del adaptador de aplicaciones. Los escenarios de ejemplo podrían ser agregar una lógica de autorización personalizada respetando al mismo tiempo las especificaciones de autorización del entorno SaaS.

Servicios compartidos

Los siguientes son servicios compartidos:

• Servicios de gestión de inquilinos y usuarios. –Estos servicios se encargan del registro y gestión de los inquilinos. Proporcionan una funcionalidad transversal que está separada de los servicios de aplicaciones y que se comparte entre todos los inquilinos.
• Servicio de modelo de fundación –El diagrama de arquitectura de la solución explicado al principio de esta publicación representa este microservicio, donde la interacción desde API Gateway con las funciones Lambda se produce dentro del alcance de este microservicio. Todos los inquilinos utilizan este microservicio para invocar los modelos básicos de Anthropic, AI21, Cohere, Stability, Meta y Amazon, así como modelos ajustados. También captura la información necesaria para el seguimiento del uso en los registros de CloudWatch.
• Servicio de seguimiento de costos –Este servicio rastrea el costo y el uso de cada inquilino. Este microservicio se ejecuta según una programación para consultar los registros de CloudWatch y generar el seguimiento de uso agregado y el costo inferido en el almacenamiento de datos. El servicio de seguimiento de costos se puede ampliar para crear más informes y visualizaciones.

Servicio de adaptador de aplicaciones

Este servicio presenta un conjunto de especificaciones y API que un inquilino puede implementar para integrar su lógica personalizada al entorno SaaS. Según la cantidad de integración personalizada que se necesite, este componente puede ser opcional para los inquilinos.

Almacén de datos multiinquilino

Los servicios compartidos almacenan sus datos en un almacén de datos que puede ser un único compartido Amazon DynamoDB tabla con una clave de partición de inquilinos que asocia elementos de DynamoDB con inquilinos individuales. El servicio compartido de seguimiento de costos genera los datos agregados de seguimiento de costos y uso en Amazon S3. Según el caso de uso, también puede haber un almacén de datos específico de la aplicación.

Un entorno SaaS multiinquilino puede tener muchos más componentes. Para obtener más información, consulte Creación de una solución SaaS multiinquilino mediante los servicios sin servidor de AWS.

Soporte para múltiples modelos de implementación

Los marcos SaaS suelen describir dos modelos de implementación: grupo y silo. Para el modelo de grupo, todos los inquilinos acceden a los FM desde un entorno compartido con infraestructura informática y de almacenamiento común. En el modelo de silo, cada inquilino tiene su propio conjunto de recursos dedicados. Puede leer sobre los modelos de aislamiento en el Documento técnico sobre las estrategias de aislamiento de inquilinos de SaaS.

La solución propuesta se puede adoptar para ambos modelos de implementación de SaaS. En el enfoque del grupo, un entorno de AWS centralizado aloja la API, el almacenamiento y los recursos informáticos. En modo silo, cada equipo accede a las API, el almacenamiento y los recursos informáticos en un entorno de AWS dedicado.

La solución también encaja con los planes de consumo disponibles proporcionados por Amazon Bedrock. AWS ofrece una opción de dos planes de consumo para la inferencia:

• On-Demand – Este modo le permite utilizar modelos básicos de pago por uso sin tener que contraer compromisos de plazos basados ​​en el tiempo.
• Rendimiento aprovisionado – Este modo le permite proporcionar suficiente rendimiento para cumplir con los requisitos de rendimiento de su aplicación a cambio de un compromiso de plazo basado en el tiempo.

Para obtener más información sobre estas opciones, consulte Precios de Amazon Bedrock.

La solución de referencia SaaS sin servidor descrita en esta publicación puede aplicar los planes de consumo de Amazon Bedrock para brindar opciones de niveles básicos y premium a los usuarios finales. Básico podría incluir el consumo de rendimiento aprovisionado o bajo demanda de Amazon Bedrock y podría incluir límites de presupuesto y uso específicos. Los límites de inquilinos se pueden habilitar limitando las solicitudes en función de las solicitudes, el tamaño de los tokens o la asignación de presupuesto. Los inquilinos del nivel premium podrían tener sus propios recursos dedicados con el consumo de rendimiento aprovisionado de Amazon Bedrock. Estos inquilinos normalmente estarían asociados con cargas de trabajo de producción que requieren alto rendimiento y acceso de baja latencia a Amazon Bedrock FM.

Conclusión

En esta publicación, analizamos cómo crear una plataforma SaaS interna para acceder a modelos básicos con Amazon Bedrock en una configuración multiinquilino con un enfoque en el seguimiento de los costos y el uso, y en la limitación de límites para cada inquilino. Los temas adicionales a explorar incluyen la integración de soluciones de autenticación y autorización existentes en la organización, la mejora de la capa API para incluir sockets web para interacciones bidireccionales entre cliente y servidor, la adición de filtrado de contenido y otras barreras de gobernanza, el diseño de múltiples niveles de implementación y la integración de otros microservicios en SaaS. arquitectura y muchos más.

El código completo para esta solución está disponible en el Repositorio GitHub.

Para obtener más información sobre los marcos basados ​​en SaaS, consulte Marco de viaje de SaaS: creación de una nueva solución SaaS en AWS.

Acerca de los autores

Hasan Poonawala es un arquitecto senior de soluciones especializado en IA/ML en AWS y trabaja con clientes de atención médica y ciencias biológicas. Hasan ayuda a diseñar, implementar y escalar aplicaciones de inteligencia artificial generativa y aprendizaje automático en AWS. Tiene más de 15 años de experiencia laboral combinada en aprendizaje automático, desarrollo de software y ciencia de datos en la nube. En su tiempo libre, a Hasan le encanta explorar la naturaleza y pasar tiempo con amigos y familiares.

Anastasia Tzeveleká es arquitecto senior de soluciones especializado en IA/ML en AWS. Como parte de su trabajo, ayuda a los clientes de toda EMEA a crear modelos básicos y soluciones escalables de inteligencia artificial generativa y aprendizaje automático utilizando los servicios de AWS.

Brusin pistón es un arquitecto de soluciones especializado en inteligencia artificial generativa y aprendizaje automático para AWS con sede en Milán. Trabaja con grandes clientes ayudándoles a comprender en profundidad sus necesidades técnicas y a diseñar soluciones de inteligencia artificial y aprendizaje automático que aprovechen al máximo la nube de AWS y la pila de aprendizaje automático de Amazon. Su experiencia incluye: aprendizaje automático de extremo a extremo, industrialización del aprendizaje automático e inteligencia artificial generativa. Le gusta pasar tiempo con sus amigos y explorar nuevos lugares, además de viajar a nuevos destinos.

vikesh pandey es un arquitecto de soluciones generativas de IA/ML, que se especializa en servicios financieros, donde ayuda a los clientes financieros a construir y escalar plataformas y soluciones generativas de IA/ML que escalan a cientos o incluso miles de usuarios. En su tiempo libre, a Vikesh le gusta escribir en varios foros de blogs y construir legos con su hijo.

• Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
• PlatoData.Network Vertical Generativo Ai. Empodérate. Accede Aquí.
• PlatoAiStream. Inteligencia Web3. Conocimiento amplificado. Accede Aquí.
• PlatoESG. Carbón, tecnología limpia, Energía, Ambiente, Solar, Gestión de residuos. Accede Aquí.
• PlatoSalud. Inteligencia en Biotecnología y Ensayos Clínicos. Accede Aquí.
• Fuente: https://aws.amazon.com/blogs/machine-learning/build-an-internal-saas-service-with-cost-and-usage-tracking-for-foundation-models-on-amazon-bedrock/