Kimi K3 versus Claude Opus 4.8: testes de matemática, física e programação em nível de pós-graduação

Kimi K3 vs Claude Opus 4.8: teste prático de matemática, física e programação em nível de pós-graduação#

Em contas aritméticas simples, todo modelo grande consegue dar respostas bonitas. O que realmente separa os modelos é outra coisa: a derivação termina dentro do orçamento de saída? A matriz e as condições de contorno foram escritas corretamente? O programa gerado realmente satisfaz a semântica do enunciado?

Desta vez, elevei o nível dos problemas para algo equivalente a um TCC de graduação ou a uma disciplina de mestrado, usando o mesmo conjunto de prompts para testar kimi-k3 e claude-opus-4-8:

• Matemática: distribuição estacionária, tempo de primeiro alcance, primeiro e segundo momentos de uma cadeia de Markov finita com três estados;
• Física: oscilador de dois graus de liberdade com amortecimento aterrado e amortecimento acoplado, pedindo modos sem amortecimento e resposta harmônica complexa;
• Programação: algoritmo de escalonamento exato com fechamento de dependências, janela de tempo, capacidade diária e função objetivo em três níveis.

Primeiro, o veredicto:

• claude-opus-4-8 retornou as três tarefas completas dentro do orçamento desta rodada, e o finish_reason nas três foi stop;
• kimi-k3 precisava ter temperature configurado como 1; com limite de 6000 completion tokens, as três tarefas terminaram com finish_reason=length, e os três conteúdos visíveis tiveram comprimento 0;
• As respostas de matemática e física do Opus 4.8 passaram por verificação numérica independente;
• O código de escalonamento do Opus 4.8 passou nos 13 asserts que ele mesmo incluiu, mas, ao adicionar um probe independente exigindo que a tarefa predecessora viesse antes da sucessora, descobri que ele só garante que a dependência seja selecionada junto, sem garantir que a predecessora fique antes da posterior;
• A latência média dos pedidos bem-sucedidos nesta rodada foi de cerca de 70.59 秒 para o Opus 4.8 e cerca de 225.47 秒 para o Kimi K3. Essa diferença vale apenas para este conjunto de rota e prompt; não deve ser tratada diretamente como SLA de longo prazo.

Ambiente de teste e restrições de parâmetros#

Os testes foram feitos entre 18 e 19 de julho de 2026, horário de Pequim. Primeiro, confirmei via /v1/models que os dois model IDs estavam visíveis:

kimi-k3
claude-opus-4-8

As requisições foram feitas por meio da interface OpenAI-compatible da Crazyrouter:

POST https://cn.crazyrouter.com/v1/chat/completions

Condições comuns:

Mesmo system prompt
Mesmo enunciado do usuário
Sem ferramentas e sem acesso à internet

Os parâmetros dos modelos não puderam ser exatamente iguais, porque o upstream impõe uma restrição rígida ao Kimi K3:

Na primeira tentativa, usei temperature=0.1 com o Kimi K3, e a interface retornou explicitamente:

Parameter temperature must be 1 for this model.

Por isso, este artigo registra essa limitação de parâmetro como um fato do teste, em vez de esconder a falha como se o modelo estivesse “indisponível”. Ao usar os resultados em uma escolha de produção, também faz sentido levar as capacidades específicas de parâmetros de cada modelo para a camada de configuração, em vez de assumir que todos aceitam o mesmo conjunto de parâmetros de sampling.

Tabela geral de resultados#

O formato comum das três saídas do Kimi foi muito consistente: a API retornou o nome do modelo e o usage, mas message.content não trouxe nenhuma resposta final utilizável. Para aplicações que precisam mostrar o resultado ao usuário ou entregar algo para um compilador, isso deve ser classificado como “tarefa não concluída”, e não como “o modelo acertou, mas o log não registrou”.

Problema de matemática: tempo de primeiro alcance e variância em uma cadeia de Markov finita#

O enunciado usa a matriz de transição:

com o estado-alvo 3 e a definição:

$\tau=\min\{n\ge 0:X_n=3\}。$

