A nuvem de inference de ponta para agents — Byung-Gon (Gon) Chun, 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: The Frontier AI Inference Cloud for Agents — Byung-Gon (Gon) Chun, FriendliAI · Canal: AI Engineer · 14:28 · Assistir no YouTube

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

Resumo

Byung-Gon Chun apresenta a FriendliAI e explica por que agents exigem uma infraestrutura de inference diferente da usada para chat. Como os agents executam tarefas longas, alternam entre chamadas ao LLM e ferramentas e acumulam contexto, a métrica central passa a ser a latência da tarefa inteira. A FriendliAI busca reduzir essa latência com prefix caching, gerenciamento do KV cache, roteamento consciente de cache e otimizações que consideram o contexto do agent. A apresentação também destaca o uso de modelos open-weight de ponta para tornar agents de produção mais rápidos, confiáveis e econômicos.

Pontos-chave

Agents transformam a unidade de trabalho de uma requisição individual em uma tarefa que pode envolver muitas chamadas ao LLM, ferramentas e subagents.
A métrica relevante para a experiência do usuário é a latência de ponta a ponta da tarefa, não apenas a latência de uma chamada ou de um token.
Modelos open-weight de ponta podem oferecer qualidade adequada para muitos workflows de agents por uma fração do custo de modelos fechados.
Como etapas consecutivas de um agent compartilham grandes prefixos, reutilizar o KV cache evita recomputação e reduz o tempo até o primeiro token.
Gerenciamento hierárquico e distribuído do KV cache ajuda a manter mais contexto ativo e disponível entre réplicas.
O roteamento consciente de cache busca preservar a localidade do prefixo sem deixar que uma parte do sistema fique sobrecarregada.
Otimizações conscientes do agent podem antecipar trabalho, orientar decisões de preempção e melhorar o descarte de cache com base no contexto da tarefa.
A FriendliAI oferece Model API, endpoints dedicados e BYOG para atender diferentes necessidades de implantação.
A apresentação cita Kilo Code e LG como clientes que usam inference para workloads de agents.

Capítulos

Início	Capítulo	Resumo
00:13	FriendliAI e o avanço dos modelos open-weight	Gon Chun apresenta a empresa e argumenta que a combinação de agents em expansão e modelos open-weight mais capazes torna viável ampliar o uso de agents.
03:23	Por que inference para agents é diferente	A apresentação contrasta chat com tarefas longas de agents, que alternam chamadas ao LLM e ferramentas e acumulam contexto.
06:47	A infraestrutura de inference para agents	A FriendliAI descreve seus pilares técnicos, incluindo prefix caching, gerenciamento de KV cache e roteamento consciente de cache.
09:31	Roteamento e otimização consciente do agent	O palestrante explica como preservar a localidade do cache e usar o contexto do agent para orientar decisões de execução.
11:09	Uso em produção e resultados com clientes	A FriendliAI apresenta a combinação de modelos open-weight e sua infraestrutura, além de exemplos envolvendo Kilo Code e LG.
13:20	Opções de implantação e conclusões	A palestra encerra apresentando Model API, endpoints dedicados e BYOG e recapitulando a importância de otimizar a latência da tarefa.

Citações

O usuário se importa com quando a tarefa inteira será concluída. — 03:58

Inference para agents não é apenas chat com mais requisições. — 06:16

A métrica real é a latência de ponta a ponta da tarefa, não a latência de uma única requisição. — 06:47

Agents não são apenas chat com mais chamadas. — 13:54

Conceitos e entidades

