O Google lançou hoje suporte nativo de drafters Multi-Token Prediction no LiteRT-LM, o framework de inferência de produção open-source em github.com/google-ai-edge/LiteRT-LM. O lançamento do Gemma 4 12B de ontem flagou os drafters MTP como a peça de redução de latência baked-in no modelo; o número concreto chegou esta manhã. O speedup de decodificação é 1,6x no Gemma 4 E2B e 2,2x no E4B, sem degradação de qualidade reclamada. End-to-end, o runtime LiteRT-LM é reportado a 1,8x a 3,7x mais rápido que llama.cpp, MLX, Cactus e ONNX em prefill mais decodificação para variantes Gemma 4. As APIs se expandem além das superfícies Kotlin e C++ existentes para adicionar Swift e JavaScript, o que coloca o runtime nos paths iOS, web e Node.js sem ports separados.
O mecanismo é speculative decoding via um drafter MTP leve co-treinado com o modelo Gemma 4 primário. O speculative decoding padrão tem existido no llama.cpp, vLLM e ecossistema MLX por dois anos, mas o bottleneck sempre tem sido o data interplay entre drafter e verifier: se o drafter roda em um hardware IP diferente do modelo primário, o round trip come o speedup. O claim de engineering específico do LiteRT-LM é enforcement de memory locality, o drafter MTP leve E o modelo primário executam no mesmo hardware IP (e.g., o GPU), o que remove o round trip cross-IP que limita as implementações especulativas naive. Essa é a parte que vale a pena pausar para builders considerando se o 2,2x é reproduzível em seu stack: depende de se seu framework de inferência respeita o constraint de locality ou não. Números dos benchmarks próprios do Google; a reprodução independente em cargas que igualam as suas é o próximo passo padrão antes de apostar sua infraestrutura no número.
Dois fios de ecossistema a trackear. Primeiro, MTP-as-acceleration é agora uma primitiva builder concreta em vez de uma curiosidade de pesquisa. O modelo ship com o drafter baked-in (variantes Gemma 4 mid-sized), e o framework de inferência respeita o contrato de locality, e o speedup é publicado com comparações aos frameworks que os builders realmente usam. Esse é o stack completo que você precisa para que uma feature de speculative decoding se torne defaults-on em vez de expert-only. Outras famílias de modelos com drafters MTP (o trabalho MTP da DeepSeek, a pesquisa especulativa da Meta e outros) agora têm um padrão de implementação de referência a seguir. Segundo, a coorte de comparação importa estrategicamente. LiteRT-LM se posiciona contra llama.cpp (o default open-source de inferência local), MLX (o default Apple Silicon), Cactus (o framework de inferência móvel) e ONNX (o padrão de serialização cross-platform). O Google está nomeando os incumbents e colocando números concretos ao lado, o que sinaliza que o LiteRT-LM está posicionado como um contender para o slot default-local-inference em vez de um protótipo de pesquisa.
Segunda-feira pela manhã, se você roda Gemma 4 localmente em llama.cpp, MLX ou ONNX hoje: pull LiteRT-LM e benchmark em sua carga real antes de decidir trocar. O 2,2x é o upper bound do Google; em hardware consumer o número real está mais frequentemente na faixa 1,7x a 2,2x, o que ainda é meaningful mas vale medir em seu comprimento de contexto e batch size. Se você ship Gemma 4 em apps iOS ou web, as novas APIs Swift e JavaScript mudam o que é factível nessas superfícies, trate como uma avaliação fresca em vez de se apoiar em conclusões de framework anteriores. Se você constrói infraestrutura de inferência para qualquer família de modelo MTP-equipped, o padrão de enforcement de locality é a lição de engineering que vale a pena levar para outros runtimes; drafter e verifier co-localizados no mesmo hardware IP é a parte que faz o speculative decoding rápido na prática em vez de só no papel. E como sempre com benchmarks vendor contra frameworks open, os números de comparação 1,8x a 3,7x são vendor-published; a reprodução independente pelas comunidades llama.cpp e MLX é a validação que importa.