Unite AI: Nikunj Bajaj, cofundador e CEO da TrueFoundry – Série de entrevistas

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
Nikunj Bajaj é cofundador e CEO da TrueFoundry, onde lidera a visão e a estratégia da empresa na construção de plataformas de IA confiáveis e de nível empresarial. Com experiência em escalar produtos e equipes de tecnologia, ele se concentra em capacitar organizações a implementar e operar sistemas de IA de forma segura e eficiente. Ele escreve sobre a adoção de IA corporativa, estratégia de plataformas de IA e tendências emergentes em IA de produção.
A TrueFoundry é uma plataforma de infraestrutura de IA empresarial que ajuda organizações a construir, implementar, governar e escalar aplicações de aprendizado de máquina e IA generativa em ambientes baseados em Kubernetes, seja na nuvem, localmente ou em modelos híbridos, com forte governança, segurança e controle de custos. Ela combina um AI Gateway para centralizar o acesso a modelos, LLMs e fluxos de trabalho de agentes com ferramentas para ajuste fino, implementação, monitoramento e escalonamento automático de modelos, visando simplificar o MLOps e acelerar o retorno sobre o investimento para equipes de ciência de dados e engenharia. A abordagem da TrueFoundry, focada no desenvolvedor e agnóstica em relação à nuvem, enfatiza a conformidade corporativa e a flexibilidade, permitindo que as equipes gerenciem cargas de trabalho complexas de IA sem dependência de fornecedores (vendor lock-in), ao mesmo tempo em que aplicam padrões como SOC 2, HIPAA e ITAR.
Você trabalhou com pesquisa de aprendizado de máquina, IA de produção no Facebook e sistemas de recomendação em larga escala antes de fundar a TrueFoundry. Quais experiências o levaram mais diretamente a construir uma empresa de infraestrutura de IA empresarial e qual problema você sentia que não estava sendo resolvido na época?
Na Meta, víamos o aprendizado de máquina como um caso especial de software, e a IA generativa como um caso especial de aprendizado de máquina, o que resultava em uma pilha vertical com software na base, aprendizado de máquina no meio e IA generativa no topo. Nessa configuração, se eu sou um desenvolvedor de aprendizado de máquina, os modelos que crio seguem o mesmo padrão de implementação do restante do software, o que torna o escalonamento de sistemas muito direto.
A maioria das empresas, no entanto, estava implementando pilhas paralelas, o que significa que tinham pilhas separadas para software, aprendizado de máquina e IA generativa. No momento em que você tem essas pilhas paralelas, o escalonamento torna-se mais complexo devido às transferências necessárias entre o aprendizado de máquina e o mundo do software.
Nossa equipe sempre trabalhou na interseção entre a construção de modelos de aprendizado de máquina e a infraestrutura para esses modelos, então tínhamos um ponto de vista único de que poderíamos trazer pilhas verticais semelhantes para as empresas e adaptá-las às suas necessidades específicas. Também tínhamos a hipótese, no final de 2021, de que o aprendizado de máquina estava se aproximando de um ponto de inflexão e que, quando isso acontecesse, mais empresas precisariam de uma pilha integrada verticalmente para implementar e escalar esses sistemas de forma eficaz. Foi isso que, em última análise, nos levou a fundar a TrueFoundry, e nossa hipótese estava correta. A adoção de IA acelerou após o lançamento do ChatGPT no final de 2022.
À medida que os sistemas de IA passam da experimentação para as operações cotidianas, o que mudou na forma como as organizações devem pensar sobre confiabilidade e falhas?
Os riscos com a IA generativa são significativamente maiores em comparação com os sistemas tradicionais de aprendizado de máquina. À medida que esses sistemas entram em produção, as organizações lidam com um nível muito maior de ambiguidade e não determinismo, porque os LLMs são estocásticos por natureza. Sistemas baseados em agentes construídos sobre eles adicionam ainda mais ambiguidade.
Além disso, as falhas não são mais binárias. Em vez de sistemas simplesmente falharem ou não falharem, muitos problemas aparecem como falhas parciais ou degradações silenciosas. Os sistemas podem responder com maior latência, qualidade degradada ou comportamento incorreto ao longo do tempo. Em muitos casos, essas degradações podem ser mais difíceis de detectar e, às vezes, até mais prejudiciais do que uma interrupção total.
As organizações precisam pensar na confiabilidade não apenas em termos de tempo de atividade, mas também na degradação do desempenho ao longo do tempo.
O TrueFailover foi lançado em meio a uma onda de interrupções de alto perfil em serviços de nuvem e IA. Quais eventos recentes deixaram claro que a confiabilidade da IA deixou de ser um diferencial para se tornar um requisito arquitetural básico?
Um de nossos clientes da área de saúde, que processa solicitações de pacientes em tempo real e sensíveis ao tempo relacionadas a prescrições, foi impactado por uma interrupção causada por uma falha no modelo. Seus fluxos de trabalho geram milhares de dólares em receita por segundo, e a interrupção prejudicou alguns desses fluxos críticos. Como um dos primeiros clientes do TrueFailover, conseguimos ajudar na recuperação rápida e o impacto foi contido.
Incidentes como este levantam uma questão importante. À medida que os riscos dos sistemas de IA generativa continuam a aumentar, por que os processos de recuperação ainda são amplamente manuais? Isso reforçou a ideia de que os sistemas devem ser construídos com a premissa de que falhas ocorrerão e devem ser projetados para se autocorrigirem automaticamente. A confiabilidade também precisa ser incorporada à própria pilha de IA por meio do uso de AI Gateways, que podem fornecer roteamento centralizado, observabilidade, guardrails e troca inteligente de modelos entre provedores.
Muitas interrupções de IA ainda são tratadas como problemas técnicos passageiros. Onde você vê os custos econômicos e humanos reais começando a surgir quando os sistemas de IA saem do ar?
A IA empresarial evoluiu a ponto de esses problemas não afetarem mais apenas os fluxos de trabalho internos. Hoje, interrupções e degradações impactam a percepção pública e os lucros direta e imediatamente, porque os casos de uso em produção agora estão voltados para o cliente. Essa mudança dos testes internos para aplicações de alto risco voltadas ao público é o motivo pelo qual estamos vendo uma demanda crescente por atenção e supervisão executiva.
À medida que os sistemas de IA se tornam mais profundamente integrados aos fluxos de trabalho operacionais, as interrupções deixam de ser apenas problemas técnicos. Elas passam a ter consequências diretas para os negócios, para os clientes e para a reputação.
Em ambientes de missão crítica, como farmácias, operações de saúde ou suporte ao cliente, com que rapidez o tempo de inatividade da IA pode escalar para um risco operacional ou reputacional?
Em ambientes de missão crítica, a escalada acontece quase imediatamente, porque esses sistemas suportam fluxos de trabalho em tempo real e sensíveis ao tempo. Mesmo uma breve interrupção pode paralisar processos críticos, atrasar a entrega de serviços ou interromper sistemas dependentes, criando efeitos operacionais em cascata por toda a organização.
Em setores como o de saúde, o impacto vai além da interrupção operacional, afetando a experiência do cliente e os resultados dos serviços. Se um paciente não consegue retirar sua prescrição a tempo, pode haver consequências reais. Isso não é apenas um problema para o paciente, mas também pode prejudicar a reputação de uma farmácia ou de um provedor de saúde. Em ambientes de missão crítica onde a confiança é um fator determinante, é fundamental que os sistemas permaneçam online. É por isso que as organizações estão reconhecendo cada vez mais que os sistemas de IA devem ser projetados com a premissa de que falhas ocorrerão e que os mecanismos de recuperação precisam ser ativados automaticamente para minimizar os riscos.
Você disse que muitas equipes projetam pensando na capacidade em vez da continuidade. Por que você acha que a resiliência tem sido historicamente despriorizada no design de sistemas de IA?
Isso se deve, em grande parte, aos incentivos dentro das organizações. Novas capacidades são visíveis e empolgantes. Elas desbloqueiam demonstrações, funcionalidades e possibilidades de produtos que a liderança consegue visualizar imediatamente.
A continuidade, por definição, é invisível quando as coisas estão funcionando bem. Por causa disso, os sistemas de recompensa tendem a ser voltados para o lançamento de novas funcionalidades, em vez de garantir que nada quebre. Como resultado, as organizações frequentemente investem de forma desproporcional no desenvolvimento de capacidades, em vez de investir em engenharia de resiliência.
À medida que as empresas dependem cada vez mais de modelos e APIs externos, quais novas fragilidades estão sendo introduzidas na pilha de IA que os líderes talvez ainda não compreendam totalmente?
Os LLMs são, fundamentalmente, recursos compartilhados, e as empresas não os possuem como fazem com a infraestrutura tradicional. Além disso, sistemas críticos para os negócios dentro das empresas estão sendo executados em sistemas externos que ainda não foram totalmente testados pelo tempo. Os próprios LLMs estão evoluindo rapidamente, o que significa que um provedor de modelos não pode ser responsabilizado por questões como latência ou uma leve queda no desempenho do modelo, pois eles estão iterando em suas pesquisas muito rapidamente.
Como os LLMs são recursos compartilhados, a latência pode aumentar porque outro consumidor desses LLMs realiza uma ação específica. Existem muitos desses pontos de falha que são introduzidos devido à natureza fundamental dos LLMs, e as empresas, neste novo mundo, simplesmente não têm controle total. Sem controle total, a melhor coisa que uma empresa pode fazer é criar redundâncias de sistema suficientes para projetar um sistema resiliente.
Sem focar em produtos específicos, como as organizações devem repensar a arquitetura de IA para assumir a falha, em vez de tratar as interrupções como casos raros e isolados?
As organizações devem retornar aos princípios básicos do design de sistemas distribuídos. Os sistemas de software foram construídos sob a premissa de que componentes de rede e máquinas falhariam, e que uma região inteira poderia ficar fora do ar.
Os sistemas de IA não devem ser diferentes. Devemos assumir que os provedores de modelos enfrentarão problemas de latência, degradações ou interrupções, e incorporar redundância para que as aplicações permaneçam resilientes em diferentes cenários de falha.
Você espera que a resiliência da IA se torne um fator decisivo na seleção de plataformas e fornecedores, de forma semelhante a como o tempo de atividade e a redundância moldaram as decisões de infraestrutura em nuvem?
À medida que mais sistemas de IA entram em produção, a resiliência se tornará um requisito básico. Se um fornecedor não puder apresentar seus gráficos e métricas de tempo de atividade e resiliência geral, ele nem será considerado. Uma vez que a resiliência se torne uma expectativa padrão entre os fornecedores, os fatores decisivos mudarão para a experiência do usuário, otimização de desempenho, observabilidade e capacidades de produto de nível superior. Com o tempo, componentes como um AI Gateway e capacidades de failover automatizado se tornarão elementos fundamentais da infraestrutura de IA empresarial.
Olhando para o futuro, o que realmente significa IA "pronta para produção" em um mundo onde se espera que a IA esteja continuamente disponível, e não apenas ocasionalmente útil?
Sistemas de IA prontos para produção devem ser observáveis, controláveis e recuperáveis. Todos esses três requisitos precisam ser atendidos.
Para que a IA de produção seja observável, as equipes precisam de visibilidade profunda sobre o comportamento do modelo, latência, taxas de erro, uso de tokens, desvio (drift) e padrões de falha. Sem uma observabilidade robusta, torna-se muito difícil detectar degradações antes que os usuários comecem a notá-las.
Para que os sistemas sejam controláveis, isso inclui modelagem de tráfego, limitação de taxa (rate limiting), guardrails, aplicação de políticas e roteamento inteligente entre modelos e provedores. É aqui que um AI Gateway se torna fundamental, atuando como um plano de controle centralizado que impõe guardrails, fornece governança consistente e permite a troca dinâmica de modelos quando o desempenho ou a confiabilidade caem.
E, por último, quando se trata de ser recuperável, os sistemas devem ser construídos com a premissa de que os componentes podem estar parcial ou totalmente quebrados, seja devido a interrupções do provedor, qualidade degradada do modelo, limites de taxa ou entradas inesperadas de agentes mal-intencionados. Mecanismos de failover automatizado e autorrecuperação devem ser nativos da arquitetura, não manuais de procedimentos acionados após algo dar errado.
Esta é a direção na qual estamos trabalhando na TrueFoundry. Os fornecedores que definem a prontidão para produção desta forma, combinando observabilidade, controle centralizado e recuperação automatizada, conquistarão a confiança do cliente a longo prazo e serão capazes de continuar resolvendo novos problemas à medida que surgirem.
Sobre a TrueFoundry:
A TrueFoundry fornece um AI Gateway de nível empresarial que engloba um LLM Gateway, MCP Gateway e Agent Gateway, permitindo que as empresas conectem, observem e governem com segurança o acesso a modelos, ferramentas, guardrails e agentes a partir de um único plano de controle. O AI Gateway possibilita cargas de trabalho de agentes que são seguras, eficientes e preparadas para o futuro por meio de conexões unificadas e componíveis entre provedores.
Além da camada de gateway, a TrueFoundry permite que as organizações implantem e treinem LLMs personalizados em GPUs, hospedem servidores MCP e executem agentes personalizados — tudo por meio de uma interface nativa do Kubernetes. Ela oferece suporte a instalações on-premise e em VPC tanto para o AI Gateway quanto para ambientes de implantação. A TrueFoundry garante conformidade de nível empresarial com os padrões SOC 2, HIPAA e ITAR. Com autoscaling, cache e otimização de recursos integrados, a TrueFoundry capacita as organizações a construir, implantar e governar sistemas de IA de forma segura, eficiente e em uma pilha preparada para o futuro. Para saber mais, visite truefoundry.com
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.
The fastest way to build, govern and scale your AI












.jpeg)


.jpeg)


.jpeg)
.webp)