FriendliAI (empresa): Empresa que oferece uma nuvem de inference voltada a agents e apresenta otimizações para reduzir a latência de tarefas.
Byung-Gon (Gon) Chun (pessoa): Fundador e CEO da FriendliAI, responsável pela apresentação.
agentic inference (conceito): Inference otimizada para tarefas de agents, considerando múltiplas chamadas, uso de ferramentas e contexto crescente.
continuous batching (conceito): Técnica de otimização de inference que, segundo a apresentação, foi inventada pela equipe de pesquisa da FriendliAI.
Orca (repo): Trabalho de pesquisa citado como inspiração para um framework open source amplamente utilizado.
vLLM (ferramenta): Framework open source citado na apresentação como inspirado pelo trabalho Orca.
GLM-5.2 (modelo): Modelo open-weight usado nos exemplos de coding agent e de execução de tarefas.
Opus 4.8 (modelo): Modelo da Anthropic comparado ao GLM 5.2 em uma tarefa de criação de jogo.
KV cache (conceito): Cache de key-value que permite reutilizar prefixos já processados em etapas posteriores de um agent.
Kilo Code (ferramenta): Ferramenta de coding agent citada como cliente da FriendliAI e usada em demonstrações.
MiniMax (modelo): Modelo open-weight mencionado entre as opções servidas pela FriendliAI.
Kimi (modelo): Modelo open-weight mencionado entre as opções servidas pela FriendliAI.
LG (empresa): Empresa global citada como cliente da FriendliAI.
BYOG (conceito): Opção que permite executar a inference da FriendliAI em infraestrutura própria de GPU.

Tradução completa (pt-BR)

00:13 Vamos começar. Olá a todos. Obrigado por terem vindo. Estamos no fim da tarde do último dia. Agradeço muito. Sou Gon, fundador e CEO da FriendliAI. Hoje quero falar sobre inference para agents. Primeiro, vou explicar o que mudou, por que isso importa e como reconstruímos a nuvem de inference para agents. Antes de nos aprofundarmos, deixem-me apresentar brevemente

00:43 a FriendliAI. A FriendliAI é a nuvem de inference de ponta para agents. Fazemos inference para agents em escala, com mais rapidez, menor custo e mais confiabilidade. Nascemos de uma equipe de pesquisa da S National University, e essas raízes de pesquisa ainda nos definem. Somos a equipe que inventou o continuous batching, a otimização de inference que agora é padrão em todo o setor. Nosso trabalho com Orca inspirou o 3LM, um framework open source amplamente usado.

01:16 Hoje, operamos globalmente, com sede em San Francisco e uma equipe em Seul para expandir a inference de ponta. Como vocês sabem, 2026 é o ano em que os agents entram em produção em larga escala, impulsionados pela convergência de duas tendências. Primeiro, os agents estão crescendo exponencialmente. Os agents de IA estão impulsionando uma adoção explosiva em operações de software e trabalho do conhecimento. Segundo, os modelos open-weight chegaram à fronteira e tornam os agents economicamente viáveis.

01:51 Agora, eles rivalizam em capacidade com os modelos de ponta fechados, o que significa que é possível executar agents de qualidade de ponta com modelos abertos e um custo por token muito menor. Deixem-me explicar melhor a questão dos modelos open-weight. Eles agora são fortes o bastante para esses tipos de workflows agentic reais. Aqui, demos exatamente a mesma tarefa — criar um jogo de tower defense com um agent de programação — para dois modelos. À esquerda está o GLM 5.2, um modelo open-weight

02:22 rodando na FriendliAI. À direita está o Opus 4.8 da Anthropic. O importante não é que os resultados sejam idênticos. O importante é que ambos concluem a tarefa em um nível claramente útil para muitos workflows agentic. Os modelos open-weight ultrapassaram o patamar de qualidade, mas a economia é muito diferente para a mesma tarefa. O Opus 4.8 custou cerca de

02:53 US$ 1,50; o GLM 5.2 na FriendliAI custou 27 centavos, cerca de 5,6 vezes menos. Essa é a promessa que mencionei antes: os modelos open-weight oferecem agents de qualidade de ponta por uma fração do custo. Mas o custo do modelo é apenas uma parte da história. Para que um agent seja realmente rápido e confiável, a própria stack de inference precisa mudar. Então, vamos ver o que

03:23 realmente acontece dentro de uma workload agentic. Primeiro, vamos observar as mudanças na workload. No passado, o uso predominante era o chat. A unidade básica era uma solicitação: uma pessoa faz uma pergunta, o modelo responde e a pessoa lê a resposta. Latência significava: quanto tempo levei para receber uma resposta? Os agents são diferentes. A unidade básica é uma tarefa. Uma tarefa pode envolver muitas chamadas ao modelo, muitas chamadas a ferramentas e pode ser executada autonomamente por algum tempo.

