A conta de IA está alta demais: Tokenomics 101 — Eugene Cheah, Featherless AI

Ver no idioma original →

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 AI Bill Is Too Damn High: Tokenomics 101 — Eugene Cheah, Featherless AI · Canal: AI Engineer · 54:57 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Inferência e otimização de modelos, Modelos de IA, Modelos locais e open source

Resumo

Eugene Cheah apresenta estratégias para controlar os custos de tokens em organizações, começando pela medição detalhada do uso por equipe e caso de uso. Ele recomenda escolher modelos e velocidades adequados a cada tarefa, avaliar modelos menores e considerar fine-tuning quando o volume justificar. Também explica como equilibrar velocidade, throughput e custo ao comprar capacidade de inferência. Por fim, alerta que mais tokens e mais agentes não significam necessariamente mais produtividade: é preciso melhorar processos, validação e responsabilização pelo conteúdo gerado.

Pontos-chave

• Meça o gasto com tokens por departamento, equipe e caso de uso antes de tentar otimizar custos.
• Diferencie cargas de trabalho agênticas, geralmente longas e intensivas em contexto, de processos automatizados, que costumam ser tarefas isoladas e de alto volume.
• Atribua modelos conforme a tarefa: modelos mais capazes para planejamento e revisão, e opções mais rápidas e baratas para implementação e tarefas repetitivas.
• Use evals e casos de teste para encontrar o modelo mais barato que atenda aos requisitos, em vez de presumir que o menor modelo é suficiente.
• Classificadores e modelos especializados podem reduzir custos em tarefas de decisão e classificação.
• Considere fine-tuning para tarefas de domínio e alto volume; dados de referência de qualidade e evals ajudam a orientar o processo.
• Velocidade por solicitação e custo não escalam linearmente: aumentar o processamento em paralelo pode elevar o throughput e reduzir o custo por token.
• Use capacidade dedicada para a carga de base e avalie encaminhar picos para capacidade sob demanda, quando apropriado.
• Tokens gastos não equivalem a trabalho concluído; mais agentes podem duplicar tarefas e aumentar a carga de revisão.
• Responsabilize as pessoas pelo material gerado e avalie resultados, testes e processos, não apenas o uso de IA.

Capítulos

Início	Capítulo	Resumo
00:01	Apresentação e contexto	Eugene Cheah apresenta a Featherless AI, sua experiência com modelos abertos e o foco da conversa em custos de tokens.
04:39	Tipos de carga de trabalho e escala	O palestrante diferencia cargas agênticas de automações de processo e ilustra como o uso pode crescer rapidamente.
09:18	Medição e escolha de modelos	A conversa passa da medição para o right-sizing e aborda a aproximação entre modelos abertos e fechados.
12:54	Modelos de classificação e economia agêntica	O palestrante discute classificadores e explica por que cargas agênticas tendem a repetir muitos tokens de entrada.
17:38	Modelos por equipe e por tarefa	São apresentados exemplos de alocação de velocidade por prioridade e de nomes de modelos adaptados a cada departamento.
20:44	Evals e redução de custos em processos	Para automações de alto volume, o palestrante recomenda testar modelos, encontrar opções menores e identificar tarefas classificáveis.
23:21	Fine-tuning e dados de treinamento	A palestra explora quando especializar modelos, como gerar dados e como encaminhar tarefas entre modelos de tamanhos diferentes.
28:33	Velocidade, throughput e custo	O palestrante explica as trocas entre tokens por segundo, paralelismo, capacidade de GPU e custo de inferência.
34:18	Revisão dos processos e produtividade	A discussão alerta que o crescimento do gasto com tokens pode não se traduzir em produtividade e que processos podem virar gargalos.
39:29	Conteúdo gerado e responsabilidade	Exemplos de código e apresentações mostram como a geração em massa pode transferir o trabalho de verificação para outras pessoas.
44:39	Perguntas sobre fine-tuning e evals	Na sessão de perguntas, Cheah comenta métodos de fine-tuning, prompt tuning, conjuntos de dados de referência e evals.
49:49	Migração de Claude Code e harnesses	A conversa aborda a dependência do Claude Code e caminhos para experimentar outros agent harnesses e dividir planejamento e implementação.
52:25	Cache e roteamento automático	O palestrante comenta caches dedicados e recomenda cautela com roteamento por turno para não reduzir a eficiência do cache.
53:56	Roteamento por tarefa e encerramento	Cheah favorece o roteamento por tarefa e por organização e encerra a sessão convidando o público a conversar.

Citações

Se você não está medindo, pode praticamente ignorar todo o resto que eu disser e começar pela medição. — 09:18

Em geral, você só quer pagar pela velocidade de tokens por segundo quando há alguém esperando. — 31:42

Tokens não são trabalho concluído. — 36:53

As pessoas devem ser responsáveis pelo que entregam ou geram. — 42:35

Conceitos e entidades

• Tokenomics (conceito): Refere-se à gestão do uso de tokens, dos custos de inferência e da capacidade de modelos em uma organização.
• Featherless AI (empresa): Empresa apresentada por Eugene Cheah como provedora de inferência e plataforma para modelos abertos.
• Eugene Cheah (pessoa): Fundador e CEO da Featherless AI, que apresenta estratégias de otimização de custos de IA.
• DeepSeek V4 (modelo): Modelo citado como uma opção popular em diferentes cargas de trabalho.
• Qwen 27B (modelo): Modelo mencionado como base para experimentos de prompt tuning e fine-tuning em tarefas de classificação.
• Claude Code (ferramenta): Ferramenta de programação citada como exemplo de forte dependência de um ecossistema específico.
• Pi (ferramenta): Agent harness de programação citado como alternativa leve e adaptável para experimentação com modelos.
• Hugging Face (empresa): Plataforma mencionada como lugar para baixar modelos e consultar benchmarks.
• Cerebras (empresa): Empresa citada como provedora de capacidade voltada a alta velocidade de geração de tokens.
• AT&T (empresa): Empresa mencionada como exemplo de uso de modelos fine-tuned menores em aplicações de alto volume.
• Shopify (empresa): Empresa citada como exemplo de fine-tuning para uma tarefa ligada à linguagem proprietária de configuração de lojas.
• Google Gemini (modelo): Família de modelos citada como opção para gerar dados de treinamento, observadas as condições de uso aplicáveis.
• MCP (conceito): Protocolo mencionado na discussão sobre integrar agentes, com a ressalva de que o acesso ao sistema de arquivos depende da configuração.
• simple JAF (repo): Projeto open source citado como implementação que replica uma API de classificação usando modelos abertos.

Tradução completa (pt-BR)

00:01 [música] >> Obrigado a todos por virem aqui. Não sei bem se fico feliz ou triste por tanta gente estar sofrendo com a conta de tokens. A oficina está lotada. Vamos falar sobre tokenomics. Para começar, um pouco de contexto, certo? Sou Eugene, da Featherless AI. Sou CEO e fundador da empresa. E faço parte da equipe por trás do

00:32 projeto de IA árabe open source, o primeiro modelo de IA sob a Linux Foundation. E trabalhamos em arquiteturas de IA de próxima geração. Esse é um pouco do meu histórico acadêmico. Meu perfil no Twitter é PicoCreator. Mas, mais importante, um pouco sobre a Featherless AI: nossa missão é tornar a IA acessível a todos, em todos os idiomas, dialetos e países. Fazemos isso criando a maior plataforma de modelos abertos do mundo, com mais de 40 mil modelos abertos. Isso inclui fine-tunes especializados, como o modelo Sunflower,

01:03 o primeiro modelo de linguagem de Uganda, feito especificamente para o idioma do país, além de muitos outros modelos especializados. Portanto, não estamos falando apenas do maior modelo open source, mas também de modelos de linguagem especializados ou voltados para casos de uso específicos — alguns deles também vou abordar. E, além de oferecer uma grande variedade de modelos em escala, a Featherless AI também atende clientes em escala. Alguns dos nossos maiores clientes servem literalmente 2 trilhões de tokens por dia. E eles servem esses tokens por cerca de US$ 0,30 por milhão de tokens, ou

01:33 US$ 60 mil por dia. Eles fazem isso com cerca de 512 GPUs AMD MI215. Para esse cliente em particular, trata-se de um modelo privado 400 Android BM OE. E ele oferece desempenho da classe Opus 4.8. São muitas solicitações simultâneas e um grande volume de tokens. É isso que queremos dizer com escala. E, se você olhar para isso, US$ 0,03 por milhão de tokens, com desempenho da classe 4.8, não é algo que você consiga encontrar no mercado de nuvem pública.

02:04 São configurações muito especializadas, projetadas para operar na escala de que estamos falando. Isso leva a dois avisos importantes com que vou começar. Primeiro, vendemos inference. Portanto, tudo o que vou abordar se aplica a qualquer provedor. Nada aqui é específico da Featherless. Mas, para deixar claro, vendemos inference. Então, isso também se baseia nos nossos dados e, respectivamente, na nossa experiência. Certo? O outro ponto é que

02:35 esta oficina vai abordar muita otimização em escala e provavelmente não será adequada para você se sua organização gasta menos de US$ 10 mil por mês. Meu conselho para quem está abaixo desse limite — e é um limite arbitrário — é que, se você gasta menos do que isso, provavelmente vale mais a pena se concentrar em encontrar casos de uso sólidos para sua organização, em vez de tentar otimizar a conta de tokens. Um caso de uso sólido pode trazer muito mais de US$ 10 mil por mês para sua organização. E esse deveria ser

03:06 seu principal foco, mas não é o foco da minha palestra. Nesta oficina, vamos abordar quatro etapas principais, nesta ordem: medir, ajustar o tamanho, decidir como comprar capacidade e verificar o processo. Então, medir. Sim. Você vai se surpreender com o quanto isso é essencial. Quantos de vocês sabem quanto gastam no total com tokens? Podem levantar a mão?

03:37 Uau, só metade da sala levantou a mão. Certo. Quantos de vocês conseguem medir isso por departamento? Quem está com a mão levantada, mantenha-a no alto. Estou vendo que mais ou menos metade baixou a mão. Sim. E o número vai diminuindo cada vez mais quando chegamos ao nível da equipe e ao nível do caso de uso. É fácil encontrar 30% ou 40% dos nossos clientes que nos procuram usando, de início, uma única chave compartilhada por toda a organização. E aí fica: como é que vamos medir isso? Como

04:07 começamos? Isso não depende de um fornecedor específico: vocês precisam começar a separar as chaves, por departamento e por principais casos de uso, para saber onde estão todos os tokens. A partir daí, isso pode orientar suas cargas de trabalho. As chaves de API não deveriam ser tão difíceis de emitir. Depois que você souber disso, pode começar a ajustar as coisas, respectivamente. Por exemplo: em que as equipes estão gastando? Em quais cargas de trabalho? O que a pessoa estava esperando? Algumas equipes precisam de tokens por segundo. Alguns

04:39 agents em segundo plano rodando à meia-noite provavelmente não precisam da velocidade de tokens por segundo pela qual você está pagando. Não pague pelo plano Ultra para um agent em segundo plano. Isso é simplesmente uma bobagem. E, com base nisso, você também pode analisar seu uso para orientar melhor a compra de capacidade dedicada, seja para modelos abertos ou até para modelos fechados. Também pode verificar quais equipes gastam mais tokens e se estão sendo produtivas. Vou falar disso também. Uma das coisas que você precisa saber

05:11 sobre cargas de trabalho de IA — e vocês talvez já tenham percebido — é que há duas grandes categorias, com economias muito diferentes. Uma delas são as cargas de trabalho agentic. É claro que há coisas intermediárias, como agents multitenant de longa duração. Agents de programação são um exemplo específico disso. Alguns desenvolvedores podem deixar agents de programação rodando literalmente durante a noite, por longos períodos e com várias compactações. Esses casos maximizam o uso do contexto. A outra categoria extrema é a automação de processos.

05:43 Pense em centrais de atendimento, encaminhamento de e-mails, transcrição de atas de reunião e coisas do tipo. Em geral, o contexto é bem mais curto, embora haja muitos exemplos que contradizem essa afirmação. Mas são processos muito bem definidos, tarefas bem isoladas e, essencialmente, um jogo de volume. Então, o que quero dizer com mais uso? Essa é provavelmente uma das primeiras grandes explosões que muitas organizações enfrentam, especialmente quando entram na onda da nuvem aberta ou de um dos clones de nuvem.

