Обновить

Сегодня хочу поднять тему, которую редко обсуждают отдельно, но без неё Docker просто не работал бы так стабильно и предсказуемо - манифесты образов.

Периодически в разные частях документации или статьях про Docker вы будете встречать "манифесты". Обычно это звучит как что-то второстепенное: мол, есть какая-то мета-информация, по которой Docker собирает образ из слоёв.

Но на деле это одна из ключевых деталей, которая отвечает за то, что контейнеры:

  • воспроизводимы

  • одинаковые на разных машинах

  • и не превращаются в "ну у меня работало".

Я попытаюсь все описать максимально просто.

Docker Manifest - это JSON-документ, который описывает образ. Можно представить его как схему или инструкцию, по которой Docker понимает:

  • какие слои относятся к образу

  • какие контрольные суммы должны быть у каждого слоя

  • в каком порядке их нужно использовать

  • для какой ОС и архитектуры этот образ подходит

И важный момент: когда ты делаешь docker pull, Docker сначала получает манифест, а уже потом начинает скачивать слои.

Как посмотреть манифест самому: docker manifest inspect nginx:latest.

Тут можно заметить, что один тег (nginx:latest) может ссылаться сразу на несколько вариантов образа - например под amd64 и arm64. Это как раз история про multi-arch. Иногда под словом manifest имеют в виду не сам образ, а manifest list (index). Это как меню: Docker смотрит на твою платформу и выбирает подходящий вариант (amd64/arm64).

Каждый слой Docker-образа имеет SHA256-хеш, который вычисляется из его содержимого.

Логика максимально простая:

  • поменялся файл

  • поменялось содержимое

  • поменялся хеш

  • значит получился другой слой

По сути это очень похоже на философию Git: всё завязано на содержимое, а не на "имя файла".

Docker Registry использует Content Addressable Storage - то есть хранит и раздаёт данные не по названию, а по их хешам.

Что происходит при push / pull?

Если упростить до понятной схемы, то процесс примерно такой:

  • клиент сначала отправляет/получает манифест

  • registry проверяет хеши и наличие слоёв

  • передаются только те слои, которых ещё нет

  • каждый слой проверяется по SHA256

То есть никакой лишней передачи данных и никаких "примерно совпало".

Комбинация манифестов и хешей даёт сразу несколько сильных преимуществ:

  • Безопасность - слой нельзя незаметно подменить

  • Экономия места - одинаковые слои не хранятся по сто раз

  • Целостность - скачанное гарантированно равно загруженному

  • Версионирование - образ это конкретная комбинация слоёв, а не “что-то похожее”

Именно поэтому условный nginx:latest на dev и на prod - это реально один и тот же образ, а не "почти такой же, но чуть другой". Ладно, давайте будем более дотошными. На самом деле нет - использовать latest плохая практика. За время пока образ приехал,- там уже могут быть разные образы.

Как минимум используйте конкретный тег, а еще лучше даже sha256 docker pull nginx@sha256:...

_________________

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩

Теги:
Всего голосов 4: ↑2 и ↓20
Комментарии0

Как мы запустили Qwen3.8–27B целиком на RTX 5060 8 GB и получили ~30 токенов/с

Наш проект называется ExVRAM Lab. Это открытая исследовательская лаборатория, в которой мы проверяем, насколько большие локальные LLM можно запускать на обычных видеокартах с ограниченным объёмом VRAM, если использовать ultra‑low‑bit quantization, полное размещение весов на GPU и существующие open‑source inference‑технологии.

ExVRAM расшифровывается как Exchange Compute for VRAM. Основная идея проекта — в ряде сценариев выгоднее потратить часть свободной вычислительной мощности GPU на работу с более компактным представлением весов, чем хранить часть модели в оперативной памяти и постоянно передавать данные через PCIe.

Когда мы начинали проект, исходный вопрос был достаточно простой: можно ли запустить dense‑модель примерно на 27 миллиардов параметров на видеокарте всего с 8 ГБ VRAM так, чтобы она не просто «запустилась», а работала полностью на GPU, поддерживала длинный контекст и обеспечивала нормальную интерактивную скорость генерации.

В качестве основной тестовой системы мы используем NVIDIA GeForce RTX 5060 8 GB на архитектуре Blackwell. Основная модель в текущих экспериментах — Qwen3.8–27B.

Сначала результат выглядел не слишком впечатляюще. Модель запускалась, но значительная часть весов оставалась в системной памяти. Около 5,7 GiB весов находилось на GPU, ещё примерно 2,5 GiB — на CPU. Скорость генерации составляла порядка 3,8–5,5 токена в секунду.

При этом сама видеокарта была загружена далеко не полностью.

Это стало одним из первых важных наблюдений проекта. Проблема заключалась не столько в нехватке вычислительной мощности RTX 5060, сколько в том, что часть decoder weights находилась в RAM. Во время autoregressive generation данные приходилось постоянно передавать между CPU и GPU через PCIe.

Как мы запустили Qwen3.8–27B целиком на RTX 5060 8 GB и получили ~30 токенов/с

Публикации