03:58 Assim, o usuário não se importa tanto com a latência de uma solicitação individual. Ele se importa com quando a tarefa inteira será concluída. Isso significa que precisamos otimizar para tarefas, não apenas para solicitações individuais. Vamos examinar os workflows de agents mais de perto. Um agent executa uma sessão composta por tarefas. Cada tarefa normalmente é executada em um loop. Primeiro, ele planeja, o que geralmente significa uma chamada de LLM. Depois, age, talvez chamando uma ferramenta. Em seguida,

04:33 observa o resultado, adiciona isso ao contexto e repete o processo até concluir a tarefa. Portanto, alternamos constantemente entre inference de LLM e uma ou mais execuções de ferramentas que não são de LLM. Assim, há um intervalo entre as chamadas de LLM. Um agent também pode criar subagents e executá-los em paralelo. As entradas dos agents também são muito diferentes das do chat. O gráfico mostra a

05:05 distribuição dos tamanhos de prompt e de conclusão das execuções do nosso agent de programação interno com o GLM 5.2, que usamos no dia a dia. Elas são muito mais longas. Crescem conforme a tarefa avança, porque cada observação é acrescentada ao contexto. Há um padrão importante aqui: etapas consecutivas de um agent geralmente compartilham um prefixo enorme. Se recalcularmos o mesmo prefixo toda vez, desperdiçamos muito poder computacional em trabalho que já fizemos.

05:40 Essa é uma das maiores oportunidades em inference agentic. Então, quantos tokens os agents consomem? Agora, vejamos um exemplo de tarefa de longo horizonte, como uma pesquisa aprofundada. Usamos o GLM 5.2 na FriendliAI para explicar, com código, a especificação do framework de decodificação especulativa em VLM. Há várias etapas, e cada uma é composta de subagents que executam múltiplas inferências e chamadas a ferramentas. Portanto, a execução pode envolver dezenas ou até centenas de

06:16 etapas de inference, às vezes ao longo de minutos ou até horas, e o contexto compartilhado continua crescendo durante todo esse tempo. Para o usuário, o que importa não é a latência de um único token ou de uma chamada. O que importa é: quando minha tarefa será concluída? Portanto, inference para agents não é apenas chat com mais solicitações. É um problema diferente. O contexto cresce com o tempo. O trabalho é intercalado entre chamadas ao modelo. O

06:47 número de chamadas ao modelo depende da entrada. Portanto, não dá para planejar com base em um plano de taxa fixa de solicitações. E a métrica real é a latência da tarefa de ponta a ponta, não a latência de uma única solicitação. É aqui que a FriendliAI entra. Reconstruímos a nuvem de inference de ponta especificamente para agents, com foco nos desafios que acabei de apresentar, e definimos um objetivo: otimizar a latência de ponta a ponta da tarefa, não apenas da solicitação. Então, como

07:21 fazemos isso? Deixem-me mostrar a engenharia principal por trás dessa abordagem. Este é o mapa de engenharia de como pensamos sobre o problema. Construímos a stack camada por camada em torno dos workflows de agents. Há quatro grandes pilares que vou abordar hoje: cache de prefixo, cache de chave-valor — em resumo, cache KV —, gerenciamento de cache, roteamento sensível ao cache e otimização sensível a agents. E, claro, por baixo de tudo isso, precisamos de otimizações na camada do modelo, como atenção esparsa

07:54 para contextos longos, técnicas para reduzir erros, kernels rápidos, serving resiliente e muito mais. Nesta apresentação, vou me concentrar nos quatro pilares. Vamos começar pelo cache de prefixo. Como as etapas dos agents compartilham um prefixo extenso, calculamos os valores de chave e valor desse prefixo uma vez e os armazenamos em cache. Depois, nas etapas seguintes, reutilizamos os valores de chave e valor em cache e processamos apenas o sufixo novo. Ler do cache é muito mais barato do que recalcular o prefill. Isso

08:28 melhora o time to first token e reduz o custo computacional em cada etapa. E, quanto mais tempo a tarefa dos agents é executada, mais valioso isso se torna. Mas o cache só funciona se o cache KV realmente couber e puder ser movimentado com eficiência. Por isso, precisamos de um gerenciamento robusto do cache KV. Usamos gerenciamento eficiente de memória para acomodar mais contexto ativo na memória de cada GPU. Usamos

