Локальный ИИ-сервер для логистической компании: оптимизация маршрутов и склада на собственном оборудовании

Искусственный интеллект в логистике не всегда требует отдельного GPU-сервера. Для расчёта рейсов, прогноза нагрузки и некоторых задач видеоаналитики может хватить готового сервиса или вычислений на обычном процессоре (CPU). Графический ускоритель (GPU) стоит тестировать, если эти варианты не обеспечивают нужную скорость или пропускную способность, а ПО поддерживает такое ускорение.

Разберём, как выбрать первую задачу, оценить необходимость локального сервера и собрать исходные данные для расчёта конфигурации. Покажем, почему размещение оборудования в своей серверной само по себе не гарантирует автономную работу и соответствие требованиям к защите данных.

Коротко о главном

• Для оптимизации маршрутов сначала проверьте возможности действующей системы и CPU-решателя на одинаковых данных за обычный и пиковый день. Сравните время расчёта, длину или стоимость маршрутов и соблюдение ограничений по вместимости транспорта и окнам доставки.
• Для видео оцените обработку реальных потоков целиком: одновременную работу камер с рабочим разрешением и частотой кадров, от декодирования до выдачи события. Измерьте задержку и пропускную способность всей системы, а не только скорость нейросети.
• Для прогноза сравните результат с простым методом по историческим данным на периоде, который модель не видела при обучении. Например, при недельной повторяемости нагрузки ориентиром может стать показатель того же дня прошлой недели. Затем проверьте, помогает ли выигрыш в точности планировать транспорт или работу склада.
• Место обработки выбирайте отдельно: с учётом связи, допустимой задержки и движения данных. Определите, какие функции должны работать при потере внешней сети и какие данные могут покидать площадку. После этого сравните облачный сервис, локальный сервер и обработку у камер.

Какие задачи решают алгоритмы и искусственный интеллект в логистике

Система управления перевозками (TMS) и система управления складом (WMS) остаются частью рабочего процесса: в них хранятся заказы и операционные данные. Вычислительный модуль получает нужные сведения, рассчитывает результат и возвращает его диспетчеру или в учётную систему. Маршрутизация, компьютерное зрение и прогнозирование при этом требуют разных алгоритмов и ресурсов.

Оптимизация маршрутов: ограничения, CPU и GPU

Задача маршрутизации транспорта (VRP) — распределить заказы между автомобилями и определить последовательность остановок с учётом ограничений. Для расчёта собирают адреса и координаты точек, вместимость машин, интервалы доставки, продолжительность разгрузки, смены водителей и точки начала рейсов. Это задача математической оптимизации, для которой нейросеть не обязательна.

Заранее определите, что считать хорошим планом. Минимальный пробег, меньше машин на линии и своевременная доставка — разные цели. Обязательные условия задают как ограничения, а допустимые компромиссы — через приоритеты и штрафы. Короткий маршрут не подходит, если ради него придётся перегрузить автомобиль или нарушить обязательное окно доставки. На сложной задаче решатель может найти качественный план, не доказав, что он лучший из всех возможных.

Отдельно нужна дорожная матрица — время и расстояние между точками. Её получают из картографической системы с учётом доступных дорожных данных. Например, API Яндекс Карт для матрицы расстояний поддерживает грузовой режим с параметрами массы и габаритов транспорта. Размер запросов ограничен, а доступ к асинхронному режиму для больших матриц предоставляют по запросу.

Разумная отправная точка — существующая TMS, сервис маршрутизации или Google OR-Tools на CPU. NVIDIA cuOpt — пример GPU-решателя, который можно развернуть на своей площадке. Проверять переход стоит, если текущее решение не даёт план приемлемого качества за отведённое время. Универсального порога «после определённого числа машин нужен GPU» нет.

Сравнивайте решения на одинаковых заказах, дорожной матрице, ограничениях и целевой функции. Задайте одинаковый лимит времени. При оценке времени ответа учитывайте подготовку данных, очередь, расчёт и обмен с TMS. Для повторных запусков полезен 95-й перцентиль времени ответа (p95): 95% запросов выполняются не дольше этого значения. Если в соглашении об уровне обслуживания (SLA) задан порог по p95, сравнивайте результат с ним. Доступность оценивайте отдельно.