06:14 Por exemplo, entre várias equipes de desenvolvimento que apoiamos, analisamos uma equipe com apenas cinco desenvolvedores que mantinha, em média, oito agents rodando continuamente, em uma das empresas com que trabalhamos. Eles usavam a API do Opus 4.8 e gastavam basicamente US$ 150 mil por mês mantendo esses agents em execução contínua. Alguns eram agents que eles usavam para programar; outros eram ativados à noite. Eram um pouco mais avançados. Já sabiam que deveriam

06:44 iniciar algumas tarefas à noite, quando ninguém estivesse trabalhando. Mas, essencialmente, gastavam 116 bilhões de tokens por mês. Nós os ajudamos a mudar literalmente para uma instância GRM 5.3. Antes, era a versão 5.2; eles já haviam atualizado para a 5.3. E isso rodava em um único nó. Custava menos de US$ 10 mil por mês. E eles não perceberam nenhuma interrupção ou impacto. Portanto, conhecer sua equipe permite tomar essas decisões. E, como destaquei, conhecer os processos e as cargas de trabalho também permite separar as tarefas. Por exemplo,

07:15 antes, eles deixavam tudo rodando ao longo do dia, mas começaram a programar alguns agents em segundo plano para quando a equipe estivesse dormindo, deixando-os rodar durante a noite. Isso permite aproveitar melhor o hardware. Como mencionei brevemente, o outro lado da automação de processos é simplesmente um jogo de volume. É extremamente predefinido. Posso dar um exemplo mais específico, fora da gravação, mas pense em milhões por dia, ou até dezenas de milhões por dia, de decisões em centrais de atendimento.

07:46 centros, linhas de código analisadas, e-mails e mensagens de texto filtrados. Uma das empresas de telecomunicações com que trabalhamos chega facilmente ao pico de 10 milhões de mensagens em um único minuto. E isso não deveria ser uma surpresa. Feliz Ano-Novo é a pior época. É. Então, essas… E elas ajudam… E o motivo de filtrarem mensagens é que oferecem um recurso para disponibilizar um telefone seguro para crianças. Então precisavam de uma IA para analisar, basicamente, se há palavrões, conteúdo sexual etc. Então, isso realmente não é um contexto longo…

08:17 mas é um jogo de volume. Outras coisas, como processos de conferência entre criador e revisor, processos de aprovação e processamento de documentos. Tudo isso é um jogo de volume para várias organizações. Então, suspeito que, para as instituições financeiras aqui, já que estamos em Nova York, muitos OCRs, muitos documentos, muitas aprovações e muitos riscos de transação se enquadrem nessa categoria. Certo. Então, sim. Se você ainda não está acompanhando seus gastos com tokens e a divisão do uso de tokens, estamos disponibilizando como open source uma ferramenta de acompanhamento de tokenomics, que é…

08:48 só um jeito muito sofisticado de dividir sua chave de API e acompanhar quanto cada chave de API gasta, algo separado desta palestra. Sim. Então, se quiser atualizar de novo, fique à vontade para escanear este QR code e, respectivamente… Além disso, se quiser os slides desta palestra e ser avisado quando a gravação for publicada pela AI Engineering, você também pode preencher o formulário ali. Certo. Certo. Certo. Então, sim. Isso foi sobre medição. Sim. Se você não está medindo, pode…

09:18 praticamente ignorar todo o resto que eu disser e começar medindo, porque seu maior ROI vem simplesmente de medir. Mas, depois que você tiver medido as coisas, a pergunta é: como dimensioná-las corretamente? É aí que as coisas ficam mais complicadas. Em geral, uma das coisas que começamos a observar conforme a IA é implantada em escala dentro das organizações é um padrão: como a IA é o martelo novo e brilhante, tentamos aplicá-la a tudo. Especialmente nos…

09:50 laboratórios de inovação, tentamos aplicá-la a qualquer coisa. E tendemos — já vi organizações aplicarem literalmente fábulas às coisas mais bobas. Então, há muitos modelos, e muitos deles são realmente caros. Descobrir o que fazer e onde se encaixam é uma etapa importante do processo. Sei que modelos abertos — muitos de vocês provavelmente já ouviram falar de modelos abertos — fazem parte do nosso negócio.

10:20 E, por isso, muitas empresas nos procuram, por exemplo, para encontrar modelos abertos adequados aos seus casos de uso e que possam substituir diretamente os modelos atuais. Em geral, orientamos essas empresas com base nos casos de uso delas. Essas são regras gerais que provavelmente serão atualizadas mês a mês, porque modelos abertos são lançados a cada poucos meses, e o mesmo vale para modelos de código fechado. As coisas mudam rapidamente. Mas o que achamos empolgante é que, neste ano, as coisas começaram a mudar. No ano anterior…

10:51 o melhor modelo de código fechado era, sem dúvida, melhor do que o melhor modelo open source. Quase. Mas, com a chegada deste ano, estamos começando a ver essa diferença diminuir. Estamos começando a ver situações em que alguns modelos abertos já estão no mesmo nível ou até superam os outros. Por exemplo, antes do lançamento da atualização do Opus 5.5, o Kimi K3 estava superando o Opus em design de interface do usuário em alguns benchmarks de interface. E esses são benchmarks muito…

11:21 públicos. Nos benchmarks de clientes, já começávamos a ver modelos open source superarem modelos em benchmarks muito especializados, em casos de uso específicos. Um caso particular que vale destacar é o modelo step one five, por exemplo. Ele conseguiu chegar perto da qualidade do Opus e do Extra, apesar de ser um modelo 10 vezes menor, em benchmarks financeiros e casos de uso financeiros. É o melhor modelo de programação? Não. Mas, nesse caso de uso, ele é extremamente forte e competente. Então, o cenário está mudando aos poucos…

11:52 e você pode ter substitutos diretos para muitos casos de uso que, às vezes, custam até 10 vezes menos, respectivamente, se você conhecer sua carga de trabalho e puder substituí-los diretamente. Uma menção especial também para DeepSeek-V4 e Flash. Por algum motivo, esse modelo é extremamente popular em todos os tipos de carga de trabalho, respectivamente, porque é fácil de usar com prompts para muitas empresas. Quanto aos outros modelos que listei ali, eles são boas opções padrão em suas categorias.

12:22 DeepSeek-V4 e Flash parecem ser bastante populares, independentemente do caso. Sim. Embora a pontuação nos benchmarks não pareça justificar por que são tão populares. Sim. Outra coisa que vale destacar é que, há algumas semanas, foi introduzida uma nova classe de modelos de IA, chamada classificadores one-shot, mais conhecida como JAF. Projetos open source já começaram a ganhar força, como o Simple JAF. E esses são modelos inteiramente…

12:54 voltados apenas a tomar decisões e classificar tarefas. A principal vantagem é que, tecnicamente, eles costumam ser 10 vezes mais baratos do que os modelos existentes, ou até mais rápidos. A desvantagem é que não conseguem dar uma resposta em formato de chat. Então, essas são coisas que estão mudando e acontecendo, e que talvez vocês queiram começar a analisar em segmentos de como melhorar sua economia de tokens. Sim. Mas, voltando à parte da economia de tokens, há…

13:27 dois caminhos principais, e é importante separá-los e acompanhar cada um. No lado agentic, estamos falando de tarefas de longa duração e contextos longos, como mencionei antes. E é preciso entender que essa carga de trabalho tende a consumir muito cache, a usar muito a entrada e o cache, e a ter apenas uma pequena porcentagem de saída. Nas aplicações agentic que vemos em produção, apenas 1% das requisições corresponde a tokens de saída. E isso é muito…

14:00 lógico, porque são várias rodadas, repetidas continuamente. Mas isso também determina o custo dos tokens, porque, como vocês já devem ter visto, no custo de implantação a saída pode ter o maior valor. Mas, mesmo que o valor da entrada ou do cache seja bem menor, ele é repetido muitas vezes nesse caso de uso. Sim. Esta não é uma oficina sobre agentes de programação, mas um dos padrões mais comuns que vemos em muitas organizações, ao tentarem…

14:32 escalar a implantação de agentes de IA nas equipes de programação, é usar o melhor agente para fazer o planejamento, um agente mais rápido e barato para a implementação e, talvez, o melhor agente novamente para a revisão. Há um bom motivo para essa divisão ser tão comum em todos os frameworks de agentes: você obtém o melhor dos dois mundos, porque a fase de implementação tende a consumir muitos tokens. Há muitos processos repetidos de ida e volta, como modificar o arquivo, testar, verificar os resultados e repetir.

15:02 E a maioria desses agentes — especialmente o Gemini 5.3 Flash — é mais do que capaz de realizar uma tarefa com a mesma qualidade que um agente muito mais forte, como Astra ou Opus, supondo que esses agentes façam o planejamento. Trabalhamos com algumas organizações em que, literalmente, o agente de planejamento e revisão é o melhor modelo de fronteira de código fechado, enquanto os agentes que implementam são o GRM 5.3 Flash, por exemplo, ou o Deep Seek 4.1 Flash. Sim. Uma das observações que fizemos com esse tipo de divisão é que, infelizmente, por mais que desejemos que todos façam isso, ninguém realmente troca de modelo para economizar dinheiro para a empresa. As pessoas têm preguiça de trocar de modelo, em geral. É preciso dar um incentivo para que troquem. Ou, alternativamente, se o seu agent harness…

15:34 5.3 Flash como exemplo, ou Deep Seek 4.1 Flash. Sim. Uma das observações que fizemos com esse tipo de padrão dividido, certo, é que, infelizmente, por mais que desejemos que todos façam isso, ninguém realmente troca de modelo para economizar dinheiro para a empresa. As pessoas têm preguiça de trocar de modelo, em geral. Você quer oferecer um incentivo para que troquem. Ou, alternativamente, se o seu agent harness estiver

16:05 bom o suficiente. Então, por exemplo, alguns harness, como o M, automatizam o processo. Ele usa o modelo mais fraco como referência e, depois, usa um modelo maior e mais inteligente para automatizar a troca quando é necessária uma consulta mais inteligente. Isso ajuda a reduzir o atrito e a melhorar a economia de tokens em escala de usuários. Uma regra prática importante que agora damos aos nossos clientes, depois de passar por isso algumas vezes, é que você quer o modelo mais inteligente,

16:35 e, como ele já é tão caro como referência, você quer que o modelo mais rápido — o modelo mais barato — seja mais rápido. Isso cria um incentivo natural. As pessoas querem terminar o trabalho rápido. Se o modelo for inteligente o suficiente para fazer isso e for mais barato, elas simplesmente vão usá-lo porque é mais rápido, não porque é mais barato. Tivemos equipes em que tanto o modelo mais inteligente quanto o mais barato tinham a mesma velocidade em tokens por segundo e, enquanto tinham tokens de sobra no orçamento, ninguém

17:07 trocava. Por outro lado, também vimos equipes no extremo oposto, que definiam um orçamento extremamente baixo. Assim, se usassem um modelo mais inteligente, acabavam com o orçamento em um dia. Então, todo mundo simplesmente mudava para o Dharma, o modelo mais rápido, porque esse era o limite do orçamento. Era quase como se o modelo mais inteligente nem existisse. Portanto, fique atento à dinâmica da sua equipe e a como as pessoas fazem essas trocas. O melhor equilíbrio é priorizar a velocidade, porque as pessoas são naturalmente incentivadas por ela. Assim, se for mais rápido,

17:38 e mais barato, elas simplesmente vão trocar para ele. Sim. Mais uma vez, o lembrete: meça, e meça duas chaves de tokens separadas. Mas isso vai além de apenas medir. Por exemplo, CI/CD é um caso de uso muito comum hoje para coisas que rodam em segundo plano. Ajudamos equipes a configurar uma velocidade maior de tokens por segundo para os usuários, ou seja, as pessoas, e uma velocidade muito menor de tokens por segundo

18:09 mas com um custo muito menor em escala para o pipeline de CI/CD. Isso depende apenas da prioridade de cada tarefa. E você pode controlar isso no nível da chave. Outra descoberta importante vem da nossa experiência ao fazer deploy para equipes. Por exemplo, em algumas empresas, quantos de vocês já tiveram a experiência, boa ou ruim, de ouvir o CEO

18:40 dizer: “Todo mundo precisa implementar IA agora, e todo mundo precisa ter um segundo cérebro agora.” Várias organizações começaram a fazer isso. Em alguns casos, até nos Emirados Árabes Unidos, isso se tornou literalmente uma exigência por lei. Muitos departamentos não estão preparados para entender quais são as compensações envolvidas. Então, uma boa regra prática: os desenvolvedores costumam saber

