Inferência de LLM — Passado, Presente e Futuro: Para Onde Vai o Valor?
Nos últimos dois anos, a inferência de LLM tem sido uma das camadas mais disputadas da infraestrutura de IA. Dezenas de provedores de inferência, nuvens de GPU, projetos open-source e fornecedores de chips perseguiram o mesmo objetivo: servir um modelo treinado de forma mais rápida e barata que a concorrência.
A atração se baseava em uma ideia plausível. A inferência parecia um problema de software com um fosso de software. Kernels melhores, um escalonador mais inteligente ou uma decodificação especulativa mais robusta podiam justificar preços premium ou margens melhores pelo mesmo preço. Por um tempo, um engine interno foi uma arma competitiva real, e benchmarks ganhavam contratos.
Esse período está chegando ao fim. A inferência importa mais do que nunca, e o mercado continua crescendo, mas o valor defensável se afastou do engine. A camada de engine está se commoditizando rapidamente. O valor está migrando primeiro para as operações e plataformas de serving, depois para capital, capacidade de GPU e, por fim, para os próprios data centers.
O desempenho de software ainda importa. Um engine lento ou pouco confiável pode desqualificar um provedor. No entanto, o bom desempenho se tornou amplamente disponível, o que dificulta que qualquer empresa cobre por ele. A questão não é mais se o engine gera valor, mas quem captura esse valor quando o engine se torna infraestrutura comum.
Três gerações de hardware tornam essa mudança visível. O mesmo padrão explica a competição entre os provedores de inferência hoje e para onde ela provavelmente caminhará.
Parte I: O Passado — Quando o Engine Era o Fosso
Três gerações, três checklists
Cada geração de hardware da NVIDIA veio com um checklist para um engine interno. O que mudou foi a velocidade com que o checklist se tornou conhecimento público e o quanto restou de vantagem depois que todos o completaram.
A era Ampere (A100). A barreira inicial era concreta. Um engine que suportasse CUDA Graphs para eliminar a sobrecarga de lançamento, implementasse decodificação especulativa como EAGLE-1 ou Medusa e oferecesse quantização INT8 W8A8 sólida estava à frente da maior parte do mercado. A engenharia era difícil, mas delimitada, e completar essa lista curta colocava um provedor no topo da categoria. Esses recursos ganhavam contratos.
A era Hopper (H100/H200). A lista cresceu e se dividiu em duas. Para uma implantação única, seja uma réplica, um nó ou alguns poucos, os diferenciais eram FlashAttention-3, atenção FP8, decodificação especulativa EAGLE-3 e quantização FP8 W8A8. Implementações sólidas produziam resultados de nó único excepcionais.
Hopper também abriu uma segunda frente na implantação desagregada. O suporte à desagregação prefill–decode (PD), ao paralelismo de especialistas (EP) para as arquiteturas MoE cada vez mais dominantes e ao offload de cache KV pela hierarquia de memória fazia diferença na escala de cluster, onde estavam os maiores contratos. Essa camada exigia engenharia de sistemas além do trabalho de kernel. Por um tempo, ela separou os provedores mais fortes de todos os demais.
As duas camadas recompensavam capacidades diferentes. Times de kernel ainda podiam vencer um benchmark em uma implantação contida, enquanto as maiores cargas de produção exigiam coordenação entre máquinas, pools de memória e domínios de falha. Essa segunda camada demorou mais para ser copiada e deu aos provedores uma janela maior para transformar trabalho de engenharia em receita.
A era Blackwell (B200/B300/GB200/GB300). Aqui o checklist se reduziu a um item principal: otimização NVFP4. A rota principal não é mais uma implementação independente. Os times integram os cubins trtllm-gen fornecidos pela NVIDIA ou trabalham diretamente com o TensorRT-LLM. Decodificação especulativa, caminhos FP8 e FP4, suporte a desagregação e paralelismo MoE já estão na stack de referência.
Blackwell muda a decisão de fazer ou comprar. Construir a stack do zero já demonstrou profundidade técnica; agora, isso pode significar recriar o trabalho do fornecedor enquanto os concorrentes usam os mesmos engenheiros em outras frentes. Uma implementação proprietária ainda pode ser adequada para um modelo ou implantação incomuns, mas não é mais o caminho padrão para o desempenho de ponta.
A inferência não tem segredos. Toda técnica importante tem um artigo, uma implementação open-source ou um binário do fornecedor. O conhecimento que antes circulava por um punhado de times de performance está empacotado em código que qualquer grupo competente pode inspecionar ou integrar. O checklist ainda qualifica um engine, mas não o diferencia mais.
Por que o TRT-LLM se tornou a base de referência de Blackwell
A posição do TensorRT-LLM na era Blackwell decorre dos incentivos nos dois lados do mercado.
A NVIDIA precisa que o TRT-LLM tenha um bom desempenho. O software sustenta os benchmarks de novos hardwares da empresa, incluindo submissões InferenceX, promessas de lançamento e resultados de keynotes. As otimizações para um novo chip chegam ao TRT-LLM no dia um, apoiadas por uma grande organização de engenharia de kernel e um runtime competente.
Engines independentes não conseguem reproduzir essa vantagem apenas com esforço. A NVIDIA enxerga o roadmap de hardware, controla as camadas de software mais baixas e tem um motivo comercial direto para fazer cada geração parecer forte no lançamento. O TRT-LLM é onde esses incentivos se encontram.
Ao mesmo tempo, um punhado de famílias de modelos open-weight de fronteira agora responde pela esmagadora maioria do tráfego sério de produção. Os provedores têm menos necessidade de suportar centenas de arquiteturas. Com esse conjunto menor de modelos e o hardware Blackwell, o TRT-LLM oferece o teto de desempenho mais alto disponível. A amplitude de suporte a modelos, o argumento tradicional para um engine de propósito geral, importa menos quando a própria demanda se estreitou.
A produção agora recompensa a especialização. Um engine que lida bem com uma cauda longa é útil, mas um provedor ganha a maior parte de sua receita com os modelos que os clientes realmente solicitam. Em uma matriz pequena de modelos populares e hardware NVIDIA atual, o desempenho máximo supera a amplitude arquitetural.
Desde meados de 2025, mais times de inferência pararam de manter engines totalmente independentes e migraram para o desenvolvimento secundário em cima do TRT-LLM. Sua fraqueza persistente é a usabilidade. A experiência do desenvolvedor é difícil, mas um time pago para extrair os últimos 20% de uma frota de GPUs vai tolerar um toolchain complicado. A usabilidade desempata; o TRT-LLM em Blackwell não tem concorrentes para desempatar.
Esses times não pararam de fazer engenharia. Eles ainda ajustam modelos, corrigem o comportamento do runtime e constroem os sistemas de produção ao redor do engine. O que mudou é a camada a partir da qual eles começam. Partir da base da NVIDIA direciona mais esforço para a carga de trabalho deles e menos para reproduzir maquinário genérico.
O acelerador: agentes de codificação
A convergência open-source e o avanço vertical da NVIDIA já estavam encurtando a vida útil das vantagens proprietárias. Nos últimos seis meses, os agentes de codificação encurtaram ainda mais esse ciclo ao reduzir o custo da engenharia de inferência.
Trabalho de kernel, mudanças no runtime e infraestrutura de serving podem ser concluídos mais rápido com assistência de IA. O Intent Lab levou cerca de uma semana, trabalhando com assistência de agentes no TRT-LLM, para entregar otimizações que produziram ganhos ponta a ponta muito grandes. Antes, um trabalho dessa proporção poderia ocupar um engenheiro dedicado por um trimestre.
A economia do trabalho em engines proprietários muda com essa velocidade. Uma técnica que exigisse seis meses de engenheiro e comprasse nove meses de exclusividade poderia justificar o investimento. Se leva duas semanas para construir e os concorrentes a reproduzem em três, o resultado não é um fosso; é uma esteira. O trabalho continua tecnicamente difícil, mas a vida útil da vantagem está se aproximando de zero.
O que importa economicamente é quanto tempo dura a vantagem. Uma otimização difícil ainda pode ser comercialmente fraca se ela se difundir antes que a empresa recupere o custo de construí-la. Os agentes de codificação não tornam a engenharia trivial; eles fazem a exclusividade expirar mais rápido.
O que resta para os engines abertos: comunidade, usabilidade e pouquíssima lealdade
O vLLM, o SGLang e outros engines open-source atendem o mercado deixado em aberto pela experiência de desenvolvimento difícil do TRT-LLM. Muitos usuários fora dos provedores com times de inferência dedicados são pesquisadores ou executam geração offline: cargas de trabalho batch orientadas a throughput, em vez de serving online sensível à latência. Nesses cenários, a diferença de desempenho em relação ao TRT-LLM é modesta, muitas vezes insignificante.
Esses usuários otimizam para um fluxo de trabalho diferente. Eles precisam subir um modelo rapidamente, trocar de arquitetura sem reescrever a stack e encontrar respostas quando algo quebra. Alguns pontos percentuais de throughput raramente justificam dias lutando contra um runtime, especialmente quando a carga de trabalho não tem uma meta de latência interativa.
A adoção depende, em vez disso, da facilidade de uso, da documentação e da comunidade. Instale o pacote, aponte para um repositório Hugging Face e exponha um endpoint compatível com OpenAI. Para um pesquisador ou um pipeline de geração batch, essa é toda a decisão de compra.
Adoção não é lealdade. A padronização na API compatível com OpenAI reduz a troca de engine, no caso mais simples, a uma alteração no base_url. Um time pode rodar o vLLM hoje, testar o SGLang amanhã e comparar os dois no final da semana. Os engines abertos precisam continuar competindo por cargas de trabalho que já conquistaram.
Os usuários se beneficiam dessa portabilidade; projetos que buscam controle duradouro, não. O tamanho da comunidade pode atrair uma carga de trabalho, e a documentação pode mantê-la por um tempo, mas nenhum dos dois impede que um time repita a comparação quando um concorrente lança uma versão mais rápida.
Os custos reais de troca aparecem na produção online. Eles vêm de monitoramento e alertas, pipelines de implantação, recuperação de desastres, recuperação automatizada de falhas, correções de bugs acumuladas e a cauda longa de casos extremos de produção. Só o parsing de chamadas de ferramenta já fornece vários deles. Essa camada operacional cria lock-in, mas é um atrito de migração, não um fosso de capacidade. Um time competente consegue reproduzir isso em torno de outro engine em semanas. Mais importante: esse conhecimento pertence à organização de SRE do usuário, então o projeto do engine não captura nada disso.
Comercialmente, o conhecimento operacional torna uma implantação aderente sem dar poder de precificação ao fornecedor do engine. O usuário arca com o custo da migração e é dono da maior parte dos sistemas ao redor. Mesmo quando a substituição é trabalhosa, o engine em si não garantiu a conta.
Open source como bem público
Os principais engines open-source aceitaram esse papel em grande parte. O vLLM e o SGLang devolvem quase todo o seu trabalho para a comunidade. O objetivo estratégico deles é a adoção; o resultado é uma base gratuita cada vez melhor em recursos, desempenho e estabilidade. Na prática, o ecossistema está subsidiando a inferência de ponta para todos.
Há um custo para os próprios projetos. Cada melhoria na base reduz o espaço para diferenciação, inclusive para os engines internos e para os engines abertos que fizeram a melhoria. Ao elevar o piso, esses projetos também comprimem o valor da própria camada deles.
O sinal: as empresas de engine estão subindo na stack
O comportamento dos autores de engines oferece a evidência mais clara de que um engine sozinho não consegue capturar muito valor.
As empresas por trás dos dois principais engines open-source começaram a assumir trabalhos de serving em produção, assinando, segundo relatos, contratos de inferência com laboratórios de modelos de destaque e plataformas de consumo. A justificativa declarada faz sentido: operar produção é o caminho mais rápido para expor as falhas que um engine precisa lidar. Fazer dogfooding em escala encontra os casos extremos.
Isso também coloca essas empresas em competição com provedores que antes eram seus usuários e defensores mais importantes. O projeto impulsiona a adoção, enquanto os contratos de serving geram receita. Esses papéis são difíceis de conciliar quando os usuários do projeto vendem o mesmo serviço.
As empresas de engine são compreensivelmente cautelosas com o rótulo de provedor. O ecossistema delas depende de empresas que querem um projeto upstream neutro, não um concorrente subsidiado. No entanto, uma vez que a empresa de engine opera produção para clientes, a sobreposição é real, independentemente de como o trabalho é descrito.
Entrar no serving diz mais do que a explicação que acompanha. Os autores de engines não esperam que a camada de engine sustente um negócio sozinha. A questão é se o serving é mais defensável.
Parte II: O Presente — O Que Realmente Diferencia os Provedores
As vantagens reais dos incumbentes não têm nada a ver com kernels
As vantagens duradouras dos principais provedores de inferência, como Together AI, Fireworks e Baseten, não aparecem em um benchmark de engine.
Vantagem do pioneiro e marca. Quando um laboratório de modelos precisa de um parceiro de lançamento ou uma startup nativa de IA precisa de inferência em produção, essas empresas entram na primeira shortlist. Mindshare parece algo intangível até decidir contrato após contrato. Ser a opção padrão em um mercado acelerado vale mais do que uma vantagem apertada em benchmark.
A plataforma. Anos de trabalho se acumularam em ferramentas de implantação, observabilidade, controles empresariais e conformidade. Um novo entrante precisa reconstruir essa superfície peça por peça enquanto os incumbentes continuam expandindo-a.
Nenhum desses recursos vence um ranking público de velocidade, mas juntos eles decidem se um cliente consegue levar uma carga de trabalho para produção. Eles também se acumulam. Cada implantação expõe outro controle ausente ou modo de falha, e a correção passa a fazer parte da plataforma oferecida ao próximo cliente.
Capacidade de GPU e sua cadeia de suprimentos. Essa é a vantagem mais difícil e a menos discutida. Os provedores precisam garantir alocações entre gerações de hardware, negociar com nuvens e neoclouds, gerenciar frotas heterogêneas e planejar capacidade contra uma demanda irregular. Os incumbentes aprenderam a fazer isso sob pressão. Quando um contrato grande chega, a pergunta decisiva geralmente não é qual engine é mais rápido, mas quem consegue colocar milhares de GPUs online no próximo mês.
Os entrantes tardios estão respondendo a essa economia. A Modal lançou um serviço de inferência. A Nebius adquiriu a Eigen AI para adicionar serving à sua nuvem. A inferência tem margens melhores do que horas de GPU cruas, então as nuvens de GPU estão subindo enquanto as empresas de engine entram no serving vindo de baixo. Provedores, nuvens e empresas de engine estão convergindo para a mesma camada porque é lá que o valor se concentra atualmente.
Cada grupo começa com uma vantagem diferente. As empresas de engine trazem expertise em software, as nuvens de GPU trazem capacidade, e os provedores estabelecidos trazem clientes e experiência operacional. O movimento delas em direção ao mesmo produto torna as diferenças restantes mais fáceis de enxergar: distribuição, capital e a capacidade de operar um serviço confiável em escala.
Por que os rankings de TPS em batch pequeno vão desaparecer
O ranking de velocidade de saída com baixa concorrência no Artificial Analysis ainda atrai atenção e, por anos, foi um proxy justo da qualidade de engenharia. Ele diz menos a cada ciclo de hardware. Os testes padrão de API usam uma única requisição ou dez requisições paralelas. Nessa carga, um provedor pode combinar hardware mais novo com decodificação especulativa sensível à carga, como o DSpark, gastar mais capacidade de batch em cada requisição enquanto a máquina está ociosa e publicar um TPS por usuário extraordinário. O número é real, mas estreito: ele mostra com que rapidez um endpoint com carga leve consegue emitir os tokens de um usuário, não com que eficiência uma frota atende a um negócio.
A produção tem um objetivo diferente. Primeiro, manter o TPS por usuário acima do nível que a aplicação exige. Depois, maximizar o total de tokens por minuto por GPU (TPM/GPU) sem cair abaixo desse piso. Quando a experiência do usuário é rápida o suficiente, mais um incremento de TPS com carga leve pode valer muito menos do que atender mais usuários simultâneos na mesma GPU. O custo por token entregue importa mais do que a posição no ranking.
A decodificação especulativa acentua essa distinção. Um trabalho de verificação que é barato em batch baixo pode consumir capacidade de batch valiosa sob concorrência, então uma configuração ajustada para o maior TPS com carga leve não precisa estar na melhor curva de custo de produção. O resultado útil é uma fronteira de Pareto: TPS por usuário em um eixo e TPM/GPU no outro, com o piso de velocidade da aplicação selecionando o ponto de operação e o custo por token decorrendo dele.
O TPS em batch pequeno não é inútil. Ele estabelece um piso de interatividade e expõe endpoints que são claramente lentos demais. Os próprios testes de concorrência progressiva do Artificial Analysis apontam na direção mais útil, medindo o que o sistema como um todo consegue sustentar. O que vai desaparecer é a leitura de que o vencedor leva tudo no ranking de batch pequeno. Os compradores de produção vão se importar menos com quem publica o maior TPS e mais com quanto tráfego pago cada GPU carrega enquanto o TPS por usuário permanece acima do piso exigido. É o padrão deste texto em miniatura: o número mais visível deixa de prever para onde o dinheiro vai.
Suporte no dia 0: o fosso do relacionamento se aprofunda
Uma mudança em 2026 fortaleceu ainda mais os incumbentes: os desenvolvedores de modelos estão cada vez mais fechando parcerias diretas com provedores de inferência.
O suporte no dia 0 antes passava pelos engines open-source. Antes de um lançamento, um laboratório coordenava com o vLLM ou o SGLang; o engine integrava o suporte; provedores a jusante adotavam. Isso dava aos engines abertos um lugar central na cadeia de distribuição.
A antiga dependência está desaparecendo. Os principais laboratórios agora concedem acesso antecipado aos provedores de inferência antes do lançamento, às vezes antes até dos times de engines open-source. Um laboratório precisa de mais do que um pull request integrado no dia do lançamento. Ele precisa de capacidade de produção ajustada e testada sob carga, com um SLA. Um provedor pode entregar o pacote completo; um engine fornece apenas o primeiro componente.
O acesso antecipado é um relacionamento, não uma técnica publicada; por isso, os concorrentes não conseguem reproduzi-lo a partir de um artigo ou de um kernel. Os laboratórios o concedem a parceiros em quem já confiam, reforçando provedores que já têm marca e capacidade. Os engines open-source, por sua vez, estão perdendo seu lugar na frente do pipeline de lançamentos. Os provedores estão cada vez mais liderando o trabalho do dia 0, e os engines seguem.
Um lançamento bem-sucedido aumenta a probabilidade de um provedor receber acesso antecipado no próximo, e o acesso antecipado melhora suas chances novamente. Diferente de uma otimização, o relacionamento não se torna disponível para o resto do mercado após a publicação.
O fim do jogo na camada de serving: um jogo de capital
Quando os concorrentes chegam à camada de serving, eles enfrentam um padrão comum. Um provedor confiável precisa sustentar seu SLA sob pressão, entregar latência de primeira linha e preservar a precisão. Esses são requisitos operacionais difíceis, e eles separam os provedores dos revendedores de GPU. Eles também são o custo de entrada: cumpri-los garante a participação no jogo, enquanto não cumpri-los elimina um provedor.
Engines compartilhados e técnicas públicas aproximam provedores sérios de desempenho, confiabilidade e preços comparáveis. Acima dessa linha, a capacidade de GPU se torna a variável decisiva. Em outras palavras, a disputa vira uma disputa por capital.
O flywheel é direto. Capital garante capacidade de GPU. Capacidade viabiliza contratos maiores com laboratórios de modelos e empresas, que concorrentes limitados precisam recusar. Esses contratos geram volume de inferência e ARR. Um ARR maior sustenta uma rodada de financiamento maior e uma avaliação maior, o que paga pelo próximo bloco de capacidade.
Uma frota pronta também muda a conversa de vendas. Um cliente escolhendo um provedor para um lançamento importante não pode contar com capacidade que talvez apareça depois. Ele precisa de máquinas reservadas, conectadas e prontas. Um provedor que consegue comprometer esses recursos tem uma vantagem antes mesmo de latência e preço por token entrarem na negociação.
Para engenheiros, esse é um desfecho desconfortável. O fim do jogo no serving se parece menos com uma competição de software e mais com infraestrutura intensiva em capital, próxima dos primórdios da computação em nuvem, das companhias aéreas ou das telecomunicações. A excelência operacional determina a sobrevivência; o acesso ao capital determina a escala.
As operações ainda separam empresas viáveis das que fracassam. Utilização ruim, confiabilidade fraca ou planejamento de capacidade deficiente podem destruir um provedor bem financiado. No entanto, quando todo concorrente sério atinge o padrão técnico, mais uma melhoria de kernel não pode substituir o balanço patrimonial necessário para aceitar o próximo grande contrato.
O mercado já caminhou nessa direção. Os principais provedores levantaram rodadas grandes e viram suas avaliações se multiplicarem no último ano. Os investidores estão pagando por posição em uma corrida por capacidade, não por engenharia de kernel.
Parte III: O Futuro — O Valor Se Transforma em Concreto
Previsão: todos vão comprar data centers
A lógica do capital aponta para a propriedade. Em escala suficiente, uma empresa cujo custo dos produtos é dominado por GPUs e eletricidade perde margem sempre que aluga capacidade computacional ou espaço em data centers. Cada camada alugada transfere parte da margem bruta para outro balanço patrimonial.
Por isso, os principais provedores de inferência vão comprar ou adquirir data centers, incluindo as instalações e os contratos de energia por trás deles, em vez de parar nas alocações de GPU ou em compromissos de longo prazo com nuvens. Os cofres de guerra que eles levantaram só fazem sentido sob esse desfecho.
O provedor de inferência começou como uma empresa de software cujo produto era o engine. Tornou-se uma empresa de serviços gerenciados que vende uma plataforma e um SLA. Agora está se tornando uma empresa de infraestrutura que vende capacidade. Ao longo dessa progressão, o valor migrou dos kernels para as operações de serving e depois para aço, terra e acordos de compra de energia.
Cada passo muda as habilidades e a economia da empresa. A iteração de software dá lugar à gestão de frotas, compras, financiamento e estratégia de energia. A interface pode continuar sendo uma API, mas o negócio por trás dela se torna mais pesado e mais exposto à utilização.
A história começou com a perda de um fosso de software. Ela termina com as mesmas empresas competindo pelos fossos mais antigos do mundo: terra, energia e capital. O fosso nunca esteve realmente no software.
Continuam sendo "provedores de inferência", nunca "neoclouds"
Mesmo depois de comprar data centers, essas empresas vão continuar se descrevendo como provedores de inferência, não como neoclouds. Os mercados de capital concedem um múltiplo maior a uma empresa de infraestrutura de IA que vende tokens do que a uma neocloud que aluga horas de GPU.
Por baixo do rótulo, elas vão se parecer com um novo tipo de neocloud: a mesma base pesada em ativos com uma interface diferente, vendendo tokens, SLAs e APIs em vez de GPUs nuas. Os CoreWeaves do mundo construíram a base de ativos primeiro e estão caminhando para o serving. Os Fireworks do mundo construíram a interface primeiro e estão caminhando para a base de ativos. Os dois caminhos levam ao mesmo formato corporativo; o ponto de partida determina o rótulo e o múltiplo associado a ele.
Vender por meio de uma API muda a embalagem. Tokens empacotam software, operações e capacidade em um produto que o cliente pode consumir diretamente. Horas de GPU expõem mais a commodity subjacente. Duas empresas podem possuir ativos semelhantes e ainda assim receber avaliações muito diferentes, porque uma empacotou esses ativos em uma camada mais alta da stack.
Elas vão ser donas dos data centers e ainda assim se chamar de provedores de inferência, porque o rótulo vale mais do que o prédio.
O concorrente real vem de baixo
Se o destino é um negócio de tokens intensivo em capital e dono de data centers, classificar os players atuais pela distância até ele muda o panorama competitivo.
A Together AI, a Fireworks e a Baseten têm marcas, plataformas e contratos. Ainda precisam construir ou comprar uma base de ativos composta por instalações, energia e uma cadeia de suprimentos em escala de neocloud, tudo limitado por prazos de construção e de energia de vários anos.
A Nebius já possui data centers e opera sua própria cadeia de suprimentos de GPU. Como empresa de capital aberto, ela também tem um canal de financiamento que provedores privados só conseguem se aproximar por meio de rodadas grandes repetidas. A peça que faltava era a camada de serving. A aquisição da Eigen AI trouxe software e um time, e um ano focado fecha a maior parte da lacuna de software, porque a inferência não tem segredos.
Em contraste, um provedor com foco em software não consegue comprimir o cronograma físico da mesma forma. Interconexões de energia, construção e entrega de equipamentos seguem cronogramas de vários anos. O capital pode garantir um lugar nessas filas, mas não pode transformá-las em um ciclo de lançamento de software.
É muito mais rápido adicionar software a uma base de ativos do que adicionar uma base de ativos a uma empresa de software. A commoditização de engines ajudou os provedores a crescer, mas também arma seu concorrente mais perigoso.
O maior rival que a Together AI, a Fireworks e a Baseten enfrentam não é outro provedor. É a Nebius, seguida por qualquer neocloud disposta a subir na stack.
Em vez disso, para onde vão as horas de engenharia
A engenharia de inferência ainda será importante dentro dos provedores, mas sua alocação mudará. Engines de código aberto tornam essa realocação possível.
À medida que a baseline dos engines gratuitos melhora, os provedores podem tirar o custoso tempo de engenharia de kernels e runtimes. As horas vão para a confiabilidade da infraestrutura, que dá substância ao SLA; para a experiência da plataforma, que favorece renovações; e, cada vez mais, para RL. Os rollouts de reinforcement learning são intensivos em inferência, então a expertise em serving é transferida diretamente para a infraestrutura de RL no crescente mercado de pós-treinamento.
Os provedores não estão recuando do trabalho técnico. Confiabilidade em uma frota heterogênea, recuperação rápida sob carga e rollouts eficientes de RL são problemas difíceis de sistemas. Suas soluções permanecem mais próximas dos clientes e das operações do provedor, tornando-as mais úteis como fontes de diferenciação.
O valor na camada de engine não desapareceu. O código aberto incorporou esse valor a uma base gratuita, permitindo que o valor da engenharia migre para os sistemas construídos acima dela. A questão estratégica para a maioria das empresas não é mais se devem construir um engine. É onde gastar o tempo que um engine gratuito economiza. Os beneficiários do trabalho de código aberto como bem público aparecem nos roadmaps de outras empresas.
A história ainda não acabou
O fim do jogo permanece em aberto. Vera Rubin, MI455, LPU e outros hardwares focados em inferência vão resetar o checklist, como toda transição de hardware anterior fez. Cada reset reabre brevemente espaço para diferenciação de engines por meio de novos formatos numéricos, hierarquias de memória e trade-offs de paralelismo. As técnicas então se espalham e a janela se fecha.
Novas arquiteturas de modelo e workloads criarão aberturas semelhantes. Agentes com grandes contextos reutilizáveis e RL em escala de produção impõem novas restrições. A commoditização de engines é um ciclo recorrente. O intervalo entre invenção e difusão está diminuindo, mas não desapareceu.
Durante cada abertura, um time rápido ainda pode conquistar negócios relevantes. Vantagens temporárias fazem diferença quando chegam acompanhadas de uma grande transição de hardware ou de modelo, porque a receita e os relacionamentos com clientes podem persistir depois que os concorrentes alcançam o mesmo nível. O que mudou é o tempo disponível para reconhecer e explorar a abertura.
Engines e provedores ainda enfrentam dois testes. O primeiro é a velocidade de reação: eles conseguem aproveitar uma transição enquanto a vantagem ainda está disponível? Cada geração deixou para trás empresas bem administradas que chegaram um ciclo de hardware atrasadas. Times que apostaram cedo na desagregação ou na economia de NVFP4 da Blackwell obtiveram ganhos temporários, porém compostos.
O segundo teste é financeiro: eles conseguem preservar a margem enquanto o ARR cresce? Um provedor pode registrar mais receita e perder mais dinheiro ao comprar crescimento com capacidade subprecificada. À medida que a concorrência se intensifica e as margens brutas se aproximam da economia típica de infraestrutura, a disciplina operacional se torna condição de sobrevivência. Utilização da frota, custos de energia, previsão de demanda, planejamento de capacidade e o equilíbrio entre receita comprometida e receita spot decidirão o próximo grupo de vencedores. Levantar bilhões é apenas o começo; gastar bem esses bilhões é a arte.
O valor neste mercado continua se movendo: dos modelos para os engines, dos engines para o serving e do serving para capacidade e energia. Isso deixa camadas onde não resta nenhum fosso competitivo durável. Os próximos vencedores reconhecerão a mudança antes que o checklist se torne de conhecimento geral.
