Crie um serviço SaaS interno com rastreamento de custo e uso para modelos básicos no Amazon Bedrock | Amazon Web Services

As empresas procuram desbloquear rapidamente o potencial da IA ​​generativa, fornecendo acesso a modelos básicos (FMs) para diferentes linhas de negócios (LOBs). As equipes de TI são responsáveis ​​por ajudar a LOB a inovar com velocidade e agilidade, ao mesmo tempo que fornecem governança e observabilidade centralizadas. Por exemplo, eles podem precisar acompanhar o uso de FMs entre equipes, estornar custos e fornecer visibilidade ao centro de custo relevante na LOB. Além disso, eles podem precisar regular o acesso a diferentes modelos por equipe. Por exemplo, se apenas FMs específicos puderem ser aprovados para uso.

Rocha Amazônica é um serviço totalmente gerenciado que oferece uma escolha de modelos básicos de alto desempenho de empresas líderes de IA como AI21 Labs, Anthropic, Cohere, Meta, Stability AI e Amazon por meio de uma única API, juntamente com um amplo conjunto de recursos para construir IA generativa aplicativos com segurança, privacidade e IA responsável. Como o Amazon Bedrock não tem servidor, você não precisa gerenciar nenhuma infraestrutura e pode integrar e implantar com segurança recursos de IA generativos em seus aplicativos usando os serviços da AWS com os quais você já está familiarizado.

Uma camada de software como serviço (SaaS) para modelos básicos pode fornecer uma interface simples e consistente para os usuários finais, ao mesmo tempo que mantém a governança centralizada de acesso e consumo. Os gateways de API podem fornecer acoplamento flexível entre os consumidores do modelo e o serviço de endpoint do modelo, além de flexibilidade para se adaptar às mudanças no modelo, nas arquiteturas e nos métodos de invocação.

Nesta postagem, mostramos como construir uma camada SaaS interna para acessar modelos básicos com Amazon Bedrock em uma arquitetura multilocatário (equipe). Nós nos concentramos especificamente no uso e no rastreamento de custos por locatário e também em controles como limitação de uso por locatário. Descrevemos como a solução e os planos de consumo do Amazon Bedrock são mapeados para a estrutura geral da jornada do SaaS. O código da solução e um Kit de desenvolvimento em nuvem da AWS (AWS CDK) está disponível no Repositório GitHub.

Desafios

Um administrador de plataforma de IA precisa fornecer acesso fácil e padronizado aos FMs para diversas equipes de desenvolvimento.

A seguir estão alguns dos desafios para fornecer acesso governado aos modelos básicos:

• Acompanhamento de custo e uso – Rastreie e audite os custos individuais dos inquilinos e o uso de modelos básicos e forneça custos de estorno para centros de custo específicos
• Controles de orçamento e uso – Gerencie cotas de API, orçamento e limites de uso para o uso permitido de modelos básicos em uma frequência definida por locatário
• Controle de acesso e governança de modelo – Definir controles de acesso para modelos listados com permissões específicas por locatário
• API padronizada para vários locatários – Fornece acesso consistente a modelos de fundação com API aberta padrões
• Gerenciamento centralizado de API – Fornece uma única camada para gerenciar chaves de API para acessar modelos
• Versões e atualizações do modelo – Lidar com lançamentos de versões de modelos novos e atualizados

Visão geral da solução

Nesta solução, referimo-nos a um Multi inquilino abordagem. A inquilino aqui pode variar de um usuário individual, um projeto específico, uma equipe ou até mesmo um departamento inteiro. Ao discutirmos a abordagem, usamos o termo Profissionais, porque é o mais comum. Usamos chaves de API para restringir e monitorar o acesso à API para equipes. Cada equipe recebe uma chave API para acesso aos FMs. Pode haver diferentes mecanismos de autenticação e autorização de usuários implantados em uma organização. Por simplicidade, não os incluímos nesta solução. Você também pode integrar provedores de identidade existentes com esta solução.

O diagrama a seguir resume a arquitetura da solução e os principais componentes. Equipes (locatários) atribuídas a centros de custo separados consomem Amazon Bedrock FMs por meio de um serviço de API. Para rastrear o consumo e o custo por equipe, a solução registra dados para cada invocação individual, incluindo o modelo invocado, o número de tokens para modelos de geração de texto e dimensões de imagem para modelos multimodais. Além disso, agrega as invocações por modelo e os custos de cada equipe.