Não é uma questão que se resolve só substituindo probabilidades em uma fórmula. É preciso lidar com a distribuição estacionária, a submatriz transiente, os momentos de primeira e segunda ordem do tempo de primeiro alcance e, além disso, deixar explícitas as condições de contorno do estado-alvo t_3=s_3=0.

Resultado do Opus 4.8#

Ele deu a distribuição estacionária como:

e verificou componente por componente que πP=π.

Tomando {1,2} como estados transientes, obteve:

A equação de primeiro momento foi:

portanto:

Para o segundo momento, usou:

e obteve:

Fiz uma resolução independente com Fraction, e o resultado coincidiu exatamente com o do Opus; ao substituir t e s de volta nas duas equações de primeiro passo, tudo também fechou. O problema de matemática foi classificado como “aprovado por completo”.

Resultado do Kimi K3#

O Kimi K3 rodou por cerca de 235 segundos com temperature=1 e max_tokens=6000, e o usage mostrou completion_tokens=6000, reasoning_tokens=5997, finish_reason=length, com content visível vazio.

Isso significa que, nesta rodada, não dá para concluir pela saída do Kimi se ele resolveria ou não essa cadeia de Markov. O que se pode afirmar é apenas que, com a interface, o prompt e o orçamento atuais, ele não condensou o raciocínio em uma resposta final visível.

Problema de física: matriz e resposta em frequência de um oscilador com amortecimento acoplado#

A segunda questão usa um sistema de dois blocos de massa, com dois graus de liberdade:

m1=1.5 kg，m2=1.0 kg
k1=120 N/m，k2=80 N/m，k3=150 N/m
c1=1.2 N·s/m，c2=0.8 N·s/m，c3=1.5 N·s/m
F(t)=10 cos(8t) N

k2 e c2 são os elementos acoplados entre as duas massas, e c1 e c3 são os amortecimentos aterrados de cada lado. O enunciado pede primeiro os modos naturais sem amortecimento e depois a amplitude complexa em ω=8 rad/s; portanto, não dá para colocar todos os amortecimentos simplesmente em uma matriz diagonal.

Matrizes corretas#

O Opus 4.8 escreveu:

A equação característica sem amortecimento forneceu as frequências naturais angulares:

As razões modais correspondentes X2/X1 foram 0.6173 e -2.4298, representando, respectivamente, os modos em fase e em oposição de fase.

Resposta em frequência para ω=8#

A matriz complexa de rigidez dinâmica:

O cálculo complexo independente deu:

A checagem de energia do Opus também passou: a potência média dissipada foi de cerca de 1.2574 W, consistente com a potência de entrada da força dentro do erro de arredondamento. Ele também explicou corretamente que, se c2 fosse interpretado erroneamente como amortecimento aterrado, os termos não diagonais C12=C21=-0.8 seriam zerados por engano, e tanto a transferência de energia quanto os resultados de fase mudariam.

Resultado do Kimi K3#

O Kimi K3 esgotou 6000 tokens depois de cerca de 204.6 segundos e ainda assim terminou com finish_reason=length e content vazio. Como não houve equações finais nem números finais, não dá para avaliar se a modelagem física estava correta; nesta rodada, o registro só pode ser “não entregue dentro do orçamento”.

Problema de programação: fechamento de dependências, janela temporal e escalonamento exato#

A tarefa de programação pedia implementar:

schedule_jobs(jobs, dependencies, capacity_by_day)

Cada tarefa tem duration, release_day, deadline_day e value; a tarefa precisa ser agendada integralmente em um único dia, cada dia tem um limite de capacidade, e as dependências significam que a tarefa predecessora precisa terminar antes de a sucessora começar. O objetivo é comparar os resultados nesta ordem:

1. Valor total máximo;
2. Menor duração total;
3. Lista de IDs ordenada em ordem lexicográfica menor.

Essa questão é mais difícil do que um “knapsack + sort” comum, porque é preciso lidar ao mesmo tempo com:

• Fechamento de dependências diretas e indiretas;
• Dependências desconhecidas e detecção de ciclos;
• Capacidade diária e janelas de tempo das tarefas;
• Bin packing exato de subconjuntos viáveis;
• Desempate em múltiplos níveis.

Comportamento da implementação do Opus 4.8#

