Ollama v0.40.12 mira a velocidade de prompts e os detalhes de imagens pequenas

Ollama publicou o candidato a lançamento Ollama v0.40.12 com quatro mudanças voltadas ao desempenho de modelos locais, ao tratamento de imagens e às dependências de software subjacentes. A distinção importa: suas melhorias no processamento de prompts e na geração vêm de alterações separadas, com limites diferentes.

A história central é a distância entre oferecer suporte a um modelo e executá-lo bem. Um modelo pode carregar com sucesso enquanto processa documentos de forma ineficiente ou perde detalhes úteis de imagens. Este lançamento aborda exemplos específicos dessa lacuna, em vez de anunciar uma nova família de modelos.

A comparação também vai além do próprio Ollama. MLX, o framework de arrays para aprendizado de máquina da Apple, oferece um caminho de desenvolvimento mais direto para pesquisadores que trabalham com suas operações subjacentes. O papel do Ollama é integrar esses recursos a um runtime de modelos, o software que executa modelos. Para desenvolvedores de aplicações, essa integração determina quais melhorias upstream realmente chegam às suas cargas de trabalho.

O que o Ollama v0.40.12 realmente muda

Esta é uma atualização direcionada do runtime, e o artefato publicado continua sendo um candidato a lançamento.

O candidato a lançamento usa a tag v0.40.12-rc0, embora seu título de exibição seja v0.40.12. O GitHub o marca como uma prévia e o data de 27 de outubro de 2026. Sua comparação parte de v0.40.11.

Essa diferença de nomenclatura merece atenção porque um título de exibição, por si só, não comprova que uma versão estável foi lançada. Leitores que avaliam uma atualização devem distinguir o candidato publicado de qualquer artefato estável posterior. As conclusões sobre esta compilação devem manter sua tag completa.

As mudanças listadas abrangem o tratamento de imagens no Gemma 4 compacto, atualizações de dependências do MLX, suporte ao DFlash2 e uma atualização de dependência do llama.cpp. As quatro entradas atribuem crédito ao colaborador dhiltgen. Em conjunto, elas descrevem manutenção em vários caminhos de execução, e não um único recurso de aceleração universal.

Esse escopo torna o lançamento relevante para grupos diferentes por razões distintas. Desenvolvedores que usam modelos de imagem afetados enfrentam uma questão de correção. Desenvolvedores que aguardam o processamento de prompts enfrentam uma questão de responsividade. Desenvolvedores que testam a aceleração de geração compatível enfrentam outra questão de desempenho.

Essas questões devem permanecer separadas ao interpretar o anúncio. Processar documentos mais rapidamente não significa automaticamente gerar respostas mais rápido. Preservar detalhes de imagem não comprova maior precisão em todas as tarefas visuais. Atualizar uma dependência não especifica o benefício para todos os dispositivos compatíveis.

Portanto, o enquadramento útil é específico para cada carga de trabalho. Qual operação mudou, qual modelo a utiliza e que parte de uma aplicação depende dessa operação? Essas perguntas produzem uma leitura mais acionável do que tratar cada entrada do changelog como evidência de uma IA local amplamente mais rápida.

Para um assistente de documentos, a melhoria mais relevante pode ocorrer antes de qualquer resposta aparecer. Para um assistente de capturas de tela, ela pode estar relacionada às informações preservadas na entrada. Para uma aplicação que gera respostas mais longas, o caminho de geração pode merecer uma análise mais cuidadosa.

Estes são exemplos analíticos, não implantações de clientes relatadas. Eles ilustram por que o mesmo lançamento pode importar de maneira diferente entre aplicações que usam uma interface idêntica. O produto visível pode permanecer familiar enquanto o trabalho executado por baixo muda.

A atualização também pressiona os mantenedores de aplicações a revisitar suposições antigas. Uma comparação anterior pode refletir um caminho de execução mais antigo, em vez de uma limitação duradoura do modelo. Por outro lado, um novo benchmark não deve apagar evidências de uma carga de trabalho em produção sem outra comparação.

Esse é o significado prático de uma atualização de manutenção como esta. Ela cria razões específicas para reavaliar o comportamento existente, enquanto deixa sem resposta alegações mais amplas sobre qualidade do modelo e adequação de implantação.

Imagens pequenas expõem a lacuna entre carregar e enxergar

A mudança nas imagens aborda a perda de informações antes de o modelo produzir uma resposta.

