llama.cpp ganha otimização Vulkan para DeepSeek-V4 e acelera inferência em GPUs AMD

O llama.cpp, o framework open-source de inferência local de LLMs mais usado do mundo, ganhou uma otimização importante para quem roda o DeepSeek-V4 em GPUs AMD por meio do backend Vulkan. A versão b10844 adiciona as operações fundidas de “hiper-conexão” do modelo (chamadas DSV4_HC_COMB, DSV4_HC_PRE e DSV4_HC_POST), eliminando um gargalo que consumia cerca de 32% do tempo de decodificação em processadores integrados AMD Strix Halo.

O que mudou tecnicamente

O DeepSeek-V4 usa um mecanismo de hiper-conexão (hyper-connection) para coordenar suas múltiplas streams de especialistas — uma técnica baseada no algoritmo Sinkhorn, que redistribui tokens entre os especialistas durante a decodificação. Nos backends CUDA (NVIDIA) e Metal (Apple), essa etapa já rodava com operações fundidas, otimizadas para executar em registradores. O Vulkan — usado principalmente por GPUs AMD e Intel, e pelo crescente mercado de mini-PCs e notebooks com gráficos integrados — era o último grande backend a rodar a cadeia primitiva não-fundida.

O custo disso era concreto. Em um chip Strix Halo (gfx1151), a cadeia de combinação Sinkhorn não-fundida sozinha respondia por cerca de 32% do tempo de decodificação, espalhada em aproximadamente 16 mil dispatches por token. Com a mudança, a operação dsv4_hc_comb passa a executar as 20 iterações do Sinkhorn inteiramente em registradores, e um único dispatch substitui cerca de 137 execuções de nós estritamente ordenadas.

Por que isso importa agora

A inferência local de modelos abertos deixou de ser nicho. Com os preços crescentes de APIs de nuvem e a chegada de modelos abertos fortes como a família DeepSeek-V4, cada vez mais profissionais rodam LLMs em máquinas próprias — e, no Brasil, o hardware AMD costuma ter melhor custo-benefício por real investido do que as alternativas de alto custo. O backend Vulkan é justamente a porta de entrada para quem não tem uma GPU dedicada: ele permite usar gráficos integrados, incluindo os APUs Strix Halo que equipam notebooks e mini-PCs intermediários.

O ganho não é apenas de velocidade. Menos dispatches por token também significam menos consumo de energia e menos latência na geração de texto, o que melhora a experiência em cenários como assistentes locais, sumarização de documentos e agentes que rodam de forma contínua. A otimização alinha o Vulkan aos outros backends e fecha uma lacuna de desempenho que penalizava especificamente quem usa hardware AMD.

O que ainda falta

A mudança é um avanço de engenharia, não uma mudança de arquitetura do modelo. O ganho se aplica ao backend Vulkan em execução do DeepSeek-V4 (com destaque para a variante Flash) e não altera o comportamento dos backends CUDA ou Metal, que já eram otimizados. Além disso, as melhorias se concentram na fase de decodificação — a etapa de pré-processamento (prefill) segue com suas características próprias de desempenho.

Como em toda atualização do llama.cpp, o ideal é testar a versão b10844 no seu hardware e comparar a velocidade de geração real, já que o impacto varia conforme o modelo, o tamanho do contexto e o driver Vulkan instalado.