Kimi K2.7-Code: modelo open source de código com melhor eficiência de tokens

 (huggingface.co)
1 pontos por GN⁺ 4 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Um modelo de código orientado a agentes voltado para tarefas de programação de longa duração e fluxos complexos de engenharia de software, baseado no Kimi K2.6, com maior capacidade de concluir tarefas de ponta a ponta e melhor eficiência no uso de tokens
  • Em relação ao Kimi K2.6, reduziu em cerca de 30% o uso de tokens de raciocínio, enquanto o Kimi Code Bench v2 subiu de 50.9 para 62.0 e o MCP Mark Verified de 72.8 para 81.1
  • A arquitetura do modelo é baseada em MoE, com 1T de parâmetros no total, 32B de parâmetros ativos, janela de contexto de 256K e encoder de visão MoonViT
  • A implantação é voltada para a API oficial e para vLLM, SGLang e KTransformers; como tem a mesma arquitetura do Kimi-K2.5/Kimi-K2.6, é possível reutilizar o método de implantação existente
  • No uso, o modo Thinking e preserve_thinking são obrigatórios; há suporte a entrada de imagens, e entrada de vídeo é suportada atualmente de forma experimental apenas na API oficial

Visão geral do modelo

  • Kimi K2.7-Code é um modelo de agente focado em programação baseado no Kimi K2.6, com melhorias em tarefas realistas de programação de longa duração
  • Reforça a capacidade de conclusão de tarefas de ponta a ponta em fluxos complexos de engenharia de software
  • Em comparação com o Kimi K2.6, reduz em cerca de 30% o uso de tokens de raciocínio, aumentando a eficiência de tokens
  • É disponibilizado com tags como entrada imagem-texto, Transformers, Safetensors, conversational e custom_code

Resumo do modelo

  • A arquitetura é Mixture-of-Experts (MoE), com 1T de parâmetros no total e 32B de parâmetros ativos
  • O número de camadas é 61, incluindo camadas Dense, sendo 1 camada Dense
  • A Attention Hidden Dimension é 7168, e a MoE Hidden Dimension é 2048 por especialista
  • São 64 Attention Heads, 384 especialistas, 8 especialistas selecionados por token e 1 especialista compartilhado
  • O vocabulário tem 160K e a janela de contexto é 256K
  • O mecanismo de attention é MLA, e a função de ativação é SwiGLU
  • O encoder de visão é o MoonViT, com 400M de parâmetros

Resultados de avaliação

  • Benchmarks de código

    • No Kimi Code Bench v2, o Kimi K2.6 registrou 50.9, o Kimi K2.7 Code 62.0, o GPT-5.5 69.0 e o Claude Opus 4.8 67.4
    • No Program Bench, o Kimi K2.6 registrou 48.3, o Kimi K2.7 Code 53.6, o GPT-5.5 69.1 e o Claude Opus 4.8 63.8
    • No MLS Bench Lite, o Kimi K2.6 registrou 26.7, o Kimi K2.7 Code 35.1, o GPT-5.5 35.5 e o Claude Opus 4.8 42.8

  • Benchmarks de agentes

    • No Kimi Claw 24/7 Bench, o Kimi K2.6 registrou 42.9, o Kimi K2.7 Code 46.9, o GPT-5.5 52.8 e o Claude Opus 4.8 50.4
    • No MCP Atlas, o Kimi K2.6 registrou 69.4, o Kimi K2.7 Code 76.0, o GPT-5.5 79.4 e o Claude Opus 4.8 81.3
    • No MCP Mark Verified, o Kimi K2.6 registrou 72.8, o Kimi K2.7 Code 81.1, o GPT-5.5 92.9 e o Claude Opus 4.8 76.4

  • Condições de avaliação

    • Salvo indicação em contrário, o Kimi K2.7 Code e o K2.6 foram testados no Kimi Code CLI com o modo Thinking ativado, temperature 1.0, top-p 0.95 e janela de contexto de 262.144 tokens
    • O GPT-5.5 foi executado no modo xhigh do Codex, e o Opus 4.8 foi executado no modo xhigh do Claude Code
    • Tirando essas diferenças, todos os benchmarks foram avaliados nas mesmas condições

  • Composição dos benchmarks

    • O Kimi Code Bench V2 é um benchmark interno que avalia agentes de programação em tarefas realistas, cobrindo mais de 10 linguagens de programação principais e toda a stack tecnológica de produção
    • O Kimi Code Bench V2 inclui casos de uso internos de engenharia, incidentes de produção e tarefas de projetos open source reais
    • Program Bench exige reproduzir o comportamento de programas apenas com binários compilados e documentação, usando 200 tarefas e mais de 248.000 testes de comportamento gerados por fuzzing
    • MLS-Bench avalia se sistemas de IA conseguem criar métodos de ML generalizáveis e escaláveis, e o MLS-Bench-Lite é um subconjunto oficial de 30 tarefas
    • O Kimi Claw 24/7 Bench é um benchmark interno que avalia desempenho de agentes de longa duração em colaboração contínua de vários dias, cobrindo 17 cenários especializados e 610 pontos de avaliação
    • MCP-Atlas avalia o desempenho de LLMs em tarefas realistas de uso de ferramentas por meio de MCP escalável
    • O MCPMark-Verified é a versão validada por humanos do MCPMark, avaliando o uso de ferramentas MCP em 5 ambientes reais de servidor, incluindo Notion, GitHub, Filesystem, Postgres e Playwright