A correção compacta de visão diz respeito às torres compactas de visão do Gemma 4, os componentes que convertem imagens em entradas para o modelo. Segundo o pull request, o dimensionamento dinâmico podia arredondar a menor grade de imagem para baixo de seu orçamento pretendido de 70 tokens.

Aqui, tokens são as unidades usadas para representar informações de imagem no processamento pelo modelo. A alteração arredonda essa grade para cima para a torre compacta, com um limite no próximo orçamento compatível. O mantenedor afirma que os orçamentos explícitos e o dimensionamento existente para torres maiores e unificadas permanecem inalterados.

Trata-se de uma correção restrita, com uma implicação útil. Quando uma entrada perde detalhes durante a preparação, o raciocínio posterior não consegue recuperar de forma confiável as informações ausentes. Um modelo capaz ainda depende do que o runtime transmite a ele.

Considere uma aplicação que responde a perguntas sobre uma pequena captura de tela contendo um rótulo de status. Se a preparação remove detalhes relevantes, mudar a formulação da pergunta talvez não resolva o problema subjacente. A aplicação precisa que a evidência visual sobreviva tempo suficiente para ser interpretada.

Esse cenário explica por que o tratamento de imagens faz parte de uma discussão sobre desempenho. Os usuários avaliam a tarefa concluída, inclusive se o sistema lê corretamente a entrada. Uma resposta que chega rápido, mas ignora o rótulo relevante, cria trabalho adicional.

No entanto, a correção não deve se transformar na alegação de que modelos compactos agora lidam com todas as imagens pequenas com precisão. A fonte identifica um comportamento de dimensionamento e uma correção limitada. Ela não estabelece um resultado geral para capturas de tela, documentos digitalizados, diagramas ou fotografias.

As dimensões da imagem também fornecem uma descrição incompleta da dificuldade. Uma imagem pequena com um símbolo destacado apresenta um desafio diferente de outra com texto denso. Uma avaliação deve refletir as informações que uma aplicação real espera extrair.

A comparação mais clara preservaria a imagem original e a pergunta entre as compilações. Redimensionar a imagem de forma diferente durante uma avaliação introduziria outra explicação para qualquer resposta alterada. O objetivo é isolar o comportamento do runtime em análise.

Para mantenedores, isso muda a forma como falhas devem ser investigadas. Uma resposta visual incorreta não se origina necessariamente das capacidades aprendidas pelo modelo. A preparação da entrada é outra camada plausível, e este patch oferece um exemplo concreto.

Também muda a interpretação de resultados negativos anteriores. Se uma configuração afetada descartava informações úteis, um teste mais antigo pode subestimar o que essa configuração consegue oferecer após a correção. Essa possibilidade justifica novos testes, não reescrever resultados anteriores como inválidos.

A lição mais ampla diz respeito aos limites das comparações de modelos. O nome de um modelo, por si só, não descreve o sistema completo em avaliação. A preparação de imagens, o software de execução e o comportamento da aplicação ajudam a determinar a resposta que chega ao usuário.

O desempenho do Ollama MLX melhora antes de a resposta começar

A mudança na velocidade de prompts acelera a leitura da solicitação, enquanto o mantenedor relata explicitamente que a velocidade de decodificação permanece inalterada.

A atualização do processamento de prompts atualiza o MLX e o MLX-C, sua interface em linguagem C. Ela usa atenção nativa de janela deslizante, que limita as operações de atenção relevantes a uma janela móvel das entradas do modelo.

O mantenedor relata melhorias de prefill em um Apple M5 Max. Prefill é a fase que processa a entrada antes de gerar uma nova saída. Com um prompt de 2.048 tokens, a taxa de transferência relatada aumenta 9,2% para Gemma, 14,5% para Flint e 24,1% para Laguna.

Com um prompt de 6.144 tokens, os ganhos relatados correspondentes são 7,5%, 14,3% e 27,0%. Essas são medições do mantenedor para configurações de modelo especificadas. O pull request afirma que a velocidade de decode, a taxa de geração de saída, permanece inalterada.

Essa ressalva define o escopo da alegação de desempenho do Ollama MLX. Um usuário que espera a leitura de um documento longo enfrenta um gargalo diferente daquele que espera uma resposta longa. Melhorar o primeiro não comprova melhoria no segundo.