Você pode implantar a solução em sua própria conta usando o AWS CDK. O AWS CDK é uma estrutura de desenvolvimento de software de código aberto para modelar e provisionar recursos de aplicativos em nuvem usando linguagens de programação familiares. O código AWS CDK está disponível no Repositório GitHub.

Nas seções a seguir, discutiremos os principais componentes da solução com mais detalhes.

Capturando o uso do modelo básico por equipe

O fluxo de trabalho para capturar o uso de FM por equipe consiste nas seguintes etapas (conforme numeradas no diagrama anterior):

1. O aplicativo de uma equipe envia uma solicitação POST para Gateway de API da Amazon com o modelo a ser invocado no model_id parâmetro de consulta e o prompt do usuário no corpo da solicitação.
2. O API Gateway roteia a solicitação para um AWS Lambda função (bedrock_invoke_model) que é responsável por registrar informações de uso da equipe em Amazon CloudWatch e invocando o modelo Amazon Bedrock.
3. O Amazon Bedrock fornece um VPC endpoint desenvolvido por AWS PrivateLink. Nesta solução, a função Lambda envia a solicitação ao Amazon Bedrock usando PrivateLink para estabelecer uma conexão privada entre a VPC da sua conta e a conta de serviço do Amazon Bedrock. Para saber mais sobre o PrivateLink, consulte Use o AWS PrivateLink para configurar o acesso privado ao Amazon Bedrock.
4. Após a invocação do Amazon Bedrock, Amazon CloudTrail gera um Evento CloudTrail.
5. Se a chamada do Amazon Bedrock for bem-sucedida, a função Lambda registrará as seguintes informações dependendo do tipo de modelo invocado e retornará a resposta gerada ao aplicativo:
   • id_da_equipe – O identificador exclusivo da equipe que emite a solicitação.
   • Identificação do Pedido – O identificador exclusivo da solicitação.
   • id_modelo – O ID do modelo a ser invocado.
   • entradaTokens – O número de tokens enviados ao modelo como parte do prompt (para geração de texto e modelos de incorporação).
   • saídaTokens – O número máximo de tokens a serem gerados pelo modelo (para modelos de geração de texto).
   • altura – A altura da imagem solicitada (para modelos multimodais e modelos de embeddings multimodais).
   • largura – A largura da imagem solicitada (somente para modelos multimodais).
   • passos – As etapas solicitadas (para modelos de IA de estabilidade).

Acompanhamento de custos por equipe

Um fluxo diferente agrega as informações de uso e, em seguida, calcula e salva diariamente os custos sob demanda por equipe. Ao ter um fluxo separado, garantimos que o acompanhamento de custos não afeta a latência e a produção do fluxo de invocação do modelo. As etapas do fluxo de trabalho são as seguintes:

1. An Amazon Event Bridge regra aciona uma função Lambda (bedrock_cost_tracking) diário.
2. A função Lambda obtém as informações de uso do CloudWatch do dia anterior, calcula os custos associados e armazena os dados agregados por team_id e model_id in Serviço de armazenamento simples da Amazon (Amazon S3) em formato CSV.

Para consultar e visualizar os dados armazenados no Amazon S3, você tem diferentes opções, incluindo Seleção S3 e Amazon Athena e Amazon QuickSight.

Controlando o uso por equipe

Um plano de uso especifica quem pode acessar uma ou mais APIs implantadas e, opcionalmente, define a taxa de solicitação alvo para começar a limitar as solicitações. O plano usa chaves de API para identificar clientes de API que podem acessar a API associada para cada chave. Você pode usar o API Gateway planos de uso para limitar solicitações que excedam limites predefinidos. Você também pode usar Chaves API e limites de cota, que permitem definir o número máximo de solicitações por chave de API que cada equipe pode emitir dentro de um intervalo de tempo especificado. Isto é além de Cotas de serviço Amazon Bedrock que são atribuídos somente no nível da conta.

Pré-requisitos

Antes de implantar a solução, certifique-se de ter o seguinte:

Implante a pilha do AWS CDK

Siga as instruções no README arquivo do repositório GitHub para configurar e implantar a pilha AWS CDK.

A pilha implanta os seguintes recursos:

• Ambiente de rede privada (VPC, sub-redes privadas, grupo de segurança)
• Função do IAM para controlar o acesso ao modelo
• Camadas Lambda para os módulos Python necessários
• Função lambda invoke_model
• Função lambda list_foundation_models
• Função lambda cost_tracking
• API Rest (API Gateway)
• Plano de uso do API Gateway
• Chave API associada ao plano de utilização

Integre uma nova equipe

Para fornecer acesso a novas equipes, você pode compartilhar a mesma chave de API entre equipes diferentes e rastrear o consumo do modelo fornecendo uma chave diferente. team_id para a invocação de API ou crie chaves de API dedicadas usadas para acessar recursos do Amazon Bedrock seguindo as instruções fornecidas no README.

A pilha implanta os seguintes recursos:

• Plano de uso do API Gateway associado à API REST criada anteriormente
• Chave de API associada ao plano de uso da nova equipe, com configurações reservadas de limitação e burst para a API

Para obter mais informações sobre configurações de limitação e intermitência do API Gateway, consulte Acelere as solicitações de API para obter melhor rendimento.

Depois de implantar a pilha, você verá que a nova chave de API para team-2 também é criado.

Configurar o controle de acesso do modelo

O administrador da plataforma pode permitir acesso a modelos básicos específicos editando a política IAM associada à função Lambda invoke_model. O

As permissões do IAM são definidas no arquivo setup/stack_constructs/iam.py. Veja o seguinte 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 o serviço

Depois de implantar a solução, você poderá invocar o serviço diretamente do seu código. A seguir

é um exemplo em Python para consumir o invoke_model API para geração de texto através de uma solicitação 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 é uma plataforma tecnológica interna desenvolvida pela Amazon para executar e operar muitos de seus serviços e produtos. Algumas coisas importantes sobre Bedrock…

A seguir está outro exemplo em Python para consumir o invoke_model API para geração de embeddings através de uma solicitação 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"]

Saída: 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…

Acesso negado a modelos de fundação

A seguir está um exemplo em Python para consumir o invoke_model API para geração de texto através de uma solicitação POST com resposta de acesso negado:

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)