Диспетчер проверяет предложенные маршруты перед передачей водителям

Видеоаналитика склада: оценивать нужно весь видеопоток

Видеоаналитика на складе может искать и считать объекты, а также формировать события для оператора. Инференс нейросети — применение обученной модели к новым данным, в данном случае к кадрам. До модели поток нужно принять, декодировать и подготовить. После неё могут потребоваться отслеживание объектов и проверка условий события.

Поэтому «30 камер Full HD» — недостаточное описание нагрузки. Даже при одинаковом числе камер обработка каждого кадра и выборка нескольких кадров в секунду создают разную нагрузку и могут по-разному влиять на качество обнаружения. Для теста зафиксируйте параметры по этапам:

Что измерить при тестировании видеоаналитики

Покупка GPU не обязательна даже при использовании нейросети. Например, ONNX Runtime позволяет выполнять модель на CPU или использовать ускорение через CUDA, TensorRT и другие механизмы. Нужно проверить, какие операции выбранной модели поддерживает механизм исполнения и где они будут выполняться. Оборудование выбирайте по тесту всей цепочки: от камеры до готового события.

ИИ для склада выбирают под конкретное событие, а не под демонстрацию распознавания. Если нужно обнаруживать занятые ворота, проверьте результат на своих ракурсах, при разном освещении и частично перекрытом обзоре. Высокая точность распознавания объекта ещё не доказывает надёжность бизнес-события.

Роботизация склада — отдельная задача. Центральная аналитика не заменяет управление движением и системы безопасности автономного погрузчика. Для беспилотного промышленного транспорта предусмотрены отдельные требования безопасности, в частности ISO 3691-4. Сформировать событие для отчёта и обеспечить безопасное движение техники — разные задачи.

Прогноз загрузки: сначала простая модель

Определите, какое решение должен поддерживать прогноз. Логистический оператор может оценивать число прибывающих машин, объём приёмки и отгрузки, потребность в сменах и загрузку ворот. Прогнозирование товарного спроса уместно, если компания действительно управляет ассортиментом и запасами. Складской оператор не обязательно отвечает за закупки товаров клиента.

Начните с простого ориентира: например, объёма в тот же день предыдущей недели. Затем сравните его со статистической моделью или машинным обучением на CPU. Для прогноза могут понадобиться история операций, календарь, сезонность, особенности смен и изменения графика поставок, известные на момент расчёта. В документации scikit-learn есть пример прогнозирования по прошлым значениям с помощью градиентного бустинга — без обязательного перехода к глубокой нейросети.

Проверяйте модель на более поздних периодах, которые она не видела при обучении. Случайное перемешивание прошлого и будущего способно завысить оценку качества. Сравните ошибку с базовым методом, отдельно посмотрите на пики и систематическое завышение или занижение прогноза.

Оценивайте ИИ в складской логистике по операционному результату: помогает ли прогноз вовремя назначать смены и распределять ресурсы. GPU стоит обсуждать, когда измерения покажут, что обучение модели или её применение не укладывается в требования по времени или объёму обработки. Нехватку истории и ошибки исходных данных ускоритель не исправит.

Простой метод и модель проверяют на одном и том же более позднем периоде

Облако, локальный сервер или вычисления на складе

Тип вычислений и место их выполнения — два отдельных решения. Обработка рядом с камерами называется периферийной, или edge. Её может выполнять отдельный узел или модуль самой камеры, не обязательно мощный GPU. В гибридной схеме часть задач остаётся на складе, а управление и сводная аналитика — в центральной инфраструктуре.

Где обрабатывать данные: варианты и условия выбора

Контроль данных, коммерческая тайна и 152-ФЗ

Сначала опишите движение информации: где находятся персональные данные водителей, адреса получателей и видео, что получает картографический сервис, кому доступны базы, журналы и резервные копии. Проверять нужно фактическую схему, а не только расположение основного сервера.

