Com a crescente demanda por modelos de linguagem de grande escala (LLMs), a eficiência da inferência se tornou um gargalo crítico, especialmente em cenários onde latência, custo e escalabilidade são fatores essenciais. O LMCache surge como uma solução inovadora nesse cenário, revolucionando a forma como os tokens são pré-processados (prefill) e decodificados durante a inferência — e fazendo isso com integração transparente a motores como o vLLM.

Por que a infraestrutura atual está ficando para trás?

O tempo de prefill (processamento inicial de tokens no contexto) e o custo de decodificação (geração de novos tokens) são duas das maiores causas de latência em LLMs. Mesmo com arquiteturas otimizadas como FlashAttention e KV-caching em GPUs modernas, o uso repetido de contextos semelhantes (com prompts quase idênticos, como ocorre em assistentes e RAGs) ainda gera redundância computacional.

É aí que o LMCache entra como game-changer.

LMCache: Cache para Tokens de LLM

O que é?

O LMCache é uma espécie sistema de cache semântico especializado para modelos de linguagem. Ele permite que tokens de saída (logits) previamente inferidos em contextos semelhantes sejam reutilizados, eliminando a necessidade de computação redundante.

Imagine que você tem um assistente que responde a milhares de prompts que começam com “Você é um assistente útil…”. Em vez de recalcular sempre os mesmos embeddings e estados do modelo, o LMCache detecta similaridade e recupera partes da resposta direto do cache.

Principais Benefícios:

• Até 4× mais throughput em workloads típicos de assistentes.
• Menor latência de resposta, especialmente na primeira tokenização (prefill).
• Redução de custo em GPU/HW por inferência.
• Totalmente compatível com vLLM (integração oficial e em produção).
• Cache persistente com Redis ou DuckDB (ideal para escala).

Inovação Técnica: “SpecDecode” e “ShortestPrefillFirst”

1. SpecDecode – Execução Especulativa + Cache

O SpecDecode introduz a combinação de decodificação especulativa (speculative decoding) com o LMCache. A ideia é gerar múltiplos tokens candidatos rapidamente usando um modelo pequeno e validar a sequência com o modelo maior. Ao combinar isso com o LMCache, temos:

• Inferência ultrarrápida sem comprometer a qualidade
• Redução do número de chamadas ao modelo principal
• Reutilização massiva de logits decodificados

Essa técnica é particularmente eficiente para tarefas de completions longos, como geração de documentos ou agentes autônomos.

2. ShortestPrefillFirst – Ordenação Inteligente de Requisições

No artigo Shortest Prefill First, os autores propõem reordenar os pedidos de inferência por comprimento de contexto. Essa estratégia melhora a utilização do cache porque permite que o LMCache maximize o reuso de prefixos mais curtos e mais comuns antes de processar prompts longos e únicos.

Resultado? Melhor paralelismo e menos fragmentação no uso da KV-cache da GPU.

🔧 Integração com vLLM: Zero Modificações em Modelos

Se você já usa vLLM, integrar com o LMCache é simples

# 1. launch vLLM
vllm serve Qwen/Qwen2-VL-2B-Instruct \
  --kv-transfer-config '{"kv_connector":"LMCacheConnectorV1","kv_role":"kv_both"}' \
  --no-enable-prefix-caching --enforce-eager

# 2. POST an image prompt twice – watch the logs
curl -X POST http://localhost:8000/v1/chat/completions -H "Content-Type: application/json" \
  -d @first_image.json
curl -X POST http://localhost:8000/v1/chat/completions -H "Content-Type: application/json" \
  -d @first_image.json   # instant response, log shows ~16k KV hits

🏁 Conclusão: Caminho Inevitável para LLMs em Produção

O LMCache, aliado ao vLLM, marca uma virada de paradigma na inferência de LLMs. Ao aplicar técnicas de cache, ordenação inteligente e decodificação especulativa, é possível alcançar níveis inéditos de performance e economia.

Se sua empresa ou projeto depende de LLMs com alto volume ou precisa escalar assistentes com contexto repetitivo (como RAGs, copilots ou workflows empresariais), implementar LMCache é uma decisão estratégica.

🔗 Referências:

• Post oficial no Medium
• Repositório GitHub: LMCache
• SpecDecode blog
• ShortestPrefillFirst blog

O cenário da inteligência artificial está passando por uma transformação acelerada — e a China vem ganhando destaque ao combinar inovação, eficiência e acessibilidade. Um dos marcos mais recentes dessa evolução é o lançamento do modelo GLM-4.5, desenvolvido pela startup chinesa Z.ai (anteriormente Zhipu), que promete oferecer desempenho de ponta com menor custo computacional e financeiro.

Uma Nova Era para IAs de Código Aberto

O GLM-4.5 chega como uma resposta direta à crescente demanda por modelos abertos, acessíveis e eficientes, competindo com nomes de peso como DeepSeek e até mesmo OpenAI. Com 355 bilhões de parâmetros e arquitetura baseada em Mixture of Experts (MoE), o modelo une três pilares fundamentais: raciocínio complexo, geração de código e operação agentiva (capacidade de executar tarefas autônomas em múltiplas etapas).

O destaque? Ele opera com apenas oito chips Nvidia H20, uma alternativa desenvolvida especialmente para o mercado chinês, respeitando restrições de exportação dos EUA.

Comparativo do GLM-4.5 com diversos modelos da OpenAI, Anthropic, Google DeepMind, xAI, Alibaba, Moonshot e DeepSeek em 12 benchmarks que abrangem IA agentiva (3), raciocínio (7) e programação (2). No geral, o GLM-4.5 ficou em 3º lugar, e o GLM-4.5 Air em 6º (Imagem: Z.ai)

