Mesmo modelo, velocidades diferentes: por que seu provedor de inferência importa — FriendliAI

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Same Model, Different Speed: Why Your Inference Provider Matters — FriendliAI · Canal: AI Engineer · 12:36 · Assistir no YouTube

Tópicos: Inferência e otimização de modelos, Infraestrutura e hardware de IA, Modelos locais e open source

Resumo

Yun Mo, engenheiro fundador da FriendliAI, explica por que a qualidade do provedor de inferência pode afetar velocidade, confiabilidade e custo mesmo quando o modelo é o mesmo. Ele destaca o avanço dos modelos de pesos abertos e compara seu desempenho e custo com modelos proprietários em tarefas de programação. Em seguida, apresenta técnicas da FriendliAI para acelerar a inferência, como roteamento com reconhecimento de cache, gerenciamento hierárquico de memória e speculative decoding. A palestra conclui que provedores devem ser avaliados com cargas de trabalho reais, considerando também erros e disponibilidade, e cita resultados de um teste da Kilo Code.

Pontos-chave

Modelos de pesos abertos já competem com modelos proprietários em algumas tarefas e podem custar menos para executar.
O mesmo modelo e a mesma tarefa podem ter tempos de resposta diferentes conforme o provedor de inferência.
A experiência de inferência depende de vários componentes, incluindo arquitetura, cache, roteamento, quantização e uso de GPU.
O roteamento com reconhecimento de cache direciona solicitações para réplicas que já armazenam prefixos relevantes.
Uma hierarquia de cache entre GPU, RAM da CPU e armazenamento pode reduzir o custo de processar contextos longos.
O speculative decoding propõe vários tokens para validação em uma passagem e pode melhorar o tempo por token sem alterar a qualidade da saída.
A FriendliAI descreve uma abordagem híbrida que escolhe dinamicamente métodos de speculative decoding conforme a carga de trabalho.
A confiabilidade também faz parte do desempenho: falhas ou limites de taxa podem interromper fluxos de trabalho com agents.
A palestra recomenda comparar provedores usando a própria carga de trabalho, incluindo velocidade, confiabilidade, custo e qualidade.

Capítulos

Início	Capítulo	Resumo
00:01	Modelos de pesos abertos e diferenças entre provedores	Yun Mo apresenta o avanço dos modelos de pesos abertos e mostra que custo e velocidade podem variar entre provedores, mesmo com o mesmo modelo.
03:17	A infraestrutura por trás da inferência	A palestra relaciona a experiência do usuário aos componentes do sistema e explica como roteamento e cache ajudam a reduzir o trabalho de processamento.
05:31	Cache e velocidade de geração	O palestrante detalha o reaproveitamento de prefixos, o cache hierárquico e o speculative decoding como métodos para melhorar o desempenho.
09:19	Confiabilidade e avaliação com cargas reais	A FriendliAI defende avaliar latência, erros, disponibilidade, custo e qualidade usando a carga de trabalho real, e apresenta um relato da Kilo Code.

Citações

Não se trata mais apenas da qualidade do modelo. Trata-se do que você consegue executar em escala. — 02:42

Mesmo com o mesmo modelo e a mesma tarefa, a experiência pode ser muito diferente dependendo do provedor. — 04:23

Para a sua aplicação, o único benchmark que realmente importa é a sua própria carga de trabalho. — 11:01

Conceitos e entidades

FriendliAI (empresa): Empresa apresentada na palestra como provedora de uma API e de um mecanismo de inferência para modelos de pesos abertos.
Yun Mo (pessoa): Engenheiro fundador da FriendliAI e palestrante do vídeo.
GLM-5.2 (modelo): Modelo de pesos abertos citado em comparações de desempenho e custo em tarefas de programação.
Code Opus 4.8 (modelo): Modelo mencionado na comparação de classificações em benchmarks de programação.
Kilo Code (empresa): Plataforma de coding agent citada como cliente que comparou provedores de inferência para modelos GLM.
Roteamento com reconhecimento de cache (conceito): Técnica que encaminha uma solicitação à réplica que já mantém em cache o prefixo relevante.
Cache hierárquico (conceito): Organização do cache em níveis de memória, incluindo GPU, RAM da CPU e armazenamento.
speculative decoding (conceito): Técnica que propõe tokens futuros para que o modelo principal os valide em uma única passagem.