O Opus forneceu uma implementação completa com bitmask + DFS com memoização, além de 13 asserts. Extraí os dois blocos de código Python e executei em Python 3.11; todos os asserts do próprio modelo passaram:

all assertions passed

Ele cobriu corretamente entrada vazia, capacidade insuficiente, dependências diretas/indiretas, dependências desconhecidas, dependências cíclicas e a comparação da função objetivo em três níveis.

Mas os asserts internos não verificavam se a tarefa predecessora vinha antes da sucessora. Eu acrescentei um probe independente:

jobs = [
    {"id": "A", "duration": 4, "release_day": 1,
     "deadline_day": 1, "value": 1},
    {"id": "B", "duration": 4, "release_day": 0,
     "deadline_day": 0, "value": 10},
]
result = schedule_jobs(jobs, [("A", "B")], {0: 4, 1: 4})

Na semântica correta, A é predecessora de B, mas só pode ser agendada no dia 1, enquanto B só pode ser agendada no dia 0; logo, as duas não deveriam ser selecionadas ao mesmo tempo. O código do modelo, porém, retornou:

selected_ids: ['A', 'B']
assignment: {'A': 1, 'B': 0}

Isso mostra que a implementação só verificou “ao escolher B, A também precisa ser escolhida”, sem checar:

assignment[A] < assignment[B]

Portanto, a tarefa de programação não pode ser considerada totalmente aprovada. A avaliação mais precisa é: a estrutura do algoritmo e a validação de entrada estão razoavelmente completas, e a lógica de alocação de recursos funciona, mas a semântica principal do negócio deixou de fora a restrição temporal de ordem das dependências. Para um sistema de escalonamento em produção, isso é um problema de corretude que precisa ser corrigido, não um detalhe de formato.

Resultado do Kimi K3#

O Kimi K3 terminou após cerca de 236.4 segundos com length, consumindo todos os 6000 tokens em reasoning, sem entregar código executável.

Latência, orçamento de saída e respostas visíveis#

Latência média nas três tarefas:

Kimi K3:       (235.420 + 204.568 + 236.434) / 3 = 225.474 秒
Claude Opus:   (57.870 + 64.966 + 88.934) / 3 = 70.590 秒

As três chamadas do Kimi tiveram usage muito parecido:

completion_tokens = 6000
reasoning_tokens  = 5997
content.length    = 0
finish_reason     = length

Esses dados mostram que quem integra a API não pode olhar só para o status HTTP e o campo model. O mínimo é registrar ao mesmo tempo:

choice.finish_reason
response.usage
response.choices[0].message.content

Se finish_reason for length, mesmo com HTTP 200, o fluxo deveria seguir para retry, fallback ou revisão humana.

Como reproduzir o experimento#

Abaixo está a forma mínima de chamada usando o OpenAI Python SDK. No teste real, é preciso usar os enunciados completos do artigo e os parâmetros compatíveis com cada modelo:

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_CRAZYROUTER_API_KEY",
    base_url="https://cn.crazyrouter.com/v1",
)

response = client.chat.completions.create(
    model="claude-opus-4-8",
    temperature=0.1,
    max_tokens=9000,
    messages=[
        {"role": "system", "content": "Benchmark rigoroso, forneça apenas conclusões verificáveis."},
        {"role": "user", "content": "Substitua pelo teste completo de nível de pós-graduação"},
    ],
)

print(response.model)
print(response.choices[0].finish_reason)
print(response.usage)
print(response.choices[0].message.content)

Ao chamar o Kimi K3, é preciso mudar temperature para 1 e reservar tempo suficiente para um reasoning mais longo; nesta rodada, mesmo com 6000 tokens, ainda não foi possível obter uma resposta visível.

Recomendações para escolha em produção#

Quando faz sentido testar primeiro o Claude Opus 4.8#

• É necessário obter uma derivação completa ou código completo em uma única requisição;
• A tarefa envolve matrizes, condições de contorno e verificação numérica;
• O negócio é mais sensível à latência de primeira tela e à entregabilidade;
• É possível adicionar testes independentes e checagem semântica ao código gerado.

Quando ainda vale continuar avaliando o Kimi K3#

