cuopt-routing-api-python

cuOpt Routing — Python-only skill NVIDIA для постановки и решения задач маршрутизации vehicle routing через API cuOpt. Источник прямо ограничивает область Python-интерфейсом и отдельно указывает, что этот маршрут не является C API. Он подходит, когда нужно подготовить задачу TSP, VRP или PDP, описать locations, orders и fleet, передать матрицу стоимости и затем разобрать статус решения. Перед реализацией инструкция предлагает уточнить тип задачи, число локаций и депо, способ получения стоимости или расстояния, обязательные точки обслуживания, спрос или service per stop, количество машин, их capacity, старт и финиш, а также временные окна, service times и precedence. Минимальный пример создаёт cudf.DataFrame с cost matrix и явным dtype float32, затем формирует routing.DataModel с n_locations, n_fleet и n_orders. В модель добавляются матрица стоимости и позиции заказов через cudf.Series с dtype int32. После этого вызываются routing.Solve и routing.SolverSettings; при статусе успеха маршрут можно показать через display_routes(). Такой пример показывает ожидаемую форму данных и последовательность API, но не выбирает значения за пользователя: реальная постановка должна определить стоимость перемещения, состав заказов и параметры автопарка. Для ограничений источник приводит отдельные методы cuOpt. Временные окна задаются через transit time matrix и order time windows; грузовые или иные размерности capacity — через add_capacity_dimension с demand и capacity; обслуживание остановок — через set_order_service_times. Для автомобилей можно определить start и end locations и vehicle time windows. Связи pickup-delivery задаются парами индексов через set_pickup_delivery_pairs, а порядок выполнения — add_order_precedence с node_id и preceding_nodes. Эти вызовы нужно сочетать с данными задачи: добавление только окна заказа без transit time matrix является одной из причин некорректного результата, отмеченных в разделе типичных проблем. Результат следует проверять программно. get_status() возвращает 0 для SUCCESS, 1 для FAIL, 2 для TIMEOUT и 3 для EMPTY. При успехе доступны get_route() и get_total_objective(); при другом статусе инструкция предлагает читать get_error_message() и список infeasible orders. Пустое решение требует проверить или расширить time windows и travel times, а невыполнимые заказы — capacity и размер fleet. Для матрицы стоимости отдельно рекомендуется проверить симметричность, если постановка предполагает симметричный маршрут. Типы данных важны для повторяемости и диагностики: матрицы стоимости приводятся к float32, индексы заказов и demand — к int32, а настройки SolverSettings допускают time limit, verbose mode и error logging mode. В примере также есть предупреждение о compute_waypoint_sequence: метод заменяет колонку location в route_df идентификаторами waypoint на месте, поэтому при необходимости исходных индексов следует передать копию route_df. Это ограничение относится к обработке результата, а не к самой оптимизации. Рабочий сценарий такой: сначала зафиксировать TSP, VRP или PDP и входные ограничения, затем подготовить cudf-данные с явными типами, собрать DataModel, добавить только подтверждённые ограничения, задать SolverSettings, вызвать Solve и разобрать каждый статус. Skill не обещает, что любая модель будет выполнима или что один набор настроек подходит для всех маршрутов. При contribution или build-from-source источник направляет к отдельному developer skill; для текущей карточки достаточно Python API и проверки фактических данных задачи.