Quantização Native INT4

  • O Kimi-K2.7-Code adota o mesmo método de quantização native int4 do Kimi-K2-Thinking

Implantação

  • A API do Kimi-K2.7-Code pode ser acessada em https://platform.moonshot.ai
  • A API oficial oferece API compatível com OpenAI/Anthropic
  • Os motores de inferência recomendados são vLLM, SGLang e KTransformers
  • O Kimi-K2.7-Code tem a mesma arquitetura do Kimi-K2.5/Kimi-K2.6, então o método de implantação pode ser reutilizado diretamente
  • O requisito de versão do transformers é >=4.57.1, <5.0.0
  • Exemplos de implantação podem ser vistos no Model Deployment Guide

Como usar

  • Condições básicas para chamadas de API

    • A demonstração de uso se baseia no método de chamada da API oficial
    • O Kimi-K2.7-Code força o uso de Thinking e preserve_thinking como True
    • Em APIs de terceiros implantadas com vLLM ou SGLang, chat com conteúdo de vídeo é um recurso experimental atualmente suportado apenas na API oficial
    • O temperature recomendado para o modo Thinking é 1.0, e o top_p recomendado é 0.95
    • O modo Instant não é suportado

  • Chat Completion

    • O exemplo de Chat Completion chama a API do K2.7-Code no modo Thinking
    • O código de exemplo usa o cliente openai para chamar client.chat.completions.create e define max_tokens=4096
    • Na resposta, são exibidos response.choices[0].message.reasoning e response.choices[0].message.content

  • Entrada de conteúdo visual

    • O K2.7-Code oferece suporte a entrada de imagem e vídeo
    • O exemplo de entrada de imagem codifica a imagem em base64 e a envia em image_url, gerando resposta com max_tokens=8192
    • O exemplo de entrada de vídeo codifica um arquivo mp4 em base64 e o envia em video_url
    • Chat com vídeo é atualmente um recurso experimental suportado apenas na API oficial

  • Preserve Thinking

    • O Kimi K2.7 Code força o modo preserve_thinking, mantendo todo o conteúdo de reasoning em interações multi-turno
    • preserve_thinking melhora o desempenho em cenários de agentes de programação
    • Esse recurso é ativado por padrão e não pode ser desativado
    • Algumas APIs podem não suportar reasoning_content, então pode-se tentar reasoning

  • Interleaved Thinking e chamadas de ferramentas em múltiplas etapas

    • O K2.7-Code compartilha com o K2 Thinking o design de Interleaved Thinking e Multi-Step Tool Call
    • Para exemplos de uso, consulte a documentação do K2 Thinking

  • Framework de agente de programação

    • O Kimi K2.7-Code funciona melhor quando usado com o Kimi Code CLI como framework de agente
    • O Kimi Code CLI é fornecido em https://www.kimi.com/code