09:01 contiguidade do cache KV para reduzir o consumo de memória. Também usamos cache hierárquico entre a memória da GPU, a memória do host e os discos, para podermos ir além dos limites da GPU. E também usamos cache distribuído. Assim, um prefixo pode ser disponibilizado entre réplicas, não apenas dentro de uma instância. Na escala de um cluster global, o roteamento se torna muito importante. Um balanceador de carga simples

09:31 pode distribuir as solicitações igualmente entre clusters de GPU, mas pode destruir a localidade do cache. Um roteador sensível ao cache, em escala global, faz algo mais inteligente. Ele envia uma solicitação para a instância que já tem o prefixo correto em cache, transformando um prefill caro em uma leitura do cache. Ao mesmo tempo, ainda precisa balancear a carga para que uma instância não se torne um ponto de sobrecarga. Neste exemplo, as duas solicitações da tarefa A vão para a mesma instância, para preservar a localidade do cache.

10:04 O próximo ponto é a otimização sensível a agents. E essa é a próxima fronteira da inference agentic. Hoje, a maioria dos sistemas agenda cada chamada de LLM como se fosse independente. Eles não entendem de verdade que essa chamada faz parte de um programa mais longo de um agent. Mas, se o otimizador conhecer o contexto do agent, podemos tomar decisões melhores. Por exemplo, preemptar o

10:35 trabalho certo, fazer o prefill especulativo do contexto para uma próxima etapa improvável ou tomar uma decisão melhor sobre a remoção de itens do cache com base no contexto do agent. O objetivo é reduzir a latência da tarefa, não apenas fazer uma chamada parecer rápida. Quando juntamos tudo isso, esse é o resultado. Usamos o mesmo modelo, GLM 5.2, com o Kilo Code para criar um jogo simples para dispositivos móveis. Executamos a mesma tarefa

11:09 com as APIs de modelo da FriendliAI e de outro provedor de inference conhecido. Como podem ver, a FriendliAI conclui a mesma tarefa de ponta a ponta graças ao nosso design de nuvem centrado em agents. Então, o que isso possibilita na prática? Uma stack de agents de produção mais robusta. Escolha um agent de que você já goste. Agora, conecte a ele modelos open-weight de ponta, como o GLM

11:39 5.2, Minimax e Kimi são servidos na FriendliAI. O modelo oferece recursos de qualidade de ponta e custos menores. A FriendliAI oferece a velocidade, a confiabilidade e o desempenho em testes de ponta a ponta necessários em produção. Essa combinação de qualidade, velocidade, confiabilidade e custo é o que torna os agents realmente úteis e econômicos em produção. Atualmente, a FriendliAI é usada por equipes em produção, desde startups nativas de IA até

12:14 empresas globais. Gostaria de destacar algumas. A Kilo é uma ferramenta de programação com IA agentic muito popular, que atende milhões de usuários. A LG é uma empresa global cujos negócios vão de eletrônicos a saúde e energia. São empresas muito diferentes, mas todas precisam da mesma coisa: inference agentic rápida, confiável e econômica.

12:45 Este depoimento do nosso cliente Kilo diz tudo. No último ano, a Kilo Code testou vários provedores de inference que hospedam modelos open e fechados. Em um teste comparativo do uso do GLM5 com outros provedores terceirizados e com o uso direto do laboratório do modelo G.A.I., a FriendliAI foi consistentemente sete vezes mais rápida, com uma taxa de erro significativamente menor. Hoje, a FriendliAI é um componente central da stack da Kilo.

13:20 E você pode usar o serviço da forma que melhor se encaixar na sua stack. A API de modelos é a maneira mais rápida de começar: modelos open weight de ponta por meio da nossa API serverless. Endpoints dedicados oferecem uma implantação isolada só sua, com SLAs garantidos para cargas de trabalho de produção. E o BYOG, traga sua própria GPU, permite executar a inference da FriendliAI na sua própria infraestrutura. A mesma stack, três maneiras de fazer o deploy. Para concluir, há três coisas a lembrar. Primeiro, modelos open weight de ponta

13:54 tornam os agents de produção escaláveis em termos econômicos. Segundo, agents não são apenas chats com mais recursos. A inference agentic exige otimizar a latência da tarefa de ponta a ponta, considerando os desafios que mencionei. Terceiro, a FriendliAI foi criada como uma nuvem de inference para esse mundo: inference agentic rápida, confiável e econômica. Obrigado por participarem da minha sessão. Se vocês estão desenvolvendo agents, experimentem modelos open weight de ponta na FriendliAI hoje.