19:10 qual é a diferença entre esses modelos inteligentes, por exemplo, DeepSeek Flash e GR553. Mas a maioria dos seus departamentos financeiros não faz a menor ideia. O departamento de suporte também não faz a menor ideia. Eles simplesmente escolhem o primeiro modelo que aparece e provavelmente ficam com ele. Nossa regra geral é dar aos departamentos modelos com rótulos, mas sem os nomes dos modelos. Isso também dá muito mais controle quando você faz a troca. Como mencionei antes, rápido versus inteligente; em alguns casos, também pode ser um agente financeiro ou agentes de planilhas do Excel.

19:41 São agents hiperespecializados, com fine-tuning para essas tarefas. Isso também dá muito mais controle. Permite trocar o modelo. Permite dividir o tráfego e fazer testes comparativos sem dizer: “Ei, usuários, experimentem isto.” A desvantagem é que, às vezes, os usuários podem reclamar quando você faz isso e a mudança dá errado. Mas ter esse controle é bom. Outro padrão que vemos, mesmo quando você faz isso, é talvez oferecer uma versão de prévia. É uma variante disso, mas

20:13 permite controlar as mudanças sem aumentar o esforço de comunicação em toda a organização. Isso é extremamente importante porque, em algumas das equipes com que trabalhamos, vimos literalmente pessoas usando modelos Llama 2 neste ano, mesmo enquanto conversávamos sobre o assunto, porque ninguém tinha mudado a opção. Então, vocês realmente precisam implementar isso.

20:44 Certo. Faixa de processos. Faixa de processos. Muitas coisas que mencionei antes não se aplicam tanto à faixa de processos, porque ela costuma estar muito mais integrada aos aplicativos e aos workflows. Isso se deve simplesmente ao grande volume de tráfego. E, entre todas as equipes nessa faixa de processos, elas costumam já se concentrar muito mais em escolher o tamanho adequado, por padrão, porque, se você está processando trilhões de tokens,

21:15 a maioria dos departamentos não vai aprovar algo como US$ 10 por milhão de tokens. Simplesmente não é possível. Por isso, começam cedo com evals e benchmark e, depois, encontram o modelo que tem o tamanho adequado. A pergunta comum é: como sei se o modelo menor é bom o suficiente? Você não precisa… Essa é a pergunta errada. Você só precisa garantir que configurou seus casos de teste, suas evals e seus exemplos. Depois, é só fazer a busca a partir daí.

21:46 Empresas como a nossa terão todo o prazer em ajudar, porque temos mais de 40.000 modelos. Mas também não é tão difícil baixar 10 modelos do Hugging Face e testá-los. A partir daí, você faz a busca, encontra o modelo mais barato que passa na maioria dos testes e, então, vê como iterar e fazer fine-tuning. Também temos um processo mais específico, que não acho que seja exclusivo nosso, e que também vamos abordar. Por exemplo, para uma das principais empresas de telecomunicações com que trabalhamos,

22:18 ajudamos a equipe a reduzir o custo de inference de 250 mil para 7,6 mil por mês, substituindo o modelo fechado que usavam, apenas seguindo este processo: “Certo, vocês começam usando o melhor modelo. Vamos ver quais modelos podemos separar e, depois, quais modelos podemos encaixar e em quais podemos fazer fine-tuning.” Isso foi para atender a casos de uso de suporte ao cliente, entre outros. E, para destacar novamente o Jev e o Simple Jev, um projeto open source que fizemos e que replica isso.

22:50 Você vai se surpreender com a porcentagem do tráfego de IA que é de classificação. No fim das contas, claro, responder às solicitações de suporte ao cliente envolve texto. Mas, mesmo assim, muitas equipes já têm respostas de texto predefinidas que colocam no contexto para o modelo usar na maioria dos casos. E você poderia usar um classificador nesse caso. Há uma grande mudança acontecendo agora no mundo da IA.

23:21 E essa é uma das grandes alavancas desses tipos de processos para reduzir sua conta de tokens. Um exemplo de modelo desse tipo envolve fine-tuning. Muitos modelos e processos se beneficiam disso em escala, quando você começa a fazer fine-tuning do seu próprio modelo. Por outro lado, no caso de modelos de programação, há organizações que fazem fine-tuning de modelos para você, como a Devin, por exemplo.

23:51 Muitos desenvolvedores geralmente só querem o melhor modelo. Então, a menos que você esteja nesse espaço de IA, é meio difícil acompanhar o fine-tuning do melhor modelo de programação. Mas, por outro lado, para o seu domínio, pode valer a pena fazer fine-tuning de um modelo de domínio para o seu caso de uso, especialmente se o modelo for muito menor. Por exemplo, quando a AT&T fez fine-tuning dos modelos, passou de modelos de classe aberta de 27B para modelos até de 7B. E eles têm

24:22 publicou isso. Então, nós fomos um dos parceiros de lançamento deles. E vocês podem experimentar os modelos de diálogo aberto deles. E isso é basicamente o que eles usam nos bastidores. E aqui tudo gira em torno do volume. Acho que a maioria de vocês entende a escala da AT&T, dos call centers e coisas assim. Sim. Mas é um bom exemplo de como fazer fine-tune em modelos para especializá-los em casos de uso. E, quando se chega a esse ponto, outras organizações — um grande exemplo é a Shopify — também começam a fazer isso. E…

24:54 não precisa necessariamente ser um fine-tune em grande escala. Por exemplo, no caso de uso da Shopify, eles fizeram isso porque a loja virtual da Shopify tinha uma linguagem de programação proprietária para configurar a loja. E os modelos existentes simplesmente não eram muito bons nisso, então eles fizeram fine-tune. E a AT&T também tinha exemplos disso, especialmente em tarefas como organizar as torres de celular e coisas do tipo. Sim. Uma tarefa bem específica de telecomunicações. Talvez eu não seja o especialista certo para responder a essa pergunta. Mas eles tinham esses casos de uso.

25:26 Então, eles fizeram fine-tune para esses casos, respectivamente. Talvez vocês também tenham esses casos de uso. E como se dá o pontapé inicial com um modelo desses? A boa notícia é que hoje em dia é fácil começar, porque, se o melhor modelo — aquele que é caro demais para usar em escala — consegue realizar a tarefa, vocês já podem começar. Uma maneira simples de fazer isso, que vemos com bastante frequência, é gerar os próprios dados ou preparar os próprios dados, o que é difícil.

25:58 Por algum motivo, ninguém gosta de fazer isso. Mas outro caminho comum é começar com um modelo caro, implantá-lo em pequena escala e, então, gerar um conjunto de dados. Entendo que, para alguns laboratórios, isso vai contra os termos de serviço, então talvez vocês queiram consultar seus advogados, mas há laboratórios que aceitam isso abertamente. Por exemplo, o Google Gemini — os modelos de fronteira deles — tem literalmente um serviço de API dedicado para isso. Isso permite que vocês

26:28 criem conjuntos de dados para os próprios casos de uso usando um modelo robusto, que depois podem reduzir drasticamente, por exemplo, para uma escala de 7B. Como alternativa, os modelos open source permitem que vocês os executem e façam destilação neles, então também podem executar os melhores modelos open source. Depois de coletar os dados, vocês podem fazer fine-tune com eles e testar diferentes tamanhos para ver qual funciona melhor. Então, mais uma vez, como no exemplo da proporção 80/20, eles têm o modelo 27B e

27:00 o 7B para diferentes níveis do call center. As chamadas rotineiras podem ser atendidas por um… Esperem. Acho que não posso dizer qual tamanho vai para cada caso, mas as chamadas rotineiras podem ser direcionadas ao modelo bem menor e, então, escaladas por algum gatilho de classificação, por exemplo. É assim que vocês fazem o tráfego fluir, dividem o tráfego e chegam a esse nível de eficiência. Uma das coisas em que também costumamos trabalhar com as equipes quando fazem isso é que, mesmo depois de passarem por essas etapas e

27:31 transferirem completamente o tráfego para o modelo com fine-tune, como os melhores modelos continuam evoluindo, normalmente recomendamos que redirecionem parte do tráfego para o melhor modelo, como tráfego sombra, para continuar montando o conjunto de dados. Isso permite acompanhar a evolução dos melhores modelos open source. E a economia unitária é muito importante aqui, porque uma coisa que eu gostaria de lembrar às pessoas é que elas subestimam muito

28:02 a velocidade com que a IA está avançando, especialmente no caso dos modelos que vocês conseguem executar com muito mais economia em escala. Tomem este laptop como exemplo. Gosto de avaliar qual é o melhor modelo que consigo comprar no MacBook Pro mais caro. E os melhores modelos de hoje, sejam modelos MoE de tamanho 31B, 32B ou 27B, já são muito melhores que o GPT-4. Então, essencialmente,

28:33 esse modelo que roda em um laptop já é melhor que o melhor modelo que vocês tinham no ano passado, mais ou menos. As pessoas gostam de discutir os detalhes, mas vamos dizer isso de forma geral. E, quando vocês fazem fine-tune dele para a tarefa de vocês, isso significa que, se conseguem executar esse modelo em um laptop, também conseguem executá-lo nos servidores de GPU em escala com muito mais eficiência. Sim. Isso nos leva ao próximo tópico: comprar GPUs, o que aparentemente está ficando cada vez mais difícil. Então,

29:05 é aí que empresas como a nossa entram. Uma coisa que percebemos em muitas conversas com clientes é que as pessoas ficam bastante surpresas ao descobrir que as coisas não escalam linearmente. O que quero dizer é que existe uma grande compensação entre os tokens por segundo em uma solicitação individual e o custo da própria solicitação. Por exemplo, se vocês não se importarem com o custo, podem executar o melhor modelo — digamos, um modelo fixo —

29:37 no melhor hardware, usando as oito GPUs e tamanho de lote um, e conseguir, digamos, 100 ou 200 tokens por segundo. Se vocês realmente quiserem milhares de tokens por segundo — e essa não é a nossa especialidade —, empresas como a Cerebras oferecem isso com todo o prazer. E custa ainda mais. Há, sem dúvida, casos de uso em que isso faz sentido. Mas muita gente cai na armadilha de pensar: “Se eu tiver essa velocidade, talvez custe metade.” Nem chega perto. Uma regra prática que às vezes menciono é:

30:08 “A cada duas vezes mais velocidade, o custo fica três vezes maior, e isso se acumula.” Neste exemplo específico do JM 5.3, um nó JM — vocês podem ver o mesmo servidor — chega a 112 tokens por segundo ao executar solicitações individuais. Mas, se vocês executarem 16 solicitações em paralelo, terão cerca de metade da velocidade em cada solicitação, mas aumentarão em dez vezes a saída total. Isso dá literalmente um custo cerca de 9 a 10 vezes menor, simplesmente mudando o perfil de velocidade desejado.

30:39 Então, quando muitos clientes nos perguntam: “Como implantamos isso em escala?”, às vezes a primeira pergunta é: “Qual qualidade de modelo vocês querem? E qual velocidade, em tokens por segundo, vocês querem?” Aí começamos a recomendar a quantidade de GPUs e a escala da implantação. Essa meta de tokens por segundo envolve uma compensação importante. Em casos mais extremos, se vocês realmente conseguirem executar as coisas a 10 tokens por segundo — quase ninguém faz isso, mas existem alguns casos de uso incomuns que permitem —, podem obter um volume de processamento total ainda mais

31:11 impressionante. Normalmente, vemos clientes escolherem entre 20 e 30, que é mais ou menos a velocidade do ChatGPT, sem muita reflexão, e até 60, que é a velocidade mais alta. Se quiserem 120 tokens por segundo, geralmente é nessa faixa. A maioria fica entre 20 e 30 e 60, dependendo da duração da cadeia de tarefas. Então, mencionei que, em geral, vocês só querem pagar pela velocidade em

31:42 tokens por segundo quando há alguém esperando por ela — seja um desenvolvedor ou um cliente. Essas são as compensações que vocês precisam considerar. E, mesmo nesse caso, vimos situações em que uma pequena redução já consegue cortar o custo pela metade, com impacto quase mínimo para o cliente. E, mais uma vez, não executem tarefas em segundo plano a 120 tokens por segundo. Não faz sentido.

32:13 Sim. Então, depois que você já tiver… Antes, eu disse para medir, certo? Você consegue ver o padrão do seu tráfego. Muitos padrões de tráfego tendem a ser, de certa forma, irregulares, com alguma carga base, porque sempre tem alguém executando alguma coisa em algum momento, especialmente agents em segundo plano. E é aqui que você também pode planejar seus deploys, respectivamente. Sei que, como trabalhamos bastante com o setor financeiro, talvez isso não seja uma opção, porque eles usam apenas deploy em instâncias dedicadas,