Oportunidade Estratégica: Chips H20 e a Corrida Computacional

O sucesso do DeepSeek em escalar IA com chips H20 despertou o interesse de gigantes como Tencent, Alibaba e ByteDance, que agora estão aumentando seus pedidos pelos mesmos chips. O GLM-4.5, sendo ainda mais econômico e eficiente, impulsionou essa tendência. Mesmo com as exportações de H20 temporariamente suspensas, a Nvidia já anunciou que pretende retomar os envios em breve — sinal de que a disputa por poder computacional continua aquecida.

Por que o GLM-4.5 se Destaca?

• Aberto e gratuito para desenvolvedores
• Custo de uso extremamente competitivo:
  • Entrada: $0,11 por milhão de tokens (vs. $0,14 da DeepSeek)
  • Saída: $0,28 por milhão de tokens (vs. $2,19 da DeepSeek)
• Alto desempenho em benchmarks de raciocínio, como MMLU Pro e AIME24
• Alta eficiência em tarefas agenticas, com 90,6% de sucesso em chamadas de ferramentas
• Suporte nativo a raciocínio estruturado, codificação full-stack e navegação web

Z.ai terá custo inferior ao da DeepSeek, já considerada uma IA mais barata (Imagem: Mojahid Mottakin / Shutterstock.com)

Capacidade Agentiva: Um Novo Paradigma

O GLM-4.5 é construído sobre o conceito de IA agentiva, que permite ao modelo dividir automaticamente tarefas complexas em subtarefas, otimizando a precisão e velocidade. Isso o torna ideal para casos como:

• Geração de aplicações web completas (frontend, backend e banco de dados)
• Criação de materiais de apresentação, como slides, pôsteres e relatórios
• Automação de pesquisas e coleta de dados em múltiplas etapas

Em benchmarks como o BrowseComp, ele respondeu corretamente a 26,4% das perguntas — à frente de Claude-4-Opus, por exemplo.

Crescimento Chinês e Apoio de Gigantes

A Z.ai não é uma novata. Fundada em 2019, já captou mais de US$ 1,5 bilhão em investimentos de pesos-pesados como Alibaba, Tencent, Qiming Venture Partners e fundos estatais chineses. O modelo GLM-4.5 coloca a empresa no radar de gigantes ocidentais, a ponto de ter sido citada em alertas da própria OpenAI sobre o avanço da IA chinesa.

Outras startups chinesas também estão inovando: a Moonshot, por exemplo, lançou o Kimi K2 — voltado para tarefas de programação, com desempenho acima do Claude e ChatGPT em benchmarks específicos.

Conclusão

O lançamento do GLM-4.5 representa mais do que um avanço técnico — é uma jogada estratégica da China para democratizar o acesso à IA de alto desempenho. Com custos reduzidos, arquitetura avançada e capacidades agentivas, o modelo abre novas possibilidades para startups, desenvolvedores independentes e grandes corporações que buscam soluções potentes, abertas e eficientes.

A corrida global da IA está longe de terminar — mas a China está claramente acelerando.

Kimi K2 é o mais novo modelo de linguagem de código aberto da Moonshot AI, projetado para ir além de um chatbot tradicional. Ele não apenas responde perguntas, mas também pode agir de forma autônoma, utilizando ferramentas, executando código e coordenando tarefas complexas. Nesta análise rápida, vamos destacar as principais capacidades e diferenciais do Kimi K2, seus avanços técnicos em relação às versões anteriores da série Kimi, e as potenciais aplicações práticas desse modelo de inteligência artificial de última geração.

Kimi K2: o “faça-tudo” da IA em linguagem simples

Imagine um assistente virtual que não só conversa, mas abre planilhas, roda códigos, gera relatórios e conclui tarefas sozinho. Esta é a especativa é o Kimi K2, o novo modelo de inteligência artificial (IA) aberto da Moonshot AI. A seguir, você vai entender por que tanta gente está falando dele — sem precisar ser engenheira(o) de software.

1. O que é o Kimi K2?

O Kimi K2 promete ser um “supercérebro” digital de código aberto. Ele foi treinado com volumes gigantescos de texto e, por isso, sabe responder perguntas sobre praticamente qualquer assunto. A grande novidade é que ele foi pensado para agir, não apenas para falar. Por exemplo, pode receber uma ordem (“analise estes dados de vendas”), abrir a ferramenta certa, fazer cálculos, criar gráficos e entregar o resultado — tudo sem intervenção humana.

2. Por que ele é diferente dos chatbots tradicionais?

• Time de especialistas sob o capô – Em vez de um único modelo monolítico, o Kimi K2 funciona como uma equipe de mini-especialistas. Cada um entra em ação quando seu conhecimento é mais útil. Assim ele mantém alta qualidade sem desperdiçar energia.
• Leitura de “livros” inteiros de uma vez – Ele consegue analisar documentos muito longos (até 128 mil palavras em uma única passada). Pense em contratos extensos, códigos-fonte ou relatórios empresariais sem precisar fatiar tudo em pedaços menores.
• Treinamento para usar ferramentas – Durante o aprendizado, o modelo “jogou” em cenários simulados onde precisava escolher a ferramenta certa (por exemplo, Python ou planilhas) para resolver problemas. Esse treino faz com que ele seja naturalmente bom em automatizar fluxos de trabalho.

3. O que ele já provou que consegue fazer?

Nos testes independentes mais usados pela comunidade:

• Conhecimento geral: desempenho entre os melhores modelos abertos.
• Matemática e lógica: acertos de nível avançado.
• Programação: escreve e corrige código com alta taxa de sucesso.

