O problema do modelo único para tudo
Quem já construiu agentes de Inteligência Artificial (IA) conhece bem o dilema: toda requisição — seja uma simples consulta de status ou uma análise complexa — acaba sendo enviada para o mesmo modelo grande e caro hospedado na nuvem. Essa abordagem de tamanho único eleva os custos de API, introduz latência imprevisível e torna o sistema completamente dependente de conectividade.
Para endereçar esse problema, a AWS publicou um artigo técnico apresentando o Adaptive Agentic Intelligence Framework (AAIF), construído sobre o Strands Agents. A ideia central é simples: usar Modelos de Linguagem Pequenos (SLMs) para resolver tarefas rotineiras localmente, e acionar modelos de nuvem via Amazon Bedrock apenas quando a complexidade realmente exigir. Essa lógica tem respaldo acadêmico: pesquisadores Belcak et al. da NVIDIA argumentam que SLMs são “suficientemente poderosos, inerentemente mais adequados e necessariamente mais econômicos para muitas invocações em sistemas agênticos”.
Arquitetura em três camadas
O AAIF organiza o processamento de IA em três camadas, cada uma otimizada para um tipo diferente de tarefa:
- Orquestração inteligente: um SLM leve (
llama3.2:1b) atua como camada de decisão. Ele classifica cada requisição recebida e a direciona para a camada adequada, sem regras fixas codificadas manualmente. - Processamento local: tarefas rotineiras como recuperação de telemetria de dispositivos e análise de imagens são tratadas por SLMs rodando no próprio hardware, via Ollama. Essas tarefas completam com baixa latência e sem dependência de nuvem.
- Processamento em nuvem: análises de padrões complexos e recomendações estratégicas são enviadas para modelos de fronteira no Amazon Bedrock, que oferecem raciocínio de múltiplos passos e contexto mais amplo.
No centro da arquitetura está o agente Strands, que se conecta a um runtime Ollama hospedando tanto o modelo orquestrador de 1 bilhão de parâmetros quanto o modelo de visão. O agente expõe três ferramentas: get_device_telemetry para recuperação local de dados de sensores, analyze_camera_feed para processamento de visão no dispositivo via llama3.2-vision, e get_expert_insights que aciona o Amazon Bedrock via boto3 para análises complexas.
O framework se adapta às restrições do ambiente de implantação sem exigir reestruturação de infraestrutura. Ele roda em dispositivos de borda como um Raspberry Pi com 8 GB de memória, em implantações totalmente em nuvem onde toda inferência passa pelo Amazon Bedrock, ou em configurações híbridas que combinam velocidade local com raciocínio em nuvem.
Pré-requisitos para o walkthrough
Para seguir o passo a passo técnico descrito no artigo original, os seguintes componentes são necessários:
- Uma conta AWS com acesso ao Amazon Bedrock configurado na região desejada.
- Python 3.10+ instalado.
- Ollama instalado com os modelos
llama3.2:1b(orquestrador) ellama3.2-vision(análise visual) disponíveis. - Strands Agents instalado:
pip install strands-agents strands-agents-tools. - Interface de Linha de Comando da AWS (AWS CLI) configurada com credenciais apropriadas.
- Boto3 instalado:
pip install boto3.
Configurando o ambiente
O primeiro passo é criar o diretório do projeto e iniciar o servidor Ollama:
mkdir aaif-demo && cd aaif-demo
ollama serveEm seguida, baixar os modelos necessários:
ollama pull llama3.2:1b
ollama pull llama3.2-visionImplementando as ferramentas de processamento local
O Strands Agents utiliza o decorador @tool para definir as capacidades que os agentes podem invocar. A primeira ferramenta recupera dados de telemetria de dispositivos. Em produção, ela se conectaria a sensores reais de Internet das Coisas (IoT); no walkthrough, usa dados simulados:
from strands import Agent, tool
import random
DEVICE_TELEMETRY = {
"sensor-001": {
"device_type": "Temperature Sensor",
"location": "Building A - Floor 2",
"temperature": 72.5,
"humidity": 45.2,
"status": "normal"
},
"camera-001": {
"device_type": "Security Camera",
"location": "Main Entrance",
"fps": 30,
"resolution": "1080p",
"status": "recording"
},
"hvac-001": {
"device_type": "HVAC Controller",
"location": "Building A - Central",
"set_temp": 71.0,
"current_temp": 72.5,
"mode": "cooling",
"status": "active"
}
}
@tool
def get_device_telemetry() -> str:
"""Retrieve current telemetry data from connected IoT devices."""
device_id = random.choice(list(DEVICE_TELEMETRY.keys()))
device_data = DEVICE_TELEMETRY[device_id]
report = f"Device: {device_id} ({device_data['device_type']})\n"
report += f"Location: {device_data['location']}\n"
report += f"Status: {device_data['status']}\n"
for key, value in device_data.items():
if key not in ['device_type', 'location', 'status']:
report += f"{key}: {value}\n"
return reportA segunda ferramenta realiza análise visual usando um SLM local. O modelo llama3.2-vision roda inteiramente no hardware local, o que significa que feeds sensíveis de câmera não saem do dispositivo:
import ollama
@tool
def analyze_camera_feed(image_path: str) -> str:
"""Analyze visual data from cameras using local vision model."""
stream = ollama.chat(
model='llama3.2-vision',
messages=[{
'role': 'user',
'content': 'Describe this image in one sentence. '
'What are the 3 most important things you see?',
'images': [image_path]
}],
stream=True,
)
full_response = ""
for chunk in stream:
chunk_content = chunk['message']['content']
print(chunk_content, end='', flush=True)
full_response += chunk_content
return f"Object Detection Report:\n{full_response}"Implementando o processamento em nuvem
Para análises que requerem raciocínio mais amplo, uma terceira ferramenta aciona o Amazon Bedrock. Ela é invocada apenas quando o orquestrador determina que os modelos locais não conseguem resolver a requisição:
import boto3
@tool
def get_expert_insights(context_data: str, question: str) -> str:
"""Get advanced analysis and expert recommendations for complex questions via Amazon Bedrock."""
client = boto3.client("bedrock-runtime", region_name="us-east-1")
conversation = [
{
"role": "user",
"content": [
{"text": f"Context: {context_data}\n\nQuestion: {question}"}
],
}
]
response = client.converse(
modelId="<", //Refer model id [details](https://docs.aws.amazon.com/bedrock/latest/userguide/foundation-models-reference.html)
messages=conversation,
inferenceConfig={
"maxTokens": 512,
"temperature": 0.5,
"topP": 0.9
}
)
response_text = response["output"]["message"]["content"][0]["text"]
return f"Expert Analysis:\n{response_text}" Configurando o agente com orquestração inteligente
O núcleo do AAIF é a configuração do agente Strands. Ele utiliza um SLM local (llama3.2:1b) como orquestrador, via provedor Ollama:
from strands.models.ollama import OllamaModel
model = OllamaModel(
model_id="llama3.2:1b",
host="http://localhost:11434",
params={
"max_tokens": 300,
"temperature": 0.3,
},
)
system_prompt = """You are a monitoring assistant for operational facilities.
You have access to device telemetry tools, analysis capabilities, and expert insights to help monitor operations effectively.
When users ask for:
- Device status or telemetry: use get_device_telemetry
- Image or data analysis: use analyze_camera_feed
- Expert advice or complex questions: use get_expert_insights
Always return the complete tool results directly to the user."""
agent = Agent(
model=model,
system_prompt=system_prompt,
tools=[
get_device_telemetry,
analyze_camera_feed,
get_expert_insights,
],
)O orquestrador baseado em SLM analisa cada requisição e a encaminha para a ferramenta adequada sem correspondência de palavras-chave codificada. O roteamento acontece pelo entendimento contextual do modelo. A tabela abaixo resume o comportamento esperado:
- “Verificar status do dispositivo” → SLM local, baixa latência
- “Analisar esta imagem” → IA de visão local, baixa latência
- “Quais estratégias de otimização você recomenda?” → Nuvem (Amazon Bedrock), latência maior por round-trip de rede
Com o agente configurado, a interação é direta:
# Local processing - device telemetry
response = agent("What's the current status of our devices?")
print(response)
# Local processing - vision analysis
response = agent("Analyze the camera feed from camera-001")
print(response)
# Cloud processing - complex analysis
response = agent(
"Based on current telemetry patterns, "
"what optimization strategies do you recommend?"
)
print(response)Adaptando para diferentes cenários de implantação
A arquitetura AAIF suporta três configurações principais, ajustáveis apenas trocando a configuração do modelo:
Totalmente em nuvem
Quando não há hardware de borda disponível, toda inferência passa pelo Amazon Bedrock com escalonamento automático:
from strands.models import BedrockModel
model = BedrockModel(
model_id="<", //Refer model id [details](https://docs.aws.amazon.com/bedrock/latest/userguide/foundation-models-reference.html)
region_name="us-east-1"
) Híbrido (configuração padrão do AAIF)
Mantém o orquestrador SLM local e aciona modelos de nuvem apenas para requisições que excedem a capacidade local. Cerca de 80% do tráfego não atinge um endpoint de API pago, o que representa economia significativa de custos.
Totalmente local (air-gapped)
Para ambientes com requisitos estritos de soberania de dados ou sem conectividade, um modelo local maior substitui a ferramenta de nuvem. Um modelo de 3 bilhões de parâmetros consegue lidar com tarefas moderadamente complexas que o orquestrador de 1B escalaria para a nuvem. A contrapartida é menor profundidade de raciocínio nas consultas mais difíceis:
model = OllamaModel(
model_id="llama3.2:3b", # Larger local model for complex tasks
host="http://localhost:11434",
)Próximos passos: servidores MCP para chamadas centralizadas de ferramentas
A implementação descrita usa chamadas de ferramentas locais definidas diretamente no código do agente. Para implantações em produção com múltiplos agentes compartilhando ferramentas entre serviços, o artigo recomenda expor essas ferramentas como servidores do Protocolo de Contexto de Modelo (MCP). O MCP fornece uma interface padronizada para descoberta e invocação de ferramentas, permitindo centralizar o gerenciamento e reutilizar ferramentas em diferentes agentes.
Na configuração distribuída, o Dispositivo 1 atua como hub orquestrador, rodando o agente Strands com o roteador SLM e uma ferramenta de telemetria local. Ele se conecta via protocolo MCP ao Dispositivo 2, que roda um servidor de processamento de visão de borda com llama3.2-vision, e ao Dispositivo 3, que serve como gateway de análise em nuvem conectado ao Amazon Bedrock. Do ponto de vista do orquestrador, todas as ferramentas remotas aparecem como chamadas de função locais, pois a camada de transporte MCP cuida da serialização e comunicação de rede de forma transparente.
Limpeza do ambiente
Para evitar cobranças futuras, o artigo recomenda os seguintes passos de limpeza:
- Desabilitar o acesso ao modelo no Amazon Bedrock: abrir o console do Amazon Bedrock, acessar “Model access” e revogar o acesso ao Amazon Nova Lite. Consulte Gerenciar acesso a modelos no Guia do Usuário do Amazon Bedrock para detalhes.
- Parar o servidor Ollama e remover os modelos para liberar espaço em disco (aproximadamente 2 GB):
ollama stop ollama rm llama3.2:1b ollama rm llama3.2-vision - Deletar o diretório do projeto se o código de exemplo não for mais necessário:
rm -rf aaif-demo
IA responsável no caminho de inferência em nuvem
Antes de executar esse padrão em produção, o artigo recomenda adicionar controles de IA responsável ao caminho de inferência em nuvem, já que essas requisições carregam saídas de ferramentas, dados recuperados e entradas do usuário. É possível anexar Amazon Bedrock Guardrails ao BedrockModel do Strands com um ID e versão de guardrail. Ele então aplica filtros de conteúdo para categorias prejudiciais, filtros de injeção de prompt e verificações de fundamentação contextual que bloqueiam respostas não suportadas pelos dados de origem. Para aplicar as mesmas políticas à camada de SLM local, basta chamar a API ApplyGuardrail standalone nas entradas e saídas — garantindo que toda requisição siga um único padrão de segurança, independentemente de qual modelo a processa.
Aplicações além do monitoramento de IoT
O padrão arquitetural descrito vai muito além do cenário de monitoramento de IoT usado como referência. Uma organização de saúde poderia rodar monitoramento de pacientes localmente enquanto roteia suporte a diagnósticos para modelos em nuvem. Uma empresa de serviços financeiros poderia processar transações on-premises e reservar capacidade de nuvem para análise de risco. Uma equipe de manufatura poderia rodar modelos de visão para controle de qualidade na borda enquanto envia requisições de otimização para a nuvem.
Para saber mais sobre como construir agentes com Strands Agents, consulte a documentação do Strands Agents. Para informações sobre os modelos de fundação disponíveis, acesse o Amazon Bedrock.
Fonte
Adaptive agentic intelligence framework using Strands Agents (https://aws.amazon.com/blogs/machine-learning/adaptive-agentic-intelligence-framework-using-strands-agents/)
Leave a Reply