Tradução completa (pt-BR)

00:01 [música] Certo, vamos começar. Olá a todos. Meu nome é Yun Mo. Sou engenheiro fundador na FriendliAI, onde desenvolvo, com nossa equipe, um mecanismo de inference para otimizar o desempenho da inference. Hoje vou falar sobre como criamos uma API de inference rápida e confiável para modelos open-weight de ponta.

00:34 Obrigado. Certo, antes de começarmos, vamos fazer uma rápida enquete levantando as mãos. Quem aqui usa modelos proprietários de ponta, como GPT ou Claude? Certo, a maioria de vocês já usa esses modelos. E quem aqui usa principalmente modelos open-weight? Sim. Sim. Menos gente do que usando modelos proprietários. Pessoalmente, tenho usado uma mistura dos dois ultimamente, mas estou migrando gradualmente mais das minhas cargas de trabalho para modelos open-weight. O motivo é que os modelos open-weight atingiram um patamar importante. Por exemplo, em benchmarks de codificação, raciocínio e agentes. Modelos como GLM 5.2 estão competindo no mesmo nível que os principais modelos proprietários. Como vocês podem ver neste placar do Code Arena, GLM 5.2 está até acima de Code Opus 4.8. Então, ele está

01:06 logo abaixo de Claude Fable 5. Da mesma forma, em vários benchmarks de codificação, terminal e uso de ferramentas, GLM 5.2 e Minimax M3 apresentam resultados fortes. Portanto, a questão já não é apenas se os modelos open-weight são bons o bastante para muitas cargas de trabalho. Agora, eles são. A próxima pergunta é: com que rapidez e confiabilidade conseguimos executá-los em produção? Os números dos benchmarks, por si só, não

01:38 dão uma ideia clara de como as coisas realmente funcionam. Por isso, fiz um experimento prático simples para ver como esses modelos se saem de verdade. Pedi a GLM 5.2 e Opus 4.8 que criassem um jogo de defesa de torres como este. Como vocês podem ver, os dois modelos produziram implementações funcionais com estrutura e qualidade semelhantes. Ambos têm um mapa, e as torres atiram nos inimigos que estão ao alcance. Sim, os dois ficaram muito bons, considerando que fiz isso

02:08 com um único prompt. Mas, quando olhamos para o custo, a diferença fica muito clara. GLM 5.2 foi mais de 5,6 vezes mais barato para essa tarefa. Em workflows no estilo agentic, nos quais é preciso iterar várias vezes, a diferença aumenta rapidamente. Então, já não se trata apenas da qualidade do modelo. Trata-se do que você consegue pagar para executar em escala. Depois da qualidade e do custo do modelo, a próxima questão é a qualidade do provedor, e a qualidade do provedor tem muito a ver com

02:42 desempenho. Mesmo que os pesos do modelo sejam os mesmos, a latência, a taxa de transferência e a confiabilidade podem variar bastante, dependendo de onde ele é executado. Este retrato do OpenRouter mostra que essas diferenças podem ser medidas. Se você está criando um produto de IA, não deve perguntar apenas qual modelo usar, mas também quais provedores oferecem o melhor desempenho, confiabilidade e preço. Vou mostrar outro exemplo. Aqui, usei o mesmo modelo, 5.2, e o

03:17 mesmo workflow de coding agent. A tarefa é criar um jogo para celular simples no estilo Candy Crush, que chamamos de Moto Crush. Como vocês podem ver, à esquerda está a FriendliAI. Ela gera o jogo em menos de dois minutos. Outro provedor leva mais de três minutos. O modelo é o mesmo. O aplicativo de agent é o mesmo, mas o provedor é diferente. Modelo, ferramentas de desenvolvimento e coding agent: é essa experiência que os usuários realmente