Isso é especialmente relevante quando uma solicitação inclui material de apoio substancial e pede uma resposta breve. Nessa carga de trabalho hipotética, processar a entrada pode representar uma parte significativa da experiência. Uma preparação mais rápida pode importar mesmo quando a saída subsequente chega na mesma velocidade.

A situação inversa exige outra interpretação. Uma aplicação com uma solicitação curta e uma extensa saída gerada pode gastar relativamente pouco tempo no processamento de prompts. Sua experiência geral não deve ser prevista apenas pela taxa de transferência de prefill.

As porcentagens também descrevem taxa de transferência, e não uma redução universal no tempo de espera. A latência de ponta a ponta, o tempo decorrido para a solicitação completa, inclui mais do que a fase de processamento medida. Carregamento, sobrecarga da aplicação e outros trabalhos complicam qualquer tradução direta.

Essa distinção evita um erro comum de reportagem: apresentar uma melhoria em um componente como uma melhoria equivalente na tarefa concluída. Um benchmark pode descrever com precisão o componente, deixando em aberto o resultado da aplicação.

O lançamento oferece aos desenvolvedores uma razão mais específica para investigar cargas de trabalho com entradas longas. Ele não exige que concluam que a aplicação ficou mais rápida antes de medi-la. São padrões de evidência diferentes.

Para equipes que montam contexto documental, as implicações também se estendem ao desenho de avaliações. Entradas em cache, que reutilizam trabalho previamente calculado, devem ser distinguidas de entradas novas. Caso contrário, solicitações repetidas podem obscurecer qual trabalho de processamento a atualização afeta.

Uma comparação de aplicações confiável deve, portanto, descrever o que o usuário enviou e o que o sistema reutilizou. Sem essa distinção, uma diferença aparentemente pequena pode ocultar uma melhoria, ou uma diferença aparentemente grande pode ter outra causa.

O desempenho do Ollama MLX é mais útil como uma alegação de engenharia precisa. A fase afetada, a configuração do modelo, o hardware e o comprimento da entrada dão aos leitores algo a testar. Remover esses limites tornaria a alegação mais ampla, mas menos informativa.

O suporte ao Ollama DFlash2 mira um gargalo diferente

DFlash2 diz respeito à geração de respostas, portanto seus resultados devem permanecer separados das melhorias no processamento de prompts.

A implementação do DFlash2 adiciona uma abordagem de geração especulativa, em que a saída proposta é verificada pelo modelo-alvo. O mantenedor descreve um seletor de candidatos que condiciona escolhas sucessivas às seleções anteriores.

Segundo as notas de implementação, uma sessão elabora sete tokens por rodada e os verifica por meio do mecanismo de reversão existente. O colaborador afirma que a verificação preserva a distribuição de saída do modelo-alvo. Trata-se de uma alegação de implementação, e não de uma validação independente apresentada aqui.

O pull request compara o DFlash2 a uma cabeça integrada de previsão de múltiplos tokens, um mecanismo que propõe vários tokens futuros. Para qwen3.8:27b, usando a configuração de precisão reduzida listada, o mantenedor relata ganhos de geração em sistemas M5 Max, M5 Pro e M2 Ultra.

No M5 Max, a taxa de geração reportada sobe de 57,0 para 71,0 tokens por segundo com o prompt mais curto testado. A comparação utilizou a mesma build, em vez de medir a versão anterior em relação a esta candidata.

Essa distinção final é importante. Esses resultados comparam métodos de geração dentro de uma build. Eles não devem ser reportados como um ganho de atualização medido para todos os usuários que migram da versão anterior.

Portanto, o suporte ao DFlash2 no Ollama adiciona mais um caminho de avaliação, em vez de oferecer uma promessa geral de velocidade. Uma configuração compatível cria uma oportunidade para comparar comportamentos. Ela não informa a todos os aplicativos qual método de geração entregará o melhor resultado.

A troca envolvida na geração especulativa é simples. As propostas ajudam quando um número suficiente delas é útil para justificar o trabalho de produzi-las e verificá-las. Avaliar apenas a etapa de proposta deixaria de fora o custo da verificação.

Para um desenvolvedor de aplicativos, a saída concluída importa mais do que a quantidade de tokens candidatos propostos internamente. Um método que elabora rascunhos de forma agressiva ainda precisa produzir uma saída aceita com eficiência. O resultado relevante é uma geração útil nas condições reais do aplicativo.

