NVIDIA disponibiliza o cuOpt para testar rotas e estoque sem comprar GPU

O cuOpt decide rotas, não dirige caminhão

O cuOpt é um motor de otimização que a NVIDIA mantém e documenta publicamente em docs.nvidia.com, hoje na versão 26.10. Ele não controla veículo nem robô: recebe um conjunto de dados (pedidos, endereços, capacidade de cada veículo, janelas de horário) e devolve a melhor combinação de rotas, turnos ou alocação de estoque que encontrar dentro do tempo que você der a ele. Quem decide o que fazer com essa resposta continua sendo o sistema de gestão do armazém (o WMS) ou de transporte (o TMS) da empresa.

A diferença para uma planilha de roteirização comum é o hardware por trás: o cuOpt roda em GPU, a mesma peça usada para treinar modelos de IA, e isso permite testar milhares de combinações de rota em segundos. Segundo a documentação, o histórico de versões registrado vai de 25.05 (maio de 2025) até 26.10, o que mostra um projeto em atualização contínua há mais de um ano, não um lançamento de ontem.

Três problemas que ele resolve ao mesmo tempo

A documentação separa o cuOpt em três frentes, e cada uma resolve um tipo diferente de dor de cabeça de operação:

• Roteirização (TSP, VRP e PDP): o TSP é o problema clássico do caixeiro viajante (visitar vários pontos no menor percurso); o VRP é a versão com frota, quando vários veículos dividem as entregas; o PDP soma coleta e entrega no mesmo roteiro, útil quando o motorista pega material num fornecedor antes de entregar no cliente.
• Programação linear (LP): aloca recursos contínuos, como quantidade de cada produto a fabricar ou transportar, respeitando limites de capacidade.
• Programação inteira mista (MIP, em beta): entra quando a decisão é discreta, tipo "ligar ou não ligar essa linha" ou "usar o veículo A ou o veículo B", e não um valor que pode ser fracionado.

Para o armazém, o uso mais direto é a roteirização: organizar rotas de entrega, turnos de coleta (picking) e deslocamento de material dentro da própria planta.

O que dá pra configurar sem reescrever o sistema

A lista de recursos de roteirização da documentação cobre praticamente toda situação real de uma operação de distribuição:

• frota heterogênea (veículos com capacidades e custos diferentes na mesma rota)
• janelas de horário por veículo e por pedido
• pausas obrigatórias do motorista, inclusive por distância rodada (distance-based breaks)
• coleta e entrega combinadas (pickup and deliveries)
• custo fixo por veículo, usado para penalizar o uso de um caminhão extra
• número mínimo e máximo de veículos permitidos
• ponto de partida e chegada diferente para cada veículo
• solução inicial (warm start), que permite recalcular a rota rapidamente quando um pedido novo entra no meio do turno, sem resolver tudo do zero

Tudo isso é parâmetro de configuração, não código customizado. Quem monta o modelo descreve a operação (quantos veículos, que restrições, que prioridades) e o DataModel e o SolverSettings da API em Python cuidam do resto.

Testar sem comprar GPU: três caminhos

A parte que interessa a quem planeja antes de assinar contrato é que a própria documentação lista formas de rodar o cuOpt sem ter uma GPU na empresa:

O terceiro caminho ainda permite separar quem pede a otimização de quem processa: o gRPC descrito na documentação deixa um servidor com GPU resolver os problemas enquanto o sistema do armazém, numa máquina comum, só envia os dados e recebe a resposta. Isso significa comprar ou alugar GPU para um único servidor compartilhado, não para cada posto de trabalho.

Para quem já tem modelo de otimização feito em outra ferramenta, a documentação também lista suporte a linguagens de modelagem como AMPL, GAMS, PuLP, JuMP, Pyomo e CVXPY. Na prática, dá para trocar o solver por trás de um modelo já existente pelo cuOpt sem reescrever a modelagem inteira.

O exemplo de fábrica que a NVIDIA mostra (e o que falta nele)

Entre os exemplos oficiais de Python está o "Intra-Factory Transport", que resolve justamente o deslocamento de material dentro de uma planta, e o "TSP Batch Mode", que resolve várias rotas pequenas ao mesmo tempo, como várias rotas de coleta (picking) rodando juntas num mesmo turno.

É importante dizer com clareza o que esses exemplos são: notebooks de demonstração, sem setor de indústria identificado, sem porte de empresa e sem número de antes e depois. A documentação não traz um caso real medido em fábrica brasileira ou de qualquer outro país. Serve para entender a sintaxe e testar a lógica, não como prova de ganho de produtividade.

O custo real não está na licença

A documentação não publica tabela de preço, porque o próprio uso para teste é gratuito nos caminhos citados acima. Isso não quer dizer custo zero para colocar em produção. O que de fato pesa no orçamento é:

• horas de um analista de logística ou de TI para levantar os dados de pedidos, frota e horários e montar o modelo
• o custo da instância de GPU na nuvem (ou do servidor próprio) se o uso passar de teste para operação diária
• integração com o WMS ou o TMS já em uso, para que a rota saia do cuOpt e entre direto no sistema que o time de expedição enxerga
• a pessoa que vai acompanhar o resultado no dia a dia e ajustar restrições quando a operação mudar

A documentação também tem uma página própria de licença (cuOpt License). Antes de levar qualquer coisa além do teste em Colab para produção, vale checar essa página com o jurídico da empresa, porque "código aberto" não é sinônimo automático de uso comercial sem restrição.

Robô decidindo rota perto de gente ainda é caso de NR-12

Se a saída do cuOpt vai alimentar o roteiro de um robô ou veículo guiado automaticamente (AGV) circulando perto de operadores no armazém, o cálculo da rota não substitui a segurança da máquina. O cuOpt decide o caminho mais eficiente; quem garante que o veículo pare diante de uma pessoa continua sendo o sistema de segurança do próprio equipamento (sensor, parada de emergência, zona de proteção), sob as exigências da NR-12 e da norma específica daquele tipo de máquina. Nenhum software de otimização de rota dispensa essa camada.

Como pilotar isso numa linha só

O caminho mais barato para descobrir se vale a pena é um piloto pequeno, sem tocar no sistema de produção:

1. Escolha um turno ou uma rota com problema conhecido (atraso recorrente, veículo rodando vazio, picking demorado).
2. Extraia os dados reais desse recorte: pedidos, endereços ou pontos de coleta, capacidade de cada veículo ou carrinho, janelas de horário.
3. Rode o modelo no Google Colab ou no NVIDIA Launchable, em paralelo ao processo atual, sem substituir ninguém ainda.
4. Compare, por pelo menos duas semanas, a distância total percorrida, o tempo de turno e o número de pedidos atendidos antes e depois.
5. Só então decida entre seguir no modo gratuito para testes pontuais ou migrar para um cuopt-server próprio, com custo de GPU e integração reais na conta.

Se o ganho medido nesse recorte pequeno não aparecer, o problema provavelmente não está na falta de otimização de rota, e sim em outro ponto da operação.

Fonte: NVIDIA cuOpt Documentation (User Guide e Release Notes)