03:51 sentem. Com esse exemplo simples, vimos que, mesmo com o mesmo modelo e a mesma tarefa, a experiência pode ser bem diferente dependendo do provedor. A diferença vem de toda a tecnologia de inference. A arquitetura do modelo, o sistema de cache, a política de roteamento, a estratégia de quantização e os kernels de GPU: tudo isso se combina e molda a experiência real do desenvolvedor. Esse é o cerne do valor da FriendliAI. Não estamos apenas disponibilizando uma API de modelo; a FriendliAI foi criada

04:23 como um mecanismo full-stack de inference para modelos generativos de IA. Isso importa porque uma inference rápida e confiável não depende de uma única otimização. Batching, escalonamento, quantização, decodificação especulativa e kernels precisam funcionar juntos. Então, vou explicar brevemente como criamos isso e como levamos o desempenho da inference a um nível de ponta. Nos aplicativos modernos com agents,

04:59 as entradas costumam ser muito longas. Elas facilmente ultrapassam 10 mil tokens, enquanto as saídas são relativamente curtas. Mais importante ainda: uma grande parte das entradas se repete entre as solicitações. Em muitas cargas de trabalho reais, de 50% a 80% ou 90% dos tokens são idênticos entre diferentes solicitações. Do ponto de vista do sistema, isso significa que a maior parte do custo computacional está na etapa de prefill, em que o modelo processa todas as entradas e cria um cache KV. Portanto, se recalcularmos esse prefixo compartilhado

05:31 toda vez, desperdiçaremos latência e ciclos de GPU. Quando uma nova solicitação compartilha um prefixo com a anterior, podemos reutilizar esses tensores, pular o cálculo de prefill correspondente e reduzir diretamente o TTFT. Assim, evitamos recalcular uma grande parte da entrada. No entanto, fazer isso funcionar em escala exige dois mecanismos fundamentais. O primeiro é o roteamento ciente do cache. Em um sistema distribuído, o cache KV não é centralizado. Ele fica em

06:06 réplicas individuais. Portanto, o roteador precisa enviar a solicitação recebida para a réplica que já tem o prefixo relevante no cache; caso contrário, perdemos o benefício da reutilização. O segundo mecanismo é a hierarquia de cache. O cache KV exige muita memória em modelos grandes e com contextos longos. Seu tamanho pode ultrapassar o dos pesos do modelo. Como vocês sabem, a VRAM da GPU é a mais rápida, mas também é um recurso muito limitado. Por isso, organizamos o cache em níveis: o cache quente fica na memória da GPU,

06:38 o cache morno fica na RAM da CPU, e o cache frio pode ser transferido para unidades NVMe ou para o disco. O sistema transfere dinamicamente os blocos menos usados e os prepara quando necessário. Ao combinar o roteamento ciente do cache com o gerenciamento hierárquico de memória, reduzimos significativamente o custo dos prefixos, diminuímos o TTFT e tornamos as cargas de trabalho de agents com contexto longo muito mais eficientes. O próximo ponto é a velocidade de interação.

07:10 A decodificação autorregressiva padrão gera um token por passagem para frente, o que torna a decodificação inerentemente sequencial. Durante a decodificação, a GPU costuma ficar subutilizada, e a decodificação especulativa muda a estrutura desse problema. Em vez de gerar um token e parar, ela propõe vários tokens candidatos adiante. Então, o modelo-alvo valida esses candidatos em uma única passagem e, se os tokens forem aceitos, eles não têm custo adicional. Isso melhora

07:42 o tempo por token de saída sem alterar a qualidade da saída do modelo. Há diferentes maneiras de propor candidatos. Uma delas é a especulação baseada em modelo. Ela usa um modelo auxiliar pequeno para prever os tokens seguintes. Sua vantagem é que pode alcançar uma taxa de aceitação maior, mas o custo é o processamento adicional. Outro método é a especulação sem modelo. Ela usa

