Девлог #4. Как Сделать Кастомный Докер Образ Для Тритона
Безусловно удобно, когда любую модель можно обернуть в тритоновский докер-образ, как мы научились это делать в tritoned_bert. Нам это нужно, чтобы было удобнее две наши модели поставлять вместе с платформой. Но 14-16 гигов объема каждого такого образа вызывают некоторые вопросы, мягко говоря. Слишком жирно по издержкам, чтобы упаковывать одного Берта на 700-800 Мб. Мы начали искать, как можно сократить его объем. Буквально первой ссылкой в Гугле нашли гайд на оф. сайте.
The easiest way to build Triton is to use Docker.
Когда сейчас пишу это, не представляю, каким уровнем шаманизма нужно обладать для сборки без докера.
В двух словах, чтобы уменьшить размер контейнера, нужно выпилить фичи, которые вам не нужны. По умолчанию, тритоновский образ вида tritonserve:xx.xx-py3
включает в себя всё: все бекэнды, среди которых Торч, Тензофлоу, Онникс, Питон, ТензорРТ и еще несколько, поддержку гпу, метрики и еще то, что я даже не знаю. Задумка в том, что Тритон разворачивается как один сервис, в который можно загружать множество внешних моделей под любой фреймворк. При таком сценарии нет проблем, что докер-образ весит полтора десятка гигабайт.
Но из тяжеловесов мы используем только ONNX и только на CPU. Почему только CPU? Потому что мы пока не ожидаем, что модели будут обрабатывать 100500 запросов в секунду. Если почуствуем, что нужно скорость увеличить, всегда можно включить GPU, хотя и до этого шага можно поколдовать над настройками онникса. Поэтому мы можем выкинуть, наверное, 90 процентов содержимого полного образа.
После двудневного шаманского ритуала родился вот этот гайд, как собирать кастомный образ Тритона.
Инструкция
-
Скачать репозиторий сервера
-
Переключиться на ветку
r24.05
- это едниственный релиз, который удалось собрать. Возможно, еще соберуться чуть свежее или чуть старее. Совсем новые, типа25.01
или25.03
(на момент написания 02.05.2025) по какой-то причине базовым контейнером выступает Убунта, а менеджер пакетов в Докерфайле почему-то yum, а не apt. Совсем старые релизы, как, например,22.12
, который был изначально, или некоторые из 23 года, которые мы тестили, не собираются из-за того, что не получается скачать крестовую библиотеку Boost. Ссылка больше неактуальна. (issue, еще [issue}(https://github.com/triton-inference-server/server/issues/7997) с проблемами сборки для разных релизов). -
Применить нижепредставленный патч командой
git apply fix.path
. Этот патч отключает OpenVINO (несмотря на то, что его никто и не включал при команде сборки), потому что в процессе установки образуется конфликт версий для CMAKE. Вот коммент из issue, который объясняет как именно это происходит и пример решения проблемы через патч.
diff --git a/build.py b/build.py
index e0b66036..455ead8b 100755
--- a/build.py
+++ b/build.py
@@ -685,17 +685,17 @@ def onnxruntime_cmake_args(images, library_paths):
):
cargs.append(
cmake_backend_enable(
- "onnxruntime", "TRITON_ENABLE_ONNXRUNTIME_OPENVINO", True
- )
- )
- cargs.append(
- cmake_backend_arg(
- "onnxruntime",
- "TRITON_BUILD_ONNXRUNTIME_OPENVINO_VERSION",
- None,
- TRITON_VERSION_MAP[FLAGS.version][3],
+ "onnxruntime", "TRITON_ENABLE_ONNXRUNTIME_OPENVINO", False
)
)
+ #cargs.append(
+ # cmake_backend_arg(
+ # "onnxruntime",
+ # "TRITON_BUILD_ONNXRUNTIME_OPENVINO_VERSION",
+ # None,
+ # TRITON_VERSION_MAP[FLAGS.version][3],
+ # )
+ #)
if target_platform() == "igpu":
cargs.append(
- Выполнить команду:
$ ./build.py --backend=python --backend=ensemble --backend=onnxruntime --backend=python --enable-logging --enable-stats --enable-metrics --enable-tracing --endpoint=http --enable-cpu-metrics
Сначала я забыл включить логирование и не мог понять, где логи, потом забыл включить endpoint и не мог понять, почему сервер не поднимается. Список всех бекэндов смотрите в оф. доке.
- Выполнить команду:
$ docker tag tritonserver:latest your/triton_name:your_tag
Казалось, это победа: образ собрался, сервер стартанул. Делаю запрос и мне в ответ:
{"error":"in ensemble 'ensemble_model', Failed to process the request(s) for model instance 'text_preprocessing_0_0', message: error: unpack_from requires a buffer of at least 387389211 bytes for unpacking 387389207 bytes at offset 4 (actual buffer size is 27)\n\nAt:\n /opt/tritonserver/backends/python/triton_python_backend_utils.py(117): deserialize_bytes_tensor\n"}
Кавооо???
На этот раз, оказалось, что это из-за numpy
. В контейнере оказывалась версия >2.0 и это за собой несет проблемы совместимости типов. Вот issue, в котором нашел что к чему. Поставил numpy=1.26.4
, который вышел в феврале 2024 и он же последний релиз перед numpy==2.0
, вышедший в июне 2024, и оно, наконец, полетело.
Новые образы с моделями теперь весят не безумные 16 гигов, в всего два (выкинули 87.5%). Причем половина последнего - это файлы модели. Думаю, что можно урезать еще в полтора раза, но и такой итог нас устраивает. Мы уже впилили его в tritoned-bert, скоро обновим на Гитхабе. Отдельно образ лежит здесь: astromis/tritonserver:24.05-onnx-python-cpu (если ссылка или докер недоступен, значит попробуйте сначала заменить astromis
на psytechlab
).
Обратите внимание на ссылки issue, благодаря которым мне удалось решить возникающие проблемы. В такие моменты чувствуешь силу сообщества и опенсорса.