32:44 mas, em alguns casos em que as pessoas permitem uma configuração mista, com instâncias dedicadas e alguns picos direcionados à nuvem pública, é aí que vocês têm certa flexibilidade. Então, a maior economia de custos disponível no mercado hoje é fazer deploy em uma instância dedicada, se você conhece sua carga de trabalho base. Assim, desde que use tudo plenamente, você consegue economizar. Mas é um pouco mais complicado, dependendo do seu padrão de tráfego, e muitas dessas coisas podem ser testadas e validadas. E, essencialmente, é isso que qualquer empresa de inference vai fazer com você. Não é algo exclusivo nosso. Vamos dizer: “Ei, você conhece sua carga de trabalho de tráfego? Pode compartilhar alguns dados?” E depois vamos dizer: “Certo, propomos essa quantidade. Você pode tentar mudar para isso.” E então, em geral, conseguimos mostrar quanto você economiza. E, em alguns casos extremos, em que há muitos picos, talvez você queira limitar sua capacidade dedicada a um certo nível e deixar que os picos excedentes sejam atendidos pela nuvem pública. Os diferentes casos de uso exigem dimensionamentos diferentes, mas isso é algo que você pode começar a explorar medindo sua carga de trabalho de tokens, mais uma vez, logo no início,

33:15 e as economias podem ser enormes. Mais uma vez, para o cliente para quem atendemos 2 trilhões de tokens, com um modelo da classe Opus 4.8, ele está pagando menos de US$ 0,03 por milhão de tokens. Você não encontra esse preço em nenhum outro lugar. Sim. Então, uma ressalva simples: os picos realmente importam. É muito raro alguém ter um pico curto, no limite extremo, em que executa uma carga de trabalho nessa escala todo mês e depois nada mais importa. Então, geralmente existe alguma carga de trabalho base. A questão é apenas o tamanho dessa carga base. Sim. Sim. Então, o último ponto é verificar seus processos. Daqui em diante, isso não tem nada a ver com otimização de inference. Alguns slides podem parecer muito críticos em relação à IA, mas, no geral, sou otimista. Só queria deixar isso claro, porque as coisas podem ser tiradas de

33:46 contexto. Uma das perguntas da caixa de Pandora, ou uma pergunta problemática que estamos começando a ver, é que muitas organizações estão começando a perguntar: “Ei, estou gastando 10x, 100x mais em tokens, mas não estou vendo resultados na mesma escala.” Estamos começando a ver relatos de várias organizações sobre como a IA teve ganhos limitados de produtividade, de apenas 6% ou 7%, o que não é a

34:18 escala que muitos de nós esperávamos ou imaginávamos. E, infelizmente, esse é o caso porque estamos na fase em que todo mundo simplesmente pega uma marreta enorme e sai martelando tudo. Não é que a IA não seja útil; é só que tendemos a usá-la indiscriminadamente em todo lugar. E, sim, há momentos em que eu só quero dizer: “Por favor, não faça mais disso um co-piloto.” Porque já tem demais. É preciso pensar em como você

34:49 usa isso. E outro grande problema que começamos a perceber é que, enquanto as IAs são implementadas em maior escala e com mais frequência, e as pessoas ficam mais rápidas para criar coisas, os processos da organização talvez não avancem tão rápido. O primeiro gargalo nos ambientes de programação serão os CI/CDs, e vocês talvez já tenham ouvido que a CPU se torna um gargalo. Outra coisa é simplesmente

35:19 os processos existentes. Como confiar? Como revisar? Acho que o palestrante anterior falou bastante sobre confiança. Sim, a falta de confiança é o que atrasa as coisas. E isso pode ser justificável. Talvez o agent, o agent de IA, tenha sido mal projetado e não deva ser considerado confiável. Mas também pode acontecer o inverso. E se, hipoteticamente, aquele agent estivesse fazendo tudo perfeitamente? Mas as pessoas não confiassem nele porque não havia testes, não havia validação e a confiança não foi construída. Isso atrasa as coisas. E essas coisas

35:50 têm um impacto muito maior. Então, mais uma vez, tome muito cuidado com a forma como a marreta está sendo usada, porque você precisa fazer os ajustes adequados. E isso nos leva de volta à ideia de que tokens não são trabalho concluído. Um exemplo importante que eu gostaria de destacar é algo que acontece com mais frequência do que eu gostaria: às vezes, usar mais agents e

36:21 mais tokens significa que a mesma tarefa é feita várias vezes. Um dos antipadrões que começamos a observar é o seguinte: no geral, a organização de engenharia melhora a produtividade resolvendo mais issues rapidamente e automatizando a resolução de issues. Por exemplo, quando alguém de uma equipe de QA relata uma issue e o agent a corrige automaticamente, sem nem precisar de um engenheiro, isso é ótimo. Mas um dos problemas comuns que começamos a enfrentar é que as pessoas ficam ambiciosas

36:53 muito rápido. Em vez de fazer pequenas mudanças, começam a fazer mudanças enormes, como alterar metade ou um quarto da base de código. Às vezes, quando isso é planejado com testes adequados, é ótimo. Mas, muitas vezes, a mudança acontece em uma escala tão grande que o gargalo passa a ser o revisor, que precisa fazer o merge do código. E, como tudo é feito em uma escala tão grande que uma pessoa não consegue processar, um dos antipadrões comuns que começamos a observar é o seguinte: alguém implementou as

37:24 issues. E, como tanto código é gerado, as issues que não têm código gerado não são revisadas nem selecionadas pelo revisor. Então alguém precisa gerar o código usando um agent. E, quando o agent gera aquela pilha enorme de código — que deveria ser bem menor se a pessoa revisasse adequadamente o prompt e coisas do tipo —, o revisor olha e diz: “Nossa, isso é código demais. Posso pedir ao meu agent que destaque quais mudanças são relevantes e depois as implemente de novo?” E, no fim, começaram

37:54 a reconstruir tudo à mão com o agent. Literalmente descartam o trabalho do primeiro agent. Há vários bons motivos para isso acontecer. Por exemplo, os revisores querem manter o controle e a qualidade da base de código principal. Mas esse é um exemplo muito comum de gargalo: se você não pensar o processo até o fim, só vai continuar jogando mais e mais coisas nele. E a velocidade não aumenta. Então, revisem seus processos. Uma boa forma de contornar isso é, naturalmente, estabelecer

38:26 práticas melhores de testes, para que vocês possam automatizá-los e filtrar o que for necessário. Também vale lembrar as equipes: “Ei, dividam seu merge ou deixem-no mais modular para facilitar o processo de revisão.” Coisas assim são processos humanos. Não têm nada a ver com a IA. E, sim, às vezes ficamos empolgados demais com IA. Então, isso não é apenas um problema de código. Estamos começando a ver que, como agents de IA estão sendo usados para criar apresentações, esta apresentação foi inteiramente

38:58 gerada por IA em termos de design. Passei por várias iterações. Não foi uma geração de uma só vez. Revisei cada página pelo menos 30 vezes para mudar o texto, mas o design foi feito por agents. E, às vezes, dentro da organização, você começa a notar pessoas que geram a apresentação inteira de uma só vez, coisas assim. E começam a compartilhá-la. Começam a fazer reuniões. E aí cabe a todo mundo identificar as inconsistências, os desalinhamentos. Por que isso está

39:29 práticas melhores de teste, para que você possa automatizar isso e filtrar. Além disso, lembrar as equipes: “Ei, dividam o merge ou deixem-no mais modular para facilitar o processo de revisão.” Coisas assim. Esses são processos humanos. Não têm nada a ver com a IA. E, sim, às vezes ficamos empolgados demais com IA. Então, isso não é só um problema de código. Estamos começando a ver, por exemplo, que, como os agents de IA estão sendo usados para criar apresentações, esta apresentação foi inteiramente

40:01 gerada por IA no que diz respeito ao design. Passei por várias iterações. Não foi uma geração em uma única tentativa. Revisei cada página pelo menos 30 vezes para mudar o texto, mas o design foi feito por agents. E, às vezes, dentro da organização, você começa a notar pessoas que geram todos os slides de uma vez, coisas assim. E começam a compartilhar a apresentação. Começam a fazer reuniões. E aí cabe a todos os outros filtrar o que está inconsistente, o que está desalinhado. Por que isto está em dois

40:31 dados completamente diferentes? Este também é outro exemplo, como o anterior: pessoas gerando código, slides ou relatórios, e o ônus acaba recaindo sobre algum ser humano, mais adiante, para verificar as coisas. Então, fiquem bem atentos a essa mudança organizacional. Por que ainda sou otimista? É que não acho que isso seja necessariamente algo ruim por si só, porque o problema é que todos precisam aprender. E é aí que começamos a adaptar nossos processos de acordo.

41:02 E outra coisa importante é que há muitos exemplos comuns de como usar IA. Vocês conhecem melhor o domínio da sua organização. E haverá casos de uso em que a IA poderá ser usada para automatizar um processo, por exemplo, o que poderia economizar milhões de dólares para a organização ou aumentar a produtividade em grande escala. Só vocês vão saber disso; não sou eu, como especialista em IA, que vou chegar e descobrir. Gosto de apontar o exemplo mais famoso

41:33 que o Walmart teve. Onde foi mesmo? Foi o Walmart? Acho que foi o Walmart. Eles literalmente começaram a colocar um banquinho, um degrau, dentro de cada caminhão. Foi uma mudança muito simples, mas reduziu os custos em milhões, porque diminuiu as lesões nas costas causadas pelo transporte de mercadorias pesadas. É algo específico assim que pode acontecer com o uso de IA. E talvez nem seja necessariamente o melhor modelo de IA, mas ainda assim pode ter o maior impacto. Sim. Sim. Então,

42:04 reforçando o que eu disse antes: um dos termos que foi cunhado e vem ganhando popularidade é “granada de slop”. É quando se gera um monte de coisas com IA e depois se deixa isso para outra pessoa resolver. Não deixem acontecer uma granada de slop. Isso é uma questão de cultura e de processo. Isso mesmo. Então, estas são algumas regras orientadoras que eu estabeleceria, embora sejam mais subjetivas. As pessoas discordam. Para evitar que uma granada de slop aconteça, exijam que as pessoas

42:35 assumam a responsabilidade pelo que entregam ou geram. Por exemplo, este slide: sou responsável por todo o texto gerado. Se houver algum problema, a responsabilidade é minha. Não é o meu agent de IA que tem um problema. Não posso simplesmente passar a responsabilidade para um agent. Preciso assumir essa responsabilidade. O mesmo vale para o código e para qualquer coisa que seja gerada. E também é preciso medir os resultados, não o uso. Isso fica mais complicado, porque não quero me alongar demais para explicar

43:06 isso, mas há uma fórmula simples que, na minha opinião, as pessoas usam como regra prática: tokens vezes preço, dividido pelos resultados que alguém realmente usa. E isso ajuda a orientar muitas decisões: modelos menores e mais eficientes, modelos mais rápidos, modelos maiores, blá-blá-blá. Mas o que não gosto nessa abordagem é que outra analogia que uso para falar de IA é pensar nela mais como suplementos ou esteroides que potencializam a equipe. Pensem nela como algo que, digamos, eu usaria como exemplo em um trabalho de construção.

43:38 Digamos que eu pudesse usá-la para aumentar a massa muscular dos trabalhadores. Por exemplo — não que isso seja ético. Sei que não é o caso, mas vamos considerar isso como exemplo para desenvolver o raciocínio. Algumas equipes teriam isso e melhorariam a produtividade; outras, não. Mas, mesmo sem isso, é bastante claro que algumas equipes são muito melhores do que outras. Então, a IA como suplemento, certo, não muda necessariamente tudo. Portanto, é preciso ter em mente que é difícil medir os resultados,

44:09 mas é algo que vocês podem começar a medir e observar. E, o mais importante, voltando à primeira etapa: medir. Vocês sabem quantos tokens são gastos por departamento e por equipe, e podem começar a ver qual equipe está tendo um desempenho melhor e quantos tokens ela usa. Podem começar a identificar o que funciona. Sim. Sim, como eu disse, essa medição é falha. Então, esse é o panorama geral. E, se quiserem dar início ao processo dentro da organização, podem falar comigo ou com a minha equipe, ou usar estas seis perguntas para começar: quem gastou o quê em cada equipe? O que é preciso testar para usar um modelo mais barato? Qual é a carga-base? Qual é o modelo padrão para cada equipe? E em quais tarefas há uma pessoa esperando, de modo que vocês precisam de algo mais rápido? Sim. E quanto do que geramos é útil? Estas são perguntas orientadoras para começar a fazer e aprimorar a tokenomics de vocês. Então, perguntas e respostas. Sim. >> Sim, quando você mencionou

