Startups · 15/08/2026
Infraestrutura de Modelos de Linguagem em Produção: O Trade-off Real entre Customização Local e Operações em Escala
Startups de IA precisam escolher entre desenvolver stacks proprietárias de LLM serving ou depender de infraestrutura genérica. Netflix e Kog revelam os custos reais dessa decisão: otimização de GPU, latência em agentic workflows e complexidade operacional crescente.
O que está acontecendo
Duas trajetórias distintas emergem no mercado de infraestrutura para LLMs em produção. De um lado, organizações maduras como Netflix investem em pipelines proprietários de serving, especializando toda a stack (serving layer, graph querying distribuído, device capability modeling) para casos de uso específicos. Do outro, startups como Kog questionam pressupostos consolidados sobre a adequação de GPUs para workloads agentic, atacando o problema de forma diferente: otimizando a utilização de hardware genérico ao invés de construir infraestrutura vertical.
Netflix publicou detalhes sobre seu in-house LLM serving, arquitetura que alimenta recomendações generativas (GenRec) e consultas em grafo distribuído em tempo real. Kog, startup francesa, propõe que a ineficiência de GPUs em workflows agentic não é inerente ao hardware, mas resultado de padrões de serving não otimizados para esse padrão de acesso.
Insights e Riscos
Customização de serving reduz latência absoluta, não viabiliza operações simples Netflix construiu sua própria camada de serving porque as soluções genéricas (vLLM, Ray Serve, TGI) não oferecem controle fino sobre batching, prefill/decode separation e caching de contexto para seu padrão de tráfego. O custo: overhead de engenharia contínua para manter essa stack, fragmentação de expertise dentro do time.
GPUs sob workflows agentic exigem reconceptualização, não apenas otimização Kog argumenta que o problema não é a GPU ser inadequada para agentes, mas as estratégias de batching e cache assumidas por serving genérico não considerarem características de execution agentic: padrões de multi-turn, tentativa/erro, ramificação lógica. Reconhecer isso abre superfícies de otimização (scheduling específico de tokens, speculation de branches), mas amplia a distância entre uma startup e commodities de infra.
Recomendação nativa em LLM: trade-off entre precisão vetorial e custo de inferência GenRec (Netflix) substitui busca vetorial tradicional por prompt generation + model ranking, reduzindo dependência de embedding databases separados. Ganho: pipeline mais simples, menos movimentação de dados. Custo: overhead de inferência cresce, latência p99 sobe, exige otimização agressiva de serving para permanecer viável.
Grafo distribuído em tempo real expõe complexidade operacional silenciosa Netflix queries seu grafo de usuário/item/metadados via gRPC em tempo real, mantendo consistência global. Essa escolha arquitetural não é meramente de conveniência: é requisito para GenRec retroalimentar rapidamente o sistema de recomendação. Custo operacional: sincronização de estado em escala, tolerância a falha em camada de consenso, debugging distribuído de latência tail.
Observabilidade de device capabilities: fragmentação crescente de código Netflix modela capacidades de device (resolução, codec, memória) para analytics. Em uma infra heterogênea (mobile, web, TV, devices custom), essa modelagem não é um problema secundário de observabilidade: é caminho crítico de decisão para qualidade de experiência. Cada novo tipo de device dispara recodificação de heurísticas, regression testing em escala.
O que muda na prática
Para Engenheiros de Arquitetura em Startups
Não há caminho híbrido viável. Escolha entre: (1) investir em serving proprietário desde cedo (Netflix), aceitando que isso consome 2-3 FTEs senior permanentemente, ou (2) aceitar que vencimento com commodities genéricas de infra implica em tradeoffs de latência e que seu diferencial será software (modelo, algoritmos de reranking, caching inteligente), não infra. Tentar ambos em paralelo gera debt técnico intratável.
Grafo distribuído (como Netflix usa para recomendação) é um salto arquitetural não-trivial. Se sua startup precisa retroalimentação em tempo real em nível de usuário individual, prepare-se para ACID distributed e seus custos operacionais. Alternativa: feedback batch, mas nega a velocidade que justifica LLMs em recomendação.
Para Engenheiros de Infraestrutura (DevOps/MLOps)
Monitoramento de utilização de GPU em código agentic é diferente de batch inference. Seus dashboards de nvidia-smi não capturam ineficiência de scheduling em multi-turn. Você precisará de instrumentação específica de token generation rate, speculation hit rate, branch abandonment ratio. Tooling genérico falha aqui.
GenRec reduz dependência de vector databases separadas, mas não elimina. Você ainda precisa de um embedding store para cold starts e fallback quando o LLM de ranking é muito lento. Esse sistema paralelo é debt silencioso: custa menos que manter embedding DB como sistema crítico, mas mais que remover.
Device capability modeling em analytics parece cosmético até seu modelo começar a tomar decisões baseado nele (ex.: quality tier selection). Aí, bugs em device modeling afetam SLA de forma não-óbvia. Seu pipeline de dados precisa versionamento de device profiles e canary de mudanças.
Para Engenheiros de Segurança
Grafo distribuído em tempo real exigindo gRPC multiplica a superfície de autenticação/autorização. Você não pode assumir perimeter security. Cada nó que queries o grafo precisa mTLS validado. Certificate rotation em escala não é trivial.
In-house serving de LLM é ponto de exfiltração potencial. Qualquer log, trace ou métrida de inferência pode vazar informação de contexto de usuário (padrões de comportamento, preferências, até histórico de conversação). Você precisa de data classification rigorosa, PII masking em espelho de tráfego para debugging, retenção limitada de logs.
Modelos em serving proprietário também aumentam risco de model extraction. Se seu serving é customizado, é mais fácil reverse-engineer o modelo via queries. Adicione rate limiting, anomaly detection de padrão de queries, e logging de access patterns.
Conclusão direta
Startups de IA em produção enfrentam decisão fundamental não sobre "qual framework escolher", mas sobre nível de customização que seu business case justifica. Netflix escolheu customizar porque recomendação em escala é sua core competency e economia de latência de 100ms multiplica engajamento. Kog escolheu otimizar a commodity porque acredita que padrão de acesso agentic (não GPU) é o inimigo, e resolvê-lo permite qualquer startup rodar agentes bem.
Ambas as apostas têm custo exponencial: Netflix paga em engenharia contínua de infra; Kog paga em pesquisa para validar que sua tese (GPU é adequada para agentes) tem margem lucrativa real.
Qual é o trade-off que sua startup está implicitamente fazendo hoje, sem nomeá-lo explicitamente: você está otimizando para latência absoluta (Netflix path) ou para custo operacional de escala (Kog path)?
Fontes
[Fonte: Netflix TechBlog - Medium] In-House LLM Serving at Netflix](https://netflixtechblog.com/in-house-llm-serving-at-netflix-a5a8e799ea2c?source=rss----2615bd06b42e---4)
[Fonte: Startups | TechCrunch] Kog is going deeper to squeeze more inference out of GPUs](https://techcrunch.com/2026/08/14/kog-is-going-deeper-to-squeeze-more-inference-out-of-gpus/)
[Fonte: Netflix TechBlog - Medium] GenRec: Towards LLM-Native Recommendation at Netflix](https://netflixtechblog.com/genrec-towards-llm-native-recommendation-at-netflix-f20be6f643e3?source=rss----2615bd06b42e---4)
[Fonte: Netflix TechBlog - Medium] How and Why Netflix Built a Real-Time Distributed Graph: Part 3, Querying the graph with gRPC](https://netflixtechblog.com/how-and-why-netflix-built-a-real-time-distributed-graph-part-3-querying-the-graph-with-grpc-0f3468349607?source=rss----2615bd06b42e---4)
[Fonte: Netflix TechBlog - Medium] Modeling Device Capabilities for Analytics](https://netflixtechblog.com/modeling-device-capabilities-for-analytics-e7607acebde8?source=rss----2615bd06b42e---4)