• É aceitável uma latência de vários minutos;
• A camada de chamada consegue lidar com parâmetros de sampling específicos do modelo;
• É permitido quebrar a tarefa em partes, aumentar o orçamento ou usar um fluxo assíncrono;
• O foco está no processo de reasoning, e não na entrega imediata do texto final em uma única chamada.

Mas, com os dados desta rodada, não dá para dizer que o Kimi K3 “resolveu as três tarefas, só que a saída foi escondida no log”. O que foi observado de fato é que, nas três vezes, não houve resposta final visível.

FAQ#

1. Por que essas questões são consideradas de nível de graduação final ou pós-graduação?#

A questão de matemática exige distribuição estacionária, matriz fundamental e segundo momento do tempo de primeiro alcance; a de física exige modelagem matricial, análise modal, resposta em frequência complexa e balanço de energia; a de programação exige fechamento de dependências, bin packing exato, detecção de ciclos e otimização com múltiplos critérios. Cada uma delas corresponde a dificuldades típicas de trabalhos integradores em cursos de probabilidade/processos estocásticos, mecânica clássica e vibrações, e algoritmos/design de sistemas.

2. O Kimi K3 não suporta temperature=0.1?#

Nesta interface, o Kimi K3 exigiu explicitamente que temperature fosse 1. Isso é uma restrição de parâmetros do modelo na rota atual; a aplicação chamadora deve ler a mensagem de erro e tentar novamente com a configuração correta.

3. O length do Kimi K3 prova que ele definitivamente não consegue fazer esse tipo de questão?#

Não. Ele só mostra que, com este prompt, este limite de saída e estas condições de roteamento, não foi produzido um final visível. Sem resposta visível, não há como atribuir nota de correção; mas isso também não prova que o modelo nunca resolva esses problemas em qualquer configuração.

4. A resposta de programação do Opus 4.8 pode ser usada diretamente em produção?#

Não diretamente. Os asserts internos passaram todos, mas o probe independente revelou que a restrição de ordem temporal das dependências foi omitida. O código gerado precisa de testes de semântica de negócio, e não apenas da execução dos testes que o próprio modelo anexou.

5. Por que a questão de física do Opus 4.8 precisa checar dissipação de energia?#

Porque é muito fácil escrever errado o termo não diagonal do amortecimento acoplado. A igualdade entre potência de entrada e potência dissipada pelos amortecedores é uma evidência independente de que a amplitude complexa, a fase e a matriz de amortecimento estão todas corretas ao mesmo tempo.

6. Esta latência pode ser tratada como compromisso de desempenho?#

Não. Canal de upstream, cache, concorrência e retries alteram a latência. Em produção, é preciso amostrar várias vezes e calcular P50, P95, P99, taxa de truncamento e custo por tarefa bem-sucedida.

Conclusão final#

O que esta rodada comparou de verdade não foi um “ranking de inteligência” desligado das condições de chamada, mas dois comportamentos de entrega totalmente diferentes:

1. O Claude Opus 4.8, nesta rodada, entregou respostas visíveis nas três tarefas de nível de pós-graduação, e as derivações de matemática e física passaram por verificação independente;
2. O framework de código do Opus é forte, mas ainda deixou escapar a restrição crítica de que tarefas dependentes precisam terminar em ordem temporal;
3. O Kimi K3, sob a condição forçada de temperature=1, esgotou os 6000 tokens nas três tarefas, com finish_reason=length, sem resposta visível;
4. Se o objetivo do negócio é obter, em uma única chamada, uma derivação matemática completa, um cálculo físico ou código executável, neste intervalo de teste o Opus 4.8 teve entregabilidade claramente melhor;
5. Seja qual for o modelo escolhido, finish_reason, usage, verificação numérica independente e testes semânticos de código precisam entrar no critério de aceite.

Arquivos do experimento:

• Script de teste: kimi_k3_vs_opus48_graduate_test.py
• Resultado do Kimi: kimi-k3-graduate-results.json
• Resultado comparativo: kimi-k3-vs-opus48-graduate-results.json

Leituras recomendadas:

• Kimi K3 vs GPT-5.6-SOL: teste de alta dificuldade em matemática, física e programação
• Kimi K3 vs Claude Fable 5: teste prático de raciocínio complexo
• Cadastro na Crazyrouter