44:39 fine-tuning de modelos, isso é… >> Teste, teste. >> Hum… >> Sim, estou tentando. >> tipo fine-tuning SFT ou há outros métodos de fine-tuning, dependendo do caso de uso específico ou dos dados disponíveis? >> Ah, certo. Em geral, tende a ser SFT, mas não acho que… Bem, oferecemos serviços de fine-tuning, e geralmente é SFT. Há muitos métodos sendo desenvolvidos agora. Sei que RL

45:09 está muito em alta agora, especialmente no ambiente de programação, porque é fácil gerar os dados no ciclo. Mas o que percebemos é que, para muitas organizações, especialmente em lugares como Nova York, por exemplo, instituições financeiras e coisas do tipo, não existe realmente um ambiente de RL para tarefas financeiras. Então, tende a ser mais baseado em SFT. E também há outras organizações, como a Adapted Adoption AI, que estão começando a

45:41 automatizar o refinamento dos conjuntos de dados para vocês treinarem o modelo, seja com SFT ou com machine thinking. Talvez focar nisso seja a pergunta errada. Em geral, na minha opinião, as pessoas deveriam se concentrar nos evals. Aqui vai um bom exemplo com o Jev, que surgiu quando o modelo Jev foi lançado. Depois, fizemos o projeto open source chamado Simple Jev, que replica a API do Jev para modelos open source existentes. Muitas

46:13 pessoas logo perceberam que o Qwen 27B era muito bom nessa tarefa. E várias equipes foram fazer fine-tuning do Qwen 27B. Do nosso lado, como estamos tentando adotar uma abordagem em que nossa empresa aceite qualquer modelo e construa a API por cima dele, começamos a pensar: “Olha, vemos o benchmark, vemos o modelo existente. Por que não fazemos prompt tuning em vez disso?” Nem sequer é fine-tuning. Duas semanas depois, quando a Hugging Face fez todos os benchmarks em grande escala, com mais de 10 mil perguntas e coisas do tipo, de algum modo meu

46:44 Qwen 27B com prompt tuning superou a maioria dos modelos de 27B com fine-tuning. Isso não é para me gabar, porque tenho quase certeza de que agora meu modelo foi superado pelo modelo com fine-tuning mais recente da Cloudflare, que foi feito de maneira mais adequada. Mas a questão é mais que talvez o método de tuning não seja a pergunta certa. A pergunta é: quais são os seus evals e quais resultados eles levam a obter? >> E, para isso, vocês precisam coletar golden traces para

47:15 o conjunto de dados necessário para fazer SFT, ou seja lá o que for? Ou dá para fazer assim: digamos que os modelos de ponta acertem 80% das vezes, certo? Então, em 20% das vezes, cometem algum tipo de erro. Se vocês fizerem fine-tuning com esses dados, o modelo ajustado também não vai errar em 20% dos casos? É preciso filtrar esses exemplos de algum modo e obter apenas golden traces para o treinamento, ou dá para simplesmente incluir todos os traces e treinar? >> Isso é mais uma opinião pessoal sobre a técnica, porque, em geral, tento dividir o conjunto de dados

47:46 porque as pessoas são preguiçosas para filtrar. Então, tento pelo menos obter um conjunto de dados de golden traces. Esse conjunto talvez seja bem menor, e então fazemos o fine-tuning dele também com um peso muito maior. Mas já houve vários artigos, especialmente sobre tokens de raciocínio, que até os não-

48:18 conjunto, porque as pessoas têm preguiça de filtrar. Então, tento pelo menos obter um conjunto de dados de rastros de referência. E esse conjunto de dados de rastros de referência talvez seja bem menor, respectivamente, e então fazemos fine-tuning nele também, atribuindo um peso muito maior. Mas houve vários artigos, especialmente sobre tokens de raciocínio, que mostram que até mesmo os modelos não-

48:48 A tarefa que falhou, certo? O modelo muito menor, quando você faz fine-tuning, tende a se beneficiar do treinamento porque o processo de raciocínio melhorou, mesmo que ele tenha chegado à resposta errada. Isso é um bom exemplo de tentar e depois medir: funciona em 70% dos casos. Às vezes, você só precisa aumentar a proporção de golden traces, mas essa é uma regra geral. Acho que, para muitos clientes que estão tentando fazer SFT em um modelo menor, a regra geral que tentam seguir é:

49:18 Consigo manter um nível de desempenho quase igual? Talvez a avaliação caia 1%, ou, em alguns casos, até melhore 10%, porque o modelo base não era especializado nessas tarefas. E, mais importante, isso reduz minha conta em 100 vezes? Essas costumam ser as motivações, respectivamente. Sim, as amostras douradas são essenciais se você quiser ir além do baseline. E, às vezes, isso exige que pessoas examinem os dados, embora eu adorasse que meus clientes olhassem mais para os dados,

49:49 as pessoas não gostam de fazer isso. >> Oi. Como você lidaria com os gastos com código que viriam principalmente do Claude Code e de todas as integrações ali? Porque, nesse caso, seu modelo fica totalmente preso ao ecossistema do Claude, suponho. Você tem algum conselho sobre como lidar com esse tipo de situação? >> Sim, infelizmente, Claude Code é o exemplo de algo que prende você completamente. >> [risos] >> Então, às vezes, o primeiro

50:20 passo é conseguir que eles possam trocar de harness. O harness parece ser algo bem mais flexível neste momento. Vimos organizações totalmente presas a uma opção, como: “Só vou usar Devin” ou Mboni. Também vimos organizações mais flexíveis. Algumas estão literalmente executando e criando seu próprio agent harness. E minha reação é: “Por quê? Por que vocês estão criando seu próprio agent harness do zero?” Mas uma opção comum para a qual vemos pessoas migrando,

50:51 por exemplo, é Pi. E isso também se deve ao entusiasmo em torno dele. As pessoas mostraram que, mesmo com o mesmo modelo, o custo por token fica muito menor por causa da simplicidade e eficiência. E, a partir daí, acho que a beleza do agent harness de programação Pi é que ele é fácil de adaptar, porque é muito leve. Vimos muitas equipes começarem simplesmente pedindo aos agents que façam modificações. E, quando conseguem isso, começam a entrar nesse ciclo de experimentação e mudança. Uma

51:22 maneira comum de incentivá-los bastante a mudar é apresentar um modelo bom o suficiente e muito rápido, como um que gere 100 tokens por segundo. Aí, de repente, eles começam a experimentar. Algumas pessoas — ou uma das primeiras mudanças — ainda usam Claude Code como planejador. Depois, instruem o Claude Code: “Use este agent Pi com este modelo para fazer a implementação.” Daí vem a separação entre planejador e implementação. É mais ou menos isso, e foi aí que a transição começou. Não é fácil mudar os agents das pessoas, mas

51:54 sim. >> Um exemplo disso talvez fosse disponibilizar esse agent menor como um MCP dentro do Claude, ou ter essas ferramentas para as quais você pode delegar tarefas. Suponho que isso poderia funcionar? >> MCP é mais complicado, porque agents via MCP, a menos que sejam configurados corretamente, não têm acesso ao seu sistema de arquivos. Então, normalmente, é algo bem mais simples, como instalar o Pi e executar o comando em lote pi this.

52:25 Sim, esse costuma ser o caso. >> Obrigado. >> Sim. >> Você poderia compartilhar, se possível, algum estudo de caso sobre soluções de cache, sobre como pensar cuidadosamente no cache e os resultados gerados para clientes específicos, mesmo que sejam anonimizados? >> Qual é exatamente o desafio de que você está falando? Você faz cache de um…

52:56 Entendi. Sua pergunta é mais do tipo: você quer anonimizar, quer dizer… Você não quer que informações privadas dos clientes sejam salvas no cache? >> Não, eu queria saber se, com os clientes com quem vocês trabalharam, há estudos de caso que possam compartilhar sobre os resultados que eles conseguiram ao pensar cuidadosamente na forma de fazer cache e nos diferentes métodos de cache. >> Acho que podemos conversar sobre isso depois, mas, em geral, implantamos um cache dedicado para nossos clientes de maior escala.

53:26 Isso resolve muitos problemas de informações de identificação pessoal, porque o cache é exclusivo daquele cliente. E, claro, há a formatação de prompt, mas talvez eu precise entender melhor o que você está perguntando especificamente. A resposta curta é sim, mas isso pode ser interpretado de muitas maneiras. Sim. >> Legal. Desculpe. >> O que você acha do roteamento automático baseado em turnos ou em tarefas? >> Ah,

53:56 Em geral, sou mais favorável ao baseado em tarefas. Principalmente porque é muito mais fácil controlar as expectativas no nível de um departamento ou de uma organização. Isso remete à ideia de que um departamento pode ter um modelo de rotulagem e eu posso configurar um roteador automático para esse modelo para eles. Sei que há bastante entusiasmo agora com o roteamento automático baseado em turnos. Um dos problemas é que você precisa limitar esse roteamento, digamos, a no máximo dois ou três modelos.

54:27 Caso contrário, o cache será extremamente ineficiente. Por exemplo, vimos roteamento por turnos com GRM 5.3 e GRM 5.3 flash. Faz sentido. Mas, se você colocar 30 modelos e ele continuar trocando o modelo a cada turno, a baixa taxa de acertos do cache vai prejudicar sua otimização. >> Sim, já vi isso acontecer. Vi no nível da solicitação, e não fazia sentido, aí… >> Sim. Mas dois modelos geralmente funcionam bem. O roteamento por tarefa e por organização faz mais sentido.

54:57 Sim. >> Sim. Sim, concordo. >> Certo. Muito bem. Muito obrigado. E, se alguém quiser falar comigo especificamente para fazer mais perguntas, pode vir aqui na frente e me perguntar, ou me encontrar ao lado quando o próximo palestrante chegar. Sim. Muito obrigado.

Transcrição original

[00:01] [music] >> Uh thank you for everyone for coming here. Uh not too sure whether to be happy or sad that so many people are suffering from the token bill. It’s a full workshop. Uh Yeah, that uh we’re going to talk about tokenomics. So, a little bit of a a background with the kickstarting it, right? I’m Eugene from Felis AI. I’m CEO and founder of of it. Uh and I’m part of the team behind the

[00:32] Arabic AI open source project, the first AI model under the Linux Foundation. And and we work on next generation AI architecture. Uh that’s a little bit of my academic background. And my Twitter handle is PicoCreator. But, but more importantly, right? Uh uh a little bit of background for Felis AI is that our mission is to make AI accessible for everyone, every language, every dialect, every country. And we do this We do this by creating the world’s largest platform of open models, of over 40,000 open models. And this includes specialized fine-tune like

[01:03] the Sunflower model, which is Uganda’s first language model, specifically for their language, and a lot of other specialized models. So, we’re not just not talking about the biggest open source model, but specialized language models or specialized use cases, uh some of it which I’ll touch as well. And when we when we can go on scale in terms of variety of model, Felis AI also we serve customers at scale. So, some of our largest customers are literally serving 2 trillion tokens a day. And and they’re And and they’re serving it at around 0.3 per million tokens or

[01:33] 60K a day. And they’re doing it on around 512 AMD GPUs, uh MI215. Uh and for this customer in particular, it’s a private 400 Android BM OE model. Uh and they’re serving it around Opus 4.8 class performance. So, it’s lots of concurrent requests, lots of token volume. That’s what we mean by scale. And if you look at it, 0.03 per million token at over 4.8 class, it’s not something that is not something that you can get off the public cloud market.

[02:04] This is specially very specialized setups that is meant to run at the scale that we are talking about. So, that kind of uh leads in into two major disclaimers that I’m going to start off. One, we sell inference. So, everything I cover here will cover the will will touch on any provider. Nothing here is specific to Fiddler’s. But, to to for clarity, we sell inference. So, so this is from our data points, from our experience, respectively, as well. Okay? The other thing is that

[02:35] this workshop is going to cover a lot of optimization at scale, and it probably will not fit you if you’re like spending less than 10K a month in your organization. Uh my word of advice for those who are below this this uh metric mark, and this is an arbitrary metric, is that if you’re spending less than this, you’re probably better off focusing on like trying to get strong use cases within your organization, rather than trying to optimize the token spending bill. Because a strong use case can bring your organization way more than 10K a month. And and that’s and that’s what should be

[03:06] your main area of focus, and that’s not my area of focus for this talk. So, what we are going to cover in this workshop uh is four moves in in in four major order: measuring, right-sizing, uh how do you buy your capacity, and how you check your process. So, measuring. Yep. You’ll be surprised at how essential this is. Uh like, how many of you know your total token spend? Can I have a raise of hands?

