RDNA3 · gfx1102 · construído e medido numa RX 7600

Vector Tensor Engine

Um motor de inferência de LLMs construído do zero para GPUs AMD no Windows.

Sem llama.cpp. Sem PyTorch. Sem ONNX. Só HIP, GGUF e muita medição.

0
decode single-seq
0
batch agregado
0
supera o llama.cpp (Granite)
0
Modelos de arquitetura de IA
// O que é

Todo byte, do arquivo à ALU, escrito à mão.

O VTE não embrulha nenhum runtime existente. Ele lê o arquivo GGUF sozinho, gera os kernels HIP C++ sozinho, os compila com hipcc em runtime, e conversa com o amdhip64.dll por uma ponte ctypes escrita à mão.

Parser GGUF próprio

Dequantização Q4_K / Q6_K / Q8_0 byte-a-byte, batendo com o layout de referência do llama.cpp — validada camada por camada contra NumPy.

Kernels HIP gerados

Templates .hip renderizados e compilados sob demanda, com cache por hash e rejeição de kernels que arriscam register spilling.

HIP Graphs

Todo o passo de decode capturado num único grafo e reproduzido, eliminando quase todo o overhead de dispatch do lado da CPU.

// Benchmark

Python que já supera um motor C++ com anos de otimização.

Mesmos arquivos GGUF em disco, mesmo prompt, temperature=0. O código que faz o dispatch aqui é Python puro dirigindo cada launch HIP por ctypes — e no Granite isso já entrega mais tok/s que o próprio llama.cpp; no Qwen2.5 é um empate técnico.

Qwen2.5 1.5B · Q4_K_M

97.4%
VTE
107.85 tok/s
Ollama
110.76 tok/s

Granite 4.1 3B · Q8_0

109.5% ↑
VTE
55.65 tok/s
Ollama
50.84 tok/s

Qwen3.5 2B · Q6_K, híbrido Gated DeltaNet

~85%
VTE
~66.5 tok/s
Ollama
78.56 tok/s

→ Três arquiteturas sem quase nada em comum entre si (RoPE, quantização, e no Qwen3.5 uma recorrência linear com estado persistente que nenhuma das outras duas tem) chegando a resultados competitivos — e num caso ultrapassando o llama.cpp — é evidência de que dispatch em Python é um problema de engenharia, não um imposto fixo da linguagem.

vte-ui — granite-4.1:3b-q8_0 LIVE
tok/s 0.0 ms/tok 0.0 VRAM 4.8 GB device RX 7600
// Pipeline

Do .gguf ao token, em quatro camadas.

01

Sanitize

Validação dupla do GGUF não confiável: magic, versão, bounds de cada tensor.

02

Compile

Plano de memória em VRAM + kernels HIP gerados e compilados com hipcc.

03

Capture

Decode inteiro capturado num HIP Graph estático, incluindo a LM Head.

04

Decode

Replay do grafo por token; sampler restrito ao top-k roda na CPU depois.

// Os quatro pacotes
vte/bridge

A única camada que toca o driver

Wrapper ctypes do amdhip64.dll: cada alocação rastreada, cada ponteiro checado, um KernelWatchdog anti-travamento e um limitador de duty-cycle que mantém o desktop responsivo durante gerações longas.

vte/compiler

GGUF → kernels

Parser, dequantizador, mapeadores de memória por arquitetura e o codegen que renderiza e compila os templates HIP.

vte/core

Orquestra a geração

Grafo IR, fusão de kernels, dois executores (eager + HIP Graph), o loop autoregressivo e o sampler vetorizado.

vte/ui

App desktop em Flet

Chat + dashboard de telemetria da GPU ao vivo (tok/s, ms/token, VRAM, ciclo de vida do modelo), troca de modelo em runtime e toggle de idioma pt/en — falando com o motor por um pipe local.

// O hardware

A GPU onde tudo foi construído

01 / 05 · RX 7600

RDNA3 · gfx1102 · 8 GB

A placa "gamer" onde tudo foi construído e medido. 32 Compute Units, 8 GB de GDDR6, dividida com o resto do desktop.

// A missão

Um motor pensado para o ecossistema AMD.

A maioria do software de inferência é ajustada para hardware de datacenter — um MI300X, uma RTX 4090. O VTE nasceu com o objetivo oposto: extrair desempenho real de uma placa de consumidor, uma RX 7600 com 32 CUs e 8 GB, dividida com o resto do desktop do usuário. Cada decisão de otimização veio de uma medição nesse hardware específico, não de suposição.

E, no fundo, foi um desafio pessoal: descobrir se dava para construir um motor de LLM inteiro do zero — parser, kernels, gerenciador de memória, UI — sobre o HIP no Windows, medir tudo com honestidade, e chegar perto de uma engine madura com anos de vantagem. No Granite, chegou a superá-la.

HIP·ROCm 6.4·RDNA3·gfx1102· GGUF·Q4_K·Q6_K·Q8_0· HIP Graphs·Split-K·Flash-Decoding·ctypes· Flet·Python·