Em demonstrações da própria Moonshot AI, o Kimi K2 recebeu um banco de dados salarial em branco e, sozinho, fez filtros, criou gráficos, rodou testes estatísticos e gerou um relatório HTML interativo — sem que alguém precisasse digitar um só comando.

4. Quanto custa e como testar?

A Moonshot AI publicou o modelo no repositório Hugging Face sob licença aberta, o que significa que qualquer pessoa pode baixar gratuitamente, treinar com seus próprios dados e até usar em projetos comerciais. Há também serviços online já oferecendo uma interface pronta, sem instalação. Para usar com o llama.cpp use o Pull Request #14654 or llama.cpp um fork especial.

5. Limitações e próximos passos

• Ainda não “enxerga” imagens ou vídeos, mas a Moonshot AI já sinalizou que a próxima versão deve ganhar visão multimodal.
• Como qualquer IA, está sujeita a erros de alucinações; é prudente revisar antes de confiar cegamente nos resultados.

Resumindo

O Kimi K2 marca um salto de geração na IA aberta: sai o “bot que conversa”, entra o agente que faz. Ele reúne poder de processamento, leitura de contextos gigantes e habilidade de usar ferramentas para entregar trabalho real — de graça e sem portas fechadas. Para curiosas(os) e profissionais, vale a pena acompanhar: ele pode ser o motor por trás de novos assistentes pessoais, automações de escritório e até aplicativos que ainda nem imaginamos.

Nos últimos anos, a convergência de três frentes de pesquisa — gaze estimation, detecção de esqueleto e análise facial — redefiniu a forma como monitoramos o comportamento do consumidor no ponto de venda. Ao combinar esses algoritmos em um fluxo único de processamento, conseguimos responder a duas perguntas cruciais para quem gerencia vitrines e gôndolas:

1. Onde exatamente as pessoas estão olhando?
2. Quem são essas pessoas em termos de perfil demográfico?

1. Detecção de esqueleto com OpenPose 📐

O OpenPose continua sendo referência quando precisamos rastrear pose corporal em tempo real. Ele identifica até 25 pontos-chave do corpo humano, fornecendo as coordenadas dos ombros, quadris, joelhos, pés e, principalmente, da cabeça. Ao mapear essas articulações é possível:

• Calcular a distância do shopper até a prateleira
• Estimar o ângulo da cabeça (fundamental para a etapa de gaze)
• Identificar o lado do corpo que está voltado para a gôndola

Esse contexto espacial evita falsos positivos típicos de câmeras instaladas em diagonal ou distâncias variáveis.

2. Gaze estimation 👀

