Comments 7
Все время прочтения статьи меня не покидала мысль: "на что люди не пойдут лишь бы нормальное железо не использовать". Эксперимент безусловно интересный и спасибо что поделились, но я смотрю на это с точки зрения практика. Мне непонятна конечная цель.
Если это просто домашняя лаба энтузиаста с инференсом то все ок, снимаю шляпу, оно работает и хорошо.
Если это домашняя лаба ML инженера, то это немного странно, тк каждый инженер стремится повторить реальный контур у себя в миниатюре, с vllm, paged attention, continuous batching и прочим простыми тихим радостями современного ML продакшна.
На сколько я понимаю, в этой лабе этого нет и быть не может по совокупности причин. Опять же, инференс (пусть и без параллельных запросов) это хорошо, но как быть с обучением, вернее дообучением?
Морозить верхние слои сети, 4 часа собирать flash attention 2 из исходников, запускать обучение в peft долгими вечерами получая LoRA странного качества?
Для прода такая система не подходит, для дома - Франкенштейн (хотя не мне в чужих Франкенштейнов пальцем тыкать, со своими бы разобраться). И все же, в чем космический эффект такой сборки?
Я, внимательно прочитал раздел "Что я хотел проверить", но так и не понял "Зачем":
1. Держит ли машина полный Docker‑стек приватной AI‑платформы в непрерывной работе.
Докер стек держит, но LLM-сервер запущен с --parallel 1 те физически не может обслуживать больше одного запроса одновременно. Второй пользователь или запрос просто встанет в очередь.
2. Есть ли linux/amd64‑образы для всего каталога, или придётся собирать своё.
Я так понял, что собрали свое.
3. Работает ли Radeon 8060S (gfx1151) через Vulkan как основной путь инференса.
Работает.
4. Сколько из 128 ГБ общей памяти реально достаётся GPU и какой настройкой.
Здесь важнее что dify-sandbox дошёл до 95% лимита при синтетическом тесте без реальной нагрузки (это контейнер, который исполняет код агентов, при реальной работе отдела с агентами будет ещё хуже). Получается, что памяти впритык уже на одном пользователе.
4. Пригодны ли локальные эмбеддинги и реранкер для рабочего RAG‑пайплайна.
Неизвестно: embed/rerank тестировались с 4+2 потоками 90 секунд. Это не нагрузка, это микро-бенчмарк. Также, p99 не измерялся нигде, только p50/p95 на одиночных последовательных запросах. Вы сами об этом пишете, а p99 это база проверки.
5. Какие ограничения у ROCm и мониторинга на этой платформе.
Общая память свободна (98,8 ГиБ), но GPU-память считается по трём разным механизмам одновременно, которые расходятся в разы (18,6 ГиБ vs 1,5 ГиБ vs 39,5 ГиБ для одного и того же процесса в разных снимках). Стандартные инструменты capacity planning (autoscaling по cgroup-лимитам) тут не сработают те управления нагрузкой не, а значит при контексте 256K и нескольких параллельных длинных сессиях памяти может банально не хватить.
Ни в коем случае не хочу умалить ваших достижений, поймите пожалуйста меня правильно, эксперимент интересный, просто сильно напоминает буханку и коробок спичек.
Спасибо за подробный разбор. Начну с того, что вынесло меня сильнее всего: вопрос про дообучение. Слово «обучение» в ней не встречается ни разу. Вы спорите со статьёй «домашняя лаба ML‑инженера», которая у вас в голове, а моя про другое: выдержит ли эта коробка роль постоянного инфраструктурного узла. Соберусь тюнить LoRA на 8060S, напишу отдельный текст, и вот там ваш скепсис будет по адресу.
То же самое с vLLM, paged attention и continuous batching. Вы требуете ровно то, что в системе уже есть, и ровно там, где ему место. Прод‑генерацию стек получает по LAN с пары DGX Spark. Там крутится vLLM со всем перечисленным, и как эта пара держит multi‑user, я разбирал в отдельной статье, ссылка есть в тексте. Strix‑B в этой топологии автономный резерв. Претензия «на резервном узле нет continuous batching» звучит примерно как «в запаске нет датчика давления».
Теперь по вашим номерам.
--parallel 1это параметр запуска моего же бенчмарка, опубликованный в разделе «Методика». То есть вы цитируете мне мою методику в жанре разоблачения. Слоты задаются флагом сервера, это не свойство железа. Поменять цифру стоит одну строку, а поведение под параллельными потоками честно лежит в «Не проверено». И повторюсь: очередь пользователей стоит не сюда, а на Spark.Тут прочитано зеркально. Главный результат аудита: у всех 40 внешних пинов есть готовые linux/amd64-манифесты, собирать не пришлось ничего. Локально собираются три образа, и это наши собственные агентские сервисы. Их не существует ни под какую архитектуру, пока мы их не соберём, так что их пришлось бы собирать и на «нормальном железе».
Тут согласны.
4.Про sandbox перепутаны две разные величины: 95% это доля от лимита в 1 ГиБ, который контейнеру выставил я сам, а на хосте в этот момент свободно 98,8 ГиБ. Впритык у нас не память, а моя осторожность в дескрипторе, и статья ровно это говорит: сигнал проверить лимит под code‑execution‑нагрузкой, а не симптом дефицита.
Про пригодность эмбеддингов и реранка ответ не «неизвестно», ответ в опубликованных цифрах. Реранк двадцати кандидатов занимает 141 мс, эмбеддинг батча из 32 текстов 182 мс, это порядка 175 текстов в секунду на индексации. На 50 повторах между медианой и p95 не больше двух миллисекунд, хвост на последовательных запросах практически отсутствует. В пайплайне, где после реранка идёт генерация на секунды, эти 141 мс погоды не делают. Статья и заявляет пригодность именно для описанного в ней сценария с небольшой параллельностью, а не для абстрактного хайлоада. Конкурентный профиль и p99 лежат в «Не проверено», и здесь мы совпали, потому что оба цитируем один и тот же абзац. Когда обе стороны спора ссылаются на один абзац, это уже не спор, а совместное чтение.
Вы пересказали раздел статьи в качестве возражения к нему. Эти счётчики и должны показывать разное: docker stats вычитает inactive_file, memcg GTT‑страницы практически не учитывает. Поэтому вывод в тексте совпадает с вашим: планировать по
mem_info_gtt_used, он один и детерминированный. И деталь, которая закрывает сценарий «при 256K и нескольких сессиях памяти не хватит»: KV‑буфер под всё окно 256K выделяется при старте сервера. Это те самые 2,7 ГиБ, у Qwen3.6 гибридная архитектура и классических attention‑слоёв всего десять. Потолок памяти известен до первого токена, внезапности в этой конструкции физически негде взяться.
Про космический эффект: космического не обещал. Обещанный эффект скучнее: 34 контейнера, месяц работы стека, пережитые перезагрузка хоста и рестарт демона Docker, ноль ARM‑сборок. Буханка? Согласен, буханка. Она тем и хороша, что едет каждый день, пока нормальное железо согласовывает бюджет.
Спасибо, что прочитали внимательно. Местами внимательнее, чем написано.
Начну с того, что вынесло меня сильнее всего: вопрос про дообучение. Слово «обучение» в ней не встречается ни разу. Вы спорите со статьёй «домашняя лаба ML‑инженера», которая у вас в голове
В начале статьи написано "На узле моей AI‑платформы крутятся.." и дальше описано то что обычно крутится на домашней лабе. Поэтому я предположил что это домашняя лаба, а значит и обучению есть место. Если это не домашняя и не лаба, то прошу прощения, значит я понятия не имею что это. И не понимаю зачем это нужно, потому и написал комментарий. Ответа впрочем так и не получил. Ну ок.
моя про другое: выдержит ли эта коробка роль постоянного инфраструктурного узла.
Так вы этого не показали. Вы показали p95 на - - patallel 1, те буквально то что сборка запускается, работает месяцами и не падает при работе с одним пользователем. Ну ок 2.
Как это все будет работать в проде на реальных пользователях и запросах - для меня вопрос остаётся открытым. Мне видимо не хватает воображения осознать чем это будет лучше обычной одной или паре RTX A6000 с выгузкой в обычную RAM на vllm без всяких танцев с бубном.
Она тем и хороша, что едет каждый день, пока нормальное железо согласовывает бюджет.
Я правильно понял, что вы впариваете клиентам вот эти сугубо инференсные однопользовательские амдшные коробки с RAM вместо нормального железа? Если да, то вопросов больше не имею.
Отвечу на вопрос «зачем» прямо. Это не домашняя ML-лаба и не публичный многопользовательский сервис. Это собственная приватная инфраструктура: документы и данные не покидают контур, поэтому сервисный стек работает на нашем железе. Узлы из статьи закрывают в нём конкретную роль: сервисному слою нужны обычная amd64-экосистема и большой пул памяти, а не максимальные TFLOPS.
Теперь разделю два узла и два разных теста, которые вы снова объединили. Опубликованные p50/p95 относятся к embed и rerank на Strix-A. Embed-сервис запущен с --parallel 4. Эти перцентили сняты на 50 последовательных измерениях. Отдельно был 90-секундный ресурсный тест с четырьмя потоками embed и двумя потоками rerank. Он проверял загрузку GPU и запас по лимитам, а не конкурентный p95.
--parallel 1 использовался только в контекстном тесте Qwen на Strix-B. Никаких p95 и multi-user SLO для Qwen я не заявлял. Более того, параллельная генерация прямо находится в разделе «Не проверено».
Именно поэтому рабочая пользовательская очередь находится не на Strix-B, а на паре DGX Spark с vLLM, continuous batching и paged attention. Strix-B это отдельный автономный узел и ручной резерв, а не замена основного генерационного тира. Для разных нагрузок в одной топологии используются разные инструменты, а не одна универсальная коробка.
Постоянный инфраструктурный узел в статье это прежде всего Strix-A: 34 контейнера, месяц эксплуатации при небольшом трафике, перезагрузка хоста, перезапуск Docker с live-restore, ресурсные измерения и отдельный конкурентный тест embed/rerank. Это field report по конкретной эксплуатации, а не сертификация под произвольное количество пользователей. Обратного в статье не заявлено.
Для нашего сценария показатели embed/rerank уже отвечают на вопрос о применимости: p95 эмбеддинга батча из 32 текстов составил 184 мс, то есть около 174 текстов в секунду; p95 реранка двадцати кандидатов составил 142 мс. Между p50 и p95 во всех трёх тестах не более 2 мс. В текущем RAG-контуре эти 142 мс не являются доминирующей задержкой на фоне генерации. Конкурентный профиль и p99 я не измерял и прямо это указал.
Одна или две RTX A6000 действительно могут быть лучшим выбором для CUDA, vLLM и высокой конкурентности. Статья не утверждает обратного. В моей конфигурации запуск Qwen увеличил занятый GTT примерно на 27,7 ГиБ, поэтому на одной A6000 с 48 ГБ аналогичная конфигурация потенциально могла бы поместиться без CPU offload. Тогда сравнивать нужно фактические throughput, latency, concurrency, энергопотребление и стоимость всей системы.
Если же использовать CPU offload, это уже не вариант «без танцев»: сама документация vLLM предупреждает, что выгруженные параметры подаются из CPU memory во время forward pass и требуют быстрого CPU-GPU интерконнекта. Но без прямого теста двух стендов я не буду назначать победителя по теоретическим цифрам.
И нет, эти коробки никому не «впариваются». В статье описан наш внутренний приватный контур. Коммерческий сценарий вы добавили самостоятельно, а затем предъявили его мне как тезис статьи.
Если вы видите конкретную фактическую ошибку в конкретном абзаце, процитируйте её. На предмет статьи, роли узлов и границы проведённых тестов я ответил. Спасибо за дискуссию.
Мы говорим на разных языках, хотя и занимаемся примерно одним и тем же. Вы не указали в статье сразу для чего эта система поэтому ваше - - parallel 1 на strix B выглядело как залипуха. Остальное - лирика.
По совокупности ответов я понял, что это ваше внутреннее решение, стриксы вы взяли тк нормальное оборудование долго идёт и у вас оч специфичный кейс в виде запросов от одного пользователя, ризкну предположить, что от другой большой сети и они не частые. В этом свете ваше решение начинает выглядеть логично.
Наверное, опять неправильно понял, но это уже не важно.
Смотря что считать "нормальным железом": 128 ГБ памяти, доступной модели, на потребительских видеокартах – это четыре-пять карт, киловатт из розетки и цена автомобиля. Strix Halo берёт не скоростью, а тем, что модель, которая больше никуда не влезает, здесь просто работает. А vllm с paged attention раскрывается на десятках параллельных запросов – дома с одним пользователем вы повторите не "реальный контур", а его декорацию.
это четыре-пять карт, киловатт из розетки и цена автомобиля
Там самой модели доступно что-то типа 96Gb на винде и ~110Gb на линуксе. Это две RTX A6000, те примерно в 2 раза дороже. Зато там 768 ГБ/с (GDDR6) вместо ~256 ГБ/с (LPDDR5X), но не суть. То что тестил автор вообще влезет в одну такую карту и будет работать быстрее, а стоить чуть дороже.
Strix Halo берёт не скоростью, а тем, что модель, которая больше никуда не влезает, здесь просто работает. А vllm с paged attention раскрывается на десятках параллельных запросов – дома с одним пользователем вы повторите не "реальный контур", а его декорацию.
Я с вами полностью согласен, для одного пользователя с последовательными НЕБОЛЬШИМИ запросами это хорошее решение, при условии, что вам не нужно больше 64к контекста и с ним вы готовы ждать по 2 минуты на обработке каждого запроса.
Два AMD Strix Halo в AI‑инфраструктуре: 34 контейнера на одном, ~70 tok/s Qwen3.6 на другом