[03:37] Wow, only half the room raised hand. Okay. How many of you can measure at the department level? Those those who have their hands raised up, leave your up. And so, I see about another half went down. Yeah. And it gets lower and lower down to the team level, to the use case level. Uh we like easily 30 40% of our customers that reach out to us, the first thing they had was a single shared key that everyone in the organization used. And that was like Uh uh how do we even measure that? How

[04:07] do we start from there? So So this is not and a vendor specific like you need to start splitting up your keys, start splitting up by departments, start splitting up by major use cases so that you know where all your tokens are. Um and this is then from then on it can inform your workload. So yeah, API keys shouldn’t be that hard to issue. Um once you know that, right, you can start right-sizing things uh respectively. Like like which team is uh and workloads spend on it? What was the person waiting for? Like some teams deserve the tokens per second. Some

[04:39] background agents running at midnight probably can don’t deserve the tokens per second speed that you’re paying for it. Uh yeah, don’t pay for ultra on a background agent. That’s just dumb. Um and and from that also you can also look at your usage to better advise like uh dedicated capacity that you may purchase, be it for open models or even close models. Uh yeah. And also you can also check which team spend the most token and whether they are productive. Uh I’ll touch on that as well. One of the things that you should know

[05:11] in AI workloads, right, uh and you all may already experience, right, is there are two major tracks with very opposite economics uh respectively. So there is the agentic workload and obviously there’s things in between where it tends to be like long-running multitenant agents. Coding agents are a particular example of this. Some Some Some may have some devs like run coding agents like literally overnight over a long period of time with uh with multiple compaction. And and these things maximize the context uh usage. Process automation is the other extreme.

[05:43] Uh think call centers, think email routing, things your meeting notes transcribing, and things like that. It’s all It’s much shorter in context in general, though there are a lot of examples that defy this statement. But, it’s very process-driven, very task-isolated, and it’s it’s a volume game, essentially. So, well, what do I mean by more usage? And this is probably one of the first major explosion a lot of organizations face. In particular, when they jump onto the open cloud hype or one of the cloud

[06:14] clones. So, you like like from from from various developer teams that we we support, like for example, we sampled one of the team, and it was only five devs, and they were averaging around continuously eight running agents for one of the companies we work with. And And so, they were previously running Opus 4.8 of the API, and they were essentially spending 150k a month continuously running these agents. Some of it is the agents that they use to code, some of it is the agents that kick in at night. They They were slightly more advanced. They already knew that they they they they should

[06:44] kick things off at night when no one’s are working. But, essentially, they were spending 116 billion tokens a month. And we literally helped them switch to GRM 5.3 instance. Previously, it was 5.2. They already upgraded 5.3, and that was like a single node. That was less than 10k a month. And they were And they didn’t see any disruption or impact. So, knowing your team allows you to make these decisions respectively. And like like I highlighted, like knowing processes workload also allows you to split things off. So, like, for example,

[07:15] previously, they were running everything throughout the day, but they they started scheduling some of the background agents when the team was asleep, and it runs through night. So, this allows you to utilize their hardware respectively. The As I I touched on briefly, the other side of process automation is purely a volume game. Extremely predefined. I I can give you more specific example off the off the record, but you think of it as like millions per day or even tens of millions per day, decisions in call

[07:46] centers, lines of code scanned, emails and text messages filtered. Like, one of the telcos we work with, like, they easily hit peak 10 million messages in a single minute. And this shouldn’t come as a surprise. Happy New Year is the worst. Yeah. So So So these And they And they help And the reason why they filter messages is because they provide a feature about like providing safe phone for kids. So they needed an AI to scan like basically is it profanity, sexual content, etc. etc. So So this This is really not a long

[08:17] context, but a volume game. Other things like Other things is like maker-checker processes, approval processes, document processing. These are all volume game for multiple organizations. So I suspect for the financial institutions here, since we are in New York, a lot of OCRs, a lot of documents, a lot of approval, a lot of transaction risk the is is under this category. Okay. So yeah. If you’re not yet tracking your token token spend and token view split, right, we are open sourcing a tokenomics tracking tool, which is

[08:48] just a very fancy way of like splitting up your API key and tracking which API key spends how much, which is separate from this talk. Yeah. So if you If you want to again update it, feel free to to scan this QR code and respectively. It also if you want to slides for this talk and when the recording is released from AI engineering to be notified about this talk, you can also get fill up the form there. Okay. Okay. Okay. So yeah. That was about measuring. Um yeah. If you are not measuring, you can pretty

[09:18] much ignore everything else I say and start with measuring first because all your biggest ROI is just by measuring. But once you have things measured, right, the question is how do you right-size it? And this is where things gets more complicated. Uh In In general, right, one of the things that we start to observe as as AI gets deployed at scale within organization is that there tends to be a pattern of like because AI is the shiny new hammer, we try to apply it to everything. Especially within the

[09:50] innovation labs, we just try to apply to every damn thing. And we tend and and I have seen organizations literally apply fable to really the silliest of things. So so you there’s a lot of models and a lot of models are really expensive and and and and and figuring out to do and where it fits is is is important is an important step of the process. I know open models I mean a lot of you probably heard about open models and

[10:20] that’s our line of business. Yeah. And and so a lot when a lot of companies come to us for example to like find open models that fit their use cases and drop in replacements. This is we generally guide them along their use cases. So these are these are general rule of thumb that is probably going to be updated month because open models release every few months and same thing close source models. Things change rapidly. But but there but the thing is what we find right exciting actually within this year is things have started to change. Like in the previous

[10:51] year the best close source model is without better than the best open source. Almost. But as this year approach right we are starting to see the gap close. We are starting to see situations where where some of the open models are even on par or even surpassing. So like for example before the Opus 5.5 update came out Kimi K3 was beating Opus in UI design in some of the UI benchmarks. And and this is like very

[11:21] public benchmarks. Within customer benchmarks right we were already starting to see open source models beat very specialized benchmarks in specialized use cases. So like A particular one to highlight is like for example, step one five model. They it was able to achieve near Opus and extra quality despite being like a 10 x smaller model in financial benchmarks uh financial use cases. And this is it the best coding model? No, but in that use case, it’s actually extremely strong and competent. So so so the landscape is slowly

[11:52] changing where where where you can have drop-in replacement for a lot of use cases that are sometimes even just 10 x cheaper respectively for the uh uh if if you know your workload and you can drop it in respectively. Special shoutout is also DeepSeek-V4 and Flash. For some reason, and this model is extremely popular across all workloads respectively because it’s easy to prompt there uh for a lot of companies. So well I well the rest of the models I have listed there they are they are like default for good in their categories.

[12:22] DeepSeek-V4 and Flash seems to like be quite popular regardless the case. Yeah. Uh though benchmark score doesn’t seem to justify why why is it so popular. Yeah. Yeah. Uh another thing to highlight, right, is that recently like and this is like for a few weeks ago, uh the a new class of uh AI models have been introduced called uh classifiers one-shot classifiers most popularly known as JAF. Open-source projects have already started uh taking off like simple JAF. And these are models that are entirely

[12:54] focused on just making decisions and classification on on tasks. Uh the main advantage is that because on a technical level only, they are commonly 10 x cheaper than existing models or even faster at the same time. Uh the downside is it cannot give a chat response. So so so these are things that are changing and happening that you all may want to start looking into on like on like segments of how you want to improve your your token economy. Yeah. But but back to the The the

[13:27] the token economy part, there is two major tracks and it is important to separate out and track this track them respectively. It on the agentic side we’re talking about long running long context as I said earlier. And to and you have to understand this workload tends to be extremely cash heavy, extremely input preview heavy and cash heavy and there’s only a small percentage of output. We see across like agentic use use cases in employment only 1% of the request is to the output tokens. And and and this is this is very

[14:00] logical because it takes multiple turns, rinse and repeat. But this also decides your token cost because like if you’ve seen token cost, right? Deployment cost, right? Output is may have the biggest number, but even your input value is much smaller or the cash is much smaller, it it gets repeated heavily in in this use case. Yeah. This is not coding agent workshop, but one of the most common patterns that we we see in a lot of organizations, right? Is that is that typically

[14:32] typically in terms of like trying to scale up their AI agent deployments we within within the coding teams, right? They tend to have the best agent do the planning and a faster a faster cheaper agent do do the implementation and then maybe the best agent do the review again. There’s a good reason why this split is very common across all the agent frameworks is is that you get the best of both worlds because like the implementation phase is tends to be tends to be very token heavy process. A lot of processes repeated back and forth like key

[15:02] modifying the file, testing, checking for results, rinse and repeating. And and you and most and most of these agents are especially this especially like Gemini 5.3 flash is more than capable of doing a task at the same quality level as a much more stronger agent like I say Astra or Opus, uh respectively assuming those agents do the planning. We have worked with some of the organizations where literally the planning and review agent is the best frontier close muscle model, and then the workers that implement it is the GRM

[15:34] 5.3 flash as an example, or Deep Seek 4.1 flash. Yeah. One of the observations that we made from from this from from this kind of split pattern, right, is that unfortunately, as much as we wish that everyone does so, nobody really switches their model to save the company money. Um this people are lazy to switch the models in general. You you want to give an incentive to switch. Or or alternatively, if your agent harness is

[16:05] good enough, so like for example, some harness like M, they automate the process. Like like it uses a the weaker model as a baseline, and then it uses a big the smarter model to automate switching when it needs a smarter consultation. This This helps reduce the friction respectively, and helps improve your your token economics at user scale. Like a a major rule of thumb that we we now give our clients after going through a few times is that you want the smarter model,

[16:35] and since it’s already so expensive as a baseline, but you but you want the the faster model to the cheaper model to be faster. And that naturally sets an incentive. People want to get their work done fast. If the model is smart enough to get it done and it’s cheaper, they will just use it because it’s faster, not because it’s cheaper. Um we had teams where where where both models were the smarter one and the cheaper one was maintained at the same tokens per second speed, and it and as long as they had the token budget in excess, right, no one

[17:07] switched. And it and on the flip side, we have seen teams, which is the other extreme, where they set an extremely low budget, and so that if they use a smarter model, right, they just burn it in one day. Yeah, then everyone just switch to the to the Dharma into the faster model Dharma and faster model because that’s their budget. It’s like almost as if the smarter model didn’t exist. So, like be aware about your team dynamics on how they switch. The The best trade-off is to speed because people are naturally incentivized for it. So, faster,

[17:38] cheaper, they will just switch it to it respectively. Yeah. Once again, reminder, measure, and you measure two separate token keys. Uh and but this also goes beyond just measuring. For example, like CICD is a very common use case right now of things running in the background. Uh we we have helped set up for teams like faster tokens per second that that is running for the the users, like the humans, but much slower tokens per second

[18:09] um speed, but much cheaper at scale for the CICD pipeline. Uh and and this is just the nature of like what’s your priority respectively respectively across the task. Yeah. And you can control that at a key level. So, another major finding is that we had experience with deploying for for teams, right? Uh uh So, like for example, for some companies, uh how many of you had the fortunate or unfortunate experience of the CEO

[18:40] saying, “Everyone must implement AI now, and everyone must have a second brain now.” Yeah. Multiple organizations have started this. Uh in some cases, like even in in the UAE, it became literally mandated by by by by the law of the country. So, so, like a lot of departments are not prepared to know what is the trade-off respectively. So, a good rule of thumb, right? Well, developers tend to know,

[19:10] okay, all these smart models, what’s the trade-off uh between deep seek flash and GR553, for example? Most uh your your finance department have absolutely no idea. Your your support department has absolutely no idea. They they’ll just pick whatever’s the first model and probably just go with it. So So, our general rule of thumb is that give department models labels, but not the model names. And this also gives you a lot more control as you switch it out. Uh what like like advised earlier, fast versus smart, but in some cases also like finance agent or Excel spreadsheet

[19:41] agents. Um these are hyper-specialized agents that were fine-tuned to those tasks respectively. And and this also gives you a lot more control. It allows you to swap up the model. It allows you to split split the traffic and test in between with without without telling, “Hey, users, please try this.” The downside is also users may sometimes complain when you do that and you screw that up. But having that control is a good thing. Uh another pattern that we see, even though you do this, is maybe some of a dash preview version. So, that’s a variant of it, but

[20:13] it gives you control without without taxing the communication burden across the organization. And this is extremely important because like like some of the teams that we work with, right? We literally saw members running Llama 2 models when when we are talking when talking about like in this year because no one switched the option. Yeah, so you really really need to need to uh need to set this in place. Yeah.

[20:44] All right. Process track. Process track. A lot of things that I mentioned earlier don’t really apply as much to process track because process track tends to be a lot integrated into the applications, into the workflows, uh respectively. And and that’s just by the sheer volume of the traffic. Um yeah. And And of all of teams in the process track, right? Uh they tend to be a lot more focused on focused on the right sizing already by default because because if you’re running like trillions of tokens