Vários modelos open-source ( https://github.com/fkryan/gazelle ) evoluíram bastante em robustez a iluminação adversa. Uma vez conhecido o vetor de pose da cabeça (via OpenPose), o modelo de gaze refina a estimativa calculando a orientação das pupilas dentro da órbita ocular. A saída é um vetor 3D que, projetado no plano da câmera, aponta para um ponto na gôndola.

Agrupando esses pontos ao longo do tempo, geramos mapas de calor que revelam:

• Prateleiras com maior tempo médio de fixação
• Padrões de atenção ao lançar um novo layout ou preço promocional
• Focos de desvio do olhar quando há ruído visual (ex.: excesso de wobblers)

3. Análise facial para demografia 🧑🏾‍🤝‍🧑🏼

Modelos de classificação facial leves ou variantes com MobileNet — adicionam a camada demográfica sem comprometer o FPS do pipeline. Mesmo com baixa resolução (por exemplo, 120 × 120 px), os classificadores informam faixas etárias, gênero provável e grupos étnicos majoritários, tudo em conformidade com as salvaguardas de privacidade vigentes (GDPR/LGPD).

4. Da visão ao insight acionável 📊

Quando unificamos as três saídas (pose + gaze + demografia) em um data lake de tempo real, surge uma visão 360° do público-alvo:

Essas correlações orientam testes A/B de layout, campanhas de preço dinâmico e reposicionamento instantâneo de mercadoria — tudo baseado em evidência, não intuição.

5. Desafios éticos e operacionais ⚖️

• Privacidade : anonimização on-device (blur/embedding) antes de enviar dados a qualquer servidor.
• Viés algorítmico : treinar e validar modelos em dados representativos da população local.
• Latência : GPUs compactas (Jetson Orin, Intel ARC) ou aceleração OpenVINO/ONNX RT são essenciais para manter 30 FPS em múltiplas câmeras.

Conclusão

A sinergia entre gaze estimation, OpenPose e análise facial abre portas para uma era de merchandising guiado por dados em tempo real. Se antes dependíamos de pesquisas de campo demoradas ou estimativas subjetivas, hoje é viável ajustar displays, messaging e mix de produtos quase instantaneamente, maximizando engajamento e conversão. Para quem opera no varejo, investir nessa stack tecnológica não é mais futurismo — é vantagem competitiva tangível.

A Intel anunciou o lançamento do OpenVINO™ 2025.2.0, destacando avanços importantes para desenvolvedores de IA generativa. Uma das grandes novidades desta versão é a compatibilidade com o formato GGUF, amplamente utilizado por modelos baseados no llama.cpp. Agora, é possível carregar modelos GGUF diretamente em pipelines Python e C++ usando o OpenVINO GenAI, que converte esses modelos para grafos otimizados e realiza inferência acelerada por GPU de forma dinâmica.

Essa integração já foi validada com modelos populares como DeepSeek-R1-Distill-Qwen, Qwen2.5 Instruct e LLaMA 3.2 Instruct, abrangendo variantes de 1B a 8B parâmetros. Com isso, o OpenVINO se posiciona como uma solução poderosa para executar modelos LLM localmente com alta performance, baixo consumo de memória e suporte direto ao ecossistema GGUF.

O problema: incompatibilidade direta entre tokenizadores

Os modelos treinados e distribuídos no formato GGUF, mesmo que otimizados para execução leve, ainda dependem de um tokenizador — o componente responsável por transformar texto em IDs numéricos que o modelo pode entender. Esses tokenizadores geralmente vêm da biblioteca Hugging Face Transformers, mas a API da OpenVINO exige um formato próprio para integração nativa.

Assim, é necessário um processo de conversão entre esses dois mundos — Hugging Face e OpenVINO — para que a inferência funcione corretamente, especialmente quando envolvem modelos com templates de chat personalizados, como os da família Qwen.

Como converter um tokenizador Hugging Face para uso com modelos GGUF no OpenVINO

Com o avanço da inteligência artificial generativa, cresce a demanda por rodar modelos de linguagem de forma eficiente em hardware local, como CPUs e GPUs Intel. A versão 2025.2 do OpenVINO trouxe uma grande novidade nesse sentido: suporte direto ao formato GGUF, utilizado por modelos otimizados com llama.cpp. No entanto, para que um modelo GGUF funcione corretamente dentro de um pipeline OpenVINO, é necessário converter o tokenizador original da Hugging Face para um formato compatível com a API da OpenVINO.

Este artigo apresenta e explica um programa em Python que realiza exatamente essa conversão, permitindo utilizar modelos como Qwen2.5 Instruct ou LLaMA 3.2 com inferência local acelerada via OpenVINO.

Baixando o modelo GGUF

Antes de executar qualquer conversão, é necessário baixar o arquivo .gguf do modelo desejado. Neste exemplo, usamos o modelo Qwen2.5-0.5B-Instruct, que é compatível com o novo suporte a GGUF no OpenVINO 2025.2.

Utilize o comando abaixo para fazer o download diretamente do Hugging Face:

wget "https://huggingface.co/Qwen/Qwen2.5-0.5B-Instruct-GGUF/resolve/main/qwen2.5-0.5b-instruct-q4_0.gguf?download=true" -O qwen2.5-0.5b-instruct-q4_0.gguf

Salve o arquivo .gguf em uma pasta, por exemplo, gguf_models/, que será usada no processo de conversão.

A solução: conversão do tokenizador com template customizado

O programa apresentado é responsável por:

1. Carregar o tokenizador Hugging Face de um modelo GGUF.
2. Converter esse tokenizador para o formato OpenVINO.
3. Injetar um template de chat compatível com a estrutura de mensagens esperada pelo modelo.
4. Salvar os arquivos resultantes (tokenizer.xml e detokenizer.xml) para uso direto no pipeline.

Análise do código

A função principal do programa é convert_ov_tokenizers(). Ela recebe dois argumentos: o diretório onde está o modelo e o nome do arquivo .gguf.

hf_tokenizer = AutoTokenizer.from_pretrained(
    output_dir, gguf_file=gguf_file, trust_remote_code=True)

Essa linha carrega o tokenizador padrão da Hugging Face, mesmo com base em arquivos GGUF, graças à opção trust_remote_code.

Em seguida, ocorre a conversão para o formato OpenVINO:

ov_tokenizer, ov_detokenizer = convert_tokenizer(hf_tokenizer, with_detokenizer=True)

Aqui, são criados dois objetos: um tokenizador OpenVINO e um detokenizador, necessário para reconstruir o texto após a inferência.

Antes de salvar, o script injeta um chat template customizado, que define como o histórico de mensagens será apresentado ao modelo:

ov_tokenizer.set_rt_info(chat_template, "chat_template")

Esse passo é especialmente importante para modelos como Qwen, onde o comportamento do modelo depende do formato da conversa.

Por fim, os dois componentes são salvos em disco no formato XML:

ov.save_model(ov_tokenizer, output_dir / "openvino_tokenizer.xml")
ov.save_model(ov_detokenizer, output_dir / "openvino_detokenizer.xml")

Esses arquivos serão utilizados posteriormente no pipeline de inferência da OpenVINO para processar texto de entrada e reconstruir a saída do modelo em linguagem natural.

Execução prática

A função main() define o caminho onde está o modelo .gguf e dispara o processo de conversão, medindo também o tempo necessário para a tarefa.

path_model = Path("gguf_models")
convert_ov_tokenizers(path_model, "qwen2.5-0.5b-instruct-q4_0.gguf")

Abaixo o código completo.

from pathlib import Path
import time
from transformers import AutoTokenizer
from openvino_tokenizers import convert_tokenizer
import openvino as ov


chat_template = {
    "{%- if tools %}\n    {{- '<|im_start|>system\\n' }}\n    {%- if messages[0]['role'] == 'system' %}\n        {{- messages[0]['content'] }}\n    {%- else %}\n        {{- 'You are Qwen, created by Alibaba Cloud. You are a helpful assistant.' }}\n    {%- endif %}\n    {{- \"\\n\\n# Tools\\n\\nYou may call one or more functions to assist with the user query.\\n\\nYou are provided with function signatures within <tools></tools> XML tags:\\n<tools>\" }}\n    {%- for tool in tools %}\n        {{- \"\\n\" }}\n        {{- tool | tojson }}\n    {%- endfor %}\n    {{- \"\\n</tools>\\n\\nFor each function call, return a json object with function name and arguments within <tool_call></tool_call> XML tags:\\n<tool_call>\\n{\\\"name\\\": <function-name>, \\\"arguments\\\": <args-json-object>}\\n</tool_call><|im_end|>\\n\" }}\n{%- else %}\n    {%- if messages[0]['role'] == 'system' %}\n        {{- '<|im_start|>system\\n' + messages[0]['content'] + '<|im_end|>\\n' }}\n    {%- else %}\n        {{- '<|im_start|>system\\nYou are Qwen, created by Alibaba Cloud. You are a helpful assistant.<|im_end|>\\n' }}\n    {%- endif %}\n{%- endif %}\n{%- for message in messages %}\n    {%- if (message.role == \"user\") or (message.role == \"system\" and not loop.first) or (message.role == \"assistant\" and not message.tool_calls) %}\n        {{- '<|im_start|>' + message.role + '\\n' + message.content + '<|im_end|>' + '\\n' }}\n    {%- elif message.role == \"assistant\" %}\n        {{- '<|im_start|>' + message.role }}\n        {%- if message.content %}\n            {{- '\\n' + message.content }}\n        {%- endif %}\n        {%- for tool_call in message.tool_calls %}\n            {%- if tool_call.function is defined %}\n                {%- set tool_call = tool_call.function %}\n            {%- endif %}\n            {{- '\\n<tool_call>\\n{\"name\": \"' }}\n            {{- tool_call.name }}\n            {{- '\", \"arguments\": ' }}\n            {{- tool_call.arguments | tojson }}\n            {{- '}\\n</tool_call>' }}\n        {%- endfor %}\n        {{- '<|im_end|>\\n' }}\n    {%- elif message.role == \"tool\" %}\n        {%- if (loop.index0 == 0) or (messages[loop.index0 - 1].role != \"tool\") %}\n            {{- '<|im_start|>user' }}\n        {%- endif %}\n        {{- '\\n<tool_response>\\n' }}\n        {{- message.content }}\n        {{- '\\n</tool_response>' }}\n        {%- if loop.last or (messages[loop.index0 + 1].role != \"tool\") %}\n            {{- '<|im_end|>\\n' }}\n        {%- endif %}\n    {%- endif %}\n{%- endfor %}\n{%- if add_generation_prompt %}\n    {{- '<|im_start|>assistant\\n' }}\n{%- endif %}\n"}

def convert_ov_tokenizers(output_dir, gguf_file):
    hf_tokenizer = AutoTokenizer.from_pretrained(
        output_dir, gguf_file=gguf_file, trust_remote_code=True)
    # hf_tokenizer_chat_template = hf_tokenizer.get_chat_template()
    # Qwen2.5 GGUF model stored chat_template is different from HF tokenizers_config.json, replace as chat_tempalte with HF tokenizers_config
    ov_tokenizer, ov_detokenizer = convert_tokenizer(
        hf_tokenizer, with_detokenizer=True)
    ov_tokenizer.set_rt_info(chat_template, "chat_template")

    ov.save_model(ov_tokenizer, output_dir / "openvino_tokenizer.xml")
    ov.save_model(ov_detokenizer, output_dir / "openvino_detokenizer.xml")


def main():
    path_model = Path("gguf_models")

    start = time.perf_counter()
    convert_ov_tokenizers(path_model,"qwen2.5-0.5b-instruct-q4_0.gguf")
    end = time.perf_counter()
    print(f"Convert OpenVINO tokenizer finished, elapsed: {(end - start) *1e3:.3f} ms")

if '__main__' == __name__:
    main()

Executando inferência com modelos GGUF no OpenVINO: guia prático com Qwen 2.5

Com o suporte nativo ao formato GGUF introduzido no OpenVINO™ 2025.2, ficou mais fácil executar modelos de linguagem grandes (LLMs) de forma otimizada em CPUs ou GPUs Intel. Além da conversão de tokenizadores (já explicada em outro artigo), o próximo passo é realizar a inferência em tempo real, com suporte a streaming de texto, integração com o tokenizador OpenVINO e controle de parâmetros como o número máximo de tokens gerados.

Neste artigo, vamos analisar passo a passo um código funcional que realiza inferência com streaming de tokens, utilizando o modelo Qwen2.5-0.5B-Instruct no formato GGUF, com backend CPU.

🛠️ Requisitos

Antes de rodar este código, certifique-se de que:

• Você já converteu o tokenizador com o convert_tokenizer e salvou os arquivos openvino_tokenizer.xml e openvino_detokenizer.xml.
• O arquivo .gguf do modelo está presente (neste exemplo, qwen2.5-0.5b-instruct-q4_0.gguf na pasta gguf_models/).
• As bibliotecas openvino, openvino_genai e openvino_tokenizers estão instaladas.

Descrição do código de inferência

from pathlib import Path
import time
import openvino as ov
import openvino_genai
from openvino_tokenizers import convert_tokenizer

Essas bibliotecas fornecem a base para rodar a inferência e utilizar o tokenizador OpenVINO. openvino_genai é o novo módulo que lida com pipelines LLM em OpenVINO.

📡 Função streamer() – exibindo os tokens em tempo real

def streamer(subword):
    print(subword, end='', flush=True)
    return openvino_genai.StreamingStatus.RUNNING

Esta função é chamada a cada novo token gerado pelo modelo, permitindo exibir o texto na tela conforme a resposta é construída, simulando o comportamento de um chatbot.

⚙️ Função principal main()

max_new_tokens = 40 
prompt = "What is OpenVINO?"

Define o número máximo de tokens que o modelo pode gerar e o texto de entrada (prompt).

🔄 Inicialização do tokenizador e modelo

tokenizer = openvino_genai.Tokenizer("gguf_models/")
pipe = openvino_genai.LLMPipeline("gguf_models/qwen2.5-0.5b-instruct-q4_0.gguf", tokenizer, "CPU")

• O tokenizador é carregado do diretório onde os arquivos .xml foram salvos.
• O LLMPipeline é a estrutura que junta o modelo .gguf, o tokenizador e o dispositivo de execução ("CPU" neste caso).

🧠 Configuração de geração

config = openvino_genai.GenerationConfig()
config.max_new_tokens = max_new_tokens

Você pode personalizar a geração ajustando parâmetros como:

• max_new_tokens
• temperatura, top_k, top_p (não usados aqui, mas disponíveis via GenerationConfig)

💬 Ciclo de chat

pipe.start_chat()
print("\nPrompt: ", prompt)
print("Start generation ...")
print("\nResponse: \n")
pipe.generate(prompt, config, streamer)
pipe.finish_chat()

Essas chamadas controlam o ciclo de conversação com o modelo:

• start_chat(): inicia um novo histórico (importante para manter contexto).
• generate(...): realiza a inferência com streaming em tempo real.
• finish_chat(): encerra o contexto da conversa atual.

🧪 Exemplo de saída

Prompt:  What is OpenVINO?
Start generation ...

Response: 
OpenVINO™ is an open-source toolkit developed by Intel for optimizing and deploying AI inference ...

Abaixo o código completo:

from pathlib import Path
import time

import openvino as ov
import openvino_genai
from openvino_tokenizers import convert_tokenizer

def streamer(subword):
    print(subword, end='', flush=True)
    return openvino_genai.StreamingStatus.RUNNING

def main():
    max_new_tokens = 40 

    prompt = "What is OpenVINO?"
    tokenizer = openvino_genai.Tokenizer("gguf_models/")
    pipe = openvino_genai.LLMPipeline("gguf_models/qwen2.5-0.5b-instruct-q4_0.gguf", tokenizer, "CPU")

    config = openvino_genai.GenerationConfig()
    config.max_new_tokens = max_new_tokens
    pipe.start_chat()
    print("\nPrompt: ", prompt)
    print("Start generation ...")
    print("\nResponse: \n")
    pipe.generate(prompt, config, streamer)
    pipe.finish_chat()


if '__main__' == __name__:
    main()

Conclusão

O suporte ao formato GGUF no OpenVINO representa um marco importante para a execução de LLMs de forma local e eficiente. No entanto, para que essa integração funcione, é crucial garantir que o tokenizador esteja no formato esperado. Este programa oferece uma solução prática e robusta para converter tokenizadores da Hugging Face para uso direto com pipelines de inferência da OpenVINO, incluindo o suporte a templates de chat específicos.

Com isso, desenvolvedores podem aproveitar o melhor dos dois mundos: a comunidade e o ecossistema da Hugging Face com a performance e eficiência do OpenVINO.

Este exemplo deste documento demonstra como realizar inferência local e eficiente com um modelo LLM em formato GGUF usando OpenVINO 2025.2. A combinação do LLMPipeline, Tokenizer e função streamer() permite simular o comportamento de um assistente de IA de forma fluida e otimizada para CPUs.

Esse pipeline é ideal para aplicações corporativas, embarcadas ou offline, onde o custo computacional e a latência precisam ser reduzidos sem depender de serviços em nuvem.

O Khronos® Group comemora um marco importante: o décimo aniversário do SYCL™. Publicado pela primeira vez em maio de 2015, o SYCL evoluiu de uma proposta ambiciosa para se tornar um componente essencial na programação heterogênea, permitindo que desenvolvedores escrevam código C++ de forma unificada e portátil para uma ampla gama de aceleradores — de CPUs e GPUs a FPGAs e hardware especializado em IA, de forma agnóstica ao fornecedor.

Recentemente, a comunidade de desenvolvedores e os membros do SYCL Working Group do Khronos se reuniram no International Workshop on OpenCL and SYCL (IWOCL 2025) para apresentar os avanços mais recentes no ecossistema SYCL e celebrar esta conquista.

De conceito a referência em computação de alto desempenho

A jornada do SYCL começou com uma especificação provisória apresentada em março de 2014, com sua primeira demonstração ocorrendo durante a SuperComputing 2014. Já em 2015, a versão inicial foi oficialmente ratificada. Desde então, o padrão amadureceu consideravelmente, acompanhando as crescentes demandas da computação moderna.

Inicialmente concebido como um modelo de programação C++ para OpenCL, o SYCL tornou-se um padrão robusto e independente de fornecedores, alimentando aplicações críticas em áreas como HPC, inteligência artificial, pesquisa científica e até software de produção gráfica — como o uso do backend SYCL no Blender Cycles, discutido na IWOCL.

“Na última década, o SYCL passou de uma ideia promissora para uma ferramenta indispensável na programação heterogênea”, afirma Tom Deakin, presidente do SYCL Working Group, professor na Universidade de Bristol e líder do grupo de pesquisa em computação de alto desempenho. “Sua proposta de um modelo de programação único e portável para múltiplas arquiteturas foi chave para sua ampla adoção.”

SYCL na prática: experiência com aceleração de vídeo

No ano de 2019 iniciei as pesquisas da especificação oneAPI Level Zero. Em 2020, desenvolvi uma solução de processamento de vídeo em SYS/C++ utilizando aceleração via codecs AVC, HEVC e AV1, disponibilizados pela biblioteca oneVPL — uma aplicação real do potencial do SYCL em ambientes de alto desempenho.

Use a força. Leia os fontes. Viva o SYCL C++.

Leia mais aqui: https://www.khronos.org/blog/a-decade-of-heterogeneous-c-compute-acceleration-with-sycl

O Dia do Orgulho Nerd, ou Dia do Orgulho Geek é uma iniciativa que advoga o direito de toda pessoa ser um nerd ou um geek. Teve origem na Espanha (“dia del orgullo friki”, em espanhol).^[1]

O dia do orgulho nerd é celebrado em 25 de maio desde 2006, comemorando a première do primeiro filme da série Star Wars, em 1977. O dia 25 de maio também é o Dia da Toalha, em homenagem ao escritor Douglas Adams.

Origens

Em 2006, este dia foi celebrado pela primeira vez em toda a Espanha e na internet, graças à publicidade dada por alguns meios, como:

• Salas, Javier. “Comecocos y mangas toman la calle: la revancha de los frikis“, Telecinco, 2006-5-26. Página visitada em 2006-05-26.
• Perez, Javier. “Orgullo friki“, El Mundo, 2006-5-26. Página visitada em 2005-05-26.
• Ramos, David. “25 de mayo: Día del Orgullo Friki“, 20minutos, 2006-5-25. Página visitada em 2005-05-25.

A maior concentração aconteceu em Madri, onde 300 Nerds demonstraram seu orgulho com um pacman humano.

Comemorações de 2007

Em 2007 a celebração contou com mais ajuda de instituições oficiais (como o Circo Price, de Madri) e teve comemoração mais ampla por toda a Espanha. Atividades oficiais foram anunciadas no Pilar de la Horadada, Cádiz, Huesca, Calaf, Huelva, e Valência. Houve uma campanha Doação de Sangue Nerd. Entre outros atos, foi exibido o filme Gritos no corredor.

2008: O dia do Orgulho Nerd chega à América

Em 2008, o Dia do Orgulho Nerd atravessou o Atlântico e foi comemorado oficialmente na América, onde foi divulgado por numerosos bloggers, unidos pelo lançamento do site GeekPrideDay. O matemático e autor John Derbyshire, vencedor do Prêmio Livro de Euler e blogger geek, anunciou^[2] que apareceria na parada da Quinta Avenida, vestido de número 57, na ala dos números primos – o que fez alguns bloggers dizerem que iriam procurá-lo.

Direitos e deveres dos nerds

Foi criado um manifesto para celebrar o primeiro Dia do Orgulho Nerd, que incluía a seguinte lista de direitos e deveres dos nerds:^[3]Direitos

1. O direito de ser nerd.^[3]
2. O direito de não ter que sair de casa.^[3]
3. O direito a não ter um par e ser virgem.^[3]
4. O direito de não gostar de futebol ou de qualquer outro esporte.^[3]
5. O direito de se associar com outros nerds.^[3]
6. O direito de ter poucos (ou nenhum) amigo.^[3]
7. O direito de ter o tanto de amigos nerds que quiser.^[3]
8. O direito de não ter que estar “na moda”.^[3]
9. O direito ao sobrepeso (ou subpeso) e de ter problemas de visão.^[3]
10. O direito de expressar sua nerdice.^[3]
11. O direito de dominar o mundo.^[3]

Deveres

1. Ser nerd, não importa o quê.^[3]
2. Tentar ser mais nerd do que qualquer um.^[3]
3. Se há uma discussão sobre um assunto nerd, poder dar sua opinião.^[3]
4. Guardar todo e qualquer objeto nerd que tiver.^[3]
5. Fazer todo o possível para exibir seus objetos nerds como se fosse um “museu da nerdice”.^[3]
6. Não ser um nerd generalizado. Você deve se especializar em algo.^[3]
7. Assistir a qualquer filme nerd na noite de estréia e comprar qualquer livro nerd antes de todo mundo.^[3]
8. Esperar na fila em toda noite de estreia. Se puder ir fantasiado, ou pelo menos com uma camisa relacionada ao tema, melhor ainda.^[3]
9. Não perder seu tempo em nada que não seja relacionado à nerdice.^[3]
10. Tentar dominar o mundo.^[3]

Já disponível na Multicortex, o Qwen3 é uma das suítes mais completas de modelos de linguagem de código aberto já lançadas. Desenvolvido pela equipe Qwen da Alibaba, ele traz desde modelos gigantes com desempenho de ponta até versões compactas que rodam localmente em hardwares mais modestos.

Neste artigo, faço um panorama geral da linha Qwen3, explico como os modelos foram treinados, analiso os principais benchmarks e mostro como começar a usá-los. Também vamos disponibilizar tutoriais sobre como rodar o Qwen3 localmente e ajustar os modelos — e este post será atualizado com os links assim que eles estiverem prontos.

Para ficar por dentro das novidades em IA, inscreva-se no nosso boletim gratuito The Median, enviado toda sexta-feira com os destaques da semana.

O que é o Qwen3?

O Qwen3 é a nova família de modelos de linguagem da Alibaba, com código aberto sob licença Apache 2.0. Um dos recursos mais inovadores é o “orçamento de raciocínio”: usuários podem ajustar diretamente o nível de raciocínio dos modelos, controlando a precisão e profundidade das respostas.

🔍 Aumentar o orçamento melhora o desempenho, especialmente em tarefas complexas como matemática, programação e ciências.

Principais modelos da linha Qwen3

MoE = Mixture of Experts: só parte dos parâmetros é usada a cada geração, economizando recursos.

Como os modelos foram treinados

Pré-treinamento em 3 fases, com 36 trilhões de tokens:

1. Habilidades básicas com 30T tokens.
2. Ênfase em matemática, STEM e código (5T tokens).
3. Expansão para janelas de 32K com dados de contexto longo.

Pós-treinamento em 4 etapas:

• Aprendizado passo a passo (Cold Start)
• Aprimoramento via Reforço (RL)
• Equilíbrio entre raciocínio lento e respostas rápidas
• Ajuste geral com dados de instruções e tarefas de agentes

Modelos menores são destilados dos maiores, mantendo qualidade com menos recursos.

Resultados de Benchmark

Qwen3-235B-A22B lidera ou disputa o topo em quase todos os testes:

• ArenaHard (raciocínio): 95,6 (atrás apenas do Gemini 2.5 Pro)
• AIME’24: 85,7 em matemática avançada
• CodeForces Elo: 2056 — melhor que Gemini e DeepSeek
• LiveBench: 77.1, excelente para tarefas do mundo real

Qwen3-30B-A3B também impressiona:

• ArenaHard: 91,0 — supera QwQ-32B e GPT-4o
• CodeForces Elo: 1974 — desempenho competitivo com modelos maiores

Qwen3-4B se destaca para seu tamanho:

• AIME’24: 73,8 — melhor que muitos modelos maiores
• MultiIF: 66,3 — ótimo desempenho multilíngue para um 4B

Qual modelo usar?

• Tarefas exigentes? Vá de Qwen3-235B-A22B
• Bom desempenho com custo menor? Use Qwen3-30B-A3B
• Uso geral com latência previsível? Os modelos densos (32B, 14B…) são ideais
• Aplicações leves ou embarcadas? Opte por Qwen3-1.7B ou 0.6B

Conclusão

A linha Qwen3 oferece opções de alto desempenho para uma variedade de cenários — de agentes inteligentes a aplicações embarcadas. Com código aberto, janela de 128K tokens e arquitetura moderna, eles elevam o padrão dos modelos disponíveis publicamente.

A Universidade de Hong Kong, em colaboração com o Huawei Noah’s Ark Lab, apresenta o Dream 7B, um modelo de linguagem baseado em difusão que marca um avanço significativo na geração de texto. Lançado como software de código aberto, o Dream 7B permite ajustar o número de etapas de difusão, oferecendo um equilíbrio dinâmico entre velocidade e qualidade — uma inovação promissora frente às arquiteturas autorregressivas tradicionais. Vejam o funcionamento no vídeo abaixo:

Arquitetura Inovadora: Difusão em Linguagem Natural

Com 7 bilhões de parâmetros, o Dream 7B adota uma abordagem de difusão discreta para a geração textual. Ao contrário dos modelos convencionais como GPT ou LLaMA, que produzem texto token a token da esquerda para a direita, o Dream 7B refina sequências inteiras simultaneamente, partindo de um estado completamente ruidoso.

Essa arquitetura permite ao modelo explorar o contexto de forma bidirecional, resultando em maior coerência e capacidade de raciocínio. Inicializado com os pesos do Qwen2.5 7B e treinado com cerca de 580 bilhões de tokens (provenientes de conjuntos como Dolma v1.7, OpenCoder e DCLM-Baseline), o Dream 7B combina fundamentos sólidos com inovação técnica.

Vantagens sobre Modelos Autorregressivos

O Dream 7B apresenta diversos diferenciais que o destacam:

• Contexto bidirecional: Ao processar a sequência inteira de uma vez, o modelo compreende melhor relações e restrições globais no texto.
• Raciocínio e planejamento aprimorados: Supera modelos equivalentes em tarefas complexas que exigem múltiplas etapas de raciocínio, como Sudoku e Countdown.
• Geração controlada e flexível: A geração não precisa seguir uma ordem fixa, permitindo preenchimentos arbitrários e produções condicionadas.
• Qualidade vs. desempenho ajustável: O número de passos de difusão pode ser personalizado para priorizar qualidade ou eficiência computacional conforme a demanda.

Desempenho em Benchmarks

Em benchmarks de linguagem, matemática e geração de código, o Dream 7B iguala ou supera modelos líderes de sua categoria, como LLaMA3 8B e Qwen2.5 7B. Em tarefas que envolvem raciocínio sob restrição, chega a competir com modelos significativamente maiores, como o DeepSeek V3 671B — evidência clara de sua eficiência estrutural.

Inovações de Treinamento

Entre as principais inovações utilizadas no treinamento do Dream 7B estão:

• Inicialização com pesos de modelos autorregressivos: Aproveita o conhecimento pré-existente do Qwen2.5 7B, otimizando tempo e recursos de treinamento.
• Reprogramação de ruído adaptativa ao contexto: Em vez de aplicar ruído uniforme, o modelo ajusta dinamicamente o nível de ruído por token, melhorando a eficácia do aprendizado de difusão.

Aplicações Práticas

O Dream 7B é ideal para aplicações onde modelos tradicionais enfrentam limitações:

• Conclusão e preenchimento de texto com restrições: Gera conteúdo em ordem arbitrária, ideal para completar trechos específicos ou condicionar a geração a frases-alvo.
• Decodificação customizável: Geração pode seguir diversas ordens, adaptando-se a diferentes tipos de tarefa.
• Ajuste de desempenho: Possibilita controle fino sobre a relação entre tempo de inferência e qualidade do texto.

Aprimoramento Supervisionado e Versão Instruct

Para melhorar a aderência a instruções, foi realizado um ajuste supervisionado com 1,8 milhão de pares de dados do Tulu 3 e SmolLM2. Após três épocas de refinamento, o modelo demonstrou desempenho equivalente a soluções autorregressivas em tarefas orientadas por comandos do usuário.

As versões resultantes — Dream-v0-Base-7B e Dream-v0-Instruct-7B — estão publicamente disponíveis, promovendo a experimentação aberta e o avanço da pesquisa.

Conclusão: O Futuro da Geração de Texto com Difusão

O Dream 7B desafia a hegemonia dos modelos autorregressivos e comprova que a modelagem por difusão é uma alternativa viável e promissora para tarefas de linguagem natural. Sua arquitetura flexível, aliada a resultados expressivos, abre caminho para uma nova geração de sistemas de IA mais versáteis e eficazes.

Com o lançamento em código aberto, a equipe da Universidade de Hong Kong impulsiona a inovação na área, permitindo que pesquisadores e desenvolvedores explorem novas fronteiras na geração de linguagem natural.

Fonte https://hkunlp.github.io/blog/2025/dream/#why-diffusion-for-text-generation