Blog

  • Amazon Bedrock expande disponibilidade dos modelos Claude para inferência local na Índia

    Novos modelos Claude disponíveis com inferência local na Índia

    A AWS anunciou a disponibilidade dos modelos Claude Opus 5, Claude Sonnet 5 e Claude Haiku 4.5 da Anthropic no Amazon Bedrock com suporte a inferência geográfica entre regiões dentro da Índia. Isso significa que clientes que operam no país agora podem utilizar esses modelos mantendo o processamento dos dados exclusivamente em regiões indianas — além do já disponível perfil global de inferência entre regiões.

    Essa expansão é especialmente relevante para organizações que precisam atender a requisitos regulatórios ou de conformidade que exigem que os dados sejam processados localmente, dentro de uma geografia específica.

    Como funciona a inferência geográfica na Índia

    O Amazon Bedrock oferece perfis de inferência entre regiões (cross-Region inference profiles), um recurso que distribui automaticamente as requisições de inferência entre múltiplas regiões da AWS — sem que o cliente precise gerenciar capacidade em cada região individualmente.

    No caso do perfil geográfico indiano, as requisições trafegam apenas entre as regiões ap-south-1 (Mumbai) e ap-south-2 (Hyderabad). Isso garante que os dados permaneçam dentro das fronteiras do país. Em vez de depender da capacidade de uma única região, as requisições se beneficiam de um pool de computação mais amplo, o que ajuda a manter a vazão e o desempenho consistente, especialmente em momentos de pico de tráfego.

    Segurança e privacidade dos dados

    A inferência entre regiões opera sobre a rede segura da AWS com criptografia de ponta a ponta para dados em trânsito. Os dados do cliente não são armazenados na região de destino — eles permanecem exclusivamente na região de origem da requisição.

    O Amazon Bedrock utiliza um modelo de segurança de dados com retenção zero (Zero Data Retention — ZDR): por padrão, entradas e saídas dos modelos não são armazenadas. Há uma exceção: determinados modelos podem exigir revisão humana pela AWS caso o conteúdo seja sinalizado por classificadores automáticos de segurança. Para mais detalhes, consulte a documentação sobre retenção de dados no Guia do Usuário do Amazon Bedrock.

    Faturamento e monitoramento

    O consumo de cota e o faturamento são contabilizados na conta da região de origem, independentemente de qual região de backend processou a requisição. Os registros do Amazon CloudWatch e do AWS CloudTrail também são gravados apenas na região de origem, centralizando o monitoramento em um único lugar.

    APIs e recursos compatíveis

    A inferência geográfica está disponível no endpoint bedrock-runtime e é compatível com a API Messages da Anthropic, além das APIs nativas do Amazon Bedrock: InvokeModel e Converse. O recurso também funciona em conjunto com funcionalidades do Amazon Bedrock como o Amazon Bedrock Guardrails e o roteamento inteligente de prompts.

    Como acessar os modelos Claude

    Pelo console do Amazon Bedrock

    É possível acessar os modelos Claude diretamente pelo playground de texto no console do Amazon Bedrock, sem necessidade de código ou configuração de SDK. Para isso, basta abrir o console na região desejada como origem, acessar o menu Test > Playground, selecionar o modelo (por exemplo, IN Anthropic Claude Opus 5 como perfil de inferência) e executar um prompt.

    Via código com as APIs disponíveis

    Para acesso programático, os modelos podem ser chamados com o ID do perfil de inferência geográfica da Índia usando a API Messages da Anthropic via SDK da Anthropic, ou com as APIs InvokeModel e Converse via Interface de Linha de Comando da AWS (AWS CLI) e AWS SDK.

    Pré-requisitos

    • Conta AWS ativa com acesso ao Amazon Bedrock
    • AWS CLI instalada e configurada
    • Python 3.8 ou superior
    • Boto3 instalado: pip install boto3
    • SDK da Anthropic instalado: pip install anthropic
    • Gerador de tokens Bedrock instalado: pip install aws_bedrock_token_generator
    • Função ou usuário do AWS Identity and Access Management (IAM) com as permissões necessárias para invocar modelos do Amazon Bedrock usando um perfil de inferência geográfica entre regiões

    Exemplo com a API InvokeModel (Boto3)

    import boto3
    import json
    
    # Create a Bedrock Runtime client
    bedrock_runtime = boto3.client(
        service_name="bedrock-runtime",
        region_name="ap-south-1"
    )
    
    # Invoke Claude Sonnet 5
    response = bedrock_runtime.invoke_model(
        modelId="in.anthropic.claude-sonnet-5",
        contentType="application/json",
        accept="application/json",
        body=json.dumps({
            "anthropic_version": "bedrock-2023-05-31",
            "max_tokens": 4096,
            "messages": [
                {
                    "role": "user",
                    "content": " Can you explain the features of Amazon Bedrock? "
                }
            ]
        })
    )
    
    result = json.loads(response["body"].read())
    print(result["content"][0]["text"])

    Exemplo com a API Converse

    import boto3
    
    # Create a Bedrock Runtime client
    bedrock_runtime = boto3.client(
        service_name="bedrock-runtime",
        region_name="ap-south-1"
    )
    
    # Invoke Claude Opus 5
    response = bedrock_runtime.converse(
        modelId="in.anthropic.claude-opus-5",
        messages=[
            {
                "role": "user",
                "content": [
                    {
                        "text": " Can you explain the features of Amazon Bedrock?"
                    }
                ]
            }
        ],
        inferenceConfig={
            "maxTokens": 4096
        }
    )
    
    if 'output' in response:
        blocks = response['output']['message']['content']
        print('\n'.join(b.get('text', '') for b in blocks if 'text' in b))

    Exemplo com a API Messages da Anthropic

    from anthropic import Anthropic
    from aws_bedrock_token_generator import provide_token
    
    token = provide_token(region="ap-south-1")
    client = Anthropic(
        base_url="https://bedrock-runtime.ap-south-1.amazonaws.com/anthropic",
        api_key=token,
    )
    
    response = client.messages.create(
        model="in. anthropic.claude-haiku-4-5-20251001-v1:0",
        max_tokens=1024,
        messages=[{"role": "user", "content": "Can you explain the features of Amazon Bedrock?"}],
    )
    print(response)

    Monitoramento e custos

    É possível acompanhar uso, desempenho e custos através do CloudWatch e do AWS Cost Explorer, facilitando o dimensionamento das aplicações conforme a demanda cresce.

    Conclusão

    Com a chegada dos modelos Claude Opus 5, Claude Sonnet 5 e Claude Haiku 4.5 ao Amazon Bedrock com inferência geográfica na Índia, organizações que operam no país passam a ter uma opção para construir aplicações de IA generativa escaláveis e resilientes mantendo a inferência dentro das fronteiras nacionais. O acesso pode ser feito pelo console do Amazon Bedrock ou via API usando o ID do perfil de inferência geográfica da Índia. Para informações atualizadas sobre disponibilidade de modelos por região, consulte a página de disponibilidade regional por modelo no Guia do Usuário do Amazon Bedrock.

    Fonte

    Amazon Bedrock expands Claude model availability to in-country inferencing in India (https://aws.amazon.com/blogs/machine-learning/amazon-bedrock-expands-claude-model-availability-to-india-cross-region-inference/)

  • Modelos Anthropic no Amazon Bedrock com inferência regional em Seul e Singapura

    Novidade: Claude com inferência regional na Ásia-Pacífico

    A AWS anunciou a disponibilidade dos modelos Anthropic Claude no Amazon Bedrock com suporte a inferência regional nas regiões da Ásia-Pacífico. Agora, o Claude Opus 5 e o Claude Sonnet 5 estão disponíveis em Seul (ap-northeast-2), enquanto o Claude Sonnet 5 passa a estar acessível também em Singapura (ap-southeast-1) — ambos com inferência regional no endpoint bedrock-runtime.

    Essa expansão é especialmente relevante para organizações que atuam na Coreia do Sul ou em Singapura e precisam garantir que o processamento de dados de Inteligência Artificial (IA) ocorra inteiramente dentro de uma única região — como é o caso de empresas de serviços financeiros, saúde e setor público, onde requisitos regulatórios de residência de dados são frequentemente obrigatórios.

    O que é inferência regional (in-region inference)?

    A inferência regional é um modo de operação do Amazon Bedrock no qual toda a requisição — desde o prompt enviado até a resposta gerada — é processada exclusivamente dentro da região AWS que você especifica. Em nenhum momento os dados trafegam para outra região.

    Isso difere dos perfis de inferência entre regiões (cross-region inference profiles), que possuem uma camada de roteamento. Na inferência regional, não existe essa camada intermediária: a requisição enviada para Seul é processada em Seul, e a enviada para Singapura é processada em Singapura. Tanto os prompts de entrada quanto os resultados gerados permanecem na região durante todo o ciclo de vida da requisição.

    Como contrapartida, a capacidade de processamento fica limitada à capacidade disponível naquela região específica. As requisições estão sujeitas às cotas de serviço por região, e a cobrança segue o modelo de preços sob demanda padrão da região utilizada. Métricas do Amazon CloudWatch, registros do AWS CloudTrail e consumo de cotas são todos escopados à mesma região — sem distinção entre origem e destino no monitoramento.

    Como acessar os modelos Claude no console do Amazon Bedrock

    Quem prefere explorar os modelos antes de integrar uma API pode fazer isso diretamente pelo console do Amazon Bedrock, sem necessidade de código ou configuração de SDK. No playground de texto, é possível enviar prompts, ajustar parâmetros de inferência e comparar variantes de modelos.

    Para isso, basta abrir o console do Amazon Bedrock na região desejada, acessar a opção Playground no painel de navegação (em Test), selecionar o modelo — por exemplo, anthropic.claude-opus-5 — escolher a modalidade On-Demand em Inference e aplicar. Em seguida, basta inserir um prompt e executar para obter uma resposta.

    Acesso programático: APIs disponíveis

    Para integrações em código, o endpoint bedrock-runtime é recomendado pela AWS para novas aplicações. Ele suporta a API Messages da Anthropic, a API InvokeModel e a API Converse do Amazon Bedrock, além de recursos como o Amazon Bedrock Guardrails e o roteamento inteligente de prompts. O modelo é invocado pelo seu ID direto, como anthropic.claude-opus-5 ou anthropic.claude-sonnet-5.

    Pré-requisitos

    • Conta AWS ativa com acesso ao Amazon Bedrock
    • AWS Command Line Interface (AWS CLI) instalado e configurado
    • Python 3.8 ou superior
    • Boto3 instalado: pip install boto3
    • SDK da Anthropic instalado: pip install anthropic
    • Gerador de tokens do Amazon Bedrock para autenticação: pip install aws_bedrock_token_generator

    Exemplo com a API InvokeModel (Singapura)

    O exemplo abaixo usa o AWS SDK para Python (Boto3) com a API InvokeModel, configurado para inferência regional em Singapura:

    import boto3
    import json
    
    # Create a Bedrock Runtime client with in-region inference in Singapore
    bedrock_runtime = boto3.client(
        service_name="bedrock-runtime",
        region_name="ap-southeast-1")
    
    # Invoke Claude Sonnet 5
    response = bedrock_runtime.invoke_model(
        modelId="anthropic.claude-sonnet-5",
        contentType="application/json",
        accept="application/json",
        body=json.dumps({
            "anthropic_version": "bedrock-2023-05-31",
            "max_tokens": 4096,
            "messages": [
                {
                    "role": "user",
                    "content": " Can you explain the features of Amazon Bedrock? "
                }
            ]
        })
    )
    
    result = json.loads(response["body"].read())
    print(result["content"][0]["text"])

    Exemplo com a API Converse (Seul)

    Para uma experiência unificada com múltiplos modelos, a API Converse do Amazon Bedrock também está disponível com inferência regional em Seul:

    import boto3
    
    # Create a Bedrock Runtime client with in-region inference in Seoul
    bedrock_runtime = boto3.client(
        service_name="bedrock-runtime",
        region_name="ap-northeast-2"
    )
    
    # Invoke Claude Opus 5
    response = bedrock_runtime.converse(
        modelId="anthropic.claude-opus-5",
        messages=[
            {
                "role": "user",
                "content": [
                    {
                        "text": " Can you explain the features of Amazon Bedrock?"
                    }
                ]
            }
        ],
        inferenceConfig={
            "maxTokens": 4096
        }
    )
    
    if 'output' in response:
        blocks = response['output']['message']['content']
        print('\n'.join(b.get('text', '') for b in blocks if 'text' in b))

    Exemplo com a API Messages da Anthropic (Seul)

    Também é possível usar a API Messages da Anthropic diretamente via SDK da Anthropic, com autenticação pelo gerador de tokens do Bedrock:

    from anthropic import Anthropic
    from aws_bedrock_token_generator import provide_token
    
    token = provide_token(region="ap-northeast-2")
    
    client = Anthropic(
        base_url="https://bedrock-runtime.ap-northeast-2.amazonaws.com/anthropic",
        api_key=token,
    )
    
    response = client.messages.create(
        model="anthropic.claude-sonnet-5",
        max_tokens=1024,
        messages=[{"role": "user", "content": "Can you explain the features of Amazon Bedrock?"}],
    )
    
    print(response)

    Monitoramento e custos

    O uso, a performance e os custos das aplicações podem ser acompanhados pelo CloudWatch e pelo AWS Cost Explorer, permitindo escalar as aplicações conforme a demanda cresce.

    Conclusão

    Com a chegada do Claude Opus 5 e do Claude Sonnet 5 ao Amazon Bedrock com inferência regional em Seul, e do Claude Sonnet 5 em Singapura, a AWS amplia as opções para organizações que precisam construir aplicações de IA generativa com requisitos rigorosos de residência de dados nessas regiões. O processamento de inferência permanece inteiramente dentro da região configurada, sem roteamento externo.

    Para verificar a disponibilidade atualizada de modelos por região, a AWS recomenda consultar a página de disponibilidade regional por modelos no Guia do Usuário do Amazon Bedrock.

    Fonte

    Introducing Anthropic models on Amazon Bedrock for in-region inference in Seoul and Singapore (https://aws.amazon.com/blogs/machine-learning/introducing-anthropic-models-on-amazon-bedrock-for-in-region-inference-in-seoul-and-singapore/)

  • Amazon Connect permite que equipes de negócio gerenciem mais dados de referência em tempo real

    O que mudou no Amazon Connect Customer

    A AWS anunciou uma expansão importante nas capacidades do Amazon Connect Customer: administradores agora conseguem armazenar e gerenciar volumes maiores de dados de referência que controlam as configurações do contact center — e fazem isso em tempo real, sem precisar acionar equipes técnicas para cada ajuste.

    Tabelas de dados com maior capacidade

    A novidade central é o suporte a tabelas de dados com até 20.000 valores por tabela. Essas tabelas funcionam como repositórios de configuração que alimentam diretamente os fluxos de atendimento. Entre os casos de uso suportados estão:

    • Definição de horários de funcionamento
    • Regras de escalonamento de chamadas
    • Prompts para agentes de Inteligência Artificial (IA)
    • Atribuições de filas de atendimento

    Em outras palavras, tudo aquilo que orienta como uma chamada ou interação se comporta dentro do contact center pode agora ser parametrizado e atualizado por meio dessas tabelas.

    Mais flexibilidade na gestão dos dados

    Além do aumento de capacidade, a AWS também ampliou as opções de manipulação dessas tabelas. Os administradores agora podem:

    • Exportar tabelas para uso externo
    • Editar centenas de registros de uma só vez
    • Mover tabelas entre instâncias do Amazon Connect Customer
    • Carregar dados de sistemas externos, utilizando ferramentas como Excel e o Amazon DynamoDB

    Essa integração com fontes externas é especialmente relevante para empresas que já mantêm suas bases de dados de configuração em outros sistemas e precisam sincronizá-las com o contact center.

    Autonomia para as equipes de negócio

    Um dos pontos mais relevantes dessa atualização é o ganho de autonomia para as equipes de negócio. Como os dados de configuração podem ser mantidos e atualizados diretamente pelos times responsáveis pela operação do contact center, não é mais necessário depender de recursos técnicos para cada mudança nas regras de atendimento. Isso reduz o tempo de resposta a mudanças operacionais e dá mais agilidade ao dia a dia.

    Disponibilidade

    O recurso está disponível em todas as regiões comerciais da AWS e na região AWS GovCloud (US-West) onde o Amazon Connect Customer é oferecido.

    Para saber como configurar esse recurso, a AWS disponibiliza o guia Criar e configurar tabelas de dados no Amazon Connect Administrator Guide. Mais informações sobre o serviço podem ser encontradas no site oficial do Amazon Connect Customer.

    Fonte

    Amazon Connect Customer now lets business users manage more reference data to adjust contact center configurations in real time (https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-connect-manage-data-tables/)

  • Amazon Bedrock Managed Agents com OpenAI está disponível em prévia

    O que é o Bedrock Managed Agents

    A AWS e a OpenAI anunciaram conjuntamente o Bedrock Managed Agents (BMA), um novo recurso do Amazon Bedrock disponível em prévia. O BMA foi desenvolvido sobre uma versão customizada da Agents API da OpenAI, adaptada para ser nativa da AWS e integrada ao ecossistema de serviços da plataforma.

    Em termos práticos, o BMA permite que times de engenharia construam agentes otimizados para os modelos da OpenAI que rodam inteiramente dentro da AWS — sem precisar abrir mão dos controles de identidade, permissões e governança que já estão em uso nas organizações.

    O que o BMA gerencia por você

    Uma das propostas centrais do Bedrock Managed Agents é abstrair a complexidade operacional da execução de agentes. O serviço cuida de aspectos como:

    • Como o modelo preserva estado ao longo de uma conversa ou tarefa
    • Seleção e uso de ferramentas disponíveis
    • Execução de código
    • Coordenação de trabalho em múltiplos passos e decisões

    Além disso, o BMA oferece sessões duráveis que retêm mensagens, chamadas de ferramentas e resultados intermediários. Isso significa que é possível interromper uma tarefa, retornar depois, fornecer novas informações e continuar exatamente de onde o agente parou — sem perder o contexto já construído.

    Capacidades e integrações

    O BMA traz algumas funcionalidades relevantes para quem trabalha com arquiteturas baseadas em agentes:

    • Skills reutilizáveis: é possível adicionar habilidades especializadas para procedimentos específicos, que podem ser reaproveitadas em diferentes agentes.
    • Conexão com ferramentas via MCP: os agentes podem se conectar a ferramentas, inclusive por meio de servidores do Protocolo de Contexto de Modelo (MCP — Model Context Protocol).
    • IAM por agente: cada agente opera com sua própria função do Gerenciamento de Identidade e Acesso (IAM — Identity and Access Management), garantindo isolamento de permissões.
    • Aprovação humana: suporte a fluxos de aprovação humana antes que o agente execute ações de maior impacto.
    • Auditoria com CloudTrail: a atividade de API suportada é registrada no AWS CloudTrail, facilitando rastreabilidade e conformidade.

    Disponibilidade e preço

    Durante o período de prévia, o BMA não tem custo adicional além dos recursos AWS que os agentes consomem. A AWS indica que os preços estão sujeitos a alteração na disponibilidade geral (GA — General Availability).

    O recurso está disponível em prévia nas seguintes regiões:

    • Leste dos EUA (Norte da Virgínia)
    • Oeste dos EUA (Oregon)
    • Leste dos EUA (Ohio)

    Para começar a usar o Bedrock Managed Agents pelas APIs suportadas, a AWS disponibilizou a documentação oficial do Amazon Bedrock com todos os detalhes necessários.

    Fonte

    Amazon Bedrock Managed Agents, powered by OpenAI, is now available in preview (https://aws.amazon.com/about-aws/whats-new/2026/09/bedrock-managed-agents-preview/)

  • OpenAI GPT-6.1 Sol já está disponível no Amazon Bedrock

    GPT-6.1 Sol chega ao Amazon Bedrock em disponibilidade geral

    A AWS anunciou, em 29 de setembro de 2026, a disponibilidade geral do GPT-6.1 Sol, modelo da OpenAI, dentro do Amazon Bedrock. Trata-se de uma evolução do GPT-6 Sol, trazendo melhorias significativas de desempenho para quem trabalha com agentes de IA, automação de tarefas em computador e fluxos de trabalho profissionais.

    O que muda em relação ao GPT-6 Sol

    Segundo a própria OpenAI, o GPT-6.1 Sol se aproxima do desempenho do GPT-6 Astra em avaliações mais exigentes — e faz isso a aproximadamente um quinto do custo. Na prática, isso abre espaço considerável para times de desenvolvimento construírem e operarem agentes capazes em escala, sem comprometer o orçamento.

    O modelo se destaca especialmente em três frentes:

    • Codificação agêntica — construção de funcionalidades, depuração de problemas e iteração sobre soluções de forma autônoma;
    • Uso de computador — execução de fluxos de trabalho em múltiplas etapas e investigação de bases de código complexas;
    • Trabalho profissional — suporte a tarefas de alta complexidade em contextos corporativos.

    Infraestrutura do Bedrock como diferencial

    O GPT-6.1 Sol roda sobre o motor de inferência do Amazon Bedrock, que a AWS posiciona como preparado para cargas de trabalho em produção, com foco em desempenho, segurança e confiabilidade. Os controles nativos da AWS permitem proteger as cargas de trabalho, governar o acesso e auditar a atividade de invocação dos modelos.

    Suporte a prompt caching explícito

    Um recurso que merece atenção especial é o suporte a prompt caching explícito no Amazon Bedrock. Essa funcionalidade é especialmente útil em fluxos de trabalho agênticos que reutilizam contexto entre requisições repetidas — o que é bastante comum em automações e agentes de longa duração. Com o cache, é possível evitar o reprocessamento desnecessário de contexto, tornando as aplicações mais eficientes.

    Como começar a usar

    O acesso ao GPT-6.1 Sol pode ser feito diretamente pelo console do Amazon Bedrock ou de forma programática pelas APIs suportadas pelo serviço. Para informações sobre regiões da AWS compatíveis, endpoints, APIs, funcionalidades, perfis de inferência e preços, a AWS disponibiliza a documentação do Amazon Bedrock. Para um aprofundamento técnico sobre o modelo, vale conferir também o post no blog oficial da AWS.

    Fonte

    OpenAI GPT-6.1 Sol is now generally available on Amazon Bedrock (https://aws.amazon.com/about-aws/whats-new/2026/09/openai-gpt-6-1-sol-on-amazon-bedrock/)

  • Monitoramento Sintético com Amazon Nova Act: como a IA substitui scripts frágeis

    O que é monitoramento sintético e por que ele importa

    Monitoramento sintético é a prática de simular jornadas reais de usuários por meio de transações automatizadas. Em vez de esperar que clientes encontrem problemas, equipes validam continuamente fluxos críticos — como login, compra e envio de formulários — em intervalos programados. Com isso, falhas de desempenho ou quebras de interação com a interface são detectadas muito antes de chegarem ao usuário final.

    Para negócios voltados ao cliente, especialmente no e-commerce, isso significa garantir que a busca de produtos funciona corretamente, que preços e estoque aparecem como esperado, que operações de carrinho são concluídas e que confirmações de checkout ocorrem sem erros. O mesmo raciocínio se aplica a outros setores: serviços financeiros validam fluxos de acesso a contas, empresas de viagem monitoram reservas, organizações de saúde acompanham portais de agendamento.

    O problema com a abordagem tradicional

    A maioria das organizações monitora a saúde da infraestrutura por meio de métricas, logs, rastreamentos e verificações em nível de API. Porém, falhas de alto impacto frequentemente ocorrem na camada da jornada do usuário — onde os sinais de backend podem não revelar o problema imediatamente. Um botão de checkout quebrado por um deploy de frontend, uma tela de login de terceiro que mudou inesperadamente ou uma regressão de interface que deixa elementos críticos sem resposta são exemplos comuns que passam despercebidos pelo monitoramento tradicional.

    Fonte

    Implementing synthetic monitoring using Amazon Nova Act (https://aws.amazon.com/blogs/machine-learning/implementing-synthetic-monitoring-using-amazon-nova-act/)

  • Claude Sonnet 5.5 já está disponível no AWS GovCloud (US)

    O que foi anunciado

    A AWS anunciou que o Claude Sonnet 5.5, modelo de linguagem da Anthropic, já está disponível no AWS GovCloud (US). Para equipes que já trabalham com o Sonnet 5, essa é uma atualização direta — o novo modelo traz melhorias claras em codificação e em tarefas de produção de conhecimento, com menor custo por tarefa na maioria dos casos e velocidade superior.

    O que muda em relação ao Sonnet 5

    O Claude Sonnet 5.5 é descrito como uma evolução do Sonnet 5, não uma substituição radical. A ideia é que times que já constroem soluções sobre o Sonnet encontrem no 5.5 um upgrade natural, sem necessidade de reescrever fluxos inteiros.

    As melhorias se concentram em duas frentes principais:

    • Codificação: o modelo se sai melhor em tarefas de escopo bem definido dentro de uma estratégia maior de desenvolvimento — como construir e corrigir funcionalidades na mesma sessão, ou verificar se o código produzido atende aos requisitos estabelecidos.
    • Trabalho de conhecimento: o Sonnet 5.5 produz entregas prontas para compartilhamento, incluindo documentos de uma página, diagramas, slides de resumo, edições de documentos e organização de planilhas.

    Acesso via Amazon Bedrock

    O acesso ao Claude Sonnet 5.5 no GovCloud se dá pelo Amazon Bedrock, serviço gerenciado da AWS que centraliza o uso de modelos de fundação. Pelo Bedrock, os dados permanecem dentro da infraestrutura AWS, com residência regional garantida — ponto importante para organizações governamentais e reguladas que precisam de controle sobre onde seus dados trafegam e são processados.

    Além disso, o Bedrock oferece acesso a recursos gerenciados pela AWS, como Guardrails (controles de segurança e conformidade para aplicações de IA) e Knowledge Bases (bases de conhecimento para enriquecer respostas dos modelos com dados próprios da organização).

    Para saber mais, a AWS disponibiliza a documentação do Amazon Bedrock e informações sobre disponibilidade regional dos modelos.

    Fonte

    Claude Sonnet 5.5 now available on AWS GovCloud (US) (https://aws.amazon.com/about-aws/whats-new/2026/09/claude-sonnet-5-5-aws-govcloud-us/)

  • Grok 4.7 já está disponível no Amazon Bedrock

    O que é o Grok 4.7 e por que ele chegou ao Bedrock

    A xAI disponibilizou o Grok 4.7 no Amazon Bedrock, adicionando ao catálogo de modelos da plataforma uma opção de fronteira voltada para programação, agentes de longa execução e trabalho intensivo com conhecimento. O modelo conta com janela de contexto de 500 mil tokens e suporte a quatro níveis configuráveis de esforço de raciocínio: low, medium, high e xhigh.

    O Grok 4.7 é servido pelo endpoint bedrock-runtime por meio de perfis de inferência entre regiões (cross-Region inference profiles) e suporta as APIs Responses, Chat Completions e Converse.

    Para que o Grok 4.7 foi construído

    As informações de capacidade e treinamento desta seção têm como base o anúncio de lançamento da xAI, Introducing Grok 4.7, publicado em 21 de setembro de 2026, e a documentação oficial do modelo.

    A xAI posiciona o Grok 4.7 como seu modelo mais capaz para programação e trabalho com conhecimento. O tema central é resistência, não velocidade bruta: o modelo trabalha por mais tempo em tarefas difíceis e verifica o próprio trabalho com mais cuidado antes de avançar.

    Em termos de treinamento, a xAI informa que o Grok 4.7 usa um modelo base novo e maior. Ele foi treinado com um ciclo de aprendizado por reforço mais longo, sobre um conjunto de tarefas mais difícil, deliberadamente ponderado para problemas que levam muitas horas para serem concluídos. Duas capacidades emergiram desse processo: o modelo ficou melhor em verificar o próprio trabalho e faz uso mais eficiente da janela de contexto de 500 mil tokens em tarefas longas. A xAI também o treinou para entender nativamente o harness Grok Bot, o que traz melhorias em tarefas conversacionais e de conhecimento geral.

    Para quem constrói agentes, o comportamento de autoverificação é o detalhe mais relevante. Um modelo que confere o próprio output antes de continuar tende a falhar de forma menos catastrófica em trajetórias longas, onde um erro inicial se propaga por todas as etapas seguintes.

    A xAI também destaca geração mais robusta de documentos e apresentações, além de ganhos em trabalho profissional especializado — do tipo realizado por advogados, enfermeiros e analistas financeiros. As avaliações publicadas pela empresa abrangem engenharia de software com CursorBench e DeepSWE, trabalho de terminal e escritório de várias horas com Terminal-Bench e AA Briefcase, engenharia elétrica com EEBench, trabalho jurídico com o Harvey Legal Agent Benchmark e raciocínio clínico com HealthBench Professional. Para os resultados completos, consulte o anúncio oficial da xAI.

    Avaliação independente

    O Artificial Analysis conduz avaliações próprias em vez de depender dos números divulgados pelos desenvolvedores, o que o torna uma segunda referência útil ao lado dos resultados publicados pela xAI. Segundo o Artificial Analysis, o Grok 4.7 melhora em toda a sua suíte de avaliação. Os maiores ganhos estão em trabalho de conhecimento agêntico de longo horizonte e em agentes de programação executados no harness da própria xAI.

    O Intelligence Index é um índice composto construído a partir de múltiplas avaliações independentes cobrindo uso agêntico de ferramentas, raciocínio e conhecimento, confiabilidade de conhecimento e trabalho em contexto longo.

    Métrica (Artificial Analysis) Grok 4.7 Grok 4.6
    Intelligence Index 46 44
    Coding Agent Index 56 47
    AA-Briefcase, trabalho de conhecimento de longo horizonte (Elo) 1.657 1.546
    GDPval-AA, produtos de trabalho profissional (Elo) 1.695 1.605
    AA-Omniscience Index 32 30
    Taxa de alucinação AA-Omniscience 29% 34%
    Tokens de saída por tarefa do Intelligence Index ~81k ~38k

    O Grok 4.7 é medido no nível de esforço xhigh e o Grok 4.6 no nível reportado pelo Artificial Analysis para cada métrica. A última linha da tabela é o tradeoff a considerar: os ganhos vêm com aproximadamente o dobro de tokens de saída por tarefa. Por isso vale configurar o nível de esforço de forma deliberada em vez de herdar o padrão.

    Segurança e cibersegurança

    Segundo a xAI, o Grok 4.7 foi construído com uma pilha de salvaguardas completamente nova e é o modelo mais robusto que a empresa já testou em termos de recusas e resistência a jailbreak. A xAI enquadra o objetivo em domínios de uso dual — como cibersegurança e trabalho biológico — como manter duas coisas ao mesmo tempo: continuar útil para tarefas legítimas enquanto recusa as perigosas.

    Em cibersegurança especificamente, a xAI informa que o modelo permite apenas uma pequena fração de prompts arriscados de uso dual enquanto raramente bloqueia trabalho legítimo de segurança. A xAI também começou a conceder acesso por convite a parceiros selecionados de cibersegurança às capacidades de red team do Grok 4.7 para pesquisa defensiva.

    Como o Grok 4.7 está empacotado no Amazon Bedrock

    O Grok 4.7 aceita entrada de texto e imagem e retorna texto. O modelo é servido pelo endpoint bedrock-runtime por meio de perfis de inferência entre regiões, então as requisições nomeiam um perfil em vez de um ID de modelo direto:

    Opção de inferência ID do modelo URL base
    Cross-Region geográfico us.xai.grok-4.7 https://bedrock-runtime.{region}.amazonaws.com/openai/v1
    Cross-Region global global.xai.grok-4.7 https://bedrock-runtime.{region}.amazonaws.com/openai/v1

    O Grok 4.7 suporta a API Responses, a API Chat Completions, InvokeModel e a API Converse. Como o modelo é compatível com OpenAI, há escolha de cliente. O SDK da OpenAI funciona contra o caminho /openai/v1 com um bearer token, que pode ser uma chave de API do Amazon Bedrock ou um token de curta duração gerado a partir das credenciais do Gerenciamento de Identidade e Acesso da AWS (IAM — Identity and Access Management). Os SDKs da AWS acessam o mesmo modelo via Converse, assinando requisições com as credenciais AWS comuns.

    Use o SDK da OpenAI se estiver portando uma integração existente. Use Converse se quiser um formato de mensagem único entre os modelos da sua conta, com log de invocação e streaming de resposta pelos tipos de evento padrão do Bedrock.

    Usando o Grok 4.7 com recursos do Bedrock

    O cache implícito de prompts se aplica automaticamente a prefixos de prompt repetidos, então agentes que reenviam um grande prompt de sistema ou documento de referência a cada turno pagam a taxa de cache para esse prefixo. O Amazon Bedrock Guardrails se conecta por ID e versão na requisição, aplicando filtros de conteúdo, tópicos negados, redação de Informações de Identificação Pessoal (PII — Personally Identifiable Information) e políticas de palavras tanto no prompt quanto na resposta. Com saídas estruturadas, é possível restringir uma resposta a um JSON Schema para que o código downstream possa analisá-la diretamente. O log de invocação captura cada chamada no Amazon CloudWatch com a requisição, a resposta e as contagens de tokens incluindo tokens de raciocínio.

    Regiões e opções de inferência

    O Grok 4.7 roteia por um de dois perfis de inferência entre regiões em vez de fixar em uma única região. O perfil Global, global.xai.grok-4.7, roteia cada requisição para qualquer região AWS comercial suportada, distribuindo a carga por mais capacidade, e tem preço abaixo de um perfil geográfico. O tradeoff é menos controle sobre onde uma determinada requisição é atendida, o que pode significar latência mais variável. O perfil geográfico dos EUA, us.xai.grok-4.7, mantém o processamento dentro da geografia dos EUA, o que atende a requisitos de residência de dados americanos.

    Camada de serviço e preços

    Standard é pago por token sem compromisso, selecionado definindo "service_tier": "default" ou omitindo o campo. Priority entrega processamento mais rápido e priorizado por um valor premium ("service_tier": "priority"). Flex oferece acesso de menor custo para trabalhos sem urgência ("service_tier": "flex"). A camada de serviço é uma alavanca significativa de custo sob seu controle. Para preços por token em cada camada, consulte a página de preços do Amazon Bedrock.

    Enviando sua primeira requisição

    Antes da primeira chamada, confirme que o modelo está disponível para você no console do Bedrock para a região AWS que planeja usar. Instale o SDK da OpenAI e o boto3 se planeja usar a API Converse:

    pip install openai
    pip install boto3

    Gere uma chave de API de longa duração do Amazon Bedrock pelo console do Bedrock para exploração e configure o ambiente:

    export OPENAI_API_KEY="<provide your Bedrock API key>"
    export OPENAI_BASE_URL="https://bedrock-runtime.us-east-1.amazonaws.com/openai/v1"

    Uma primeira requisição com a API Chat Completions:

    from openai import OpenAI
    
    client = OpenAI()
    
    response = client.chat.completions.create(
        model="us.xai.grok-4.7",
        messages=[
            {"role": "user", "content": "Can you explain the features of Amazon Bedrock?"}
        ],
    )
    
    print(response.choices[0].message.content)

    A mesma chamada pela API Responses:

    response = client.responses.create(
        model="us.xai.grok-4.7",
        input="Can you explain the features of Amazon Bedrock?",
    )
    
    print(response.output_text)

    E pela API Converse com boto3. Como o raciocínio está sempre ativo, o primeiro bloco de conteúdo carrega o raciocínio e a resposta fica em um bloco posterior, então é preciso percorrer os blocos em busca do texto em vez de indexar content[0]:

    import boto3
    
    client = boto3.client("bedrock-runtime", region_name="us-east-1")
    
    response = client.converse(
        modelId="us.xai.grok-4.7",
        messages=[
            {"role": "user", "content": [{"text": "Can you explain the features of Amazon Bedrock?"}]}
        ],
        inferenceConfig={"maxTokens": 2048},
    )
    
    blocks = response["output"]["message"]["content"]
    text = next(b["text"] for b in blocks if "text" in b)
    print(text)

    No Converse, o nível de esforço é configurado via additionalModelRequestFields em vez de um parâmetro de raciocínio:

    response = client.converse(
        modelId="us.xai.grok-4.7",
        messages=[{"role": "user", "content": [{"text": "What is 17*23? Number only."}]}],
        inferenceConfig={"maxTokens": 3000},
        additionalModelRequestFields={"reasoning_effort": "xhigh"},
    )

    Três notas operacionais importantes. Primeiro, as requisições devem nomear us.xai.grok-4.7 ou global.xai.grok-4.7. Segundo, bedrock:InvokeModel é avaliado contra três recursos: o projeto padrão da sua conta, o perfil de inferência que você nomeia e o modelo base (FM — Foundation Model) subjacente. O Nome de Recurso da Amazon (ARN — Amazon Resource Name) do modelo base usa wildcard entre regiões porque os perfis cross-Region roteiam fora da região chamante. A autenticação por bearer token adicionalmente requer bedrock:CallWithBearerToken, que boto3 e Converse não precisam:

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": "bedrock:InvokeModel",
          "Resource": [
            "arn:aws:bedrock:{region}:{account-id}:project/default",
            "arn:aws:bedrock:{region}:{account-id}:inference-profile/us.xai.grok-4.7",
            "arn:aws:bedrock:*::foundation-model/xai.grok-4.7"
          ]
        },
        {
          "Effect": "Allow",
          "Action": "bedrock:CallWithBearerToken",
          "Resource": "*"
        }
      ]
    }

    Liste todos os perfis de inferência que planeja usar. Os perfis têm escopo individual, então uma política que nomeia us.xai.grok-4.7 não cobre global.xai.grok-4.7. Terceiro, os dois mecanismos de autenticação cobrem caminhos de código diferentes. Uma chave de API do Amazon Bedrock em OPENAI_API_KEY viaja como bearer token e autentica as chamadas compatíveis com OpenAI. Os exemplos Converse com boto3 assinam com SigV4, usando as credenciais AWS comuns do ambiente, de um perfil ou de uma role. Configure ambos se pretende usar Converse junto com as APIs compatíveis com OpenAI.

    Trate uma chave de API de longa duração como credencial apenas para exploração. Para produção, use tokens de curta duração gerados a partir das suas credenciais IAM com o pacote aws-bedrock-token-generator, pois eles expiram automaticamente e mantêm o acesso vinculado à sua identidade IAM.

    Trabalhando com o esforço de raciocínio

    O raciocínio está ativo no Grok 4.7, e o nível de esforço é o principal controle que você tem sobre custo e latência. Ele é configurado pelo parâmetro reasoning na API Responses com low, medium, high ou xhigh, e via additionalModelRequestFields no Converse. O padrão é high — vale configurar isso explicitamente em vez de herdar, porque deixar sem definir em chamadas sensíveis à latência ou de alto volume vai gastar mais tokens de raciocínio do que essas chamadas precisam.

    Como o modelo é treinado para trabalhar mais tempo e verificar o próprio output, esforço maior compra mais do que deliberação extra em uma única resposta: compra mais autochecagem ao longo de uma tarefa longa. Chamadas curtas de extração e classificação pertencem ao nível low. Planejamento em múltiplas etapas, trajetórias longas de agentes e trabalho onde um erro inicial se propaga são onde high e xhigh justificam seus tokens.

    O conteúdo de raciocínio é criptografado. É possível solicitá-lo passando o seguinte em uma requisição da API Responses:

    include=["reasoning.encrypted_content"]

    Em seguida, envie esse conteúdo de volta nos turnos subsequentes para dar ao modelo seu próprio raciocínio anterior como contexto em uma conversa de múltiplos turnos. A API Chat Completions não retorna tokens de raciocínio.

    from openai import OpenAI
    
    client = OpenAI()  # OPENAI_BASE_URL points at the bedrock-runtime endpoint
    
    response = client.responses.create(
        model="us.xai.grok-4.7",
        reasoning={"effort": "high"},
        include=["reasoning.encrypted_content"],
        input="Explain quantum entanglement simply.",
    )
    
    print(response.output_text)

    Para encontrar onde o raciocínio adicional deixa de compensar, faça benchmark dos níveis com sua própria carga de trabalho.

    Como começar

    Com o Grok 4.7 no Amazon Bedrock, é possível acessar uma janela de contexto de 500 mil tokens, quatro níveis de esforço de raciocínio, entrada de imagem, chamada de ferramentas e roteamento cross-Region geográfico e global — tudo pelas APIs Responses, Chat Completions e Converse. Para começar a construir, revise o model card do Grok 4.7 para a lista atual de regiões, matriz de funcionalidades e detalhes de parâmetros, e consulte a página de preços do Amazon Bedrock para as taxas por token. Se você gerou uma chave de API de longa duração do Amazon Bedrock para exploração, exclua-a do console do Bedrock quando terminar. Uma credencial em aberto que você não precisa mais apenas amplia a superfície de ataque da sua conta.

    Referências

    Fonte

    Grok 4.7 is now available on Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/grok-4-7-is-now-available-on-amazon-bedrock/)

  • Construindo aplicações de voz em tempo real com vLLM-Omni no SageMaker AI – Parte 1

    Voz em tempo real sem pausas longas: o desafio por trás da solução

    Agentes de voz, ferramentas de acessibilidade, assistentes de atendimento ao cliente e aplicações educativas interativas têm um requisito em comum: precisam responder rapidamente, sem silêncios longos que quebram a experiência do usuário. Para isso, o ideal é que o sistema comece a reproduzir o áudio antes mesmo de terminar de gerar toda a resposta — uma técnica conhecida como streaming de áudio.

    A AWS publicou um tutorial técnico que mostra exatamente como fazer isso no Amazon SageMaker AI, usando o Container de Aprendizado Profundo (DLC) vLLM-Omni para implantar o modelo Qwen3-TTS. O fluxo envia texto de entrada e recebe chunks de áudio de saída por uma única conexão bidirecional persistente, com a experiência sendo demonstrada por meio de uma aplicação Gradio.

    Este é o Parte 1 de uma série sobre DLCs especializados — incluindo vLLM-Omni, WhisperX e llama.cpp. Esta primeira parte foca em fala em streaming para aplicações de voz em tempo real. A Parte 2 aplica o mesmo DLC vLLM-Omni para geração de imagens e vídeos.

    O que são os AWS Deep Learning Containers especializados

    Os AWS Deep Learning Containers são imagens Docker pré-configuradas com frameworks de aprendizado profundo e todas as dependências necessárias para treinamento e inferência na AWS. A empresa fornece orientações de implantação para frameworks amplamente adotados como vLLM e SGLang.

    Runtimes de inferência especializados suportam arquiteturas de modelos e pipelines de mídia que diferem da geração de texto convencional. Os DLCs da AWS empacotam esses runtimes com suas dependências de framework e configuração de implantação, oferecendo um caminho padronizado baseado em imagem para computação AWS e serviços gerenciados de inferência.

    O projeto vLLM-Omni expande o vLLM além da geração de texto, permitindo servir modelos que processam ou geram texto, áudio, imagens e vídeo. O DLC vLLM-Omni da AWS empacota as releases rastreadas do vLLM-Omni em imagens AWS e adiciona um middleware de roteamento para o SageMaker AI.

    A abstração de pipeline heterogêneo do vLLM-Omni coordena fluxos de trabalho de modelos em múltiplos estágios, incluindo estágios autoregressivos e de difusão. Ele também fornece saídas em streaming e APIs compatíveis com o padrão OpenAI. O runtime não se limita a Texto para Fala (TTS): os modelos suportados incluem modelos omni unificados, Reconhecimento Automático de Fala (ASR), TTS, geração de áudio, geração de imagens e geração de vídeo.

    Contexto: o lado da entrada já foi coberto

    Um artigo anterior da AWS demonstrou o lado da entrada de um pipeline de voz: ele transmite áudio do microfone para o modelo Voxtral-Mini-4B Realtime de Fala para Texto (STT) e retorna eventos de transcrição. O tutorial atual adiciona o lado da saída — enviando texto para o Qwen3-TTS e transmitindo o áudio gerado de volta pelo DLC vLLM-Omni.

    Com as duas peças combinadas, é possível montar um pipeline completo: o áudio do microfone entra no modelo de transcrição, o texto resultante passa pela lógica de conversa da aplicação, e a resposta em texto é convertida em fala em streaming para o usuário. A orquestração entre os dois endpoints, no entanto, fica fora do escopo deste tutorial.

    Visão geral da solução

    O exemplo completo está disponível no repositório 03-features/bidirectional-streaming-vLLM-Omni. O clone do repositório fornece o script de implantação, o transporte de streaming compartilhado e o cliente Gradio juntos.

    O streaming bidirecional do SageMaker expõe um WebSocket full-duplex transportado sobre HTTP/2. O cliente conecta ao endpoint do SageMaker Runtime na porta 8443. O sidecar de inferência do SageMaker encaminha a conexão para a rota WebSocket nativa do vLLM-Omni dentro do container.

    O cliente envia eventos de configuração de sessão e de texto. O Qwen3-TTS retorna eventos de ciclo de vida de áudio e chunks de áudio pela mesma conexão. O DLC vLLM-Omni v1.5 adiciona o rótulo de capacidade de streaming bidirecional e o middleware de roteamento exigidos pelo SageMaker AI. O exemplo usa a rota v1/audio/speech/stream, uma das rotas WebSocket nativas expostas pelo vLLM-Omni.

    A configuração do endpoint também utiliza pools de instâncias do SageMaker. Um pool de instâncias define uma lista priorizada de tipos de instâncias compatíveis para uma variante de produção. O SageMaker tenta primeiro o ml.g6.xlarge e, se não houver capacidade disponível, recorre ao ml.g6e.xlarge, ml.g5.xlarge ou ml.g4dn.xlarge. Ainda assim, apenas uma instância é provisionada — não uma por entrada no pool.

    O SageMaker valida a cota para cada entrada configurada no pool ao criar o endpoint, portanto é necessário ter cota disponível para cada tipo incluído. O custo por hora também pode variar se o SageMaker selecionar um tipo diferente. Use o parâmetro --instance-types para restringir o pool aos tipos que atendem aos requisitos de cota, preço e desempenho.

    Pré-requisitos

    Antes de começar, são necessários:

    • Uma conta AWS com credenciais configuradas para a Interface de Linha de Comando (CLI) da AWS ou um SDK AWS
    • Git
    • Python 3.12 ou mais recente
    • Uma role de execução do SageMaker AI
    • Permissão para criar e invocar endpoints do SageMaker AI
    • Cota de endpoint para pelo menos um tipo de instância do pool: ml.g6.xlarge, ml.g6e.xlarge, ml.g5.xlarge ou ml.g4dn.xlarge
    • Boto3 versão 1.40.0 ou mais recente
    • O cliente Python HTTP/2 do SageMaker Runtime versão 0.4.0

    O tutorial usa a região US East (N. Virginia). O exemplo constrói o URI da imagem DLC e o endpoint de runtime a partir da variável AWS_REGION.

    Implantando o endpoint de fala em streaming

    Clonando o repositório e instalando dependências

    O primeiro passo é clonar o repositório de exemplos de hospedagem e entrar no diretório do exemplo de streaming bidirecional vLLM-Omni:

    git clone https://github.com/aws-samples/sagemaker-genai-hosting-examples.git
    cd sagemaker-genai-hosting-examples/03-features/bidirectional-streaming-vLLM-Omni

    Em seguida, crie um ambiente virtual e instale as versões definidas pelo exemplo:

    python3.12 -m venv .venv
    source .venv/bin/activate
    python -m pip install -r requirements.txt

    Configurando o exemplo

    Defina a role de execução do SageMaker AI. O exemplo usa us-east-1 como padrão. Passe --region para usar outra região suportada:

    export SAGEMAKER_EXECUTION_ROLE_ARN="arn:aws:iam::<account-id>:role/<sagemaker-execution-role>"

    A configuração do AMI de inferência é necessária para o sidecar do SageMaker que lida com o WebSocket HTTP/2. O caminho de invocação do modelo deve omitir a barra inicial, pois o SageMaker a adiciona antes de encaminhar a requisição.

    Implantando e mantendo o endpoint

    O script cria um modelo SageMaker a partir do DLC, uma configuração de endpoint e um endpoint em tempo real. A variável de ambiente SM_VLLM_MODEL informa ao container qual modelo carregar. O script também executa um teste de smoke de streaming e salva o resultado como validation-output.wav:

    python deploy_bidi_stream.py \
        --endpoint-name vllm-omni-bidi \
        --region us-east-1 \
        --keep-endpoint

    Aguarde até que o endpoint atinja o status InService. A primeira implantação leva mais tempo porque a instância precisa baixar a imagem DLC e os artefatos do modelo.

    Iniciando a aplicação Gradio

    Execute o cliente Gradio contra o endpoint:

    python sagemaker_bidi_tts_client.py \
        --endpoint-name vllm-omni-bidi \
        --region us-east-1

    Abra http://127.0.0.1:6006 no navegador. A opção --share cria um link público do Gradio — mantenha-a desabilitada a menos que esse comportamento seja necessário.

    Gerando fala em streaming

    Insira um texto, escolha uma voz e um idioma, e clique em Generate speech. O cliente compartilhado abre o stream bidirecional, configura a saída em Modulação por Código de Pulso (PCM) e envia o texto:

    await send_json(
        stream,
        {
            "type": "session.config",
            "voice": voice,
            "language": language,
            "response_format": "pcm",
            "stream_audio": True,
        },
    )
    await send_json(stream, {"type": "input.text", "text": text})
    await send_json(stream, {"type": "input.done"})

    O componente de áudio do Gradio reproduz cada chunk de PCM a 24 kHz à medida que o cliente o recebe. O campo de status reporta a contagem de chunks e o total de bytes de áudio.

    Removendo os recursos do exemplo

    Para evitar cobranças contínuas, interrompa o processo do Gradio e então exclua o endpoint, a configuração do endpoint e o modelo:

    python deploy_bidi_stream.py \
        --endpoint-name vllm-omni-bidi \
        --region us-east-1 \
        --delete-endpoint

    Confirme que o comando de limpeza reporta a exclusão do endpoint, da configuração do endpoint e do modelo. Se o processo for interrompido antes de a limpeza ser concluída, exclua os recursos pelo console do SageMaker AI ou pela API. Um endpoint de GPU em execução continua gerando cobranças.

    O que este exemplo demonstra

    Ao implantar um modelo de Texto para Fala (TTS), este tutorial mostra como o DLC vLLM-Omni da AWS no SageMaker AI transmite áudio enquanto o modelo ainda está gerando a resposta. Isso ilustra como os DLCs especializados da AWS suportam modelos multimodais cujos padrões de execução e streaming diferem da geração de texto convencional.

    Combinado com o exemplo anterior de fala para texto com vLLM, os dois exemplos mostram caminhos complementares: transmitir áudio do microfone para transcrição e, em seguida, transmitir a resposta em texto da aplicação de volta como fala. A Parte 2 mostrará como usar a mesma família de DLC para geração de imagens e vídeos.

    Recursos adicionais

    Fonte

    Build real-time voice applications with vLLM-Omni on SageMaker AI – Part 1 (https://aws.amazon.com/blogs/machine-learning/build-real-time-voice-applications-with-vllm-omni-on-sagemaker-ai-part-1/)

  • Claude Sonnet 5.5 chega ao Amazon Bedrock: mais inteligente, mais rápido e com menor custo por tarefa

    A AWS anuncia o Claude Sonnet 5.5 no Amazon Bedrock

    A AWS acaba de anunciar a disponibilidade do Claude Sonnet 5.5 no Amazon Bedrock e na Claude Platform on AWS. O novo modelo da Anthropic foi projetado para ser mais inteligente e eficiente que o Sonnet 5, com foco em tarefas de codificação e trabalho com conhecimento — entregando menor custo por tarefa para a maioria dos casos de uso, com velocidade superior.

    No Amazon Bedrock, o Sonnet 5.5 opera com os dados dentro da infraestrutura AWS, respeitando a residência regional dos dados. A integração com os controles já utilizados pelas equipes é nativa: Gerenciamento de Identidade e Acesso (IAM) para controle de acesso, AWS CloudTrail para auditoria, Amazon CloudWatch para monitoramento e Amazon Bedrock Guardrails para governança. O consumo do modelo aparece diretamente na fatura AWS.

    O que diferencia o Claude Sonnet 5.5

    Os avanços do Sonnet 5.5 se destacam especialmente em trabalhos bem delimitados. Quando um desenvolvedor atribui ao modelo uma funcionalidade ou correção de bug, o Sonnet 5.5 executa a tarefa e verifica o resultado em relação aos requisitos definidos. Além disso, o modelo produz documentos e visuais mais refinados do que o Sonnet 5 — incluindo resumos executivos, diagramas de arquitetura e slides de apresentação.

    Combinado ao menor custo por tarefa, isso torna o Sonnet 5.5 especialmente adequado para cargas de trabalho contínuas ou em escala. No contexto de engenharia, os casos de uso incluem:

    • Primeira resposta a alertas
    • Monitoramento contínuo de agentes
    • Geração de SQL
    • Testes de Interface do Usuário (UI) e Experiência do Usuário (UX)
    • Agentes de codificação rápida em Ambiente de Desenvolvimento Integrado (IDE) com teto de gasto fixo

    No contexto corporativo, o modelo suporta análises delimitadas, edições rápidas em planilhas e tarefas rotineiras de documentação para grandes bases de usuários.

    Combinando Sonnet 5.5 com Opus 5.5

    Com o lançamento recente do Opus 5.5, a AWS passa a oferecer uma dupla complementar de modelos Claude para diferentes tipos de trabalho: decisões que exigem julgamento cuidadoso e tarefas onde a abordagem já está clara e o que resta é executar com agilidade.

    A lógica de uso recomendada é a seguinte:

    • Claude Opus 5.5 assume as decisões que exigem julgamento. Em codificação, isso inclui depuração de releases, stacks de funcionalidades com múltiplos pull requests, revisão de segurança em pull requests grandes e migrações de código com alvos bem definidos. Fora do código, o Opus 5.5 lida com análises longas que resultam em planilhas, apresentações ou relatórios finalizados, além de pesquisa financeira e revisão de contratos.
    • Claude Sonnet 5.5 assume o trabalho onde a abordagem já está clara e o que resta é executar rapidamente — com menor custo por tarefa (em relação ao Opus 5.5) e maior velocidade.

    Como começar com o Claude Sonnet 5.5 no Amazon Bedrock

    Para experimentar o Sonnet 5.5 diretamente pelo console, basta acessar o console do Amazon Bedrock, navegar até Test > Playground e selecionar o Sonnet 5.5 como modelo. A partir daí, é possível enviar prompts diretamente contra o modelo.

    Para uso programático, o modelo pode ser chamado via Anthropic Messages API apontando para o endpoint bedrock-runtime através do Anthropic SDK. Também é possível usar as APIs Invoke e Converse no bedrock-runtime via Interface de Linha de Comando AWS (AWS CLI) e AWS SDK.

    Pré-requisitos

    • Conta AWS ativa com acesso ao Amazon Bedrock
    • AWS CLI instalado e configurado
    • Python 3.10+
    • Boto3 instalado: pip install boto3
    • Permissões de Gerenciamento de Identidade e Acesso (IAM): bedrock:InvokeModel, bedrock:InvokeModelWithResponseStream

    Exemplo com AWS SDK para Python (Boto3)

    Abaixo está um exemplo de chamada ao modelo usando a API InvokeModel:

    import boto3
    import json
    
    # Create a Bedrock Runtime client
    bedrock_runtime = boto3.client(
        service_name="bedrock-runtime",
        region_name="us-east-1"
    )
    
    # Invoke Claude Sonnet 5.5
    response = bedrock_runtime.invoke_model(
        modelId="global.anthropic.claude-sonnet-5-5",
        contentType="application/json",
        accept="application/json",
        body=json.dumps({
            "anthropic_version": "bedrock-2023-05-31",
            "max_tokens": 4096,
            "messages": [
                {
                    "role": "user",
                    "content": " Write a Python function slugify(text) that lowercases a string, replaces spaces and underscores with hyphens, and strips any character that isn't a letter, digit, or hyphen. Code only."
                }
            ]
        })
    )
    
    result = json.loads(response["body"].read())
    
    # Sonnet 5.5 may return a thinking block before the text block,
    # so select the text block rather than a fixed index.
    print(next(b["text"] for b in result["content"] if b["type"] == "text"))

    Para mais exemplos, a AWS disponibiliza um notebook de introdução no GitHub. O monitoramento de uso, desempenho e custos pode ser feito via Amazon CloudWatch e AWS Cost Explorer para escalar as aplicações conforme a demanda cresce.

    Disponibilidade e preços

    O Claude Sonnet 5.5 está disponível hoje no Amazon Bedrock através do perfil de inferência Global CRIS (global.) no bedrock-runtime. A documentação do Amazon Bedrock traz a lista completa de regiões AWS suportadas. As informações de preço estão disponíveis na página de preços do Amazon Bedrock. O modelo também está disponível via Claude Platform on AWS na América do Norte.

    Para experimentar, acesse o console do Amazon Bedrock, a Claude Platform on AWS ou explore os notebooks de introdução no GitHub.

    Fonte

    Introducing Claude Sonnet 5.5 on AWS (https://aws.amazon.com/blogs/machine-learning/introducing-claude-sonnet-5-5-on-aws/)