“Traceback (última chamada mais recente):n Arquivo ”/var/task/index.py”, linha 213, em lambda_handlern resposta = _invoke_text(bedrock_client, model_id, body, model_kwargs)n Arquivo ”/var/task/index.py ”, linha 146, em _invoke_textn raise en Arquivo ”/var/task/index.py”, linha 131, em _invoke_textn resposta = bedrock_client.invoke_model(n Arquivo ”/opt/python/botocore/client.py”, linha 535, em _api_calln retorne self._make_api_call (nome_da operação, kwargs)n Arquivo ”/opt/python/botocore/client.py”, linha 980, em _make_api_calln levante error_class (parsed_response, nome_da operação) nbotocore.errorfactory.AccessDeniedException: Ocorreu um erro (AccessDeniedException) ao chamar a operação InvokeModel: Sua conta não está autorizada a invocar esta operação API.n”

Exemplo de estimativa de custos

Ao invocar modelos do Amazon Bedrock com preços sob demanda, o custo total é calculado como a soma dos custos de entrada e saída. Os custos de entrada são baseados no número de tokens de entrada enviados ao modelo e os custos de saída são baseados nos tokens gerados. Os preços são por 1,000 tokens de entrada e por 1,000 tokens de saída. Para obter mais detalhes e preços de modelos específicos, consulte Preços da Amazon Bedrock.

Vejamos um exemplo em que duas equipes, team1 e team2, acessam o Amazon Bedrock por meio da solução desta postagem. Os dados de uso e custo salvos no Amazon S3 em um único dia são mostrados na tabela a seguir.

As colunas input_tokens e output_tokens armazene o total de tokens de entrada e saída em invocações de modelo por modelo e por equipe, respectivamente, para um determinado dia.

As colunas input_cost e output_cost armazenar os respectivos custos por modelo e por equipe. Eles são calculados usando as seguintes fórmulas:

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

Visão completa de um ambiente SaaS sem servidor e multilocatário funcional

Vamos entender como pode ser um ambiente SaaS funcional multilocatário sem servidor de ponta a ponta. A seguir está um diagrama de arquitetura de referência.

Este diagrama de arquitetura é uma versão ampliada do diagrama de arquitetura anterior explicado anteriormente na postagem, onde o diagrama de arquitetura anterior explica os detalhes de um dos microsserviços mencionados (serviço de modelo fundamental). Este diagrama explica que, além do serviço de modelo fundamental, você também precisa ter outros componentes em sua plataforma SaaS multilocatário para implementar uma plataforma funcional e escalonável.

Vamos examinar os detalhes da arquitetura.

Aplicativos de inquilino

Os aplicativos de locatário são os aplicativos front-end que interagem com o ambiente. Aqui, mostramos vários locatários acessando de diferentes ambientes locais ou AWS. Os aplicativos front-end podem ser estendidos para incluir uma página de registro para novos locatários se registrarem e um console de administração para administradores da camada de serviço SaaS. Se os aplicativos de locatário exigirem a implementação de uma lógica customizada que precise de interação com o ambiente SaaS, eles poderão implementar as especificações do microsserviço do adaptador de aplicativo. Cenários de exemplo poderiam incluir a adição de lógica de autorização personalizada, respeitando as especificações de autorização do ambiente SaaS.

Serviços compartilhados

Os seguintes são serviços compartilhados:

• Serviços de gerenciamento de locatários e usuários –Estes serviços são responsáveis ​​pelo registo e gestão dos inquilinos. Eles fornecem a funcionalidade transversal separada dos serviços de aplicativo e compartilhada entre todos os locatários.
• Serviço de modelo de fundação –O diagrama de arquitetura da solução explicado no início deste post representa este microsserviço, onde a interação do API Gateway com as funções Lambda está acontecendo dentro do escopo deste microsserviço. Todos os locatários usam esse microsserviço para invocar os modelos básicos de Anthropic, AI21, Cohere, Stability, Meta e Amazon, bem como modelos ajustados. Ele também captura as informações necessárias para rastreamento de uso nos logs do CloudWatch.
• Serviço de rastreamento de custos –Este serviço rastreia o custo e o uso de cada inquilino. Esse microsserviço é executado de acordo com uma programação para consultar os logs do CloudWatch e gerar o rastreamento de uso agregado e o custo inferido para o armazenamento de dados. O serviço de rastreamento de custos pode ser estendido para criar mais relatórios e visualizações.

Serviço de adaptador de aplicativo

Este serviço apresenta um conjunto de especificações e APIs que um locatário pode implementar para integrar sua lógica customizada ao ambiente SaaS. Com base na quantidade de integração personalizada necessária, este componente pode ser opcional para locatários.

Armazenamento de dados multilocatário

Os serviços compartilhados armazenam seus dados em um data store que pode ser um único repositório compartilhado. Amazon DynamoDB tabela com uma chave de particionamento de locatário que associa itens do DynamoDB a locatários individuais. O serviço compartilhado de rastreamento de custos gera os dados agregados de uso e rastreamento de custos para o Amazon S3. Com base no caso de uso, também pode haver um armazenamento de dados específico do aplicativo.

Um ambiente SaaS multilocatário pode ter muito mais componentes. Para obter mais informações, consulte Construindo uma solução SaaS multilocatário usando serviços sem servidor da AWS.

Suporte para vários modelos de implantação

As estruturas SaaS normalmente descrevem dois modelos de implantação: pool e silo. Para o modelo de pool, todos os locatários acessam FMs a partir de um ambiente compartilhado com armazenamento comum e infraestrutura de computação. No modelo silo, cada locatário possui seu próprio conjunto de recursos dedicados. Você pode ler sobre modelos de isolamento no Whitepaper sobre estratégias de isolamento de locatário de SaaS.

A solução proposta pode ser adotada para ambos os modelos de implantação SaaS. Na abordagem de pool, um ambiente centralizado da AWS hospeda a API, o armazenamento e os recursos de computação. No modo silo, cada equipe acessa APIs, armazenamento e recursos de computação em um ambiente AWS dedicado.

A solução também se enquadra nos planos de consumo disponíveis fornecidos pela Amazon Bedrock. A AWS oferece a opção de dois planos de consumo para inferência:

• Sob demanda – Este modo permite que você use modelos básicos com base no pagamento conforme o uso, sem ter que assumir compromissos de prazo baseados no tempo
• Taxa de transferência provisionada – Este modo permite que você forneça rendimento suficiente para atender aos requisitos de desempenho do seu aplicativo em troca de um compromisso de prazo baseado em tempo

Para obter mais informações sobre essas opções, consulte Preços da Amazon Bedrock.

A solução de referência SaaS sem servidor descrita nesta postagem pode aplicar os planos de consumo do Amazon Bedrock para fornecer opções de níveis básicos e premium aos usuários finais. Básico pode incluir consumo de taxa de transferência sob demanda ou provisionada do Amazon Bedrock e pode incluir uso específico e limites de orçamento. Os limites de locatário podem ser habilitados limitando as solicitações com base em solicitações, tamanhos de token ou alocação de orçamento. Os locatários de nível premium podem ter seus próprios recursos dedicados com consumo de taxa de transferência provisionado do Amazon Bedrock. Esses locatários normalmente estariam associados a cargas de trabalho de produção que exigem alta taxa de transferência e acesso de baixa latência aos FMs do Amazon Bedrock.

Conclusão

Nesta postagem, discutimos como construir uma plataforma SaaS interna para acessar modelos básicos com o Amazon Bedrock em uma configuração multilocatário com foco no rastreamento de custos e uso e na limitação de limites para cada locatário. Tópicos adicionais a serem explorados incluem a integração de soluções de autenticação e autorização existentes na organização, o aprimoramento da camada de API para incluir web sockets para interações bidirecionais cliente-servidor, a adição de filtragem de conteúdo e outras proteções de governança, o projeto de múltiplas camadas de implantação, a integração de outros microsserviços no SaaS arquitetura e muito mais.

O código completo desta solução está disponível no Repositório GitHub.

Para obter mais informações sobre estruturas baseadas em SaaS, consulte Estrutura de jornada de SaaS: construindo uma nova solução SaaS na AWS.

Sobre os autores

Hasan Poonawala é arquiteto de soluções especialista sênior em IA/ML na AWS, trabalhando com clientes de saúde e ciências biológicas. Hasan ajuda a projetar, implantar e dimensionar aplicativos de IA generativa e aprendizado de máquina na AWS. Ele tem mais de 15 anos de experiência profissional combinada em aprendizado de máquina, desenvolvimento de software e ciência de dados na nuvem. Nas horas vagas, Hasan adora explorar a natureza e passar tempo com amigos e familiares.

Anastasia Tzeveleka é arquiteto de soluções especialista sênior em IA/ML na AWS. Como parte de seu trabalho, ela ajuda clientes em toda a região EMEA a construir modelos básicos e criar soluções escalonáveis ​​de IA generativa e machine learning usando serviços da AWS.

Brusem Pistone é arquiteto de soluções especializadas em IA generativa e ML para AWS com sede em Milão. Ele trabalha com grandes clientes, ajudando-os a compreender profundamente suas necessidades técnicas e a projetar soluções de IA e Machine Learning que fazem o melhor uso da nuvem AWS e da pilha Amazon Machine Learning. Sua experiência inclui: aprendizado de máquina de ponta a ponta, industrialização de aprendizado de máquina e IA generativa. Ele gosta de passar tempo com os amigos e explorar novos lugares, bem como viajar para novos destinos.

Pandey Vikesh é arquiteto de soluções generativas de IA/ML, especializado em serviços financeiros, onde ajuda clientes financeiros a construir e dimensionar plataformas e soluções generativas de IA/ML que podem ser dimensionadas para centenas ou até milhares de usuários. Nas horas vagas, Vikesh gosta de escrever em vários fóruns de blogs e construir legos com seu filho.

• Conteúdo com tecnologia de SEO e distribuição de relações públicas. Seja amplificado hoje.
• PlatoData.Network Gerativa Vertical Ai. Capacite-se. Acesse aqui.
• PlatoAiStream. Inteligência Web3. Conhecimento Amplificado. Acesse aqui.
• PlatãoESG. Carbono Tecnologia Limpa, Energia, Ambiente, Solar, Gestão de resíduos. Acesse aqui.
• PlatoHealth. Inteligência em Biotecnologia e Ensaios Clínicos. Acesse aqui.
• Fonte: https://aws.amazon.com/blogs/machine-learning/build-an-internal-saas-service-with-cost-and-usage-tracking-for-foundation-models-on-amazon-bedrock/