При сборе персональных данных граждан РФ часть 5 статьи 18 закона № 152-ФЗ не допускает запись, систематизацию, накопление, хранение, уточнение и извлечение таких данных с использованием баз данных за пределами России, кроме предусмотренных законом исключений. Требования владеть физическим сервером в этой норме нет. Российское облачное размещение не запрещено само по себе, но допустимость конкретной схемы нужно проверять.

Локальный сервер также не обеспечивает соответствие закону автоматически. Статья 19 требует правовых, организационных и технических мер: определения угроз, правил доступа, регистрации действий и восстановления данных. Для трансграничной передачи действуют отдельные требования статьи 12. Защита данных зависит не только от места установки оборудования.

Коммерческая тайна — самостоятельный правовой режим. Недостаточно просто считать маршрутную базу ценной: статья 10 закона № 98-ФЗ предусматривает перечень защищаемой информации, ограничение доступа и другие меры. До запуска согласуйте схему обработки с ответственным за персональные данные и юристом.

Физический контроль доступа — лишь одна из мер защиты данных

Задержка, связь и работа при сбоях

При потере интернета решатель сможет использовать только доступные ему данные. Если дорожная матрица и сведения о пробках приходят из внешнего API, новый расчёт может остаться без актуальной дорожной информации. Телематика — сведения о местоположении и состоянии транспорта — и доставка заданий водителям зависят от своих каналов связи.

Для удалённого склада отдельно проверьте связь с центральной площадкой. Узел возле камер может продолжить обработку при её потере, если на объекте работают модель, правила событий, необходимое хранение и локальное оповещение. Сервер в центральном офисе при обрыве связи со складом такой автономности не даст. Если камеры объединены устойчивой локальной сетью склада, централизованная обработка на самом объекте тоже может подойти.

Заранее определите, что делать при отказе ускорителя, узла или питания. Возможные варианты — переход на CPU-решатель, ручное планирование или согласованное сокращение функций видеоаналитики. Резервный режим нужно разработать и испытать: он не появляется автоматически после установки второго процессора или GPU.

Для каждого сбоя нужен заранее проверенный порядок работы

Когда собственное оборудование экономически оправдано

Сравнивайте полную стоимость владения (TCO) за одинаковый период при сопоставимых объёме работы, качестве результата и уровне сервиса. Для своей площадки учитывайте оборудование, ПО, внедрение, электроэнергию, охлаждение, размещение, сеть, хранение, сопровождение и резервирование. Внешние карты и API могут остаться платными и после покупки сервера.

Для услуги считайте не только подписку или аренду вычислений, но и хранение, передачу данных, интеграцию, поддержку и резервную связь. В обоих вариантах оцените последствия недоступности. Иначе получится сравнение обслуживаемого сервиса с ценой оборудования без расходов на его работу.

Проверьте расчёт при обычной нагрузке, на пике и при недозагрузке. При редких вычислениях покупка мощного узла может оказаться невыгодной. При постоянной нагрузке сравните своё оборудование с регулярной оплатой услуги. Условия размещения данных и допустимый простой тоже могут изменить выбор. Это критерии расчёта, а не гарантия преимущества одного из вариантов.

Отдельно считайте эффект самого проекта. Сокращение пробега и более полное использование транспорта нельзя целиком приписывать покупке GPU: часть результата мог дать алгоритм на CPU или готовый сервис. Деление цены сервера на срок службы показывает распределённые затраты, а не срок окупаемости. Для решения нужны три разных сравнения:

Какие расчёты нужны перед покупкой сервера

Как подобрать оборудование под задачу

Что измерить до запроса конфигурации

Описания «два склада и большой автопарк» недостаточно для подбора конфигурации. Подготовьте параметры каждой нагрузки и требования к результату. Снимите показатели для обычного режима и пиков, а также отметьте задачи, которые выполняются одновременно. Минимальный набор для обсуждения конфигурации — в таблице.

Исходные данные для подбора конфигурации

CPU, рабочая станция или GPU-сервер

Если CPU обеспечивает нужный результат в отведённое время, переходить на ускоритель ради «запаса для ИИ» не нужно. Для разработки и проверки GPU-сценария можно рассмотреть рабочую станцию DigitalRazor для ИИ. Это вариант для пилота, а не готовая система управления складом.