O comportamento da saída merece análise ao lado da velocidade. Equipes que usam respostas estruturadas devem verificar se o aplicativo continua recebendo o formato esperado. Equipes que avaliam respostas factuais devem preservar suas verificações de correção existentes ao introduzir outro caminho de execução.

Estas são prioridades de avaliação, não evidências de que essa implementação cause problemas de formato ou qualidade. A fonte descreve salvaguardas destinadas a preservar o comportamento. Testes independentes no aplicativo são a forma de uma equipe determinar se seus próprios requisitos continuam sendo atendidos.

Há também uma distinção de reporte entre suporte e comportamento padrão. Uma nota de lançamento que anuncia uma capacidade não estabelece, por si só, que todo modelo instalado a utiliza. Os leitores precisam identificar a configuração real por trás de qualquer resultado observado.

Esse ponto conecta esse recurso ao restante da versão. Melhorias no runtime se tornam úteis por meio de uma cadeia de decisões de compatibilidade e integração. O usuário vê uma resposta, mas o modelo escolhido e o método de execução determinam quais mudanças contribuíram.

Para cargas de trabalho com respostas longas, o mecanismo de geração merece atenção por seus próprios méritos. Combinar seus ganhos reportados com percentuais não relacionados de processamento de prompt criaria uma estimativa sem suporte. Cada melhoria precisa de uma carga de trabalho correspondente antes de poder sustentar uma conclusão em nível de aplicativo.

A Atualização de Dependência Mantém as Comparações Fundamentadas

Uma dependência mais recente identifica uma base alterada, mas não estabelece um resultado universal de desempenho.

A atualização do llama.cpp move a dependência do Ollama da build b11845 para b11901. O llama.cpp é um mecanismo de inferência, um software que executa modelos treinados para produzir saídas. O pull request foi mesclado em 26 de outubro.

O pull request visível vincula a comparação upstream sem apresentar um benchmark correspondente no aplicativo. Isso sustenta o reporte da mudança de versão. Não sustenta atribuir uma melhoria específica de velocidade ou qualidade a toda carga de trabalho que use esse caminho.

Isso importa porque atualizações de dependências podem ser fáceis de superinterpretar. Um número de build mais recente descreve a linhagem do software. Ele não identifica quais operações foram alteradas para um aplicativo específico nem estabelece se seu gargalo existente mudou.

A comparação com o uso direto do framework ajuda a esclarecer a posição do Ollama. O framework MLX expõe diretamente aos desenvolvedores interfaces de programação e operações de aprendizado de máquina. O Ollama integra capacidades subjacentes a um ambiente de execução de modelos.

Essas abordagens atendem a necessidades sobrepostas com diferentes níveis de responsabilidade. Um pesquisador que trabalha diretamente com operações do framework pode investigar de perto as escolhas de implementação. Uma equipe de aplicativos que usa um runtime integrado depende dos caminhos de execução compatíveis do runtime.

Nenhuma das abordagens vence toda comparação por definição. O acesso direto oferece controle, enquanto a integração pode reduzir o trabalho necessário para operar um modelo compatível. Uma avaliação justa deve perguntar quais responsabilidades a equipe do aplicativo deseja assumir.

A candidata também ilustra por que resultados upstream e downstream devem permanecer distintos. Uma capacidade do framework precisa de uma integração apropriada antes que um aplicativo se beneficie dela. Por outro lado, uma melhoria integrada não deve ser atribuída a um novo modelo quando o próprio modelo não mudou.

Essa distinção afeta alegações competitivas. Um resultado de um modelo, dispositivo e caminho de execução não estabelece que o Ollama supera runtimes alternativos de forma geral. Ele estabelece um resultado para o sistema testado, incluindo os limites desse sistema.

As evidências disponíveis vêm principalmente dos mantenedores do projeto. Elas sustentam a existência das mudanças e suas medições reportadas. Não fornecem um consenso independente sobre adoção em produção, confiabilidade ou superioridade entre opções de implantação.

Não é necessário fabricar uma controvérsia pública para tornar essas evidências significativas. A questão não resolvida é prática: se as mudanças oferecem ganhos úteis em aplicativos fora das medições dos mantenedores. Essa pergunta é suficientemente relevante sem apoiadores ou críticos inventados.

Para compradores corporativos, a pressão apropriada recai sobre a qualidade das evidências. Uma demonstração ampla de IA local é menos útil do que resultados que correspondam à tarefa pretendida. Decisões de aquisição exigem que modelo, hardware, carga de trabalho e requisitos operacionais estejam alinhados.