[21:15] you most departments will not approve it like $10 per token million token. It’s just not possible. And and so so so they start they start early with the evals, the benchmark, and then subsequently finding the model that right size fits it. Uh yeah. So So the thing is like the common question is how do I know the smaller model is good enough? You don’t need to That’s the wrong question to say. You just need to make sure you set up your test cases, your evals, and your examples. And then subsequently just do the search process

[21:46] from there. Uh companies like us will be more than happy to help you because we have over 40,000 models. But then But then if you’re It’s also not that hard to just download 10 models from Hugging Face and just try. Uh So So from that you you just do the search, find the cheapest model that kind of like pass most of it, and then you just see how you iterate from there, fine-tune from there. Uh we also have a more specific process that I don’t think is unique to us that we’ll cover as well also. So for example, like in for one of the major telcos that we work with, right?

[22:18] We actually helped their team lower their inference cost 250k to 7.6k a month switching from existing close-source model just by going through this process of like, “Okay, you’re running the best model first. Let’s see what what models we can split off, and then subsequently what’s the models that we can fit in in, and then what can we fine-tune?” And this was This was like to uh beat the customer support use cases and and so on and so forth. Yeah. And to re-highlight back Jeff uh and simple Jeff, which is a open-source project that we did uh that replicates it.

[22:50] You’ll be surprised at how many m- percentage of your AI traffic is classification traffic. Uh At the end of the day, right? Like Yeah, sure. Answering the customer support is text. But even then, right? Even then, right? A lot of teams, right? Already have predefined text output that they put into the context for the model to output for most cases. And and you could use a classifier there. And there’s a lot This is a new new new shift within AI world.

[23:21] And that this is one of the big levers for this kind of processes in lowering your your token bill. Yeah. So, one one one example of such a model when it comes to fine-tuning. So, a lot of models and processes, right? Uh do benefit at this scale where you start to fine-tune your own model. Uh on the flip side, for coding models, well, there are organizations that will fine-tune models for you, like Devin, for example. Uh

[23:51] a lot of developers generally just want the best model. So, it’s kind of unless you are in this AI space, it’s kind of hard to keep pace in fine-tuning the best coding model. But on the flip side, for your domain, it might be worth it to fine-tune a domain model for your use case, especially if the model is much smaller. So, for AT&T, for example, when they fine-tuned their models, they they they went from being open class to like 27B to even 7B models. And they have

[24:22] published this. So, so we were one of their launch partners. And you can actually try their open dialogue models respectively. And and This is basically what they use behind the scene. And and it’s all about volume here. Like, I I think I think most of you understand the scale of AT&T and the call centers and things like that. Uh yeah. But it’s a good example of how you fine-tune models to to specialize use cases. And once you reach that point, other organizations that are major example of like Shopify have started doing this. And and things and and it

[24:54] doesn’t necessarily need to be a large-scale fine-tune. So, for example, in the Shopify use case, they did it because Shopify web store had a proprietary la- programming language for how to configure the the web store. And the existing models just weren’t that great at it, so they went to fine-tune it. Uh but and AT&T also they had examples of that uh in particular on like how to arrange the the cell towers and things like that. Yeah. Uh very telco-specific task. I might not be the right expert to answer that question. Uh but they had those use

[25:26] cases. So so they fine-tuned respectively. You too may have that those use cases. And how do you bootstrap such a model, right? Is that the good news is that uh you can easily bootstrap things these days because if let’s say you’re willing uh if the best model that is too expensive to run at scale can do the task, you can already get started. So so so an easy way to do this, right? Uh that we see very commonly is like either you generate your own data or prepare your own data, which is hard.

[25:58] No one likes to do that for some reason. But that but another common path is that they start with an expensive model and then they deploy in a small scale and then they generate they they generate data set. I understand that some labs it’s against their terms of service to do that, so you may want to check with your lawyers, but there are labs that openly embrace it. So, for example, Google Gemini uh their their frontier models, they literally have a dedicated API service for this. Uh so so so this allows you to

[26:28] build data sets respectively on your use case on a strong model, which you can then which which you can then reduce dramatically to let’s say a 7B scale. Uh alternatively, open-source models are more than happy for you to to to run and distill on, so you can run the best uh open-source models respectively as well. Once you collect them, you can then fine-tune the data and then you can fine-tune and respectively like different sizes to see what fits best. So, once again, like in the 80/20 example, they have the 27B and

[27:00] 7B for different levels of the call center. Like your routine your routine calls may come in at a Wait. I don’t think I can say which size goes where, but your routine calls can come in for the much smaller model, and then it escalates up due to some classifier triggers as an example. Then then so so so that’s how you get the traffic to flow, get the traffic split, and then you get it at that efficient level. Uh one of the things that we also tend to work with teams on on when doing this is that even even when they go through the stages and they

[27:31] completely split over their traffic to the fine-tuned model, because the best of the best models still progress, uh they get they uh we typically advise them to cut over a cut a part of their traffic as a shadow traffic to the best model to keep building the data set. And and and this allows you to ride the wave and progress of the best open models respectively. Uh and the unit economics is actually very important here, because like one thing that I would like to remind people, right, is people severely

[28:02] underestimate the the the speed that AI is going, especially for models that you can run much cheaper at scale. Like you take this laptop as an example. I like to measure, right, what is the best model that I can buy in the most expensive MacBook Pro here. And today’s best models, be it MoE models at 31B, 32B, 27B size, is already much better than GPT-4. So, essentially,

[28:33] this model that can run on a laptop is already better than the best model that you have last year. Give and take. People like to argue on the specifics, but let’s just say broadly. And when you fine-tune it to your task, that means if you can run that model on a laptop respectively, you can run it on on on your GPU servers at scale much more efficiently. Yeah. So, Yeah. So, that brings in to the next topic, buying GPUs which which which is apparently increasingly a challenge. So,

[29:05] yeah, that’s where companies like us come in. One of the things that we we realized through a lot of customer conversations, people are rather surprised that things don’t scale linearly. Uh what I mean by that is like there is a huge trade-off between tokens per second on an individual request to to the cost to the cost of the request itself. So, for example, if you do not care about about the cost, you could run the best the model, let’s say a fixed model, on

[29:37] the best hardware, on all eight GPUs, batch size one, and you could get, let’s say, 100 tokens per second, 200 tokens per second. If you like if you really want and and and this is not our specialization, like you really want like thousands of tokens per second, that’s where companies like Cerebras is more than happy to offer that as well. And it costs even more. So, there are definitely use cases where this makes sense. But, it’s but a lot of people fall into the trap of thinking, “Hey, so if I have the speed, maybe it’s half the cost.” It’s not even close. Like like a rule of

[30:08] thumb that I sometimes say like, “For every two x of speed, it’s three x the cost and it compounds.” In this specific example for JM 5.3, it’s like one JM node is like you can see the same server, 112 tokens per second for running individual requests. But, if you run 16 requests in parallel, you get about half the speed for all the requests, but you literally 10x the output total output. You And and that that gives you like literally around 9 to 10x lower in cost. In just like changing your changing your

[30:39] target speed profile. And so, when a lot of customers ask us like, “How do we deploy things at scale?” Sometimes the first question is, “What’s the model quality you want? And what’s the tokens per second speed that you want?” And then we start recommending the amount GPUs, the amount deployment. And this this target tokens per second is an important trade-off. Essentially, um in more extreme cases, right? If you really, really can run things at 10 tokens per second, rarely anyone does, but there are some weird use cases that allows it. You can get even more

[31:11] incredible to- total throughput volumes, respectively. Typically, we see customers choosing between 20 30, which is kind of like uh your chat GPT speed without without too much thinking, all the way until like 60, which is like the fastest speed. And if they want 120 tokens like it tends to be this this range. Most stick between 20 30 to 60, depending on how how long the chain of task is. Yeah. So, yeah, uh I kind of mentioned you generally only want to pay for the

[31:42] tokens per second speed uh when when it’s in front of someone. Uh whe- whether it’s in front of your developers or whether it’s in front of your customers. Those are the trade-offs that you want to make. And even within then, right? We have seen cases where even just a slight tweak down, right? Can easily save two times the cost, but has near minimal impact for the cus- uh customer, respectively. Yeah. And once again, background jobs, please don’t run it at 120 tokens per second. It makes no sense when you do that.

[32:13] Yeah. So, uh once you have Previously, I said measure, right? You’re able to see your your your traffic pattern. So, a lot of traffic patterns tend to be bursty in some nature with some base load because someone’s always running something at some time, uh especially background agents. And and this is where you can you can also plan your deployments, respectively. Uh I know it since we’re are doing financial a lot of financial may not have this as an option, but because they are only dedicated instance deployment,

[32:44] but if for some cases where people allow mixed where they have dedicated instances with some burst to the public cloud, this is where you have some flexibility respectively. So, like the biggest cost savings you have right now in the market is deploying a dedicated instance if you know your base workload. So, as long as you fully use it, you kind of have a savings there. But, it’s a bit more complicated depending on your traffic pattern, and a lot of these things can be tested and validated uh respectively. And this is like essentially what any inference company will work with you. It’s not unique to us. We’ll be like, “Hey, this is Do you

[33:15] know your traffic workload? Can you share some data?” And then subsequently, we’ll be like, “Okay, we propose this much. You can try switching to this.” And then we we generate we can generally show you your savings respectively. And in some extreme cases where you have a lot of spikes, you may want to have limit your dedicated capacity to a certain amount and let the spikes spill over to the public cloud respectively. The different use cases uh have different right sizing, but this is something that by measuring your token workload once again at the beginning,

[33:46] you can start exploring these options, and the savings can be huge. Like once again, like for the customer that we served two 2 trillion token, and that was like uh 4.8 Opus class model, they are paying less than 0.0 $3 per million token. Like you can’t get that price anywhere. Yeah. So, yeah. Simple disclaimer is the spikes really matter. Uh it’s very rare that someone has a short spike at the extreme end where they like

[34:18] run a workload every month at that scale, and then nothing else matter. So, so usually some base workload exists. It’s just how big of a base workload. Yeah. Yeah. So, yeah. Then the last one is check your processes. Uh this has nothing to do with inference optimization from here onwards. Um Some slides may sound that very critical of AI, but I’m generally an optimist. Uh just this I just want to lay that out because things can be quoted out of

[34:49] context. So, one of the uh Pandora’s Box question or problematic question that we are starting to see is that a lot of organizations starting to ask, “Hey, I’m s- 10x 100x in my token spend, but I’m not seeing results at that same scale.” Um respect- like like we are starting to see reports from from various organizations like uh AI where AI has limited productivity only has 6% productivity or 7%, which is not the

[35:19] scale that a lot of us were promised or we envision. And and unfortunately, this is the case because we are at the stage where everyone’s just taking a giant hammer and hammering everything. Um it’s not that AI is not useful, it’s just that we tend to just spam it everywhere. And yeah, if uh there’s a s- there are times where I just want to like, “Can you please not do this as another co-pilot?” Because it’s just too much of it. You need to think of how you

[35:50] use it respectively. Uh um yeah. And and another major issue that we start to realize is that well well AI’s are are being deployed at a larger scale and more frequently, and people get faster in creating stuff, the organization processes may not go as fast. The first bottleneck for for coding coding environments will be the CICDs, and you all may heard that CPU becomes a bottleneck respectively. Uh another another thing is like is just

[36:21] the processes in place uh respectively. How do you trust? How do you review? I think the previous speaker spoke at length at trust. Yeah, the lack of trust is what slows things down. And this could be rightfully so. Maybe the agent the the AI agent was badly designed and shouldn’t be trusted. But it also flip and inverse. What if hypothetically the that agent was doing everything perfectly? But people weren’t trusting it because it didn’t have the test in place, it didn’t have the validation, and it didn’t build that trust. That slows things down. And these things

[36:53] make and these things have a much bigger impact. So, once again, be very wary about how the hammer is being used because you need to make your adjustments accordingly. So, and this goes back into saying like tokens are not work done. You have uh um um and one major example that I will highlight, right, is is this happens more often than than I would like, is that sometimes spamming more agents and

[37:24] more tokens sometimes means you get the same task done multiple times. So, one of the anti-patterns that we started seeing, right, uh we are well in overall the engineering organization improve productivity by clearing more issues quickly, automating clearing of issues, for example, like when someone like when a QA and and things like QA teams reporting an issue and the agent automatically fixing it without even an engineer, those are great. But one of the one of the common issues that we start facing is that people get ambitious

