Enable javascript in your browser for better experience. Need to know to enable it? Go here.
  • Plataformas

    Adote Experimente Avalie Cautela Adote Experimente Avalie Cautela
  • Novo
  • Modificado
  • Sem alteração

Plataformas

Adote ?

Sem blips

Experimente ?

  • 42. AG-UI Protocol

    O AG-UI é um protocolo aberto e uma biblioteca projetados para padronizar a comunicação entre interfaces de usuário ricas e agentes de IA no backend. Historicamente, construir UIs baseadas em agentes exigia uma infraestrutura sob medida para colaboração bidirecional e stateful. O AG-UI aborda isso fornecendo uma arquitetura consistente e orientada a eventos — com suporte a mecanismos de transporte como server-sent events (SSE) e WebSockets — para transmitir, em streaming, etapas do raciocínio, sincronizar o estado e renderizar componentes dinâmicos de UI. No entanto, o cenário arquitetural para interfaces de agentes está mudando rapidamente. O AG-UI intencionalmente se posiciona fora do MCP, funcionando como uma camada de interface entre o frontend e o backend do agente. Agora estamos vendo uma abordagem diferente emergir, onde aplicações mais recentes baseadas em MCP empacotam HTML e widgets de UI diretamente dentro de servidores MCP ou skills. Como os componentes de UI agora podem ser incorporados e disponibilizados junto com as próprias ferramentas — um padrão relacionado a padrões adjacentes emergentes como o MCP-UI —, a necessidade de uma camada de protocolo de UI separada, como o AG-UI, está sendo questionada. Embora o AG-UI continue sendo uma escolha sólida para desacoplar a UX do frontend da orquestração do backend, os times devem avaliar seu papel à luz da tendência crescente de consolidar a lógica de ferramentas e a UI dentro do ecossistema MCP.

  • 43. Apache APISIX

    O Apache APISIX é um gateway nativo de nuvem, de alto desempenho e código aberto, que resolve as limitações das soluções legadas baseadas em Nginx. Construído sobre Nginx e LuaJIT via OpenResty, ele utiliza etcd para o armazenamento de configurações, eliminando a latência causada por recarregamentos (reloads), o que o torna ideal para microsserviços dinâmicos e arquiteturas serverless. Sua principal força é a arquitetura totalmente dinâmica e extensível, que permite às equipes personalizar o gerenciamento de tráfego, a segurança e a observabilidade por meio de APIs e de um ecossistema de plugins multilíngue, incluindo suporte a WASM. Ao suportar a API de Gateway do Kubernetes, o Apache APISIX pode ser utilizado como um gateway para Kubernetes e é um forte candidato para substituir controladores de ingress legados do Nginx. Algumas de nossas equipes estão adotando o Apache APISIX e consideram seu desempenho e conjunto de recursos impressionantes.

  • 44. AWS Bedrock AgentCore

    O AWS Bedrock AgentCore é a plataforma baseada em agentes para construir, executar e operar agentes em escala, com segurança, sem o overhead de gerenciamento de infraestrutura, semelhante ao GCP Vertex AI Agent Builder e ao Azure AI Foundry Agent Service. Embora seja tentador adotar a plataforma como uma caixa preta monolítica, temos visto mais sucesso com uma arquitetura mais refinada e desacoplada: usar o runtime do AgentCore para questões de produção, como isolamento de sessão, segurança e observabilidade, mantendo a lógica de orquestração em frameworks externos como o LangGraph. Essa separação de responsabilidades permite que os times se beneficiem da infraestrutura gerenciada enquanto mantêm a flexibilidade para se adaptar à medida que o cenário de LLMs evolui. Ao focar primeiro no runtime, as organizações podem mover gradualmente cargas de trabalho baseadas em agentes para produção sem ceder o controle de sua lógica central a uma camada de orquestração específica de um fornecedor.

  • 45. Graphiti

    Estamos movendo o Graphiti para Avaliação (Trial), pois este mecanismo de grafo de conhecimento temporal de código aberto da Zep tem demonstrado viabilidade em produção no endereçamento do problema de memória de LLMs. Enquanto banco de dados vetoriais planos em pipelines de RAG falham em rastrear como os fatos mudam ao longo do tempo, o Graphiti ingere episódios discretos e mantém janelas de validade bitemporal nas arestas do grafo, de modo que fatos desatualizados são invalidados em vez de sobrescritos. Diferente do GraphRAG, que é orientado a processamento em lote, ele atualiza o grafo de forma incremental e entrega recuperação em menos de um segundo via recuperação híbrida que combina busca semântica, BM25 e travessia de grafos, sem chamadas de LLM no momento da consulta. Dois fatores impulsionaram esse movimento: benchmarks revisados por pares relatando melhorias de 18,5% na precisão e reduções de 90% na latência, além do lançamento de um servidor MCP de primeira classe que permite que agentes compatíveis com o Model Context Protocol anexem memória temporal persistente com mínimo esforço de integração. A forte adoção da comunidade sinaliza ainda mais a prontidão para produção. Estamos usando o Graphiti para construir agentes cientes de contexto com grafos de conhecimento stateful e com consciência temporal, e recomendamos avaliá-lo para aplicações baseadas em agentes. O Neo4j é o backend principal, com o FalkorDB como uma alternativa mais leve. Os times também devem considerar os custos de extração de LLM por gravação e fixar dependências (pin dependencies) devido ao seu status de lançamento pré-1.0.

  • 46. Langfuse

    O Langfuse é uma plataforma de engenharia de LLM de código aberto que abrange observabilidade, gerenciamento de prompts, avaliações e gerenciamento de conjuntos de dados. O projeto amadureceu significativamente desde a última vez que o avaliamos. A arquitetura v3 introduz o ClickHouse, Redis e S3 como componentes de backend, tornando-o mais escalável, mas também mais complexo de hospedar por conta própria. Tanto os SDKs para Python quanto para TypeScript agora são baseados nativamente em OpenTelemetry, fazendo do Langfuse uma escolha natural para times que já usam observabilidade baseada em OTEL. Novos recursos, como o SDK de execução de experimentos e o suporte a saída estruturada para experimentos de prompt, movem o Langfuse além do tracing puro, em direção a fluxos de trabalho sistemáticos de avaliação. Isso faz com que valha a pena considerá-lo em um cenário cada vez mais concorrido que inclui Arize Phoenix, Helicone e LangSmith. Equipes que desenvolvem principalmente com base em Pydantic AI também podem considerar o Pydantic Logfire, que adota uma abordagem mais ampla como uma plataforma de observabilidade OTEL full-stack, e não uma suíte de ferramentas específica para LLMs. O Langfuse permanece em Avalie, pois é uma opção sólida para times que precisam de tracing integrado, avaliações e gerenciamento de prompts em uma única plataforma que pode ser hospedada por conta própria. No entanto, os times devem avaliar se o compromisso com a infraestrutura se justifica para a sua escala e se uma ferramenta mais focada, como o Helicone pode ser suficiente caso a necessidade principal seja visibilidade de custos e latência na camada do modelo.

  • 47. Port

    O Port é um portal interno comercial para pessoas desenvolvedoras, projetado para melhorar a experiência da pessoa desenvolvedora centralizando ativos de software, automatizando workflows e impondo padrões de engenharia, dando aos times de plataforma uma única fonte de verdade para workflows de autosserviço. Vemos que isso importa cada vez mais à medida que as organizações buscam padronizar os workflows de engenharia enquanto expõem templates, APIs, automações e agentes de uma forma que as pessoas desenvolvedoras possam realmente usar, inclusive diretamente na IDE através das camadas de API e MCP do Port, e não apenas por meio de um portal independente. Em nossa experiência, o Port funciona bem para organizações que desejam capacidades de portal produzidas sem investir pesadamente em engenharia de plataforma. Em engajamentos com clientes, ele tem suportado milhares de pessoas desenvolvedoras ao mesmo tempo em que permite que times de plataforma relativamente pequenos entreguem um autosserviço eficaz rapidamente. Acreditamos que vale a pena avaliar o Port para organizações que precisam de capacidades de portal interno rapidamente e podem aceitar as restrições de uma plataforma comercial e a dependência de fornecedor.

  • 48. Replit

    O Replit é uma plataforma de desenvolvimento colaborativo nativa de nuvem que fornece ambientes de desenvolvimento instantâneos, programação em tempo real e assistência de IA integrada diretamente no navegador. Ele combina um editor, runtime, implantação e workflows de programação de IA em uma única plataforma unificada, o que permite que as pessoas desenvolvedoras comecem a programar imediatamente sem nenhuma configuração local. Descobrimos que essa IDE colaborativa baseada em IA é realmente útil para tornar a integração inicial mais fácil, tornando-a uma ótima opção para a prototipagem em time. Também a consideramos muito eficaz para sessões de treinamento, compartilhamento de conhecimento e bootcamps. Embora alguns possam ver o Replit como um lugar para projetos de hobby assistidos por IA, nós achamos que ele se destaca porque o ambiente é poderoso o suficiente para competir com IDEs locais tradicionais, tornando a iteração e a colaboração muito mais fáceis.

  • 49. SigNoz

    O SigNoz é uma plataforma de observabilidade de código aberto e nativa de OpenTelemetry que oferece suporte unificado a logs, métricas e traces. Atende às necessidades de APM e instrumentação de microsserviços modernos e arquiteturas distribuídas, evitando lock-in de fornecedor. Ao usar ClickHouse como banco de dados colunar subjacente, o SigNoz oferece armazenamento escalável, de alto desempenho e custo-efetivo com consultas rápidas, posicionando-se como uma alternativa forte self-hosted a plataformas como Datadog. Suporta consultas flexíveis via PromQL e SQL do ClickHouse, além de alertas em vários canais de notificação. Na prática, temos visto o SigNoz reduzir o consumo de recursos de infraestrutura e os custos gerais de observabilidade sem comprometer o desempenho. Embora exista um serviço de nuvem gerenciado, imagens Docker e Helm charts prontos para uso tornam-no uma opção prática para organizações que preferem manter o controle sobre dados e infraestrutura.