При подтверждённой постоянной нагрузке один из вариантов — RackStation AI с одним или двумя GPU. Конкретную комплектацию подбирают после проверки модели или решателя, потребности в видеопамяти и производительности всей цепочки обработки данных. Подходящий класс оборудования сам по себе не подтверждает совместимость с выбранным ПО и не гарантирует обработку заданного числа камер.

Scale с поддержкой до восьми GPU стоит рассматривать для большой параллельной нагрузки: нескольких вычислительных сервисов или множества независимых видеопотоков. При маршрутизации с cuOpt несколько GPU могут обслуживать независимые расчёты, но их количество само по себе не гарантирует пропорционального ускорения одной VRP-задачи. Большой автопарк сам по себе не обосновывает покупку системы с несколькими GPU.

Кроме ускорителя, проверьте загрузку CPU, оперативной памяти, декодеров, сети и накопителей. Дополнительный GPU не устранит ограничение другого компонента. Об устройстве платформы подробнее рассказали в материале «Из чего состоит сервер».

Уже измерили нагрузку и определили условия размещения? Передайте результаты пилота — по ним можно оценить, какая конфигурация подходит для вашей задачи, и проверить её на вашем ПО.

Запас для роста и отказоустойчивость

Запас рассчитывают под конкретное изменение: больше одновременно анализируемых потоков, более частое перепланирование или запуск второй модели. Проверьте, поддерживает ли ПО распределение работы между GPU. Их видеопамять не становится общим пулом автоматически: при расчёте ёмкости учитывайте, как выбранный способ исполнения размещает модель и рабочие данные.

Учтите, какие нагрузки совпадают по времени. Если обучение прогноза запускается во время интенсивной видеоаналитики, протестируйте оба процесса вместе. Пиковая производительность по отдельности не подтверждает выполнение SLA при совместной работе.

Для сбоев нужен отдельный план. Зафиксируйте допустимое время восстановления (RTO) и допустимый период потери данных (RPO). Проверьте резервное питание, копии конфигураций и моделей, процедуру восстановления узла и назначьте ответственных. Запас производительности и резервирование — разные вещи: несколько GPU в одном сервере не защищают от отказа всего узла. Простой оборудования учитывайте как операционный риск.

Отказоустойчивость узла достигается за счет резервирования его элементов или узла целиком

Как провести пилот и встроить систему в процессы

Начните с одного решения, которое нужно улучшить. Например, пересчитывать план доставки после новых заявок, определять занятость ворот или прогнозировать объём работы следующей смены. Назначьте ответственного за результат пилота и заранее опишите, что должно измениться в работе диспетчера или склада.

Проверьте данные и интеграцию. Для маршрутов согласуйте координаты, вместимость, интервалы доставки и длительность обслуживания. Для камер — доступ к потокам и качество изображения. Для прогноза — полноту истории и единицы измерения. Определите, из каких систем поступают обновления и куда возвращаются план, событие или прогноз. На первом этапе сотрудник может проверять результат до его применения в рабочем процессе.

Сравните пилот с исходным процессом. Для маршрутов измеряйте время ответа, соблюдение ограничений, необслуженные заказы и пробег. Для видео — качество событий (пропуски и ложные тревоги), задержку уведомления и незапланированные пропуски кадров при целевом числе потоков. Для прогноза — ошибку относительно простого метода и влияние на планирование ресурсов. Зафиксируйте версии ПО и конфигурацию, чтобы результат можно было воспроизвести.

Испытайте пик и отказ. Проверьте систему при пиковой нагрузке, в том числе когда задачи выполняются одновременно. Затем испытайте потерю связи, недоступность внешнего API, если он используется, и отказ вычислительного узла. Переходите к постоянной эксплуатации, когда выполнены критерии приёмки, понятны расходы, назначены ответственные и испытан резервный порядок. Отсутствие выигрыша относительно исходного решения — тоже полезный результат пилота: он позволяет не покупать лишнее оборудование.