[37:54] really fast. And they instead of doing small changes, they start doing huge changes like changing like half the code bases or one quarter of the code bases. Sometimes when this is planned with proper testing, it’s great. But a lot of times, right, the change is happening at such a large scale, right, the bottleneck becomes the on the reviewer to merge the code. And because because everything is done on such a large scale where a human cannot process it, one of the common anti-patterns that we start seeing is that okay, someone has implemented the

[38:26] the there’s issues being done. And because there’s so much code being generated, issues that do not have code generated do not get reviewed and do not get picked up by the reviewer. So, someone needs to generate the code using an agent. And then when the agent generate that giant pile of code, which should be a lot less if they were to like properly review prompting and stuff, the reviewer look at it and it’s like, “Huh, this is too many code. Can I ask my agent to highlight what changes are relevant and then re-implement it?” And and and in the end they started

[38:58] rebuilding it by hand with the with the agent. So, they literally discard the first agent’s job. There’s multiple good reasons why this happened. For example, like reviewers want to maintain control and quality of the main code base, but this is a very common example of a bottleneck where you where where if you didn’t think the process through, you’re just throwing more and more things. And respectively, and the speed is not increasing. So, review your processes. A good way around this is naturally to to to instill

[39:29] better testing practices and so that you can automate that and filter out. Also, reminding teams to like, “Hey, split up your your your merge or or make it more modular to make it easier for the review process.” Like things like that. These are human processes. It has nothing to do with the AI. And yeah, we tend to get too excited about AI sometimes. So, this is not just a code problem. Uh we are starting to see like because uh AI agents are being deployed to make decks, this deck was entirely

[40:01] design-wise was generated by AI. I went through multiple iterations. It’s not a zero-shot. I I went through every page like at least 30 times to to change the text, but the design was done by agents. And and sometimes within the organization you’re starting to notice people that just one shot from the entire slides, things like that. And and they start passing it around. They start doing meetings. And then it’s on everyone else to filter what’s the inconsistency, what’s uh what’s the misalignment? Why is this two

[40:31] data points completely different? This is also another example of like same as the previous example, people generating code or people generating slides or people generating report and the burden shifts onto a some human down the road to verify things. So, be very aware about this organization change. Uh why am I still an optimist is that I I don’t think this is necessarily a bad thing in itself because the problem is everyone needs to learn. And this is where we just start adapting our processes accordingly.

[41:02] Uh and the other major thing is that well, there are a lot of common examples on how to use AI. You’ll know your subject domain for your organization better. And there will be use cases where an AI could be used in place to automate a process, for example, that could save your organization uh millions of dollars or increase your productivity at a grand scale that that only you will know and not me as an AI expert will come in. I like to point to the most uh famous

[41:33] example that Walmart had where was it Walmart? I believe it’s Walmart. Where they literally started putting a stool a stepping stool inside every single truck. And that was like the simplest change, but it lowered their bill by the millions because it lowered back injuries across for heavy goods respectively. It it’s some something specific like that with the use of AI. And and it may not even necessarily be a the best AI model, but actually can have the biggest impact. Yeah. Yeah. So,

[42:04] uh doubling down on my previous point, uh one of the term that that was coined by uh that that’s been trending is called the slot grenade. So, generating lots of things in AI and then leaving it to someone else. Do not let slop grenades happen. Uh and this is a culture thing and a processing. Yep. So, the some guideline rules that I would set and this is more subjective. People people disagree. Um to prevent a slop grenade from happening, enforce that people should

[42:35] own what they hand over or generate. So, for example, this slide, I own every text that is generated. If there’s an issue, that’s on me. It’s not my AI agent who who who has an issue. I do not get to hand it off to an agent. I must own the responsibility. Same thing for code, same thing for anything that is generated. And you also have to measure outcomes, not usage. Uh And so this gets more complicated because I I don’t want to explain too too long to

[43:06] this, but like there there is like this simple formula that’s that I think people take as a rule of thumb, tokens times price divided by outcomes someone actually use. And and and this help guide a lot of things. Smaller, more efficient models, faster model, bigger model, yada yada. But, what I don’t like about this is that another analogy that I’ll use about AI is think of it more as like supplements or steroids that enhance the team. Think of it as uh like if let’s say I use construction work as an example.

[43:38] It let’s say I can use it to increase the muscle mass for the workers. For example, not that it’s ethically to do so. I know that’s not the case, but let’s just say as an example in the train of thought. Some teams will have it and they improve productivity, some teams don’t. But, even without that, it’s quite clear some teams are much better than others. And and so the AI being a supplement here, right, doesn’t necessarily change everything. So, you need to be aware that outcomes outcomes are hard to measure

[44:09] respectively, but it’s something that you can start measuring and observing most importantly back to the first step. Measure. You know the tokens spent per department, per team, and you can start seeing which team is performing better and you start seeing how much tokens they use. You can start seeing what works. Yeah. Yeah, as I said, this is flawed measurement. So, yeah. Uh that’s that’s the high-level overview respectively. And if if you want to to like kickstart your process internally within your organization, you can you can either

[44:39] talk to me or my team or like you have six questions for you to start asking like who team spent what, what’s the what what must you test to use a cheaper model, what’s your base load, what’s the default model for each team, and which workload has a person waiting that you need something faster, yeah. And how much of what we generate is useful. These are like guideline questions for you to start asking to refine your tokenomics. Yeah. So, Q&A. Yes. >> Yeah, so when you mentioned

[45:09] fine-tuning models, is that >> Test, test. >> Um >> Yeah, I’m trying. >> like SFT sort of fine-tuning or is there like other sort of uh fine-tuning methods that you have depending on what specific use case there is or what data there is? >> Uh okay, so in general, it tends to be SFT, but I don’t think um Well, we do provide fine-tuning services and it tends to be SFT. I there is a lot of methods that are happening right now currently. I know RL

[45:41] is very sexy right now, especially in the coding environment, because it’s easy to generate the data in the loop, but what we realize for a lot of organizations, especially like in New York, for example, financial institute, things like that, there’s not really an RL environment for financial task, for example. And and so it tends to be more SFT base. And and there are also other organizations like adapted adoption AI where where they are starting to also

[46:13] automate the the the refinement of the data sets for you to train the model be SFT base or thinking thinking of machine base. Focusing on this might be the wrong question. It to me generally what people should focus on is the evals respectively. So here’s a good example for Jeff that came when the Jeff model came out and then we did the open source project called simple Jeff which replicates the Jeff API for existing open source model. A lot of

[46:44] people quickly realized that the Quen 27B was really good at this task. And and there were multiple teams that went to fine tune the Quen 27B. I on on our side because we are trying to take the approach like our company like we want to accept any model and then we just build the API on top of it. We started taking the approach of like hey we see the benchmark we see the existing model why don’t we prompt tune it instead. It’s not even fine tune. And then and then two weeks later as hugging face went to do all the benchmarks at scale like over 10,000 questions things like that. Somehow my

[47:15] prompt tuned Quen 27B beat most of the 27B fine tune. So this this is not a flex because I’m quite sure now my model is beat by the recent Cloudflare fine fine tune model that was done on a more proper basis but it’s more of like the tuning method might the tuning method might not be the right question it’s more like what’s your evals and what’s the results that lead to it. >> And follow for that do you need do you need to collect golden traces for

[47:46] the set of data you need if you’re doing SFT or whatever it is or can you do it let’s just say like your your prior task the frontier models get like 80% accurate right? So maybe 20% of the time it makes some sort of mistake. If you fine-tune on that, won’t the fine-tuned model also get like 20% of it wrong? Are you supposed to filter that out somehow and get only the golden traces for training, or can you just throw all the traces in and train? >> So, this is more of a personal opinion technique because uh so, the generally, I try to split the data

[48:18] set because people are lazy filter. Um so, I try to at least get a golden trace data set. And the golden trace data set maybe is much smaller uh respectively, and we just and we then we fine-tune that with a much heavier weightage uh as well. But, there have been multiple papers especially as especially with thinking tokens that even the non-

[48:48] uh the failed task, right? The as much smaller model, when you fine-tune, tends to benefit from the training because it improved the thinking process even if it got the wrong answer. Um this is something This is really a good case of like try and then measure, and it works 70% of the time. Sometimes, you just you need to increase the golden trace ratio, but it’s a general rule of thumb. I think for a lot of customers when they’re trying to to SFT down a smaller model, the general rule of thumb they’re trying to keep is

[49:18] can I keep to the near same level of performance, and maybe the eval is down 1% or even in some cases it improved by 10% because the base model wasn’t specialized for these tasks. And more importantly, does it 100x reduce my bill? So, that’s usually the motivation respectively. Yeah, golden samples are critical if you want to do beyond the baseline. And sometimes that requires humans to actually look at the data, which as much as I love my customers to look at the data more,

[49:49] people don’t like to do that. >> Hi. Um how would you deal with uh code spend that would mostly come from Claude’s code and all the integrations there? Cuz then your model is fully locked into the Claude uh ecosystem, I suppose. Do you have any advice on how to deal deal with those type of situations? >> Uh yeah, unfortunately Claude code is the example of fully locked in. >> [laughter] >> So, uh sometimes sometimes the first

[50:20] movement is actually getting um them able to switch the harness. Um harness it seems to be a lot more flexible thing right now. Like we have seen organizations that are like fully locked in. Like I’m only going to use Devin only or Mboni. We have seen organizations that um that are more flexible. Like literally they are running their they are creating their own agent harness. And I’m my response is like, “Why? Why are you creating your own agent harness from scratch?” Uh but like a common one that we see people

[50:51] switching to is for example Pi. And this is also because there’s a lot of excitement around it. People have shown that even with the same model, it gets a much cheaper cost per token because of the way it’s simple and efficient. Um and from there on, the I think the beauty for the Pi coding agent harness is that it’s easy to adapt because it’s so si- so lightweight. We’ve seen a lot of teams that just start prompting their agents to make modifications. And once once they have that, then then they start getting the cycle of experimenting and changing. Uh

[51:22] a common way to get them to be very incentivized to change is to actually introduce a a a good enough model that is really fast, like 100 tokens per second. And then suddenly they start giving that a try. And some people start or like some of the first shift would be they still use their Claude code as their planner. And then they instruct the Claude code, “Use this Pi agent with this model to do the implementation.” Hence the planner implementation split. It’s more yeah, and that’s where the transition started to happen. It’s not easy to change people’s agents, but

[51:54] yeah. >> Um Yeah, so an example of these could be perhaps to expose this this smaller agent as an MCP in inside cloud or having these tools where you can offload I I suppose is that something that you would you you would say could work? >> MCP is more tricky because MCP agents unless done right don’t have access to your file system. So typically it’s just something way simpler like pies installed and they run the batch command pie this.

[52:25] Yeah, that that’s usually the case. >> Thanks. >> Yeah. >> Can you share if possible any case studies about caching solutions being very thoughtful about caching and the outcomes that have been generated for specific customers even if it’s anonymized? >> What’s the specific challenge you’re talking about? You do one caching you

[52:56] Okay, is your question more like you want anonymized you do Wait, you do not want customer private information to save in the cache. >> No, so so like with customers that you’ve worked with have you got any case studies you can share about the outcomes that they’ve been able to generate because of being thoughtful about how they cache and different sort of caching methodologies? >> Uh I think this one we can take offline, but in general for our larger scale customers we deploy them with dedicated

[53:26] cache. So it kind of solves a lot of PI issues because it’s the the cache is only for that customer. Um yeah, and obviously there’s prompt formatting, but I may need to dig in more specifically like what you’re trying to ask here. The short answer is yes, but there’s a lot of way to interpret this. Yeah. >> Cool. Sorry about that. >> Uh thoughts on turn or task-based auto routing? >> Oh,

[53:56] um I’m a I’m generally more towards task-based. Um mostly because it’s much easier to control expectation at a department organization level. So, this this is back to like, hey, a department may have a label model and I kind of auto router that model for them. Uh I know there’s a lot of hype right now for turn-based auto routing. One of the issues with turn-based auto routing is that you need to lock down your your turn-based auto routing to let’s say at most two to three models.

[54:27] If not, your cache will be extremely inefficient to be used. So, um so for example, we have seen turn-based for GRM 5.3 and GRM 5.3 flash. Make sense. But if you put in 30 models and it keeps changing your model every turn, your your low cache hit rate will start to wreck your your optimization. >> Yeah, that’s what I’ve seen before. I saw I saw it like request level and it just didn’t make sense and then >> Yeah. But two models tends to be okay. Uh task and organization makes the most sense.

[54:57] Yeah. >> Yeah. Yeah, I agree. >> All right. Okay. Thank you very much and uh if anyone wants to find me specifically for more questions, feel free to just come up front and ask me or find me by the side once the next speaker’s here. Yeah. Thank you very much.