Kimi K3.1 Pro Highspeed chega ao Amazon Bedrock: tokens 2–3 vezes mais rápidos

Quem desenvolve um agente de programação sabe que o maior problema não é o preço do token, mas a espera. O agente lê arquivos, planeja a alteração, escreve código, executa testes e corrige as falhas — e cada etapa depende da conclusão da anterior. Por isso, a velocidade de geração importa mais aqui do que um número bonito em um benchmark. É nessa necessidade que aposta o novo lançamento no Amazon Bedrock: o Kimi K3.1 Pro Highspeed, da Moonshot AI.

Que modelo é esse

O Kimi K3.1 Pro Highspeed faz parte da nova série K3.1. É uma versão do Kimi K3 com pós-treinamento: mantém a arquitetura com pesos abertos e 3 trilhões de parâmetros, além da janela de contexto de um milhão de tokens, mas recebeu um volume consideravelmente maior de treinamento adicional. Segundo a Moonshot AI, esse treinamento busca melhorar a execução de tarefas longas por agentes e reduzir erros factuais. A empresa também promete ganhos em usos profissionais, como modelagem financeira e documentos de escritório, além de código para motores de jogos, cenas 3D e scripts CAD.

O principal diferencial do nome Highspeed: segundo a Moonshot AI, o modelo gera tokens de saída 2–3 vezes mais rápido que o K3.1 Pro. Essa é uma afirmação do fornecedor; o material não apresenta medições independentes. Por isso, teste suas próprias tarefas antes de adaptar o ambiente de produção ao modelo.

O modelo oferece chamadas de ferramentas, saída estruturada, raciocínio configurável, entrada de imagens e streaming. Em segurança, a AWS promete que os dados são processados dentro dos limites da AWS, não são enviados à Moonshot AI e não são usados para treinamento. A retenção zero está sempre ativada para solicitações de inferência, e os operadores da AWS não têm acesso aos seus prompts e respostas.

Como conectar: quase nada muda

O modelo está disponível no endpoint bedrock-runtime pelas APIs Chat Completions e Responses, compatíveis com OpenAI, além de Converse e Invoke. A AWS recomenda Chat Completions. Se a aplicação já usa o SDK da OpenAI, basta apontá-la para o endpoint do Bedrock e mudar o nome do modelo. Quem já usa o Kimi K3 no Bedrock nem precisa fazer tudo isso: o endpoint, a API e os recursos continuam iguais; só muda o ID do modelo.

O acesso ocorre por perfis de inferência entre regiões:

• global.moonshotai.kimi-k3.1 — roteamento para qualquer região comercial compatível, com menor custo por token e indicado para a maioria das tarefas;
• us.moonshotai.kimi-k3.1 — processamento apenas em regiões dos EUA;
• in.moonshotai.kimi-k3.1 — processamento apenas em regiões da Índia, para atender a requisitos de localização dos dados.

Se você não tem requisitos rígidos de residência de dados, escolha global.

Há um detalhe importante: o modelo sempre raciocina antes de responder. A profundidade é definida pelo parâmetro reasoning_effort (reasoning.effort na Responses API), com os valores low, high ou max. Se ele não for informado, o modelo usa max. Em solicitações simples, isso gera tokens e latência desnecessários. Definir low explicitamente é a forma mais direta de acelerar a resposta e reduzir a conta.

Onde economizar: Flex e cache explícito

A tarifa Flex oferece o modelo pela metade do preço da Standard, mas o tempo de resposta pode ser maior. É indicada para avaliação de modelos, sumarização e tarefas em segundo plano dentro de fluxos de agentes. A tarifa é escolhida a cada solicitação: as mais sensíveis à latência podem usar Priority, o tráfego comum pode usar Standard e o restante, Flex. A cota é compartilhada entre elas. A AWS recomenda começar com uma pequena parcela do tráfego em Flex, comparar latência e custo e acompanhar a distribuição por tarifa no CloudWatch.

A segunda forma de economizar é o cache explícito de prompts. Agentes e assistentes reenviam o mesmo prefixo longo a cada interação: instruções de sistema, descrições de ferramentas e regras do repositório. O modelo armazena automaticamente em cache os prefixos repetidos. Já os breakpoints explícitos permitem indicar onde termina a parte estável e aumentar a taxa de acertos no cache. As regras são estas:

• funciona em Chat Completions, Responses e Invoke, mas não em Converse;
• o breakpoint deve ficar após pelo menos 256 tokens de conteúdo estável;
• o cache é mantido por pelo menos 30 minutos;
• a gravação no cache custa mais que a entrada comum; a leitura custa menos e não é contabilizada na cota de tokens de entrada por minuto.

É simples verificar se houve um acerto no cache: o campo cached_tokens em usage deve ser maior que zero.

Conclusão prática

O artigo mostra como conectar o modelo ao OpenCode, um agente de programação aberto que roda no terminal e não fica preso a um único modelo. É preciso configurar um provedor compatível com OpenAI baseado em Chat Completions e uma chave de API do Bedrock. As chaves de curta duração são válidas por até 12 horas, funcionam apenas na região em que foram criadas e são recomendadas para produção; as de longa duração são indicadas para experimentos. No OpenCode, os níveis de raciocínio low, high e max aparecerão como variantes do modelo.

O que fazer na prática. Para desenvolvedores que trabalham com agentes: trocar o ID no ambiente de testes, medir a duração do ciclo completo de «alteração — teste — correção» e comparar com a K3.1 Pro convencional. Para equipes de produto: distribuir o tráfego entre as tarifas para que as tarefas em segundo plano usem Flex. Para todos: não deixar reasoning_effort no valor padrão quando low for suficiente.

As limitações são claras. A aceleração de 2–3 vezes e a redução de erros são afirmações da Moonshot AI, sem verificação independente. O material não informa preços; será preciso consultá-los na página de tarifas do Bedrock. O cache não funciona via Converse, então será necessário mudar de API para adotar o cache explícito.