08:15 padrões do prompt ou de saídas anteriores. Ela tem menos sobrecarga, mas funciona melhor apenas quando a saída se parece com o contexto existente. O importante é o equilíbrio entre as vantagens e os custos. A especulação pode reduzir a latência por solicitação, mas a validação acrescenta sobrecarga ao lote. Portanto, a melhor estratégia não é fixa. Na FriendliAI, adotamos uma abordagem híbrida. O runtime pode selecionar dinamicamente entre a especulação baseada em modelo e a especulação sem modelo, de acordo com a carga de trabalho e as

08:46 características da solicitação. Também pensamos na especulação como algo que podemos aprimorar com o tempo. Com a especulação autoevolutiva, o modelo auxiliar pode se adaptar com base no tráfego real de serving. O especulador melhora continuamente suas previsões sobre a carga de trabalho que está sendo executada em produção. O próximo ponto que quero mencionar é a confiabilidade. A velocidade, por si só, não basta. A confiabilidade dos aplicativos de IA em produção

09:19 faz parte da velocidade. Se uma API é rápida, em média, mas frequentemente sofre timeouts, erros 5xx, erros 429, limites de taxa ou falhas desse tipo, a experiência do usuário ainda é prejudicada. Isso é ainda mais importante para cargas de trabalho agentic. Como vocês sabem, um agent pode precisar de várias chamadas ao modelo para concluir uma tarefa. Se uma única chamada falhar no meio do processo, o workflow inteiro pode ser invalidado. É por isso que não otimizamos apenas para

09:51 A confiabilidade faz parte da velocidade. Então, se uma API é rápida em média, mas frequentemente atinge o tempo limite, apresenta erros 5xx, limites de taxa 429 ou falhas desse tipo, a experiência do usuário ainda é prejudicada. Isso se torna ainda mais importante em cargas de trabalho agênticas. Como você sabe, um agent pode precisar fazer várias chamadas ao modelo para concluir uma tarefa, e, se apenas uma chamada falhar no meio do processo, todo o workflow pode ser invalidado. É por isso que não otimizamos apenas para a

10:26 latência ou throughput. Otimizamos toda a experiência da API, incluindo a taxa de erros, o tempo de atividade e todas essas coisas em conjunto. E este snapshot da Open AAI para o GLM 5.1 Pro mostra que a FriendliAI não é apenas rápida, mas também altamente confiável, com mais de 99,9% de tempo de atividade. Então, o que quero dizer é que muitos provedores de inference por aí, inclusive neste menu, vão dizer que são rápidos. E, até certo ponto, alguns deles são, mas

11:01 em certos benchmarks e sob certas condições. Mas, para a sua aplicação, o único benchmark que realmente importa é a sua própria carga de trabalho: seu prompt, o tamanho dos seus tokens, seus padrões de tráfego e suas expectativas de latência. Nossa recomendação é simples: traga sua carga de trabalho para nós e teste nosso serviço em termos de velocidade, confiabilidade, custo e qualidade. E, claro, construímos nosso serviço de inference exatamente para essas

11:34 cargas de trabalho de produção, e acreditamos que podemos oferecer a melhor experiência. Temos um estande neste evento. Então, traga seu problema mais difícil e vamos resolvê-lo juntos. Para encerrar, quero compartilhar um depoimento de um dos nossos clientes, a Kilo Code. A Kilo Code é uma das maiores plataformas de agentes de programação, processando vários trilhões de tokens por semana. Eles testaram muitos provedores de inference diferentes ao longo dos últimos anos e, em seu

12:05 teste A/B com modelos GLM, ficaram especialmente impressionados com a FriendliAI. Em comparação com muitos outros provedores de inference, a FriendliAI foi mais de sete vezes mais rápida e teve uma taxa de erros significativamente menor. Acredito que você pode ter a mesma experiência com a FriendliAI. Então, se você está desenvolvendo com nossos modelos open source de ponta, venha testá-los na FriendliAI, traga sua carga de trabalho real e deixe-nos mostrar

