Modelos de IA de código aberto com garantias empresariais
Cada vez mais organizações estão adotando modelos de fundação de código aberto (open-weight) para alimentar cargas de trabalho de IA em produção — de assistentes de codificação agênticos a análise de documentos com contextos longos. À medida que essas cargas de trabalho evoluem da fase experimental para implantações corporativas, dois requisitos moldam toda decisão de seleção de modelos: o modelo precisa entregar as capacidades que a carga de trabalho exige, e o ambiente de inferência precisa atender aos requisitos de segurança e conformidade da organização.
Para endereçar essa necessidade, o Amazon Bedrock oferece um serviço totalmente gerenciado para acesso a modelos de fundação líderes de mercado, com a inferência rodando inteiramente na infraestrutura operada pela AWS. Os prompts e as respostas geradas não são usados para treinar nenhum modelo, e o conteúdo não é compartilhado com os provedores dos modelos.
A MiniMax é uma empresa global de tecnologia em IA que desenvolve modelos de fundação multimodais com ênfase em arquiteturas eficientes para cargas de trabalho em escala de produção. Agora, sua família M2 está disponível no Amazon Bedrock como modelos de código aberto totalmente gerenciados.
Os três modelos da família MiniMax M2
O Amazon Bedrock suporta três modelos da família MiniMax M2, cada um com características distintas para diferentes cenários de uso. Veja o resumo:
- MiniMax M2 (
minimax.minimax-m2): primeiro a ser lançado, com geração de texto multilíngue, raciocínio, codificação e uma janela de contexto de 1 milhão de tokens. Ideal para contextos longos ou uso geral multilíngue. - MiniMax M2.1 (
minimax.minimax-m2.1): traz melhorias em profundidade de raciocínio, precisão de codificação e seguimento de instruções. Janela de contexto de 196 mil tokens. Indicado para tarefas de raciocínio complexo ou seguimento de instruções em múltiplas etapas. - MiniMax M2.5 (
minimax.minimax-m2.5): o modelo mais recente, treinado especificamente para execução nativa de agentes, com ênfase em chamada de ferramentas (tool-calling), decomposição de tarefas em múltiplas etapas e tarefas de codificação de longo horizonte. Janela de contexto de 196 mil tokens. Melhor escolha para fluxos agênticos, chamada de ferramentas ou cargas de trabalho intensivas em código.
Todos os três modelos suportam os níveis de serviço Standard, Priority e Flex, com saída máxima de 8 mil tokens. Para a lista completa e atualizada, consulte a documentação de modelos MiniMax no Amazon Bedrock.
Arquitetura Mistura de Especialistas (MoE)
A família M2 é construída sobre uma arquitetura de Mistura de Especialistas (MoE), onde apenas uma pequena fração dos parâmetros totais é ativada por token. O MiniMax M2.5, por exemplo, possui 230 bilhões de parâmetros totais, mas apenas 10 bilhões ficam ativos por passagem. Isso significa que o modelo entrega a capacidade de conhecimento de um modelo de 230B enquanto consome computação proporcional a apenas 10B parâmetros — o que se traduz diretamente em menor custo de inferência.
Por serem modelos de código aberto, é possível avaliar independentemente a arquitetura e a metodologia de treinamento, executar benchmarks próprios em cargas de trabalho representativas e até realizar ajuste fino (fine-tuning) em dados proprietários — tudo isso através de um serviço gerenciado da AWS, sem necessidade de provisionar infraestrutura.
Dois endpoints para acessar os modelos MiniMax
O Amazon Bedrock oferece dois endpoints para invocar os modelos MiniMax:
Endpoint bedrock-mantle (recomendado)
O endpoint bedrock-mantle (https://bedrock-mantle.{region}.api.aws/v1) é a API pública do motor de inferência de nova geração do Amazon Bedrock. Ele utiliza a API Chat Completions — a mesma interface dos SDKs Python e TypeScript da OpenAI — o que significa que equipes que já utilizam esse SDK podem migrar para os modelos MiniMax no Bedrock simplesmente atualizando a URL base e o ID do modelo. Suporta chaves de API do Amazon Bedrock, projetos e chamada de ferramentas no lado do cliente.
Endpoint bedrock-runtime
O endpoint bedrock-runtime (https://bedrock-runtime.{region}.amazonaws.com) utiliza as APIs Converse e InvokeModel via SDK da AWS. Use este endpoint para funcionalidades nativas do Amazon Bedrock como Guardrails, Agents, Flows e avaliação de modelos.
Primeiros passos com MiniMax M2.5 no Amazon Bedrock
Playground no console
Para experimentar o modelo sem escrever código, basta acessar o console do Amazon Bedrock, selecionar “Chat/Text playground” no menu lateral em “Test”, escolher o modelo MiniMax M2.5 e clicar em “Apply”. O modelo carrega e a interface de chat já está pronta para uso.
Usando o endpoint bedrock-mantle com o SDK OpenAI
Para usar o endpoint bedrock-mantle, é necessária uma chave de API do Amazon Bedrock ou credenciais AWS configuradas para SigV4. A política mínima necessária é:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "BedrockMantleInference",
"Effect": "Allow",
"Action": [
"bedrock-mantle:CreateInference",
"bedrock-mantle:Get*",
"bedrock-mantle:List*"
],
"Resource": "arn:aws:bedrock-mantle:us-east-1:111122223333:project/*"
},
{
"Sid": "BedrockMantleApiKeyAccess",
"Effect": "Allow",
"Action": "bedrock-mantle:CallWithBearerToken",
"Resource": "*"
}
]
}
Substitua 111122223333 pelo ID da sua conta AWS. O primeiro bloco cobre autenticação SigV4; o segundo cobre autenticação por chave de API (bearer token). Se usar apenas SigV4, o segundo bloco pode ser omitido.
Para controlar quais identidades podem gerar ou usar chaves de API do Amazon Bedrock, consulte Controle de permissões para chaves de API do Amazon Bedrock. Para restringir a organização apenas a modelos aprovados, utilize uma Política de Controle de Serviço (SCP).
O exemplo abaixo usa o SDK Python da OpenAI como biblioteca cliente para chamar o endpoint bedrock-mantle. Para workloads em produção, use chaves de API de curta duração, que expiram automaticamente (máximo de 12 horas) e herdam as permissões da função do Gerenciamento de Identidade e Acesso da AWS (IAM) que as gerou. Se você já usa credenciais AWS e não tem uma chave de API, o pacote aws-bedrock-token-generator gera um bearer token de curta duração a partir dessas credenciais.
Nota: cada invocação de modelo incorre em cobranças por token. Consulte a página de preços do Amazon Bedrock para as tarifas atuais.
import boto3
from openai import OpenAI
# Retrieve the Amazon Bedrock API key from AWS Secrets Manager
secrets_client = boto3.client("secretsmanager", region_name="us-east-1")
api_key = secrets_client.get_secret_value(SecretId="bedrock-api-key")["SecretString"]
client = OpenAI(
base_url="https://bedrock-mantle.us-east-1.api.aws/v1",
api_key=api_key,
)
response = client.chat.completions.create(
model="minimax.minimax-m2.5",
messages=[
{"role": "user", "content": "Explain the benefits of mixture-of-experts architectures for production inference."}
],
max_tokens=512,
)
print(response.choices[0].message.content)
Nota: esses exemplos recuperam a chave de API do AWS Secrets Manager. Para desenvolvimento local, é possível ler a chave de uma variável de ambiente, mas evite esse padrão em produção.
Chamada de ferramentas (tool calling)
O MiniMax M2.5 é projetado para fluxos de trabalho agênticos, sendo bem adequado para cenários de chamada de ferramentas. Nesse fluxo, você define funções (ferramentas) que o modelo pode invocar, o modelo decide quando chamá-las com base na solicitação do usuário, e a aplicação executa a função e retorna o resultado para que o modelo o incorpore na resposta final.
O exemplo abaixo demonstra esse padrão de ponta a ponta: define uma ferramenta get_weather, envia uma mensagem do usuário, deixa o modelo solicitar a chamada da ferramenta, executa a função com dados simulados e passa o resultado de volta para o modelo gerar uma resposta em linguagem natural.
import json
import boto3
from openai import OpenAI
# Retrieve the Amazon Bedrock API key from AWS Secrets Manager
secrets_client = boto3.client("secretsmanager", region_name="us-east-1")
api_key = secrets_client.get_secret_value(SecretId="bedrock-api-key")["SecretString"]
client = OpenAI(
base_url="https://bedrock-mantle.us-east-1.api.aws/v1",
api_key=api_key,
)
tools = [
{
"type": "function",
"function": {
"name": "get_weather",
"description": "Get the current weather for a given location",
"parameters": {
"type": "object",
"properties": {
"location": {
"type": "string",
"description": "City and country (e.g., Seattle, US)"
},
"unit": {
"type": "string",
"enum": ["celsius", "fahrenheit"],
"description": "Temperature unit"
}
},
"required": ["location"]
}
}
}
]
# Step 1: Send the user request with tool definitions
messages = [
{"role": "user", "content": "What's the weather like in Seattle?"}
]
response = client.chat.completions.create(
model="minimax.minimax-m2.5",
messages=messages,
tools=tools,
tool_choice="auto",
)
assistant_message = response.choices[0].message
# Step 2: Check if the model wants to call a tool
if assistant_message.tool_calls:
messages.append(assistant_message)
for tool_call in assistant_message.tool_calls:
function_name = tool_call.function.name
arguments = json.loads(tool_call.function.arguments)
# Step 3: Validate function name and run
if function_name == "get_weather":
location = arguments.get("location", "Unknown")
unit = arguments.get("unit", "fahrenheit")
result = {
"location": location,
"temperature": 18 if unit == "celsius" else 64,
"unit": unit,
"condition": "Partly cloudy",
"humidity": 72,
}
else:
result = {"error": f"Unknown function: {function_name}"}
# Step 4: Return the function result to the model
messages.append({
"role": "tool",
"tool_call_id": tool_call.id,
"content": json.dumps(result),
})
# Step 5: Get the final response incorporating tool results
final_response = client.chat.completions.create(
model="minimax.minimax-m2.5",
messages=messages,
tools=tools,
)
print(final_response.choices[0].message.content)
else:
print(assistant_message.content)
Usando o endpoint bedrock-runtime com Boto3
Para o endpoint bedrock-runtime, são necessárias credenciais AWS (usuário ou função IAM) com permissão para invocar o modelo. A política mínima é:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream"
],
"Resource": "arn:aws:bedrock:us-east-1::foundation-model/minimax.minimax-m2.5"
}
]
}
O exemplo abaixo envia uma requisição ao MiniMax M2.5 usando o SDK AWS para Python (Boto3) com a API Converse:
import boto3
client = boto3.client("bedrock-runtime", region_name="us-east-1")
response = client.converse(
modelId="minimax.minimax-m2.5",
messages=[{
"role": "user",
"content": [{"text": "What is mixture of experts?"}]
}],
inferenceConfig={"maxTokens": 2048, "temperature": 1.0, "topP": 0.95},
)
content_blocks = response["output"]["message"]["content"]
response_text = next(
(block["text"] for block in content_blocks if "text" in block), None
)
if response_text:
print(response_text)
else:
print("No text response.")
Nota: na API Converse, o MiniMax M2.5 retorna um bloco reasoningContent antes do bloco de texto. O código itera pelos blocos de conteúdo para extrair a resposta final em texto.
Usando a Interface de Linha de Comando da AWS (AWS CLI)
Também é possível acessar o MiniMax M2.5 diretamente pelo terminal usando a Interface de Linha de Comando da AWS (AWS CLI):
aws bedrock-runtime converse \
--model-id minimax.minimax-m2.5 \
--messages '[{"role":"user","content":[{"text":"Type_Your_Prompt_Here"}]}]' \
--inference-config '{"maxTokens":2048}' \
--region us-east-1
Níveis de serviço disponíveis
O Amazon Bedrock oferece múltiplos níveis de serviço para atender a diferentes requisitos de carga de trabalho. Todos os três modelos MiniMax suportam os seguintes níveis:
- Priority: para fluxos de trabalho críticos e voltados ao cliente que exigem os tempos de resposta mais rápidos. Oferece até 25% melhor latência em tokens de saída por segundo (OTPS) em comparação ao Standard. Processado com prioridade sobre requisições Standard e Flex. Preço premium sobre o on-demand padrão, sem reserva antecipada.
- Standard: para tarefas cotidianas de IA como geração de conteúdo, análise de texto e processamento de documentos. Desempenho consistente com preço on-demand padrão. Nível padrão quando nenhum nível é especificado.
- Flex: para cargas de trabalho que toleram maior latência, como avaliações de modelos, sumarização de conteúdo e fluxos agênticos. Preço com desconto em relação ao Standard. Maior latência, especialmente em horários de pico, pois as requisições Flex são processadas após as Standard.
Nota: o nível Reserved não está disponível atualmente para modelos MiniMax.
Escalando a inferência on-demand
Ao invocar modelos MiniMax no Amazon Bedrock, as requisições usam inferência on-demand (nível Standard) por padrão, onde você paga por token sem reservar capacidade. No endpoint bedrock-mantle, não há cota de requisições por minuto (RPM) — o throughput é governado por limites baseados em tokens.
Para lidar com erros transitórios, use lógica de retry com backoff exponencial. O Boto3 suporta isso via configuração padrão:
import boto3
from botocore.config import Config
config = Config(retries={"total_max_attempts": 6, "mode": "standard"})
client = boto3.client("bedrock-runtime", config=config)
Dois erros principais podem ocorrer em produção:
- HTTP 429: cota de tokens por minuto excedida. Reduza a taxa de envio e faça retry com backoff exponencial. Solicite aumento de cota via AWS Support se o limite for atingido com frequência.
- HTTP 503: pressão na capacidade regional do modelo. Faça retry com backoff exponencial para erros transitórios. Para erros sustentados, reduza a taxa de envio.
Ao aumentar a taxa de requisições, escale em incrementos graduais em vez de saltos bruscos. O procedimento recomendado é: comece na taxa alvo; se receber erros 503, reduza 50%, aguarde 15 minutos em estado estável, aumente 50% e repita até atingir o volume alvo. A espera de 15 minutos é a etapa que a maioria das equipes pula — e é justamente a mais importante.
Para orientações completas, consulte as boas práticas de escalabilidade e throughput no Guia do Usuário do Amazon Bedrock.
Cache implícito de prompts para redução de latência
Os modelos MiniMax no Amazon Bedrock suportam cache implícito de prompts. Quando requisições consecutivas compartilham um prefixo de prompt comum, pode ocorrer um acerto de cache (cache hit), permitindo que o modelo reutilize o estado interno em cache em vez de recomputá-lo — reduzindo a latência de inferência nos tokens correspondentes, sem alterações no código e sem marcadores de cache necessários.
O cache implícito está disponível em todos os níveis de serviço on-demand (Standard, Priority e Flex). Para maximizar as taxas de acerto, coloque conteúdo estático (prompts de sistema, definições de ferramentas, documentos de referência) no início do prompt e conteúdo dinâmico (mensagens do usuário, contexto variável) no final.
Disponibilidade e preços
O MiniMax M2.5 está disponível em 14 regiões AWS: Leste dos EUA (N. Virgínia), Leste dos EUA (Ohio), Oeste dos EUA (Oregon), Europa (Frankfurt), Europa (Estocolmo), Europa (Milão), Europa (Irlanda), Europa (Londres), Ásia-Pacífico (Tóquio), Ásia-Pacífico (Mumbai), Ásia-Pacífico (Sydney), Ásia-Pacífico (Jacarta), Ásia-Pacífico (Melbourne) e América do Sul (São Paulo). As requisições são atendidas na região chamada. A inferência entre regiões (Geo e Global) não está disponível atualmente para modelos MiniMax. Para a lista mais recente, consulte a página de regiões suportadas.
Os preços são por token e variam por modelo e nível de serviço. Para as tarifas atuais, consulte a página de preços do Amazon Bedrock.
Recursos adicionais
- Guia do Usuário do Amazon Bedrock
- Modelos MiniMax no Amazon Bedrock
- Model card do MiniMax M2.5
- Model card do MiniMax M2.1
- Model card do MiniMax M2
- Endpoints do Amazon Bedrock
- Cotas para o endpoint bedrock-mantle
- Boas práticas de escalabilidade e throughput
- Níveis de serviço do Amazon Bedrock
- Chaves de API do Amazon Bedrock
- Preços do Amazon Bedrock
Fonte
Run MiniMax models on Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/run-minimax-models-on-amazon-bedrock/)
Leave a Reply