Plataformas
Adote
-
46. VictoriaMetrics
Movemos o VictoriaMetrics para “Adote” porque ele amadureceu e se tornou uma escolha confiável para organizações que operam plataformas de observabilidade autogerenciadas de grande escala. Como um banco de dados de séries temporais de código aberto e alto desempenho, ele processa grandes volumes de métricas com alta cardinalidade que podem desafiar o Prometheus. Em um de nossos projetos, um cluster do VictoriaMetrics lida com cinco milhões de amostras por segundo com 20 a 30 rótulos por métrica, demonstrando sua adequação para implantações de grande escala.
A plataforma oferece uma versão simples de nó único para cargas de trabalho menores, bem como uma arquitetura em cluster que separa ingestão de dados, consulta e armazenamento em componentes independentemente escaláveis. Ela se integra a arquiteturas de observabilidade existentes ao oferecer suporte à ingestão nativa de OpenTelemetry, APIs do Prometheus e suporte a remote write, permitindo que as equipes a adotem sem substituir sua instrumentação e painéis existentes. Seja usado como armazenamento de longo prazo por trás do Prometheus ou como uma stack completa de métricas com componentes como vmagent e vmalert, o VictoriaMetrics é uma opção atraente para infraestruturas onde a retenção, a cardinalidade ou o custo se tornaram um desafio.
Experimente
-
47. Kafka Share groups
O recurso Kafka Share Groups (introduzido no KIP-932, pronto para produção desde o Kafka v4.2) traz um novo modelo cooperativo de consumo de eventos para o Kafka, permitindo um comportamento semelhante a filas. Historicamente, os grupos de consumidores tradicionais do Kafka impunham um gargalo de concorrência porque o número de consumidores ativos não podia exceder o número de partições. Os share groups removem essa restrição: registros individuais são entregues a qualquer consumidor disponível no pool sob um bloqueio (lock) de aquisição a cada registro, que o consumidor deve confirmar explicitamente. Em caso de falha ou tempo limite (timeout), o registro é liberado e reentregue a qualquer consumidor no grupo, até um número máximo configurável de tentativas de entrega. Isso garante a entrega de “pelo menos uma vez” (at-least-once) com a possibilidade de processamento duplicado. Registros que esgotam suas tentativas de entrega são encaminhados para arquivamento; o suporte a dead-letter queues (KIP-1191) ainda não está disponível.
A contrapartida é que os share groups não garantem a ordenação por partição, pois os registros são despachados e reentregues de forma independente. No entanto, para equipes que anteriormente precisavam executar tanto o Kafka quanto um sistema externo de filas, os share groups podem simplificar a arquitetura ao consolidar as cargas de trabalho no Kafka.
-
48. KServe
O KServe é um operador de Kubernetes de código aberto que gerencia a inferência de IA preditiva e generativa por meio de recursos personalizados. Em vez de atuar como um motor de inferência em si, ele orquestra runtimes de serviço como vLLM, SGLang e NVIDIA Triton, separando o ciclo de vida de um serviço de modelo do motor que o executa.
À medida que as organizações constroem fábricas de IA (AI factories), operar a inferência na infraestrutura de GPUs do Kubernetes torna-se um problema de gerenciamento de frota, em vez de uma questão de executar servidores de modelos individuais. O KServe aborda isso com dois recursos personalizados: InferenceService para aprendizado de máquina convencional e cargas de trabalho mais simples de LLMs, com scale-to-zero opcional baseado em Knative, e LLMInferenceService para serviço avançado de LLMs. Desenvolvido sobre o llm-d e a Gateway API Inference Extension, o LLMInferenceService suporta inferência multinó (multi-node), desagregação de pré-preenchimento e deprogramação (prefill/decode disaggregation) e roteamento consciente de KV-cache que direciona requisições para réplicas que já possuem o prefixo em cache relevante.
O KServe é um projeto no estágio Incubating da CNCF, e vários de nossos clientes o utilizam em produção. Nossas equipes o preferem em relação a outras ferramentas desse espaço ao construir plataformas internas de inferência no Kubernetes. O LLMInferenceService é mais recente que o InferenceService, e seu ecossistema ainda está em evolução.
-
49. LibreChat
O LibreChat é uma plataforma de chat de IA open-source e auto-hospedada que permite que pessoas de toda a organização acessem modelos de vários provedores por meio de uma única interface. Assim como o Open WebUI, ele oferece logon único (single sign-on), permissões baseadas em funções e RAG sobre documentos carregados. Seus recursos de agentes o tornam mais do que uma interface de chat. Os administradores decidem quais servidores MCP estão disponíveis. Os usuários cuja função permite podem, então, criar agentes nesses servidores sem escrever código e compartilhá-los por meio de um marketplace integrado.
Uma de nossas equipes construiu a plataforma interna de IA de um cliente sobre o LibreChat. A equipe escreveu servidores MCP para Jira, Confluence, Salesforce, Grafana e para os sistemas próprios de pedidos, estoque e receita do cliente. A própria equipe do cliente construiu os agentes: a área de vendas criou um para verificar disponibilidade e registrar pedidos, enquanto a de operações criou um para gerenciar contratos. Essa experiência é o motivo pelo qual o estamos colocando em “Experimente”. Ele oferece a pessoas fora da engenharia uma forma controlada de acessar ferramentas de IA aprovadas, que é o que recomendamos como resposta à shadow IT acelerada por IA. A ClickHouse adquiriu o LibreChat em novembro de 2025, e o projeto continua sob licença MIT.
-
50. LiteLLM
O LiteLLM tornou-se um gateway de IA open-source amplamente utilizado. Várias de nossas equipes roteiam suas chamadas de modelos por meio dele, seja como um proxy autônomo (standalone) ou como um sidecar. Ele suporta mais de 100 provedores de LLM e oferece roteamento, tradução de provedores, autenticação, orçamentos e guardrails. O núcleo do seu proxy está sendo reescrito de Python para Rust para melhorar o desempenho, mantendo o mesmo SDK e configuração em Python.
Nesta edição, estamos movendo o LiteLLM de “Linguagens & Frameworks” para “Plataformas”, pois agora o vemos mais como infraestrutura do que como uma biblioteca. Mantemos o LiteLLM em “Experimente” em vez de “Adote” principalmente devido a preocupações de segurança: no momento em que este texto foi escrito, mais de 25 CVEs foram relatadas apenas este ano. As equipes que o utilizam devem aplicar os patches de segurança prontamente. Para governar também o tráfego MCP e de agente-para-agente, considere combiná-lo com o agentgateway.
-
51. Microsoft Copilot Retrieval API
A Microsoft Copilot Retrieval API é uma solução simplificada para recuperar dados do ecossistema da Microsoft para geração aumentada por recuperação (RAG). A API recupera trechos de texto relevantes do SharePoint, OneDrive e conteúdos expostos por meio de conectores do Copilot. Ela aplica filtragem de segurança com base no usuário solicitante e respeita os controles de acesso definidos no tenant.
Desenvolvedoras podem construir agentes de IA cientes do contexto organizacional sem a necessidade de manter repositórios de dados e pipelines de recuperação customizados, deixando tarefas como fragmentação (chunking), indexação, sincronização de dados, reindexação e controle de acesso a cargo da Microsoft. A Microsoft Copilot Retrieval API é particularmente útil para sistemas de IA que precisam do conhecimento organizacional já armazenado nas ferramentas da Microsoft, e nossa experiência com sua adoção tem sido positiva.
-
52. Restate
O Restate é uma plataforma de execução durável para construir aplicações tolerantes a falhas e com estado (stateful). Como ele registra cada etapa da execução em log (journals), um serviço que falha retoma de onde parou. O Restate também garante comunicação exatamente uma vez (exactly-once) entre serviços. Uma aplicação combina Serviços Básicos para funções sem estado (stateless), Objetos Virtuais para entidades concorrentes com estado e Workflows para processos de múltiplas etapas. Da última vez que escrevemos sobre o Restate, estávamos avaliando a ferramenta em um grande sistema de seguros. Agora, ele é uma parte central desse sistema, automatizando todo um processo de negócios de seguros. A equipe confia em sua recuperação de estado e controle de concorrência e não precisou escrever seu próprio código de recuperação. Essa experiência é o motivo pelo qual estamos movendo a ferramenta para “Experimente”. O Restate é adequado para processos de longa duração que aguardam uma pessoa no circuito (human in the loop) ou que fazem várias tentativas (retries) contra sistemas legados. Ele cumpre o mesmo papel que o Temporal, que também avança para “Experimente” nesta edição. Os SDKs são licenciados sob MIT, mas o servidor utiliza a Business Source License, o que impede oferecê-lo a terceiros como um serviço gerenciado.
-
53. Talos Linux
Talos Linux é uma distribuição Linux imutável e minimalista para executar Kubernetes. Ela não possui SSH, gerenciador de pacotes nem shell interativo. Você configura os nós de forma declarativa com o talosctl por meio de uma API gRPC protegida por mTLS, e as atualizações substituem toda a imagem do SO. Esse design reduz a superfície de ataque e o drift de configuração associados a distribuições de uso geral, como o Ubuntu, tornando cada nó um dispositivo substituível, no espírito dos servidores imutáveis.
Uma de nossas equipes executa Kubernetes autogerenciado na Talos em uma grande frota bare-metal para uma plataforma de nuvem de IA e considerou o plano de controle fácil de provisionar. A maioria das organizações usa um serviço gerenciado, como o Amazon EKS, e nunca interage com o SO do nó, de modo que a Talos é voltada principalmente para equipes que operam seus próprios nós. O Bottlerocket adota uma abordagem semelhante na AWS, e o Flatcar Container Linux também tem ganhado tração. Em 2026, a Yardi adquiriu a Sidero Labs, desenvolvedora da Talos. A Talos permanece como código aberto sob a licença MPL-2.0, mas as equipes devem acompanhar os rumos que o novo proprietário tomará.
-
54. Temporal
Temporal é uma plataforma de execução durável para processos de negócio complexos que exigem fortes garantias de confiabilidade. O Temporal fornece fluxos de trabalho com retentativas (retries), persistência de estado intermediário, timeouts configuráveis, pontos de verificação com intervenção humana (human-in-the-loop), capacidade de retomada (resumability) e visibilidade do progresso de execução. Ele oferece tanto uma opção de código aberto para auto-hospedagem quanto um serviço gerenciado na nuvem.
Encontramos casos de uso atraentes para o Temporal ao construir plataformas internas para equipes de desenvolvimento e planos de controle para infraestrutura de nuvem para IA. Esses sistemas tipicamente envolvem múltiplas tarefas de provisionamento de infraestrutura de longa duração cujo estado precisa ser reconciliado posteriormente. As retentativas integradas do Temporal, o agendamento flexível de filas de workers, a capacidade de retomada, a visibilidade e a execução durável ajudam as equipes a desenvolver sistemas desse tipo com mais resiliência.
-
55. vCluster
O vCluster fornece planos de controle virtualizados do Kubernetes para ambientes multi-tenant. Ele oferece um meio-termo entre multi-tenancy em nível de namespace, em que os tenants compartilham APIs do cluster e definições de recursos personalizadas (CRDs), e o provisionamento de clusters completamente independentes, o que aumenta a sobrecarga operacional. Com o vCluster, cada tenant tem seu próprio servidor de API do Kubernetes, controller manager, datastore, RBAC e CRDs. O plano de controle é executado como uma carga de trabalho leve na infraestrutura subjacente, permitindo que ferramentas padrão como kubectl, Helm e controladores de GitOps interajam com cada tenant de forma independente.
Utilizamos o vCluster com sucesso para construir serviços gerenciados do Kubernetes e ambientes de nuvem de IA onde equilibrar o isolamento de tenants em relação aos custos operacionais é crítico. É particularmente atraente para plataformas de IA onde diferentes clientes podem precisar de seus próprios operadores de GPU, escalonadores, frameworks de inferência e CRDs. Para cargas de trabalho confiáveis, planos de controle virtualizados podem compartilhar recursos de computação subjacentes. Para ambientes de GPU voltados a clientes, nós worker dedicados podem fornecer um isolamento de carga de trabalho mais forte, mantendo o gerenciamento consolidado do plano de controle. Dado o seu sucesso em ambientes de produção de clientes, estamos colocando o vCluster em “Experimente”.
-
56. VictoriaLogs
Desenvolvido pelos criadores do VictoriaMetrics, o VictoriaLogs é uma plataforma de gerenciamento de logs de código aberto otimizada para ingestão de alta vazão, armazenamento compacto e consultas rápidas de grandes volumes de logs. Em vez de exigir índices pré-definidos, seu mecanismo de armazenamento organiza e compacta campos de log em blocos. Ele utiliza filtros de Bloom e índices de timestamp para evitar varreduras desnecessárias e paraleliza consultas entre núcleos de CPU.
Tivemos experiências positivas usando o VictoriaLogs enquanto construíamos a observabilidade para um sistema de infraestrutura de nuvem de IA. Nessa escala, os serviços do Kubernetes geram grandes volumes de telemetria, tornando a vazão de ingestão, o desempenho de consultas e a eficiência de armazenamento em considerações críticas. Em comparação com plataformas tradicionais de logs baseadas em busca como Elasticsearch, o VictoriaLogs oferece um backend de logs capaz com menor complexidade operacional e menor consumo de recursos. Também o achamos particularmente atraente para logs estruturados de alta cardinalidade e buscas de campos arbitrários quando comparado ao Grafana Loki, porque não exige o mesmo grau de planejamento de rótulos. O VictoriaLogs também inclui a linguagem de consulta LogsQL para busca em texto completo, transformações e agregação. Ele se integra ao Grafana para exploração interativa e alertas, enquanto a compatibilidade com os protocolos de ingestão do OpenTelemetry, Elasticsearch e Loki permite que as equipes o adotem sem vincular as aplicações a um pipeline de logs proprietário.
Avalie
-
57. Agent Client Protocol (ACP)
Embora agentes de programação baseados em CLI se sobressaiam na implementação em todo o repositório e na execução de fluxos de trabalho, pessoas desenvolvedoras ainda precisam de acesso inline aos agentes em suas IDEs para exploração rápida de código, correção interativa de bugs e edição ciente do contexto. Tradicionalmente, isso exige plugins individuais para cada IDE, criando uma sobrecarga de integração e aprisionando as pessoas desenvolvedoras a combinações específicas de editor e agente. O Agent Client Protocol (ACP) aborda esse problema estabelecendo uma fronteira padrão e aberta entre os agentes de IA e os ambientes de execução (hosts), seja o VS Code, JetBrains, uma janela de terminal ou um pipeline de CI/CD.
Assim como o Language Server Protocol padronizou o suporte a linguagens entre editores, o ACP depende do JSON-RPC para definir o ciclo de vida do agente e as primitivas de interação, incluindo criação e retomada de sessão, atualizações em tempo real (streaming), solicitações de permissão e cancelamento. O ACP complementa as camadas de interoperabilidade existentes: enquanto o Model Context Protocol (MCP) lida com a integração de agente para ferramenta, o ACP lida com o controle de cliente para agente, tornando todo o harness do agente um componente intercambiável.
-
58. Agent Plugins
Agent Plugins é um padrão aberto para empacotar componentes reutilizáveis de agentes em plugins portáteis. A primeira versão, lançada por uma colaboração multifornecedora incluindo Amazon, Microsoft e OpenAI, define um formato compartilhado para habilidades de agentes e servidores do Model Context Protocol (MCP). Embora a especificação seja deliberadamente mínima, um padrão aberto é um passo importante para um ecossistema que até agora estava fragmentado. Descobrimos que o "piso de interoperabilidade mínimo" facilita a extensão de um repositório existente de habilidades para que ele também funcione como um Agent Plugin.
-
59. agentgateway
agentgateway é um gateway de alto desempenho para tráfego relacionado a LLMs, hospedado pela Linux Foundation. Ele suporta inferência de LLM, comunicação via MCP e A2A por meio de um protocolo comum, tanto em versões standalone quanto em Kubernetes. Seus recursos principais incluem roteamento baseado em custo e latência, fallbacks, limites de gastos, guardrails, controle de ferramentas MCP e observabilidade com OpenTelemetry.
Estamos particularmente interessadas na versão para Kubernetes por causa de sua integração profunda com infraestrutura de LLMs auto-hospedada. Ele pode usar métricas do Kubernetes para rotear requisições para uma réplica respaldada por GPU que já tenha o contexto relevante em cache na memória ou para um servidor menos utilizado com base no uso real da GPU. Essas capacidades fazem do agentgateway uma opção que vale a pena avaliar para organizações que executam stacks de inferência auto-hospedadas.
-
60. AWS DevOps Agent
AWS DevOps Agent é uma plataforma gerenciada de agentes da AWS para investigação de incidentes orientada a IA. Quando um alarme, chamado ou mensagem de chat dispara uma investigação, a plataforma mapeia os recursos da aplicação e seus relacionamentos, correlaciona telemetria com implantações recentes e alterações de código, testa hipóteses e apresenta causas raízes prováveis e mitigações para que um engenheiro possa atuar. Integrações nativas com Datadog, Dynatrace, New Relic, Splunk e Grafana permitem que alertas dessas ferramentas disparem investigações e habilitam a plataforma a consultar sua telemetria por meio de integrações baseadas em MCP. Conexões com GitHub, GitLab, ServiceNow, PagerDuty e Slack, juntamente com servidores MCP personalizados, estendem seu alcance a sistemas on-premises e proprietários.
Nossas equipes estão experimentando o serviço em produção para investigar alarmes em tempo real. Ainda é cedo, mas os resultados parecem promissores, sugerindo um potencial para análise de causa raiz mais rápida e menor esforço operacional manual. Nossa principal ressalva é a transparência de custos. A plataforma cobra por agente-segundo gasto na investigação de um incidente, tornando os custos difíceis de prever. Os gastos podem se acumular rapidamente sem um monitoramento rigoroso. O serviço está disponível publicamente apenas desde março de 2026, por isso recomendamos avaliá-lo com validação humana de cada achado, controle rígido sobre quais eventos disparem investigações e acompanhamento ativo de custos.
-
61. Claude Managed Agents
O Claude Managed Agents é o serviço hospedado da Anthropic para a execução de agentes de uso geral. As equipes definem o modelo, prompt, ferramentas, servidores MCP e habilidades de cada agente. A Anthropic fornece o restante de um managed agents runtime: o loop do agente, sandbox, agendamento e observabilidade. Os agentes são executados de acordo com um agendamento ou quando uma aplicação inicia uma sessão por meio da API. Execuções agendadas são adequadas para trabalhos recorrentes em segundo plano, como triagem de alertas e proposição de correções na forma de pull requests para revisão humana.
As equipes podem começar sem escrever código, por meio do console, ou usar integrações baseadas em código para maior flexibilidade e controle. Definições de agente, ambiente e agendamento podem ser armazenadas em arquivos aplicados por meio de um pipeline de CI. Um cofre de credenciais injeta credenciais em requisições de saída sem expô-las ao agente. Uma de nossas equipes internas escolheu o Claude Managed Agents em vez de outras plataformas de agentes, incluindo o Gemini Enterprise Agent Platform, por ser mais fácil de entender e mais rápido de entregar.
Estamos colocando-o em “Avalie” porque nossa experiência está limitada a essa equipe e o serviço está em fase beta. Ao contrário do Amazon Bedrock AgentCore, ele suporta apenas o harness de agentes da Anthropic e modelos Claude. A Anthropic cobra pelo tempo de execução da sessão, bem como por tokens. Como o serviço armazena sessões, ele não é elegível para retenção zero de dados. Sandboxes auto-hospedados podem manter a execução de ferramentas dentro da sua rede, mas a orquestração e os resultados das ferramentas ainda passam pela Anthropic.
-
62. Decision models
Uma nova classe de modelos de IA chamada modelos de decisão (decision models) surgiu desde o último Radar. A TypeSafe AI lançou o Jev, que ela chama de um modelo 'System One' construído para tomar decisões rápidas e estruturadas. Vários outros modelos se seguiram, incluindo Laya, Nimble e Kev. Em contraste com modelos de raciocínio deliberativo, os modelos de decisão fornecem valores estruturados predefinidos como saída em vez de texto gerado. Em vez de usar aprendizado por reforço com feedback humano (RLHF) para otimizar preferências humanas, o Jev usa aprendizado por reforço com decisões calibradas (RLCD) para otimizar para decisões bem calibradas, onde as probabilidades previstas refletem com que frequência um resultado realmente ocorre. Suas saídas menores e estruturadas permitem um processamento mais rápido e barato. Os modelos de decisão recebem um estado e um conjunto de perguntas. Cada pergunta feita em relação ao estado deve corresponder a um dos três tipos: Noul para perguntas do tipo sim/não que retornam a probabilidade de uma resposta “sim”, Choice para opções categorizadas de múltipla escolha ou Score para avaliações em uma escala ordinal ordenada.
Os casos de uso de modelos de decisão incluem Jev-as-a-judge como uma alternativa a LLM como juiz, roteamento de modelos e ferramentas, portões de políticas (policy gates) e rotulagem em lote (bulk labeling). Recomendamos que as equipes evitem o uso excessivo de LLMs e definam critérios de avaliação para determinar se um decision model pode substituir um LLM para casos de uso de classificação.
-
63. KAITO
O KAITO (Kubernetes AI Toolchain Operator) é um operador Kubernetes que automatiza a infraestrutura necessária para auto-hospedar modelos open-weight em seus próprios clusters. Em vez de configurar manualmente nós de GPU e servidores de modelos, as equipes declaram um
Workspace, o recurso personalizado do KAITO para a implantação de um único modelo, especificando o modelo e o tipo de instância de GPU. O controlador do KAITO então provisiona os nós de GPU correspondentes por meio de NodePools do Karpenter, estima os requisitos de memória de GPU, ajusta o runtime e disponibiliza o modelo através do vLLM, expondo um endpoint compatível com a OpenAI via um Kubernetes Service.Nossas equipes começaram a explorar o KAITO no AKS para hospedar modelos de linguagem de pequeno porte com menor custo e latência. Anteriormente, executar o Ollama e o vLLM diretamente em VMs com GPU exigia gerenciar drivers, escalonamento e configuração de nós manualmente. Gerenciar o ciclo de vida do modelo por meio dos mesmos manifestos declarativos usados para outras cargas de trabalho promete reduzir grande parte desse trabalho repetitivo.
No entanto, o escopo do KAITO é deliberadamente afunilado. Ele lida com o provisionamento de nós e a implantação de modelos, em vez de focar na pilha de inferência mais ampla, onde o KServe é mais maduro e oferece recursos como roteamento consciente de KV-cache. O KAITO ainda é um projeto CNCF Sandbox. Seu autoprovisionamento de nós de GPU é mais maduro no AKS, e ele oferece suporte apenas para GPUs NVIDIA da geração Ampere ou mais recentes. Achamos que vale a pena avaliar, especialmente para equipes que desejam auto-hospedar modelos usando suas ferramentas Kubernetes existentes.
-
64. llm-d
O llm-d é uma stack de serviço de inferência distribuída de código aberto projetada para operar servidores de modelos como vLLM e SGLang em múltiplos nós do Kubernetes. Aplicações web tradicionais dependem frequentemente de roteamento sem estado (stateless) e escalabilidade horizontal, mas a inferência de LLMs é altamente baseada em estado (stateful) devido ao caching de chave-valor (KV). Em vez de tratar pods de serviço de modelos como backends HTTP intercambiáveis, o llm-d utiliza roteamento consciente de inferência para coordenar requisições em múltiplos aceleradores, estendendo a otimização além dos servidores de modelos individuais.
Construído em torno do Kubernetes e do Gateway API Inference Extension, o llm-d oferece diversos recursos adaptados ao tráfego de IA stateful. Ele suporta roteamento consciente de modelo e de cache KV, utilizando fatores como afinidade de cache, profundidade de fila e latência prevista para orientar as decisões de agendamento. Um recurso notável é a desagregação de prefill e decode, que permite aos operadores posicionar cargas de trabalho de prefill com uso intensivo de computação em um conjunto de GPUs e tarefas de decoding limitadas por largura de banda de memória em outro. Isso pode melhorar a utilização de hardware e os custos de inferência. Equipes que constroem plataformas de inferência GPU em grande escala devem avaliar o llm-d como uma base emergente para sua camada de inferência, especialmente ao buscar escalar enquanto atendem a objetivos rígidos de latência.
-
65. Netris
Netris é uma plataforma de automação de rede fora de banda (out-of-band) e multi-tenancy para data centers físicos e infraestrutura de IA. Usando um modelo declarativo de infraestrutura como código acessível por meio de UI, API, CRDs do Kubernetes e Terraform, ele simplifica o gerenciamento de rede abstraindo configurações de switches em clouds privadas virtuais (VPCs) no estilo cloud, redes virtuais, listas de controle de acesso (ACLs) e balanceadores de carga de Camada 4. Um controlador central gerencia políticas enquanto agentes leves executam alterações em switches e unidades de processamento de dados (DPUs). O controlador opera fora de banda como um plano de controle de automação, permitindo que o encaminhamento de pacotes continue sem interrupções mesmo se o controlador ficar offline.
Estamos destacando o Netris por seu suporte a cargas de trabalho de IA de alta largura de banda. Ele automatiza fabrics de Ethernet VPN (EVPN) roteados, gerencia o controle de fluxo para RDMA sobre Ethernet Convergida (RoCE) e orquestra DPUs NVIDIA BlueField para multi-tenancy aplicado via hardware. Ele também se integra ao NVIDIA UFM para chaves de partição InfiniBand (PKeys) e ao NMX-C para domínios NVLink, ajudando a gerenciar limites multi-tenant em diferentes fabrics de IA por meio de uma camada de gerenciamento unificada. Estamos colocando o Netris em “Avalie” para equipes que constroem clouds privadas automatizadas ou data centers de IA, embora as equipes devam avaliar a compatibilidade com seus sistemas operacionais de switch, como SONiC, Cumulus Linux e Arista EOS, bem como os limites do suporte à orquestração bare-metal.
-
66. Omnigent
O Omnigent é um meta-harness de código aberto, lançado pela Databricks, que opera acima de agentes de programação como Claude Code, OpenAI Codex e Pi, bem como agentes definidos em YAML. Ele fornece uma camada comum para recursos que, de outra forma, cada harness implementaria de maneira diferente. As políticas podem limitar gastos ou exigir aprovação antes de uma ação de risco, enquanto um sandbox do sistema operacional restringe o acesso ao sistema de arquivos e à rede e substitui credenciais em requisições de saída, permitindo que o agente as use sem lê-las. As sessões são persistentes, permitindo que uma execução continue de onde parou. O Omnigent também pode se comunicar com os agentes por meio do Agent Client Protocol (ACP) em vez de envolver cada CLI.
Em um laptop, o Omnigent oferece à pessoa desenvolvedora uma caixa de entrada de sessões paralelas, de forma muito semelhante ao que o Herdr faz. Como um servidor compartilhado, ele adiciona Single Sign-On, compartilhamento de sessão em tempo real e políticas definidas por administradores, com sessões rodando localmente ou em sandboxes na nuvem como o E2B. Isso se adequa a organizações que desejam controles consistentes, independentemente de quais agentes de programação suas pessoas desenvolvedoras escolham. Ainda não temos certeza de qual seja a abstração correta em relação aos agentes de programação, e o projeto ainda se descreve como estando na fase alfa. Equipes que desejam políticas consistentes entre vários agentes de programação devem avaliar o Omnigent levando em conta essas duas ressalvas.
-
67. VAST DataStore
VAST DataStore é a camada de armazenamento da plataforma VAST Data. Ela fornece acesso a arquivos (NFS e SMB), objetos (S3) e blocos (NVMe/TCP) por meio de um namespace unificado. Sua arquitetura desagregada do tipo shared-everything separa nós de computação sem estado (stateless) do armazenamento NVMe compartilhado, permitindo que a capacidade e o desempenho sejam dimensionados de forma independente. Estamos avaliando-a porque o throughput de armazenamento afeta cada vez mais a eficiência com que clusters caros de GPU operam durante o treinamento, o checkpointing e o carregamento de modelos. O DataStore permite que as cargas de trabalho mantenham o acesso convencional NFS/POSIX ou S3 enquanto usam NVMe e RDMA para uma transferência de dados mais rápida, oferecendo uma alternativa aos sistemas de arquivos paralelos especializados. A VAST também está trabalhando com a NVIDIA no S3 sobre RDMA e armazenamento compartilhado de KV-cache para inferência desagregada.
Comparado com o Ceph, que oferece armazenamento de blocos, arquivos e objetos de código aberto em hardware convencional, o DataStore é uma plataforma proprietária projetada para cargas de trabalho de NVMe, RDMA e IA. No entanto, ele é caro e prende você à plataforma de dados mais ampla da VAST, portanto pode ser mais do que as equipes precisam, a menos que estejam treinando modelos ou executando inferência em grande escala. Achamos que o VAST DataStore vale a pena ser avaliado por equipes que projetam grandes clusters de GPU para cargas de trabalho de IA e computação de alto desempenho (HPC), em que o carregamento de dados, o checkpointing e o acesso intensivo a metadados de bilhões de arquivos podem deixar GPUs caras esperando pelo armazenamento.
Cautela
Não encontrou algo que você esperava achar?
Cada edição do Radar inclui blips que refletem nossas experiências nos seis meses anteriores. Talvez já tenhamos falado sobre o que você procura em um Radar anterior. Às vezes, deixamos coisas de fora simplesmente porque há muitas a serem abordadas. Também pode faltar um tópico específico porque o Radar reflete nossa experiência, não se baseando em uma análise abrangente do mercado.
