Kimi K3 vs GPT-5.6-SOL: teste prático de alta dificuldade em matemática, física e programação

Kimi K3 vs GPT-5.6-SOL: teste pesado em matemática, física e programação#

Desta vez, nada de perguntas fáceis. A ideia foi fixar três problemas que exigem raciocínio encadeado: uma questão de probabilidade com sobreposição de padrão e segundo momento, uma questão de física com momento de inércia da polia e transição por afrouxamento da corda, e um problema em Python que depende de fechamento de dependências, capacidade por dia e um tie-break em três níveis. Os dois modelos usaram a mesma interface, o mesmo prompt e limites de saída semelhantes, sem ferramentas e sem acesso à internet.

Resumo direto:

• gpt-5.6-sol entregou respostas visíveis completas nas três questões, com os resultados de referência corretos em matemática e física.
• kimi-k3 terminou matemática e física com finish_reason=length no limite inicial de 6500 tokens; a resposta visível veio vazia. Mesmo com o limite de matemática elevado para 10000, ainda houve truncamento. Já o problema de programação estourou timeout de leitura depois de cerca de 245 segundos.
• A implementação de programação do GPT-5.6-SOL passou em verificações independentes de fechamento de dependências, capacidade, tie-break, dependência inválida e dependência cíclica, mas a primeira asserção de exemplo que ele mesmo incluiu tinha um valor esperado incorreto. Isso mostra que “código principal correto” e “todos os testes de exemplo corretos” precisam ser validados separadamente.

A latência citada aqui é o valor observado nesta execução, não uma SLA fixa. Na primeira rodada concorrente, as requisições de matemática e física do GPT chegaram a retornar HTTP 408; depois disso, elas foram repetidas em sequência. Por isso, o tempo serve apenas para observar a experiência de chamada, e não para declarar um ranking absoluto.

Configuração do teste#

O teste foi executado entre 2026-07-17 e 2026-07-18, no horário de Brasília, usando a interface:

POST https://cn.crazyrouter.com/v1/chat/completions
model: kimi-k3 / gpt-5.6-sol
temperature: 0.2

Na primeira rodada, os limites foram uniformes: matemática e física com max_tokens=6500, e programação com max_tokens=7500. Em cada questão, o modelo precisava apresentar uma derivação verificável ou código executável, e foram registrados finish_reason, tokens de completion/reasoning, latência, correção numérica e se o código rodava de forma independente no Python 3.11.

Tabela geral de resultados#

Nas requisições de matemática e física do Kimi, o interface reportou tokens de reasoning próximos de 6497; na reexecução da matemática, os tokens de reasoning ficaram perto de 9997. Isso não quer dizer que o Kimi “não raciocina”; quer dizer que, com este prompt e esta rota, o orçamento de raciocínio estourou facilmente, e o chamador não recebeu a resposta final.

Questão de matemática: sobreposição de padrão afeta não só a esperança, mas também a variância#

O enunciado é: com probabilidade de cara p=3/5, de coroa q=2/5, lançar moedas até aparecer a primeira ocorrência de HHTH, permitindo sobreposição de padrão, e calcular E[T] e Var(T).

O autômato de prefixos correto tem os estados S0=prefixo vazio, S1=H, S2=HH, S3=HHT, S4=HHTH（estado absorvente）. A transição crucial é S2 --H--> S2: após já ter HH, ao surgir H de novo, o maior sufixo ainda é HH; não se pode voltar erroneamente ao estado vazio.

As equações de primeira ordem montadas pelo GPT-5.6-SOL foram:

M0 = 1 + p M1 + q M0
M1 = 1 + p M2 + q M0
M2 = 1 + p M2 + q M3
M3 = 1 + q M0

Continuando com as equações de segundo momento, obtém-se:

E[T]   = 715/54       ≈ 13.2407407407
E[T²]  = 195335/729   ≈ 267.9492455418
Var(T) = 270115/2916  ≈ 92.6320301783

A esperança também pode ser conferida independentemente pela fórmula de borda. HHTH tem como fronteira própria não vazia apenas o caractere H, então E[T] = 1/p + 1/(p³q) = 715/54. A resposta completa do GPT cobriu transições de estado, expansão do segundo momento e o sanity check. Já o Kimi, tanto com 6500 quanto com 10000 tokens, não exibiu nenhuma derivação visível, então nesta rodada não foi possível atribuir nota de correção matemática; só dá para registrar como “não concluído dentro do orçamento”.

Questão de física: depois que a massa toca o chão, a restrição se rompe e não dá para continuar com a mesma equação de energia#