Exemplos de execução local

  • Transformers

    • No Transformers, é possível criar um pipeline de alto nível com pipeline("image-text-to-text", model="moonshotai/Kimi-K2.7-Code", trust_remote_code=True)
    • O carregamento direto do modelo pode ser feito com AutoModel.from_pretrained("moonshotai/Kimi-K2.7-Code", trust_remote_code=True, dtype="auto")

  • vLLM

    • O vLLM é instalado com pip install vllm e o servidor é iniciado com vllm serve "moonshotai/Kimi-K2.7-Code"
    • O exemplo de chamada usa o endpoint de API compatível com OpenAI http://localhost:8000/v1/chat/completions
    • No Docker Model Runner, a execução é feita com docker model run hf.co/moonshotai/Kimi-K2.7-Code

  • SGLang

    • O SGLang é instalado com pip install sglang e o servidor é iniciado com python3 -m sglang.launch_server --model-path "moonshotai/Kimi-K2.7-Code"
    • O exemplo de chamada usa o endpoint de API compatível com OpenAI http://localhost:30000/v1/chat/completions
    • O exemplo de execução com Docker configura GPU, memória compartilhada, cache do Hugging Face e a variável de ambiente HF_TOKEN

Licença

Leituras relacionadas

1 comentários

 
GN⁺ 4 시간 전
Comentários no Hacker News

  • Achei engraçado ler a cláusula de licença revisada. Na prática, é uma licença MIT com uma cláusula de publicidade dos antigos BSDs adicionada, e parece mais um pedido para que façam “publicidade” deles se o produto for usado, independentemente de usuários ativos mensais ou receita
    Sinceramente, parece um pedido razoável

    • Isso parece uma cláusula mirando o Cursor. A ideia é não deixá-los passar vergonha ao serem obrigados a divulgar
    • Aqui, a cláusula de “publicidade” significa só revelar em algum lugar do produto que ele foi usado. Por exemplo, colocar nos créditos da seção “About”
    • Dá a impressão de que foi acrescentado às pressas. Eu esperava que tivessem refinado melhor a redação jurídica sobre o que está incluído na “interface do usuário”

  • Dei ao Kimi K2.7-code instruções bem simples para fazer o rebase do patch Fil-C do OpenSSL de 3.3.1 para 3.5.7, e aparentemente deu certo
    O patch tinha 177 KB, então não era uma mudança pequena, e no começo ele não aplicou limpo, então o agente teve que fazer um trabalho bem substancial
    Eu só dei o patch para 3.3.1, o comando de build, o caminho de 3.5.7 e um link para a documentação de mudanças (https://fil-c.org/constant_time_crypto)
    Mas usei o T800, que é o próprio agente de programação deles, não é público, e já estava bem testado e ajustado antes para o K2.5
    O custo da API parece ter ficado entre $5~$10. Correção: era OpenSSL, não OpenSSH

  • Pessoalmente, ao usar código aberto ou roteadores, acima de um certo nível eu quase não sinto grande diferença entre os modelos. A exceção são modelos caros e meio ambíguos como o Gemini
    Nesse sentido, os modelos chineses são bem decentes. Normalmente eu faço o modelo escrever o código no nível de função ou método, depois projeto e monto tudo
    A linha GPT é mais cuidadosa e melhor, mas não sei se a diferença é tão enorme assim. Vai depender do fluxo de trabalho, mas, se você tratar o processo com rigor suficiente, fico em dúvida se a diferença é realmente grande

    • Em certa medida, já desisti dos roteadores de inferência “gratuitos”. Como era de se esperar, ao tentarem economizar inferência ao máximo, a qualidade do raciocínio muitas vezes cai
      Rodar o Qwen 3.6 35B A3B MTP transformando um MacBook M1 Pro em almofada térmica foi relativamente bem-sucedido
      Ao tentar usar modelos Gemini como se fossem “locais”, apareceu um problema parecido: eles fragmentavam demais o esforço, cometiam muitos erros e aumentavam o número de turnos
      Por outro lado, vendo falarem que o Fable é persistentemente “proativo”, parece que com branding forte e cobrança eficaz também dá para ir na direção oposta
    • Pela minha experiência, na implementação de funções individuais quase não há diferença entre modelos de ponta e modelos mais recentes na faixa de 30B
      Se já existe um projeto consistente, que é a parte difícil, dá para colocar isso em um modelo bem pequeno e obter praticamente a mesma qualidade
      Não sai tudo pronto de uma vez, mas como é mais rápido e mais barato, no fim acaba sendo vantajoso. Além disso, dá para fazer localmente
    • A diferença no resultado não é grande, mas é verdade que eles precisam ser tratados com mais rigor. Por exemplo, o Kimi K2.5/K2.6 às vezes confundia testes falhando com “falhas pré-existentes” e os comentava em vez de corrigir o problema que ele mesmo tinha acabado de criar
      Por isso, é preciso deixar explicitamente configurado que testes comentados quebrem o build. Pessoalmente, não tive esse problema com modelos da Anthropic ou da OpenAI
    • Eu preferiria que parassem de usar a expressão “modelos chineses”. Ela tem uma conotação negativa
      É parecido com quando antes se falava “carro japonês”, mas hoje isso já quase não faz sentido, e as pessoas simplesmente dizem Toyota, Honda, Lexus

  • Se alguém já comparou opencode + Kimi K2.6/2.7 com Claude Code na prática, eu realmente queria saber. Queria entender o que é melhor ou pior e como fica a comparação de custos
    No momento estou pagando $100 no plano 5x Max, mas o Fable consome o limite de uso bem rápido, e também é difícil dizer que a diferença para o Opus seja como dia e noite
    Como uso principalmente em projetos paralelos, uma fatura de $100 já pesa bastante, e não quero pagar mais do que isso

    • Eu usava principalmente Claude Code com Opus, mas migrei para opencode + Kimi 2.6 em projetos pessoais e usei assim por alguns meses
      Claude Code é melhor, sim. Mas o ponto importante é que opencode + Kimi 2.6 também é bem utilizável
      Se você sabe exatamente o que quer e só pede para escrever código simples, a maioria dos modelos populares como DeepSeek e Kimi funciona bem, e a diferença para os modelos da Anthropic não parece tão grande
      Por outro lado, o Opus entende a intenção muito melhor que o DeepSeek. Quando uso DeepSeek, preciso escrever prompts com bem mais precisão, e se escrever de forma vaga ele frequentemente vai para uma direção estranha
      O Kimi fica no meio-termo. Ele recupera um pouco desse fluxo de “prompt solto” e dá para confiar mais no plano dele do que no DeepSeek
      Dá para ter um fluxo de trabalho parecido com o do Claude Code, mas no geral ele é um pouco pior em tudo. Janela de contexto, número de erros, tomada de decisão, recomendações e capacidade de depuração ficam todos um pouco abaixo
      Em termos de uso, o plano Claude de $100 na prática tem um bom custo-benefício. O Kimi é muito mais barato por token, mas a assinatura do Claude parece ser bem subsidiada, então por $100 você recebe muito mais tokens do que conseguiria comprar via API
      No fim, com padrões de uso parecidos, o custo de opencode + Kimi e de Claude Code pode acabar ficando semelhante
      O DeepSeek é mais barato, e os tokens em cache são absurdamente baratos, mas se você vier do Claude Code talvez precise ajustar sua forma de trabalhar dependendo dos seus hábitos
      Para projetos paralelos, acho bem prático montar algo com o plano Opencode Go de $10 mais $10 de créditos do DeepSeek v4 em um serviço como o OpenRouter
    • No trabalho uso Claude, e em projetos paralelos uso Kimi. Na organização temos LiteLLM e Kimi 2.5 ativados, mas quase nunca funcionam bem, então Claude e GPT são as ferramentas principais
      O Kimi parece mais um desenvolvedor em entrevista, então é mais divertido. Ver como ele raciocina sobre o problema lembra a forma como eu explico coisas numa sessão de quadro branco. É engraçado como ele fala “wait” com frequência demais
      O Claude parece mais um funcionário já contratado, ou até uma equipe. Ele não começa com longas explicações, só faz perguntas quando precisa e depois entrega um relatório ou plano mais abrangente
      Acho o OpenCode um harness melhor. Em custo, não consigo comparar diretamente porque nunca rodei exatamente o mesmo prompt nos dois lados
      Recentemente pedi ao Kimi para criar um wrapper de libpq para a linguagem de programação ZenC (https://github.com/nobleach/zenc-postgres); levou cerca de uma hora e custou aproximadamente $4
    • Estou muito satisfeito com o ohmypi, mas também dá para usar OpenCode ou continuar com Claude Code
      O DeepSeek-V4-Pro é bom o bastante, e para tarefas ou atividades menores que você deixaria com Haiku ou Sonnet, dá para usar DS4-Flash. É só entrar com $10 pré-pagos
      O OpenCode Go custa $5 por mês, e você pode usar Qwen-3.7-Max para design, planejamento, arquitetura e resolução de problemas difíceis. Ele parece mais próximo do Opus 3.6 ou 3.7 do que do DeepSeek, e foi o mais parecido que encontrei
      O OpenAI Codex, no plano de $20 por mês, permite usar o GPT-5.5 via API para design, planejamento, arquitetura, resolução de problemas e escrita de commits. Para problemas realmente difíceis, você ainda pode pagar $100 e colar no chat do GPT-5.5-Pro
      O Xiaomi MiMo-2.5-Pro pode render 72 centavos em créditos grátis se você pegar um código de indicação de $2 com um amigo. O preço é o mesmo do DeepSeek, e ele fica em algum ponto entre Sonnet e Opus, sendo bastante capaz. Também vale tentar entrar no beta do UltraSpeed
      No OpenCode ou no ohmypi, basta ir trocando esses modelos na hora para encontrar o que funciona melhor para você. Eu uso o CodexBar para acompanhar o uso quase em tempo real
      Para usuários leves ou iniciantes em programação, o plano de $20 do Cursor é uma boa forma de começar com Composer-2.5 e Composer-2.5-Fast. Ele também tem cota de API, então além do próprio Cursor você pode acessar Opus-4.x ou GPT-5.5-Pro a partir do OpenCode ou do ohmypi
      Se você usa Grok ou Twitter, o SuperGrok de $30 por mês tem um bom modelo de visão, e eu o usei para testes automatizados de frontend. Mas agora estou migrando para Qwen-3-VL local em um Mac comum. Se você tem menos familiaridade técnica, o unreach facilita hospedar modelos locais no Mac
      Se você tiver uma GPU potente como uma RTX 5090, também vale tentar rodar Qwen-3.6 localmente. Com ollama ou llama-swap, é relativamente fácil
      Ainda não usei o novo Kimi, mas opero uma equipe com 3 desenvolvedores profissionais, 1 designer gráfico que usa bastante Midjourney e Grok Imagine, e 1 usuário não técnico que usa ohmypi para levantamento de requisitos e acompanhamento de implementação, mantendo o custo abaixo de $200 por funcionário por mês
      Com um pouco mais de esforço, talvez dê para chegar mais perto de $75 por funcionário por mês
    • Estou usando Claude Code com um proxy litellm remendado, OpenRouter e Qwen 3.7 max/Kimi K2.6/DeepSeek v4 pro conectados
      A única função que não funciona é webfetch e busca na web, mas substituí isso desviando o agente com ddg MCP e um pre-hook de busca/coleta na web
      Memória, cache e o resto funcionam bem
      O Qwen fica perto do Opus no planejamento, mas o Fable claramente é melhor
      Para codificação, quando o Opus escreve o plano, os resultados de Kimi e DeepSeek ficam quase indistinguíveis dos do Opus
      A maior diferença é o ritmo da saída. Por exemplo, o Kimi pensa por muito tempo e depois despeja muito texto rapidamente
      No momento estou testando Fable para pesquisa e planejamento, e DeepSeek v4 flash para codificação. Os resultados parecem próximos de Opus + DeepSeek v4 pro, e o custo total deve ser menor
    • Só posso falar do GLM 5.1, mas para mim ele fica mais perto do nível do Sonnet 4

É bom e lida bem com a maioria das tarefas que você joga nele, mas falha em tarefas cognitivamente complexas. Fica travando com frequência. Ainda assim, custa cerca de US$ 6 por mês.

  • Existe um ponto de inflexão em que o modelo “melhor” deixa de importar, e acho que não estamos longe disso. O Fable está realmente muito bom agora, mas se daqui a cerca de um ano o Kimi alcançar, mesmo que o Fable6 seja muito melhor, se custar 1/10 eu provavelmente usaria o Kimi
    Antes, ao ver o Opus 4.5, pensei: “se ele já está tão bom assim, em 6 a 12 meses os modelos chineses vão ficar tão bons e baratos nesse nível, então vou usar eles”, mas eu estava errado. Ainda hoje pago um prêmio por Opus 4.7/8 e Fable
    Mesmo assim, em algum momento eles simplesmente vão chegar ao nível de fazer o trabalho que você quer, e a partir daí começará uma corrida de queda de preços
    Agora as empresas chinesas podem acessar tokens do Fable muito bons, então espero que essa concorrência acelere

    • Dependendo de quem você é e de como usa o modelo, em alguns casos esse ponto já foi alcançado
    • Acho que a próxima frente de competição é a velocidade. Em vez de ficar alternando entre vários agentes, cada um fazendo sua parte, e lidando com mudança de contexto, seria ótimo se um único agente pudesse avançar em qualquer prompt em poucos segundos e manter o fluxo de um trabalho só
    • O preço por token não é a única coisa que importa. Se você precisar perguntar de novo para a IA, isso pode sair mais caro do que um modelo que acerta de primeira
      Por isso, um modelo melhor pode na prática sair mais barato, mesmo com preço por token mais alto

  • Se o Opus for 5 vezes mais caro que o Kimi K2.6 ou outros modelos chineses e ainda assim for só um pouco melhor, eu me perguntava como empresas como a Anthropic conseguem manter a competitividade
    Minha hipótese é que empresas americanas não podem enviar dados para o lado chinês, e isso eu entendo. Mas isso é mesmo um “fosso competitivo”?

    • O fosso atual é o desempenho do modelo e, por causa disso, a quantidade extra de tokens e tempo consumidos
      Digo isso como alguém que usa modelos Kimi com bastante frequência e no geral gosta deles
      Em benchmarks como o DeepSWE, que ainda não foram gamificados, o Kimi K2.6 fica bem atrás do Claude Sonnet 4.6($3/$15) e também um pouco atrás do GPT 5.4 Mini($0.75/$4.50)
      Está claro que o modelo Kimi é muito bom em muitas tarefas de programação e tem a melhor qualidade entre os modelos de pesos abertos
      Mas, para obter resultados gerais parecidos com Sonnet/Opus, em média é preciso usar muito mais tokens e gerenciar mais o modelo
      Não se deve olhar para o preço por token, e sim para quanto se paga pelo processo inteiro
    • Acho que existe a percepção de que não é “só um pouco melhor”. Essa diferença de qualidade percebida permite diferenciação de preço
      Além disso, quando se gasta muito dinheiro, há agentes racionais suficientes rodando avaliações, então é provável que “um pouco melhor” não seja apenas uma sensação pura
      Ainda assim, eu só consigo ver parte das suítes de avaliação. Também pode ser que todo mundo esteja sendo irracional e a Anthropic esteja se aproveitando disso
    • Acho que a maioria das pessoas que usou os dois diria que os modelos da Anthropic são mais do que só um pouco melhores que o Kimi
      Kimi e outros modelos open source podem pontuar bem em coisas como SWE-bench, mas, no uso real, a diferença é perceptível
    • O preço do token na API é só um dos fatores, e a assinatura do Claude tem bom custo-benefício
      Curiosamente, todo mundo diz, com base no preço da API, que a assinatura do Claude é subsidiada, mas ninguém sabe qual é o custo real de inferência do Claude, e provedores chineses também conseguem oferecer inferência barata. Então me pergunto por que acham que o Claude não conseguiria
      Para clientes corporativos também pode haver outros contratos de preço de API que não são públicos. O que vemos pode ser apenas um preço de tabela alto
    • Só em áreas comparáveis isso fica mais perto de “um pouco melhor”; em muitas outras áreas, os modelos A\ são muito melhores. Por exemplo, tarefas de um tipo que Kimi etc. não destilaram
      Nessas tarefas, a diferença é de nível abismal

  • Testando direito, isso parece uma melhora bem boa. Só o fato de usar menos tokens na mesma tarefa já é motivo suficiente para usar no lugar do K2.6 quando for preciso um modelo aberto

  • Se um modelo novo não for claramente uns 20~30% melhor que o DeepSeek v4 e ainda tiver preço por token mais alto que o DeepSeek, acho que ele quase automaticamente acaba virando um modelo de baixo uso. Talvez sirva para planejamento

    • O DeepSeek v4 Pro na prática não é um modelo tão bom assim em comparação com GLM 5.1 ou Kimi K2.6. É mais um coder/raciocinador com custo-benefício ok
    • Fico curioso se o DeepSeek está bancando esse custo, ou se as pessoas realmente conseguem hospedar modelos abertos com custo parecido

  • Ainda não estou muito acostumado com modelos open-weight/open source. Se alguém os usa profissionalmente, gostaria de ouvir sobre configuração e desempenho. Estou considerando migrar a organização dos produtos da Anthropic

    • Falando da minha experiência pessoal, no trabalho individual uso forgecode e openrouter. Primeiro, considero o forgecode um harness muito melhor que o Claude Code
      Em termos de qualidade do modelo, não há uma grande diferença, mas a diferença de custo é absurda. Pelo menos na forma como eu uso agentes, é assim
      Ontem, por exemplo, eu estava desenvolvendo uma pequena DSL para buscar documentação técnica complexa e testei o Fable para adicionar um operador pequeno
      O Fable queimou $13 e apresentou uma solução, mas objetivamente não foi melhor do que o mesmo trabalho feito pelo DeepSeek v4 por $1.7
      Dito isso, eu delego tarefas fragmentadas ao agente. No caso da DSL, eu projetei os operadores e fiz o agente implementá-los um por um
      Se eu tivesse partido de um documento complexo e pedido para ele projetar tudo, talvez o Fable tivesse brilhado
      Mas sempre que dou tarefas de escopo mais amplo ao agente, ele queima milhões de tokens e gera código duvidoso, e no fim eu preciso gastar tempo entendendo aquilo
    • Eu criei o https://github.com/gitsense/gsc-cli e diria que cerca de 80% do código é obra do glm-4.7
      Por exemplo, se você olhar um arquivo como https://github.com/gitsense/gsc-cli/blob/main/internal/cli/r..., deixei explícito qual modelo foi usado
      O 4.7 não era tão bom para código em go, então começou a aparecer Gemini 3 Flash na atribuição
      O 4.7 é um modelo fornecido pela Cerebras, e para mim a velocidade de iteração importa muito mais
      Depois de usar o MiMo v2.5.0-Pro, estou convencido de que ele teria conseguido fazer 100% do que o Gemini 3 Flash fez
      Algumas vezes, quando eu travava, precisei pedir explicações ao Sonnet, mas o segredo sujo que Anthropic e OpenAI não vão dizer é que, se você sabe programar, os modelos honestamente já são bons o suficiente
      Pela minha experiência com o MiMo e pelas avaliações de outras pessoas sobre o GLM 5.1, acho que agora entramos numa competição de hardware
      Para quem sabe programar e quer ampliar com IA o que já conhece, os modelos chineses viraram substitutos de 100% do Claude
      Agora a questão vai ser qual provedor oferece a inferência mais rápida
      O MiMo-v2.5.0-Pro-Ultraspeed gera bons resultados rápido e também queima dinheiro rápido
    • Esses modelos são open-weight, mas no momento a maioria dos modelos flagship só é acessível na prática por meio de provedores terceiros de modelos
      A principal exceção são modelos na faixa de 30B parâmetros, que ainda podem rodar em GPUs de consumo
      Só que as GPUs de consumo também ficaram cada vez mais caras nos últimos anos, então ficou difícil justificar
    • Eu continuo tentando migrar para modelos chineses, mas no fim acabo pedindo ao Claude para corrigir a saída deles. Tanto em funcionalidade quanto em estilo, e no fim sempre volto
      Também continuo tentando com o GPT, e ele é bastante sólido. É muito rápido e excelente para depuração. Mas o código muitas vezes é esperto demais e dá dor de cabeça
      Talvez dê para corrigir isso com prompt. Ajudou um pouco com os modelos chineses. Basta dizer para fazer de forma elegante, como no velho estilo do image AI: “+good -bad”
      Por enquanto, ainda é preciso que humanos consigam entender o código, e o único que atende consistentemente a esse requisito é o Claude
      Mesmo assim, espero que algum laboratório chinês encontre um molho secreto especial algum dia
      Para pequenas correções, o DeepSeek Flash é muito bom. É como ter uma IA praticamente ilimitada plugada ali na hora, o que é incrível
    • Desde que o dwarf star saiu, venho usando o DeepSeek v4 flash como modelo principal para quase todo tipo de trabalho
      Rodo em um MacBook Pro M4 Max com 128GB de memória
      Normalmente executo como servidor e, na máquina de programação, acesso via Tailscale usando o agente de código Pi
      É um salto enorme em relação a quando eu usava modelos Qwen, mas não tem capacidade de visão, então ainda rodo aqueles modelos quando preciso de visão
      Antes eu usava o GLM 4.7 flash como principal para programação, mas migrei completamente para DeepSeek em tudo que não envolve visão

  • Fico curioso se alguém já tentou remover os elementos do PCC de modelos open-weight chineses. Não estou sendo sarcástico; estou perguntando se alguém fez uma revisão minuciosa com técnicas como inspeção de resistência dos pesos ou ativação de conceitos
    Por exemplo, se o PCC realmente tentou embutir comportamentos dependentes de contexto, daria para observar como o modelo reage a entradas capazes de induzir comportamento enganoso ou malicioso
    Não sei se já foi realmente comprovada alguma suspeita, como a de gerar código vulnerável quando usado em aplicações do governo dos EUA
    Em uma época de forte competição geopolítica, esse tipo de pergunta não é irracional. É uma pergunta que vale independentemente do país em que se viva

    • Vale a pena dar uma olhada no TNG do Hugging Face
      É uma empresa de consultoria alemã, e vi uma apresentação sobre eles ajustando modelos DeepSeek e removendo vieses. Achei bem interessante
      https://www.tngtech.com/en/about-us/news/release-of-deepseek...
      O que deve preocupar não é só o código, mas também outras coisas, como mensagens latentes
    • Parece o tipo de tarefa para a qual uma ferramenta como heretic pode ser útil
      https://github.com/p-e-w/heretic
    • LLMs feitos por empresas também podem ter viés corporativo. Nada é seguro