Вычислительные модули дополняют WMS/TMS, но зависят от качества исходных данных и доступности каналов связи, которые использует выбранная схема.

Часто задаваемые вопросы

Вывод

Искусственный интеллект в логистике стоит внедрять под измеримую задачу, а не под заранее выбранную конфигурацию. Если сервер не выдержит пиковую нагрузку, расчёт рейсов и оповещения с камер могут задерживаться. Лишние GPU, напротив, увеличат стоимость проекта без пользы. Локальный ИИ-сервер для логистики имеет смысл, когда пилот подтвердил потребность в оборудовании, а сравнение вариантов показало приемлемые затраты и условия размещения.

DigitalRazor подбирает GPU-сервер с учётом модели, объёма памяти, режима работы и условий размещения. До покупки конфигурацию можно проверить на вашем приложении или модели. Перед отгрузкой каждая система проходит тестирование под нагрузкой.

Передайте описание нагрузки, результаты пилота, требования к задержке и восстановлению и запросите у DigitalRazor подбор конфигурации. Попросите проверить выбранный вариант на вашем ПО, а состав работ по внедрению и интеграции согласуйте отдельно.

Rackstation AI

Для каких задач Компактный GPU-сервер до 2 видеокарт для начальных задач в AI и графике. Оптимален для инференса, визуализации, VFX и рендеринга в студиях и лабораториях, где важна гибкость.

Подробнее

Видеокарты

RTX / RTX PRO / H200 NVL

Объем видеопамяти до 282 ГБ

Процессоры

Threadripper PRO

Количество ядер до 96

RAM до 1024 ГБ DDR5

Форм-фактор 4.5U

Devbox AI

Для каких задач Универсальная платформа на 4–6 GPU для локального обучения моделей и генеративных задач. Подходит для команд, которым важна надёжность сервера и свобода выбора графики — от RTX 5090 до PRO RTX 6000.

Подробнее

Видеокарты

RTX / RTX PRO / H200 NVL

Объем видеопамяти до 576 ГБ

Процессоры

Threadripper PRO

Количество ядер до 96

RAM до 1024 ГБ DDR5

Форм-фактор 6.5U

Scale

Для каких задач Сервер промышленного уровня на 8 GPU с кластерной архитектурой. Предназначен для дата-центров и AI-ферм, где требуется масштабируемость и полная загрузка ресурсов под обучение LLM и R&D.

Подробнее

Видеокарты

RTX PRO 6000 / RTX 5090

Объем видеопамяти до 768 ГБ

Процессоры

AMD Epyc, Intel Xeon

Количество ядер до 320

RAM до 3072 ГБ DDR5

Форм-фактор 6U

HPC 4000

Для каких задач Серия серверов для кластеризации на 4 GPU. Предназначены для дата-центров и AI-ферм, где требуется повышенная плотность для обучение LLM и R&D.

Подробнее

Видеокарты

L40s / RTX PRO / H200 NVL

Объем видеопамяти до 564 ГБ

Процессоры

AMD EPYC, Intel Xeon

Количество ядер до 128

RAM до 1536 ГБ DDR5

Форм-фактор 2U

HPC 8000

Для каких задач Серия серверов для кластеризации на 8 GPU. Предназначены для дата-центров и AI-ферм, где требуется повышенная плотность для обучение LLM и R&D.

Подробнее

Видеокарты

L40s / RTX PRO / H200 NVL

Объем видеопамяти до 1128 ГБ

Процессоры

AMD EPYC, Intel Xeon

Количество ядер до 256

RAM до 2048 ГБ DDR5

Форм-фактор 4U

HGX H200

Для каких задач HGX объединяет 8 видеокарт NVIDIA H200, достигая экстремальной плотности производительности. Благодаря внутренней связности NVSwitch мгновенно интегрируется в масштабные вычислительные кластеры.

Подробнее

Видеокарты

NVIDIA H200 SXM

Объем видеопамяти до 1128 ГБ

Процессоры

AMD EPYC, Intel Xeon

Количество ядер до 256

RAM до 2048 ГБ DDR5

Форм-фактор 5U