O problema foi montado com: m_A=4.0 kg em um plano inclinado áspero de 25°, μ_k=0.18; m_B=3.0 kg suspensa; polia com M_p=1.2 kg, R=0.10 m; B desce 1.50 m e toca o chão; a corda afrouxa imediatamente; A ainda sobe 0.10 m e encosta numa mola de k=250 N/m; g=9.8 m/s².

Antes do impacto com o chão, a corda está esticada e não há deslizamento; a massa inercial equivalente da polia é I/R²=(1/2)M_p=0.60 kg. Ao combinar o movimento dos dois blocos com a equação rotacional da polia, chega-se a:

a  ≈ 0.847 m/s²
v1 ≈ 1.59 m/s
v2 ≈ 1.18 m/s
x  ≈ 0.0835 m = 8.35 cm

Depois que B toca o chão, sua velocidade muda por causa da colisão com o solo; A ainda segue para cima ao longo do plano, e a polia também pode continuar girando. Como o enunciado deixa claro que a corda afrouxa logo em seguida, não se pode continuar usando v_A=v_B=Rω. Daí em diante, só A deve ser analisada:

v2² = v1² - 2g(sinθ + μ_k cosθ)d
1/2 m_A v2² = 1/2 kx² + m_A g(sinθ + μ_k cosθ)x

O GPT-5.6-SOL ainda conferiu dimensionalidade, distância de parada sem mola e a soma entre energia da mola e perdas por atrito/gravididade, e tudo fechou de forma consistente. O Kimi não produziu resposta visível na primeira rodada, então não houve como comparar a qualidade da modelagem intermediária.

Questão de programação: o núcleo do algoritmo passou na verificação independente, mas o exemplo do próprio modelo tinha bug#

O problema de programação pedia implementar optimize_release_plan(items, capacity_by_day, dependencies), lidando com capacidade por dia, capacidade zero para datas não configuradas, fechamento de dependências diretas e indiretas, detecção de dependência inválida e ciclo, além do tie-break em três níveis value → risk → lista de ids ordenada. Como items <= 18, enumeração por bitmask era uma base totalmente razoável.

O GPT-5.6-SOL usou cache de fechamento de dependências e enumeração de subconjuntos 2^n. Extraímos o código e fizemos uma checagem independente no Python 3.11: fechamento de dependências, exemplo de capacidade multi-dia, tie-break em três camadas value/risk/id, capacidade para data não configurada, dependência inexistente e dependência cíclica; as 6 verificações passaram.

Mas a primeira asserção de teste anexada no fim do código falhou: ele escreveu A -> B -> C, mas também incluiu X com valor 11. Com a capacidade dada, o valor total de B + C + X é 13, maior que A + B + C, que soma 12; portanto, a função retornar ['B', 'C', 'X'] é o comportamento correto, e a asserção ['A', 'B', 'C'] estava errada. Isso é um detalhe bem representativo: em questão de código, não basta olhar só a função principal, nem assumir que “vieram 8 asserts” significa que os testes são confiáveis. Os dados de teste gerados pelo modelo também precisam de revisão manual ou por implementação de referência. A requisição de programação do Kimi K3 estourou timeout de leitura depois de cerca de 245 segundos, sem entregar o código completo.

Avaliação geral#

A conclusão mais precisa não é “um modelo é absolutamente mais inteligente”, mas sim:

1. Nesta rota e com este orçamento, o GPT-5.6-SOL conseguiu condensar melhor o raciocínio complexo em resposta final, o que o torna mais adequado para fluxos que precisam de derivação ou código legíveis na hora.
2. O principal problema do Kimi K3 foi a eficiência de conversão entre orçamento de raciocínio e saída visível; mesmo subindo a matemática para 10000 tokens, a resposta ainda não terminou.
3. O código do GPT-5.6-SOL também não pode ser aceito no automático. A lógica da função passou nas verificações independentes, mas o conjunto de testes anexado tinha um erro de cálculo de valor.
4. Em seleção para produção, o ideal é registrar juntos finish_reason, tokens de reasoning, latência e resultado dos testes locais; não dá para olhar só a última frase dizendo “a resposta está correta”.

Como reproduzir#

Os scripts deste teste e os resultados do retry em sequência ficam salvos em:

.tmp/kimi_k3_vs_gpt56sol_test.py
.tmp/kimi-k3-vs-gpt56sol-results.json
.tmp/retry-gpt56sol-math.json
.tmp/retry-gpt56sol-physics.json
.tmp/retry-gpt56sol-programming.json
.tmp/retry-kimi-k3-math.json

Ao repetir o experimento, vale fixar o ID do modelo, o prompt, temperature, max_tokens e o grau de concorrência, e salvar cada saída em um arquivo separado. Carga do canal de origem, acerto de cache e estado de rate limit afetam a latência; aqui, HTTP 408, length e timeout de leitura foram registrados como parte do resultado do teste, e não escondidos.