12:36 o que uma inference rápida e confiável pode fazer. Esse é o fim da minha apresentação. Se tiver alguma pergunta, fique à vontade para perguntar. Obrigado. >> [música]

Transcrição original

[00:01] [music] All right, let’s get started. So, hello everyone. My name is Yun Mo. I’m a founding engineer at Friendly AI uh building inference engine with our team to optimize inference performance. Uh so today I’m going to talk about how we built the fast and reliable inference API for frontier openweight models.

[00:34] So oh thank you. Okay so before we dive in let’s do a quick show of hands. So who here uses closed weight frontier models like GPT or cloud? Okay most of you are already using it. And then who here mainly use openweight models? Yeah. Yeah. Fewer than the closed weight models. So personally I recently using a

[01:06] mix of both these days but I’m gradually migrating more of my workload to open weight models. The reason is that open weight models uh have crossed the threshold these days. For example, encoding, reasoning, and agentic benchmarks. Models like GLM 5.2 are competing in the same tier as the leading proprietary models. So, as you can see from this code arena leaderboard, uh GLM 5.2 is ranked even higher than code opus 4.8. So, it is

[01:38] right uh below the cloud fable 5. So, similarly across various coding terminal and tool use benchmarks uh GM 5.2 2 and minmax M3 shows strong results. So the question is no longer only whether open weight models are good enough for many workloads now they are. So the next question is how fast and reliably we can run them in production. So benchmark numbers alone uh don’t

[02:08] really give a clear sense of how well things actually works. So instead I ran a a simple hands-on experiment to see how these models actually perform. So I asked both GLM 5.2 and OPUS 4.8 uh 4.8 to build a tower defense game like this. So as you can see both models produce working implementation with similar structure and quality. So both one has a map and the turrets are shooting the the enemies within the range. So yeah, both looks pretty great considering I made it

[02:42] with a a single prompt. But when we look at a cost, the difference becomes very clear. So GM 5.2 was more than 5.6 times cheaper for this task. And in agent SL style workflows where you need to iterate multiple times, the the the gap compounds quickly. So this is not just about motor quality anymore. It is about what you can afford to run at scale. So after the model quality and cost, the next next question is provider quality and provider quality is really about

[03:17] performance. So even if the model weights are the same, latency, throughput and reliability can vary significantly depending on where you run it. Uh so this one has a open router snapshot which shows that uh these differences are measurable. So if you’re building an AI product, you should not only ask which model to use, but you should also ask which providers gives you the best performance, reliability, and pricing. So I will show you another example. So here I use the same model 5.2 and the

[03:51] same coding agent workflow. So the task is to build a simple Candy Crush style mobile game which we call moto crush. So when you see this, the left side is friendly AI. it generates the the the game within two minutes. Another provider needs uh more than three minutes. So the model is the same. The agent app is the same but the provider was different. So model developer tools and coding agent this is this exper this is the experience that users actually

[04:23] feels. So from this simple example we saw that even with the same model and the same task the experience can feel very different depending on the provider. The difference comes from the entire inference tech. So the model architecture cache system routing policy quantization strategy GPU corners all those things come together should shape what the developer actually experiences. So this is the uh core of friendly AI’s value. So we are not just exposing a model API be uh so friendly AI is built

[04:59] as a fullstack inference engine for geni models. This matters uh because fast and reliable inference is not just one optimization. It is batching scheduling quantization spec decoding and connors all all everything should work together. So let me briefly explain uh how we built that and how we make uh the inference performance uh to the cutting edge level. So in the modern agent applications

[05:31] inputs are often very long. It easily exceeds uh 10k tokens while outputs are relatively short and more importantly a large portion of the inputs are repeated across requests. In many real workloads like 50% to 80 to 90% of the tokens are identical across different requests. So from a system perspective this means uh most of the compute cost is in the prefill stage where the model processes the entire inputs and build a KB cache. So if we recompuse this share prefix