14:28 Vocês podem começar em minutos em friendly.ai. E obrigado. Estarei por aqui depois da sessão. Obrigado. >> [aplausos] [música]

Transcrição original

[00:13] Let’s uh get started. Uh hi everyone. Thank you for coming. Uh this is the late afternoon in the last day. Um so I really appre appreciate it. I’m gone, founder and CEO of friendly AI. Today I want to talk about agentic inference. So I’ll first walk through what changed uh why it matters and how we rebuilt the inference cloud for agents. Before we go deeper let me briefly

[00:43] introduce friendly AI. Friendly AI is the frontier AI inference cloud for agents. So we run inference for agents at scale faster, cheaper and more reliably. We are born from a research team at S National University and those research roots still define us. We are the team that invented continuous batching. The inference optimization that is now standard across the industry and our orca work inspired 3LM a widely used open source framework.

[01:16] Today we operate globally headquartered in San Francisco with a team in soul to scale frontier inference. As you know 2026 is a year agents go into massive production and it’s driven by two trends coming together. First agents are going exponential. AI agents are driving explosive adoption across software operations and knowledge work. Second, open rate motors have reached the frontier and make agents economic.

[01:51] They now rival closed frontier motors in capability, which means you can run frontier quality agents on open motors with much lower token cost. Let me make the openweight motor part concrete. Open weight motors are now strong enough for these types of real agentic workflows. Here we gave the exact same task building a tower defense game with a coding agent to two models. On the left is GLM 5.2 an openw rate motor

[02:22] running on friendly AI. On the right is anthropics opus 4.8. The important point is not that the outputs are identical. The point is that both complete the task at a level that is clearly usable for many agentic workflows. Open weight models have crossed the quality threshold but the economics are very different for the same task. Opus 4.8 cost about a

[02:53] $150 GLM 5.2 unfriendly AI cost 27 cents about 5.6 times cheaper. So this is the promise I mentioned earlier. Open rate models give you frontier quality agents at a fraction of cost. But motor cost is only one part of the story. To make agent actually fast and reliable, the inference stack itself has to change. So let’s look at what

[03:23] actually happens inside an agentic workload. So first let’s look at changes in the workload. In the past the dominant usage was chat. The basic unit was a request. A person asks a question, the model answers and the person reads it. Latency meant how fast did I get one response. Agents are different. The basic unit is a task. A task may involve many model cores, many tool cores and it may run autonomously for a while.

[03:58] So the user does not really care about the latency of one individual request. The user cares about when the whole task is completed. That means we have to optimize for tasks, not just individual requests. Let’s look at agent workflows more closely. An agent really runs a session made up of tasks. Each task typically runs in a loop. First, it plans, which usually means an LLM call. Then, it acts maybe by calling a tool. Then it

[04:33] observes the result and adds the that back into the context and it repeats this until the task is done. So we are constantly alternating between LLM inference and one or more nonLM tool executions. So there is a gap between LLM calls. An agent can also create sub agents and run them in parallel. Agent inputs also look very different from chat. The graph here shows the

[05:05] prompt and completion length distributions of our internal coding agent runs with GLM 5.2 which we use day-to-day. They are much longer. They grow as the task progresses since every observation gets appended back into the context. There’s an important pattern here. Consecutive agent steps usually share a huge prefix. If we recomp compute the same prefix every time, we are burning a lot of compute on work we already did.

[05:40] So this is one of the biggest opportunities in agentic inference. So how token hungry are agents? Now let’s look at a long horizon task example like deep research. We ran explained the spec decoding framework in VLM using code with GLM 5.2 unfriendly AI. There are multiple stages and each stage is composed of sub agents which run multiple inferences and tool cores. So it might run tens or even hundreds of

[06:16] inference steps sometimes over minutes or hours and the shared context keeps going the whole time. For the user what matters is not the latency of a single token or one core. What matters is when is my test completed. So agent inference is not just chat with more requests. It’s a different problem. The context grows over time. Tour work is interled between model cores. The

[06:47] number of model cores depends on the input. So you can’t really plan around a fixed request rate plan. And the real metric is end to end test latency, not a single request latency. This is where friendly AI comes in. We rebuilt the frontier inference cloud specifically for agentic goal close around the challenges I just walked through and we set one goal optimize end to end test latency the task not just the request. So how do