Avalie ?

  • 50. Agent Trace

    O Agent Trace é uma especificação aberta proposta pelo Cursor que busca padronizar a atribuição de código de IA. À medida que a adoção de agentes de programação aumenta, entender quem modificou o código agora vai além das pessoas desenvolvedoras humanas para incluir alterações geradas por IA. Estamos vendo um interesse inicial de times que precisam de melhor rastreabilidade em torno dessas mudanças. Ferramentas existentes como o git blame podem mostrar que uma linha de código foi modificada, mas falham em capturar se essa mudança foi feita por um humano, uma IA ou ambos. O Agent Trace adota uma abordagem neutra em relação a fornecedores para definir como as alterações de código são rastreadas e não é opinativo sobre como esses rastros são armazenados. Ele é compatível com múltiplos sistemas de controle de versão, incluindo Git, Mercurial e Jujutsu. A especificação define tipos de contribuintes como humano, IA, misto e desconhecido, juntamente com um registro de rastro descrevendo a origem de cada contribuição. Há sinais iniciais de adoção, com suporte de ferramentas como Cline e OpenCode, bem como implementações como o Git AI. Times que adotam agentes de programação devem avaliar ferramentas que implementam a especificação Agent Trace para melhorar a atribuição de código.

  • 51. ClickStack

    O ClickStack é uma plataforma de observabilidade de código aberto e compatível com o OpenTelemetry que unifica logs, traces, métricas e sessões em um único armazenamento de dados de alto desempenho construído sobre o ClickHouse. À medida que a infraestrutura cresce e os custos de observabilidade aumentam, muitos times enfrentam dificuldades com conjuntos de ferramentas de telemetria fragmentados e plataformas comerciais caras. O ClickStack aborda esse desafio aproveitando o armazenamento colunar do ClickHouse para permitir consultas de alta cardinalidade em subsegundos em grandes volumes de dados de telemetria, oferecendo uma base mais simples e de melhor custo-benefício para observabilidade.

  • 52. Coder

    O Coder apresenta uma boa alternativa aos ambientes de desenvolvimento transmitidos por pixels ao separar onde o código é executado de como as pessoas desenvolvedoras interagem com ele. Em vez de transmitir interfaces completas de desktop, as pessoas desenvolvedoras se conectam a ambientes remotos usando IDEs locais, como o VS Code, ou um navegador, resultando em uma experiência mais responsiva sem comprometer a usabilidade. Nesse modelo, o código é executado em infraestrutura remota e escalável, enquanto os ambientes são definidos e gerenciados como código. Isso permite que os times padronizem as configurações de desenvolvimento e simplifiquem o onboarding de novas pessoas desenvolvedoras. Também facilita o fornecimento de acesso controlado a sistemas internos e simplifica o acesso a agentes de programação de IA pré-aprovados. Nós vemos o Coder como um meio-termo entre o desenvolvimento local e desktops totalmente virtualizados: ele fornece controle centralizado e governança sem as limitações de usabilidade de VDIs transmitidos por pixels. Isso o torna uma boa opção para organizações que exigem ambientes de execução remotos ou controlados, particularmente onde mais recursos computacionais ou acesso seguro é necessário. Como em abordagens semelhantes, os times devem avaliar o overhead operacional e as responsabilidades de segurança que vêm com o gerenciamento desses ambientes.

  • 53. Databricks Agent Bricks

    À medida que as abordagens baseadas em agentes se tornam mais comuns, estamos vendo as plataformas de dados evoluírem para suportar essas cargas de trabalho nativamente, em vez de como um complemento improvisado. O Databricks Agent Bricks fornece componentes pré-construídos e de otimização automática para padrões comuns de IA, como assistentes de conhecimento e analistas de dados. Ele segue uma abordagem declarativa: as pessoas desenvolvedoras definem o objetivo e os dados subjacentes, enquanto o framework lida com a execução e a otimização. Ao simplificar o LLMOps e reduzir o esforço necessário para a curadoria de dados, os times podem focar mais nos resultados de negócios do que no boilerplate. Por exemplo, nossos times usaram-no ao lado de agentes personalizados para avaliar e construir soluções complexas de RAG para R&D pré-clínico. Se você já investiu no ecossistema Databricks e está explorando abordagens baseadas em agentes para casos de uso comuns, como chatbots e extração de documentos, considere avaliar o Agent Bricks.

  • 54. DuckLake

    O DuckLake é um formato integrado de data lake e catálogo que simplifica a arquitetura de Lakehouse usando bancos de dados SQL padrão para gerenciar o catálogo e os metadados. Enquanto formatos abertos de tabelas tradicionais, como Iceberg ou Delta Lake, dependem de estruturas complexas de metadados baseadas em arquivos, o DuckLake armazena os metadados em um banco de dados de catálogo (por exemplo, SQLite, PostgreSQL ou DuckDB) enquanto persiste os dados como arquivos Parquet no disco local ou em armazenamento de objetos compatível com S3. Essa abordagem híbrida melhora a latência de planejamento de consultas e a confiabilidade transacional durante atualizações concorrentes. DuckDB atua como mecanismo de consulta por meio da extensão ducklake, oferecendo uma interface SQL familiar para operações DDL e DML padrão. Ele também preserva características de lakehouse, como particionamento, mas omite índices e chaves primárias e estrangeiras. Com suporte para time travel, evolução de esquema e conformidade ACID, o DuckLake oferece uma opção de baixa complexidade para times que buscam uma stack analítica autônoma. Embora ainda esteja em estágio inicial de maturidade, o DuckLake é uma alternativa leve e promissora às arquiteturas de lakehouse tradicionais. Ele evita o overhead operacional associado a ecossistemas baseados em Spark ou Trino, o que o torna uma boa opção para ambientes de dados mais enxutos.

  • 55. FalkorDB

    O FalkorDB é um banco de dados de grafos baseado em Redis que suporta Cypher e atende times que desejam recursos de grafos sem adotar uma plataforma de grafos pesada. Nós o vemos como uma opção prática para organizações que constroem cargas de trabalho de aplicações e IA ricas em relacionamentos, onde o baixo atrito operacional é importante e onde um serviço de grafos baseado em servidor é preferível ao armazenamento embarcado (embedded storage). Estamos colocando-o em Análise (Assess) porque a arquitetura é promissora e o modelo para as pessoas desenvolvedoras é acessível, mas os times devem validar o comportamento em produção em relação ao escalonamento, ferramentas operacionais e maturidade do ecossistema a longo prazo antes de se comprometerem com uma adoção ampla.

  • 56. Google Dialogflow CX

    O Google Dialogflow CX é a plataforma de IA conversacional gerenciada do Google Cloud, combinando uma máquina de estados baseada em grafos de Fluxos e Páginas com capacidades generativas impulsionadas pelo Vertex AI Gemini. Nós acompanhamos anteriormente seu antecessor, o Dialogflow, no Radar. O CX representa um redesenho significativo que ganhou tração após o Google integrar os modelos Vertex AI Gemini em 2024, introduzindo Generative Playbooks para agentes orientados a instruções e Data Store RAG para fundamentar respostas em conteúdo indexado. Nós o utilizamos para construir um agente de descoberta de dados em linguagem natural, escolhendo-o em vez de uma abordagem de SDK customizado devido ao seu ambiente low-code e aos Generative Playbooks. Nós os configuramos com engenharia de prompt com poucos exemplos para traduzir consultas em linguagem natural para SQL. Times no Google Cloud que constroem interfaces de linguagem natural sobre dados internos estruturados descobrirão que o Dialogflow CX acelera a entrega em comparação com uma stack de agentes customizada. No entanto, a plataforma não possui um plano gratuito; sua profunda dependência do Google Cloud introduz um "vendor lock-in" (aprisionamento tecnológico) significativo, e as equipes devem planejar o esforço necessário para a engenharia de contexto.

  • 57. MCP Apps

    O MCP Apps é a primeira extensão oficial para o Model Context Protocol, permitindo que servidores MCP retornem interfaces HTML interativas como dashboards, formulários e visualizações que são renderizadas diretamente na conversa. Desenvolvida em conjunto pela Anthropic, OpenAI e pessoas contribuidoras de código aberto, a extensão padroniza um esquema de recursos ui:// onde as ferramentas declaram templates de UI renderizados em iframes em sandbox, com degradação suave para texto quando o host não possui suporte a UI. Diferentemente do AG-UI, que opera como uma camada de biblioteca separada, o MCP Apps empacota a UI diretamente dentro dos servidores MCP. O design bidirecional permite que os modelos observem as ações das pessoas usuárias, enquanto a interface lida com dados em tempo real e manipulação direta que o texto não consegue fazer. Clientes como Claude, ChatGPT, VS Code e Goose já vêm com suporte. Times que exploram interações mais ricas com agentes devem avaliar se a complexidade adicional em relação às respostas em texto simples se justifica para o seu caso de uso.

  • 58. Monarch

    O Monarch é um framework de programação distribuída de código aberto que traz a simplicidade das cargas de trabalho do PyTorch de uma única máquina para grandes clusters de GPU. Ele fornece uma API Python para criar processos remotos e atores, agrupando-os em coleções chamadas “meshes” que suportam mensagens de transmissão. Ele também oferece tolerância a falhas por meio de árvores de supervisão, onde as falhas se propagam acima de uma hierarquia para permitir um tratamento de erros limpo e uma recuperação refinada. Recursos adicionais incluem suporte para transferências RDMA ponto a ponto para movimentação eficiente de memória de CPU e GPU, e uma abstração de tensor distribuído que permite que atores trabalhem com tensores fragmentados entre processos enquanto mantêm um modelo de programação imperativo. O Monarch é construído sobre um backend Rust de alto desempenho. Embora ainda esteja nos estágios iniciais de desenvolvimento, a sua abstração — fazendo com que tensores distribuídos se comportem como locais — é poderosa e pode reduzir bastante a complexidade do treinamento de IA distribuídas de larga escala.

  • 59. Neutree

    O Neutree é uma plataforma de código aberto para gerenciar e servir LLMs em infraestrutura privada, posicionando-se como uma camada de modelo como serviço (model-as-a-service) para IA corporativa. Ele fornece um plano de controle unificado para gerenciamento do ciclo de vida do modelo, serviço de inferência e agendamento de computação em hardwares heterogêneos, como aceleradores NVIDIA, AMD e Intel. À medida que as organizações se afastam de APIs hospedadas em direção a implantações auto-hospedadas e governadas, o Neutree aborda uma lacuna clara: operar cargas de trabalho de LLM com capacidades de nível corporativo, como multitenant, controle de acesso, contabilização de uso e abstração de infraestrutura. Ao separar o serviço de modelo da lógica da aplicação, ele permite que os times implantem, escalem e roteiem modelos entre ambientes — incluindo bare metal, VMs (máquinas virtuais) e contêineres — sem um forte acoplamento a um provedor de nuvem específico. No entanto, o Neutree ainda é relativamente novo, e os times devem abordar a adoção com cautela. Seu ecossistema, maturidade operacional e capacidades de integração ainda estão evoluindo, quando comparados a plataformas de ML (machine learning) mais estabelecidas. Embora promissor, ele é mais adequado para times dispostos a investir na avaliação e na formação de infraestruturas emergentes de IA corporativa.

  • 60. OptScale

    O OptScale é uma plataforma FinOps multi-nuvem de código aberto com suporte para cargas de trabalho pesadas de IA/ML, onde os custos de GPU e experimentação podem disparar rapidamente. Ele ingere dados de faturamento e uso de APIs de nuvem, combinando visibilidade de custos, recomendações de otimização, rastreamento de orçamento e detecção de anomalias em um único sistema com alertas baseados em políticas alinhadas aos times ou estruturas de negócios. Em comparação com o OpenCost, o OptScale cobre casos de uso de FinOps não-Kubernetes mais amplos, enquanto ainda fornece análise no nível do Kubernetes. Ele também oferece mais controle e menos vendor lock-in do que suítes corporativas como IBM Cloudability, CloudZero, CloudHealth, IBM Kubecost e Flexera One. A contrapartida é um overhead operacional mais alto, com preocupações em torno da complexidade de implantação, edge cases de conectores e higiene de segurança de imagens de contêineres. Os times devem tratar o OptScale como um investimento em capacidade de plataforma em vez de um produto plug-and-play.

  • 61. Rhesis

    O Rhesis é uma plataforma de testes de código aberto para aplicações de LLM e aplicações baseadas em agentes que permite aos times definirem comportamento esperado em linguagem natural, gerar cenários de teste adversariais e avaliar resultados por meio de uma IU e uma SDK ou API. Ele está se tornando mais relevante à medida que as abordagens de teste tradicionais assumem um comportamento determinístico, enquanto os sistemas de IA falham de maneiras mais sutis, incluindo jailbreaks, interações de múltiplos turnos (multi-turn), violações de políticas e edge cases dependentes de contexto. Em nossa avaliação, o Rhesis é uma plataforma útil para times que precisam de mais do que simples avaliações de prompt. Recursos como o simulador de conversas, testes adversariais, tracing baseado em OpenTelemetry e auto-hospedagem via Docker tornam-no uma maneira prática de trazer times de produto, de domínio e de engenharia para um workflow de testes compartilhado. O principal benefício é a melhoria da validação em pré-produção para sistemas não determinísticos. No entanto, os times devem considerar as concessões comuns neste espaço, incluindo o custo de avaliação, os limites das métricas de LLM-como-juiz e a necessidade de requisitos bem definidos antes que a plataforma entregue valor. Nós acreditamos que vale a pena avaliar o Rhesis para times que constroem sistemas de LLMs ou baseados em agentes que exigem testes colaborativos e repetíveis além das verificações básicas de prompt.

  • 62. RunPod

    À medida que as organizações experimentam cada vez mais o treinamento e ajuste fino (fine-tuning) de LLMs, provedores de hiperescala como AWS e Google Cloud podem introduzir altos custos e disponibilidade limitada de hardware. O RunPod fornece uma alternativa econômica para cargas de trabalho de IA com uso intensivo de computação. Operando como um marketplace de GPUs distribuído globalmente, ele oferece acesso sob demanda a uma ampla gama de hardwares, desde clusters H100 de nível corporativo até RTX 4090s de nível de consumidor, frequentemente a um custo significativamente menor do que os provedores de nuvem tradicionais. Para times que precisam de infraestrutura flexível e econômica para desenvolver, treinar ou implantar modelos de IA sem compromissos de longo prazo ou bloqueios tecnológicos, o RunPod é uma opção prática que vale a pena avaliar.

  • 63. Sprites

    Sprites é um ambiente de sandbox stateful da Fly.io projetado para executar agentes de programação de IA em isolamento. Enquanto a maioria dos sandboxes de agentes é efêmera, sendo ativada para uma tarefa e desaparecendo em seguida, o Sprites fornece ambientes Linux persistentes com capacidades ilimitadas de checkpoint e restauração. Isso permite que as pessoas desenvolvedoras tirem snapshots de todo o estado do ambiente — incluindo dependências instaladas, configurações de runtime e alterações no sistema de arquivos — e façam rollback quando um agente sai dos trilhos. Isso vai além do que apenas o Git consegue recuperar, capturando o estado do sistema que o controle de versão não rastreia. À medida que nossos times adotam cada vez mais a execução em sandbox para agentes de programação como um padrão sensato, o Sprites representa um dos extremos do espectro: uma abordagem não efêmera e stateful que troca a simplicidade dos contêineres descartáveis por opções mais ricas de recuperação. Os times que avaliam o uso de sandboxes para agentes devem considerar o Sprites ao lado de alternativas efêmeras, como os Dev Containers, com base em suas necessidades e workflow.

  • 64. torchforge

    O torchforge é uma biblioteca de aprendizado por reforço nativa do PyTorch projetada para o pós-treinamento em larga escala de modelos de linguagem. Ela fornece uma abstração de mais alto nível que desacopla a lógica algorítmica das questões de infraestrutura, orquestrando componentes como o Monarch para coordenação, vLLM para inferência e torchtitan para treinamento distribuído. Essa abordagem permite que equipes de pesquisa expressem workflows complexos de aprendizado por reforço usando APIs em estilo de pseudocódigo, enquanto distribuem cargas de trabalho por milhares de GPUs sem gerenciar detalhes de baixo nível, como sincronização de recursos, agendamento ou tolerância a falhas. Ao separar o “o que” (concepção do algoritmo) do “como” (execução distribuída), o torchforge simplifica a experimentação e a iteração em sistemas de alinhamento em larga escala. Vemos isso como um passo útil para tornar técnicas avançadas de pós-treinamento mais acessíveis, embora os times devam avaliar sua maturidade e adequação à sua infraestrutura de ML existente.

  • 65. torchtitan

    O torchtitan é uma plataforma nativa do PyTorch para o pré-treinamento em larga escala de modelos de IA generativa, fornecendo uma implementação de referência limpa e modular para treinamento distribuído de alto desempenho. Ele reúne primitivas distribuídas avançadas em um sistema coeso, suportando paralelismo 4D: paralelismo de dados, de tensor, de pipeline e de contexto. Como o treinamento de modelos na escala do Llama 3.1 405B exige escala e eficiência significativas, o torchtitan oferece uma base prática para construir e operar grandes cargas de trabalho de treinamento. Seu design modular torna mais fácil para os times experimentarem e evoluírem estratégias de paralelismo, mantendo a prontidão para produção. Vemos o torchtitan como um passo útil em direção à padronização do treinamento de modelos em larga escala no ecossistema PyTorch, particularmente para times que constroem sua própria infraestrutura de pré-treinamento.

Cautela ?

Sem blips

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.

Baixe o PDF

 

 

 

English | Português

Inscreva-se para receber a newsletter do Technology Radar

 

 

Seja assinante

 

 

Visite nosso arquivo para acessar os volumes anteriores