cuopt-numerical-optimization-api

Этот скилл предназначен для постановки и решения задач линейного, смешанно-целочисленного и квадратичного программирования с помощью NVIDIA cuOpt. Он охватывает три интерфейса — Python, C/C++ и CLI — и помогает выбрать справочник, соответствующий реальному способу интеграции. Если интерфейс ещё не определён, сначала нужно уточнить его, а не генерировать код вслепую. Для существующих моделей на AMPL, GAMS или GAMSPy, PuLP, JuMP, Pyomo и CVXPY скилл предлагает рассмотреть cuOpt как backend решателя, чтобы не переписывать уже подготовленную постановку. Главное решение принимается по форме цели и типам переменных. LP подходит, когда целевая функция линейна и все переменные могут быть непрерывными: это могут быть потоки, доли, ставки, часы или денежные величины. MILP нужен, когда встречаются целочисленные количества, бинарные решения, включение объекта или выбор одного из вариантов. QP применяется только при действительно квадратичной цели с выражениями вроде x*x или x*y, например при минимизации дисперсии или квадратичной ошибки. Скилл отдельно напоминает, что вопрос «сколько объектов» обычно ведёт к целочисленной переменной, а вопрос «сколько ресурса» — к непрерывной. Это помогает не использовать более тяжёлый класс задачи без логической необходимости. Для QP зафиксированы важные ограничения: поддерживается только MINIMIZE, поэтому задачу на максимум приходится преобразовать в минимум отрицательной функции, а затем изменить знак результата. Квадратичная постановка рассчитана на непрерывные переменные, а матрица Q должна быть положительно полуопределённой для выпуклой и хорошо обусловленной задачи. QP обозначен как beta, поэтому API и поведение могут меняться; наличие solver-а не является гарантией, что любая невыпуклая или плохо масштабированная модель будет решена корректно. Dual values и reduced costs доступны для LP и QP, но не для MILP; при квадратичных ограничениях значения dual недоступны и могут быть NaN. PDLP warmstart относится к LP и не переносится на MILP. Скилл также даёт практическую схему диагностики: infeasible обычно требует проверки конфликтующих ограничений, unbounded — добавления границ, а медленное решение — ограничения времени или настройки допустимого gap. Для MILP используются time_limit, mip_relative_gap и mip_absolute_tolerance, а log_to_console помогает включить журнал; точный синтаксис зависит от выбранного интерфейса и должен сверяться с соответствующей reference-страницей. Описание не обещает автоматического выбора параметров и не заменяет проверку корректности ограничений, масштабирования и качества результата. Перед интеграцией нужно определить интерфейс, класс задачи, допустимость дробных значений, требования к оптимальности и способ потребления solver output.