[06:06] every time you’re wasting both latency and GPU cycles. So when a new reccast share a a prefix with the previous one, we can reuse those tensor and skip the corresponding prefer computation and directly reduce the TTFT and uh we can avoid recmp computing large chunk of the input and but however making this work at scale requires two key ch uh mechanisms. So first one is cache aware routing. So in the distributed system KB cache is not centralized. It lives on

[06:38] individual replicas. So the router must send incoming request to the replica that already holds the relevant prefix in its cache otherwise we re we lose the benefit of reuse. The second thing is cache hierarchy. So KB cache is extremely memory intensive for large models and long context. KB cache size can exceed model weights. So and as you know GPU VRAM is the fastest but there’s also very limited resources. So uh we treat cache as a hierarchy like hot

[07:10] cache stays in GPU memory warm cachees in uh CPU RAM and quarter cache can be offloaded to MVME or uh the disk spaces. The system dynamically offloads less used blocks and prep them when uh when they need it. So by combining cash aware routing and hierarchical memory management we significantly reduce the prefix cost lower TTFT and making long context agent workload much more efficient. So the next thing is interactive speed.

[07:42] So standard auto reggressive decoding it generates one tokens per four pass that makes decode uh inherently a sequenture and during the decode the GPU is often underutilized and speculative decoding changes the shape of this problem. So instead of generating one token and stopping it proposes multiple candidates tokens ahead then the target model validates those uh candidates in a single pass and if the tokens are accepted they are free. So this improves

[08:15] time per output token uh without changing models uh output quality and there are different ways to draft candidates. So one way is modelbased speculation. It uses a small draft model to predict the future tokens and then and the benefit of it is it can achieve higher acceptance rate but the cost is the uh extra compute and another method is model free speculation. It uses

[08:46] pattern from a prompt or prior output. So it has lower overhead but it works best only when the output resembles the existing context. So the important part is the trade-off. So speculation can improve per request latency but validation as overhead to the batch. So the best strategy is not static. And at friendly AI we take a hybrid approach. So the runtime can dynamically select between model based and model speculation uh based on the workload and

[09:19] request uh characteristic. So we also think about speculation as something we can improve over time. So with self-evolving speculation uh draft model can adapt based on the real serving traffic. So the speculator continuously improves its prediction of the workload actually running in the in your uh production. So the next thing I want to mention is reliability. So speed alone is not enough. So production AI application uh

[09:51] reliability is part of speed. So if an API is fast in average but frequently hits timeout like five 5xx error 4 to9 rate limit or fail or that kind of failure the user experiences uh still breaks. So this becomes even more important for agentic workloads. As you know agent may need multiple model cores to complete one task and if just one call phase in the middle the entire workflow can be invalidated. So that’s why we do not optimize only for the

[10:26] latency or throughput. We optimize the full API experiences uh including the error rate, uptime, all those things together. And this open AAI snapshot for GLM 5.1 pro uh shows that friendly AI is not only the fast but it’s also highly reliable with over 99.9% up time. So what I want to say is many inference provider out here of course in this menu as well they will tell you that they are fast and some point of them they are but

[11:01] on cert on certain benchmark under certain condition but for your application the only benchmark that really matters is your own workload. So your prompt your token length your traffic patterns and your latency expectation. So our recommendation is simple. So please bring your workload to us and test a poor experience with us in terms of like speed, reliability, cost and quality. And of course um we build our inference service for exactly these

[11:34] production workloads and we and we believe that we can give you the best experience. So we have a boost in this venue. So bring your hardest problem to us and let’s solve it together. So to close I want to share a testimonial from one of our customer is a kilo code. So kilo code is one of the largest coding agent platform processing like several trillions of tokens every week. So they have tested many different inference providers over past years and in their

[12:05] split test for GLM models they were especially impressed by friendly AI. So compared with many other inference provider, friendly AI was over like seven times faster and had a sign significantly lower error rate. So I believe you can get the same kind of experience with friendly AI. So if you’re building your frontier open models, building with your frontier open models, come try them on friendly AI and bring your real workload and let us show

[12:36] you what fast and reliable inference can do. So this is the end of my talk and if you have any question feel free to ask. Thank you. >> [music]