Os desenvolvedores também se beneficiam ao manter o contexto por trás de suas comparações. Equipes que documentam avaliações podem usar uma base de conhecimento pesquisável para preservar descobertas junto a configurações e exemplos. O registro útil inclui falhas e limitações, não apenas a execução mais rápida.

Três Sinais Mostrarão o Quanto Esta Candidata Importa

As próximas evidências significativas são a progressão da versão, a cronometragem reproduzível e o comportamento de tarefa verificado, nessa ordem.

Primeiro, acompanhe o que acontece com a candidata publicada. Um artefato estável, uma candidata subsequente ou uma versão corretiva esclareceriam o software disponível para adoção mais ampla. Esses eventos não estabeleceriam automaticamente a qualidade do aplicativo, mas resolveriam parte da questão sobre o status da versão.

A progressão mais informativa manteria conexões claras entre tags e mudanças. Isso permitiria aos desenvolvedores identificar se um resultado posterior diz respeito a esta candidata ou a uma build modificada. Sem essa continuidade, discussões podem combinar descobertas de softwares diferentes sob o mesmo nome de versão abreviado.

Uma correção posterior não anularia automaticamente o trabalho descrito aqui. Sua importância dependeria do comportamento afetado. Os leitores devem buscar uma relação concreta entre qualquer problema reportado, seu escopo e a configuração que utilizam.

Segundo, acompanhe medições reproduzíveis no aplicativo que separem o processamento de entrada da geração de saída. Isso testaria se as melhorias reportadas em componentes se mantêm fora das condições originais de medição. Os resultados devem identificar a configuração real do modelo e o hardware.

Evidências de uma carga de trabalho correspondente fortaleceriam o argumento para adotar a mudança relevante. Uma comparação que mostrasse pouco benefício de ponta a ponta restringiria esse argumento sem necessariamente contradizer o benchmark do componente. O aplicativo pode simplesmente estar gastando seu tempo em outra etapa.

Relatórios de tempo se tornam mais informativos quando descrevem entradas novas e reutilizadas. Eles também devem distinguir um modelo que já está carregado de uma solicitação que precisa carregá-lo. Essas condições respondem a perguntas diferentes sobre o uso cotidiano.

Terceiro, acompanhe verificações no nível da tarefa sobre o tratamento de imagens e a geração acelerada. A correção de imagens precisa de exemplos que testem a retenção de informações visuais. O caminho de geração precisa de verificações de saída ao lado das medições de tempo, especialmente quando os aplicativos dependem de uma estrutura previsível.

Relatórios úteis incluiriam a entrada original, o comportamento esperado e o resultado de cada configuração comparada. Isso permitiria que outros examinassem a alegação, em vez de depender de uma afirmação de que uma resposta parecia melhor.

Para tarefas de imagem, uma resposta correta em um exemplo fácil forneceria evidências limitadas sobre entradas difíceis. Para tarefas de geração, uma resposta rápida forneceria evidências limitadas sobre compatibilidade com o aplicativo. A força de qualquer resultado depende do que ele realmente testa.

Esses sinais devem ser interpretados em conjunto sem reduzi-los a uma única pontuação. A progressão da versão diz respeito ao artefato. A cronometragem diz respeito à execução. As verificações de tarefa dizem respeito a se o aplicativo conclui corretamente um trabalho útil.

Nos próximos meses, o acompanhamento mais valioso conectará essas camadas. Um resultado reproduzível vinculado a uma versão específica e a uma tarefa representativa fortaleceria o argumento prático. Generalizações sem suporte chamariam atenção sem resolver a questão da implantação.

Para leitores que avaliam o Ollama v0.40.12, comecem pela carga de trabalho que já importa para vocês. Preservem sua entrada, configuração do modelo e saída esperada antes de comparar builds. Registrem o tempo gasto processando a solicitação separadamente do tempo gasto gerando a resposta. Se imagens importam, mantenham os arquivos originais e inspecionem os detalhes de que seu aplicativo precisa. Se a geração acelerada importa, verifiquem as respostas concluídas junto com a velocidade. Mantenham a tag completa da candidata com suas descobertas para que comparações posteriores permaneçam interpretáveis. Depois, tomem a decisão de atualização com base em um resultado concreto: o caminho de execução alterado melhorou a tarefa que seus usuários realmente executam, nas condições que seu aplicativo realmente enfrenta?