Kimi K3.1 Pro Highspeed chega ao Amazon Bedrock com cache de prompt explícito

O que mudou

O Kimi K3.1 Pro Highspeed, da Moonshot AI, está disponível no Amazon Bedrock. É uma versão pós-treinada do Kimi K3, com a mesma arquitetura open-weight de classe 3T e a mesma janela de contexto de 1 milhão de tokens, mas treinada com volume bem maior de compute de pós-treinamento.

Segundo a Moonshot AI, esse treinamento extra mira trabalho agóntico de longo horizonte e menos erros factuais. A fonte também cita ganhos em tarefas profissionais (modelagem financeira, documentos de escritório) e em código para game engines, cenas 3D e scripts CAD. O destaque de performance: o Kimi K3.1 Pro Highspeed gera tokens de saída de 2 a 3 vezes mais rápido que o Kimi K3.1 Pro.

O modelo usa o mesmo endpoint, as mesmas APIs e os mesmos recursos do Kimi K3 já disponível no Bedrock. Quem já integrou o Kimi K3 troca apenas o model ID no código existente. Ele suporta tool calling, structured output, reasoning configurável, entrada de imagem e streaming.

No quesito segurança, nada muda em relação ao que já valia para o Kimi K3: os dados ficam dentro do AWS data boundary, não são compartilhados com a Moonshot AI nem usados para treinar o modelo. Zero retenção de dados fica sempre ativa nas requisições de inferência, e zero acesso de operador significa que ninguém da AWS vê seus prompts e completions durante a inferência.

Onde está disponível

O acesso se dá por três cross-Region inference profiles:

• global.moonshotai.kimi-k3.1: roteia para qualquer região comercial da AWS suportada e custa menos por token que os perfis geográficos. É o recomendado pela AWS para a maioria das cargas.
• us.moonshotai.kimi-k3.1: mantém o processamento dentro de regiões dos EUA, para quem tem requisito de residência de dados.
• in.moonshotai.kimi-k3.1: equivalente, mas mantendo processamento em regiões da Índia.

A fonte não lista nominalmente quais são as "supported commercial Regions" cobertas pelo perfil global, nem cita a região América do Sul (São Paulo), sa-east-1, em nenhum trecho. Para quem precisa confirmar se o tráfego pode ficar restrito a São Paulo, o caminho indicado pela própria AWS é consultar o model card do Kimi K3.1 Pro Highspeed e a página de Regional availability do Bedrock antes de colocar em produção.

Quanto custa

A fonte não traz uma tabela de preço por milhão de tokens: remete à página oficial de Amazon Bedrock pricing para os valores atualizados. Dois pontos de preço aparecem explicitamente no texto:

• O perfil global.moonshotai.kimi-k3.1 custa menos por token do que os perfis geográficos us. e in..
• O tier Flex cobra metade do preço do tier Standard, em troca de tempo de resposta potencialmente maior.

O Flex serve bem workloads em que custo pesa mais que latência: avaliação de modelos, sumarização de conteúdo e tarefas de fundo em workflows agônticos. Como o tier é escolhido por requisição, uma mesma aplicação pode misturar Priority para o que é crítico em latência, Standard para o tráfego do dia a dia e Flex para o que pode esperar. A quota on-demand é compartilhada entre os três tiers.

Sobre o cache de prompt: escritas de cache são cobradas a uma taxa maior que o input padrão, e leituras de cache saem com desconto e não contam para a quota de tokens de input por minuto.

Como começar

Sem escrever código, o caminho é console: Amazon Bedrock > Test > Playground > selecionar Kimi K3.1.

Via código, o modelo está disponível no endpoint bedrock-runtime, pelas APIs OpenAI-compatible Chat Completions e Responses, e também pelas APIs Converse e Invoke do Bedrock. A AWS recomenda a Chat Completions API. Os pré-requisitos: conta AWS com acesso ao Bedrock, Python 3.11 ou mais recente, e os pacotes instalados com pip install -U openai aws-bedrock-token-generator boto3. A identidade IAM precisa de permissão para bedrock:InvokeModel e bedrock:InvokeModelWithResponseStream nos inference profiles do modelo, mais bedrock:CallWithBearerToken se a autenticação usar bearer token.

Exemplo mínimo com a Chat Completions API:

from openai import OpenAI
from aws_bedrock_token_generator import provide_token

REGION = "us-west-2"
MODEL_ID = "global.moonshotai.kimi-k3.1"

client = OpenAI(
    base_url=f"https://bedrock-runtime.{REGION}.amazonaws.com/openai/v1",
    api_key=provide_token(region=REGION),
)

completion = client.chat.completions.create(
    model=MODEL_ID,
    messages=[
        {"role": "system", "content": "You are a concise senior engineer."},
        {"role": "user", "content": "When should I prefer a queue over a stream?"},
    ],
    reasoning_effort="high",
)
print(completion.choices[0].message.content)

O Kimi K3.1 Pro Highspeed sempre raciocina antes de responder. O parâmetro reasoning_effort controla quanto: low, high ou max. Se não for definido, o padrão é max — reduzir esse valor é a forma mais direta de cortar latência e tokens de saída em tarefas simples. Quem já chama o modelo pela Converse API muda só o modelId para global.moonshotai.kimi-k3.1.

O que muda para quem já usa

Quem já roda aplicações com Kimi K3 no Bedrock troca o model ID e segue com a mesma integração, sem reescrever chamadas. O ganho real está no prompt caching explícito, pensado para agentes e coding assistants que reenviam o mesmo prefixo grande a cada turno: instruções de sistema, definições de tools, convenções de repositório, documentos de referência.

Algumas regras valem para esse cache explícito:

• Funciona nas APIs Chat Completions, Responses e Invoke, mas não na Converse.
• Um prompt_cache_breakpoint precisa vir depois de pelo menos 256 tokens de conteúdo estável.
• O conteúdo em cache fica retido por, no mínimo, 30 minutos.

A fonte traz um exemplo de uso real: o OpenCode, agente de código open source e agnóstico de modelo que roda no terminal, conectado ao Kimi K3.1 Pro Highspeed via Bedrock Chat Completions API e uma Bedrock API key. A configuração entra em ~/.config/opencode/opencode.json, apontando o baseURL para a região escolhida. Chaves de curta duração (até 12 horas, válidas só na região em que foram geradas) são as recomendadas para produção; chaves de longa duração ficam reservadas para exploração.

A velocidade de saída importa mais em coding agóntico. Para completar uma única tarefa, um agente de código faz várias chamadas ao modelo em sequência: lê arquivos, planeja uma mudança, edita código, roda testes e corrige o que falhou.

Output speed matters most in agentic coding. To complete a single task, a coding agent makes many model calls in a row. It reads files, plans a change, edits code, runs tests, and fixes what fails.AWS Machine Learning Blog

Cada chamada precisa terminar antes da próxima começar, e boa parte desse tempo é gasto gerando raciocínio e código. Uma taxa maior de tokens de saída encurta cada etapa, então o loop inteiro de editar, testar e corrigir termina mais rápido — e o desenvolvedor espera menos entre iterações.

Fonte: AWS Machine Learning Blog