[07:21] we do that? Let me show you the key engineering behind it. Here’s the engineering map for how we think about it. We built the stack layer by layer around agent workflows. There are four big pillars I’m going to cover today. Prefix caching key value in short KB cache management, cash aware routing, agent aware optimization and of course underneath we need model layer optimization like sparse attention

[07:54] for long context techniques to reduce errors, fast corners, resilience serving and more. In this talk, I’m going to focus on the four pillars. Let’s start with prefix caching. Since Asian steps share a large prefix, we compute key value for that prefix once and cache it. Then on later steps, we reuse the cache key value and only process the new suffix. Reading from cache is much cheaper than recmp computing prefill. So this

[08:28] improves time to first token and reduces compute on every step. And the longer the task runs in agents, the more valuable this becomes. But caching only works if the KV cache actually fits and can move around efficiently. So we need strong KV cache management. We use frugal memory management to pack more active context onto each GPU memory. We use KB

[09:01] contigation to reduce the memory footprint. We you we use hierarchical caching across GPU memory, host memory and disks. So we can go beyond GPU limits. And we also use distributed caching. So one prefix can be served across replicas, not just inside one instance. At global cluster scale, routing becomes really important. A knife load balancer

[09:31] may spread requests evenly across GPU clusters, but it can destroy cache locality. A cache aware router at a global scale does something smarter. It sends a request to part that already has the right prefix cached turning a cord prefill into one cache ship. At the same time, it still has to balance load. So one part doesn’t become a hot spot. In this example, the two requests of task A go to the same part one for cache

[10:04] locality. The next piece is agent aware optimization. And this is the next fronture of agentic inference. Today, most systems schedule each LLM core as if it were independent. They don’t really understand that this core is part of a longer agent program. But if the optimizer knows the agent level context, we can make better decisions. For example, preempting the

[10:35] right work, speculatively prefilling context for an unlikely next step or making a better cache eviction decision based on agent level context. So the goal is to reduce ant latency not just make one call look fast. When we put all of this together, this is the payoff. We are using the same model GLM 5.2 with kilo code to create a simple mobile game. We ran the same task

[11:09] with model APIs of friendly AI and another well-known inference provider. As you can see, friendly completes the same task end to end tox thanks to our Asenticentric cloud design. So what does this unlock in practice? a stronger production agent stack. Take an agent you already like. Now plug in openweight frontier models like GLM

[11:39] 5.2, Minimax and Kimi served on friendly AI. The motor gives you frontier quality capability and better economics. Friendly AI gives you the speed, reliability and endtoend test performance needed in production. That combination, quality, speed, reliability, and cost is what makes agents actually useful and economical in production. Friendly AI is currently powering teams in production from AI native startups to

[12:14] global enterprises. I’d like to highlight a couple here. Hilo is a hugely popular Asantic AI coding tool serving millions of users. LG is a global enterprise whose businesses range from electronics to healthcare to energy. Very different companies, but they all need the same thing. Fast, reliable, cost effective agentic inference.

[12:45] This testimonial from our client Kilo says it all. Over the past year, Kilo Code has tested several inference providers hosting both open and closed models. In a split test of GLM5 usage compared against other thirdparty providers and direct usage from the model lab G.A.I., Friendly AI was consistently seven times faster with a significantly lower error rate. Today, friendly AI is a core component of the killer stack.

[13:20] And you can consume this however fits your stack. Model API is the fastest way to start. Core frontier open weight models through our serless API. Dedicated endpoints give you your own isolated deployment with guaranteed SLAs’s for production workloads. And BYOG bring your own GPU lets you run friendly inference on your own infrastructure. Same stack, three ways to deploy. To wrap up, there are three things to remember. First, frontier open weight

[13:54] models make production agents economically scalable. Second, agents are not just chat with more cores. Agentic inference requires optimizing end to end task latency with the challenges I mentioned. Third, friendly AI is built as an inference cloud for that word. Fast, reliable, cost effective agentic inference. Thank you for attending my session. If you’re building agents, give uh frontier

[14:28] openweight motors a try on friendly today. You can get started at friendly.ai in minutes. And uh thank you. I’ll be around after the session. Um thank you. >> [applause] [music]