flux 2 klein 9b safetensors и очередь правок в локальном запуске

В image-производстве бюджет ломается не на одном кадре, а на очереди срочных правок. Ты считаешь стоимость генерации по цене одного изображения, показываешь менеджеру красивую цифру за проход, а через месяц выясняется, что дизайнеры ждут свою партию правок по сорок минут, потому что к единственной видеокарте выстроилась очередь. Цена кадра тут ни при чём. Ломается пропускная способность.

Дальше я собираю простую модель под один вопрос: выдержит ли локальный FLUX поток правок твоей команды. Мера тут одна - сколько задач в час проходит через один GPU и одного оператора, прежде чем ожидание станет неприемлемым. В калькулятор войдут размер задания, время GPU на проход, повторные попытки и операторские паузы. Сразу оговорюсь честно: это прогноз на предполагаемых входных данных, а не замер на твоём железе. Реальные длительности ты подставишь сам.

И ещё одно различие, которое стоит зафиксировать до расчётов: GPU-узкое место и операторская пауза - это разные проблемы с разными решениями. Первое лечится железом или более быстрым режимом модели. Второе - процессом, а не видеокартой. Калькулятор нужен именно для того, чтобы не перепутать их и не купить второй GPU там, где тормозит ручная приёмка.

Платите в рублях за AI-модели без наценки на токены через provod.ai

Цена одного кадра врёт про твою нагрузку

Вендор публикует цену за проход, и это удобная, честная, проверяемая цифра. Хостовый API Black Forest Labs, по прайсу docs.bfl.ai на 2026-07-18, тарифицирует правки Klein 9B от $0.015 за первый мегапиксель вывода, а дополнительные мегапиксели считаются сверху. «От» и «мегапиксельно» - значит, что реальная стоимость правки зависит от разрешения, и как точную цену за изображение это использовать нельзя, только как порядок величины.

Цифра точная, но отвечает она на другой вопрос. Цена за кадр линейна: сто правок стоят в сто раз дороже одной. Очередь нелинейна: сто правок в спокойный день и сто правок за два часа перед релизом - это одна и та же сумма и совершенно разное ожидание. Спор о пригодности локального запуска почти всегда ведётся в терминах TCO и цены прохода, и именно поэтому команды регулярно промахиваются. Мой тезис проще и его можно опровергнуть: если расчёт покажет очередь выше допустимого ожидания, локальный режим не выдерживает заданный поток правок - независимо от того, насколько привлекательна цена одного кадра.

Опровергнуть тезис легко. Если у твоей команды поток редкий и равномерный, очередь не образуется, и тогда решает как раз TCO, а не пропускная способность. Модель ниже сама покажет этот случай: при низком потоке и коротком проходе GPU и оператор простаивают, и весь разговор про очередь становится лишним.

Что ты вообще запускаешь: flux 2 klein 9b safetensors

Прежде чем считать очередь, зафиксируем параметры модели - их нужно перепроверять перед каждым расчётом, потому что версии и лицензии меняются. Опубликованный чекпоинт flux 2 klein 9b safetensors - это модель на 9 миллиардов параметров, файл около 18.2 ГБ, который Black Forest Labs раздаёт на Hugging Face. Вместе с ним в пайплайне работает текстовый энкодер Qwen3 на 8 миллиардов параметров - он добавляет отдельную нагрузку на VRAM и загрузку сверх самого трансформера, и про него легко забыть при планировании памяти.

Ключевое для очереди - два режима запуска, и по замерам Comfy Org (2026-07-18) они дают радикально разное время прохода. Дистиллированный вариант Klein 9B работает на 4 шагах инференса и завершает генерацию или правку примерно за 2 секунды на RTX 5090 при пике около 19.6 ГБ VRAM. Недистиллированный базовый вариант тех же 9B требует 50 шагов, около 35 секунд и порядка 21.7 ГБ на той же карте. Разница во времени прохода - в семнадцать раз. Для очереди это развилка: один и тот же поток задач упрётся в разные узкие места в зависимости от режима.

По минимальному железу ориентир такой: поддерживается RTX 4080 на 16 ГБ, рекомендуется RTX 4090 на 24 ГБ. Практический размер батча - одна картинка на карте с 16 ГБ и всего 2-3 изображения при 24 ГБ и выше. Эти цифры по батчу и разбивке VRAM идут из сообщества (DeepWiki), а не из первичного документа Black Forest Labs, поэтому я держу их как вторичную сверку, а не как спецификацию. Но даже как ориентир они важны: батч ограничивает, сколько параллельных задач один GPU способен поглотить, прежде чем начнёт сериализовать очередь.

Отдельно про edit. Klein 9B поддерживает правки по одному референсу, по нескольким референсам и итеративные многопроходные правки в одной архитектуре. Из этого следует неприятная для калькулятора вещь: одна логическая «задача правки» в очереди может потребовать не одного, а нескольких вызовов модели. Когда дизайнер в режиме flux 2 klein 9b edit просит «поправь фон, потом руку, потом свет», это три прохода, а не один, и очередь считать надо по вызовам, а не по задачам.

Когда очередь начинает копиться, первый рефлекс - увести пик правок на сторону вендора. Там считают уже не GPU-секунды, а мегапиксели вывода: api flux тарифицируется по результату, и очередь превращается в счёт, который растёт вместе с разрешением. Приравнивать два маршрута нельзя, но держать рядом хотя бы один внешний контур для сравнения полезно - например, provod.ai (российский OpenRouter), где генерация и редактирование изображений доступны с рублёвого баланса без зарубежной карты. Это площадка для сравнения, а не заявление, что она быстрее локального FLUX.

Калькулятор очереди собирается из четырёх звеньев

Модель одной edit-очереди состоит из четырёх звеньев: задача, вызов GPU (или запрос к API), ожидание и оператор. Дальше - минимальный расчёт на предполагаемых входных данных. Все длительности здесь - допущения, и калькулятор ценен именно тем, что делает их явными.

# Прогноз одной edit-очереди FLUX 2 Klein 9B. # ВСЕ длительности - ПРЕДПОЛОЖЕНИЯ. Замеряй на своём железе.

tasks\_per\_hour     = 40    # входящих правок в час calls\_per\_task     = 2     # multi-pass: вызовов модели на задачу gpu\_seconds\_pass   = 2     # distilled, 4 шага, \~2с RTX 5090 (Comfy Org) batch\_size         = 1     # одна картинка на 16GB (DeepWiki) retry\_rate         = 0.15  # доля повторов, допущение - подставь своё operator\_pause\_s   = 25    # ручная приёмка/постановка между задачами

calls = tasks\_per\_hour \* calls\_per\_task \* (1 + retry\_rate) gpu\_load\_s = calls \* gpu\_seconds\_pass / batch\_size operator\_load\_s = tasks\_per\_hour \* operator\_pause\_s

print(f"GPU занят:      {gpu\_load\_s/3600:.0%} часа") print(f"Оператор занят: {operator\_load\_s/3600:.0%} часа")

Подставь дистиллированные 2 секунды - и получишь около 92 вызовов, примерно 184 секунды нагрузки на GPU и всего около 5% загрузки видеокарты в час. Оператор при тех же 40 задачах и паузе 25 секунд занят на 28%. Вывод при этих входных данных однозначен: узкое место - оператор, а не GPU. Второй ускоритель тут ничего не изменит, потому что видеокарта и так простаивает 95% времени.

Теперь поменяй один параметр - режим на базовый, 35 секунд на проход. Нагрузка на GPU подскакивает примерно до 3220 секунд в час, то есть около 89% загрузки, и очередь начинает копиться на видеокарте раньше, чем на человеке. Один и тот же поток, одно изменённое допущение - и узкое место переехало с оператора на GPU. Ровно это калькулятор и должен показывать: не абсолютную истину, а то, какое звено ломается первым при твоих числах.

Узкое место: GPU или оператор

Различать эти два случая нужно потому, что они лечатся по-разному, и ошибка стоит денег. GPU-узкое место видно по загрузке видеокарты близко к 100% и по тому, что задачи ждут именно инференса. Оно снимается более быстрым режимом или второй картой с батчингом. Операторское узкое место выглядит иначе: видеокарта простаивает, а задачи всё равно ждут, потому что человек не успевает ставить и принимать правки. Тут второй ускоритель бесполезен, помогает только процесс - шаблоны запросов, автоприёмка очевидных результатов, заранее нарезанные пресеты и вторая пара рук на приёмке.

Повторы стоит фиксировать отдельным параметром, а не прятать в «среднее время». Retry на многопроходных правках коварен: если из-за неудачного результата задача уходит на второй и третий круг, она умножает нагрузку именно там, где узко. При GPU-узком месте повторы бьют по видеокарте, при операторском - по человеку, который заново формулирует запрос. Поэтому в калькуляторе retry_rate вынесен наружу: меняя его, ты видишь, какое звено первым выходит из допустимого ожидания.

И есть третий ограничитель, который не виден ни в загрузке GPU, ни в паузах оператора. Ни модельная карточка, ни лицензия, ни прайс не описывают лимиты конкурентности, глубину очереди и поведение при масштабировании на несколько GPU для локального Klein 9B - эти параметры вендор оставляет оператору измерять, а не декларирует. Значит, любые числа про параллелизм в твоём расчёте - твои допущения, и относиться к ним надо соответственно.

Режим выбирают после прогноза, а не по цене прохода

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

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

Отдельно про юридический потолок, который перекрывает любую пропускную способность. Веса Klein 9B по умолчанию выпущены под FLUX Non-Commercial License: доход-генерирующее и продакшн- или end-user-развёртывание прямо запрещено, пока не получена отдельная коммерческая лицензия. Это жёсткое предусловие для любой команды, которая планирует продакшн-очередь правок на 9B-чекпоинте. Коммерческие тарифы самохостинга Black Forest Labs, по данным bfl.ai на 2026-07-18, ограничивают объём картинок в месяц независимо от железа - например, Builder разрешает 10 тысяч изображений в месяц на одном домене, Platform - 100 тысяч. То есть максимальный устойчивый объём очереди бывает ограничен не GPU, а условиями лицензии. И это ровно те условия, которые меняются, так что перепроверяй их перед закупкой.

Чего этот расчёт не решает

Прогноз не заменяет замер на рабочем железе - это его главное ограничение, и я не хочу, чтобы ты принял модель за измерение. Тайминги Comfy Org сняты на конкретной RTX 5090 в конкретном окружении Comfy Org; на твоей карте, драйверах и разрешении цифры будут другими. Калькулятор показывает, какое звено ломается первым при заданных допущениях, но сами допущения - твоя ответственность.

Чего он точно не делает. Он не подтверждает реальные длительности, долю повторов и фактический поток задач - всё это неизвестно до измерения. Он не описывает поведение при нескольких GPU и конкурентных запросах, потому что вендор эти параметры не публикует. Он не отменяет лицензионный потолок: даже идеально настроенная очередь упрётся в месячную квоту или в запрет коммерческого использования 9B-весов. И он не сравнивает локальный и внешний маршрут как одинаковые - у них разные оси стоимости и разные точки отказа, и приравнивать их нельзя.

Где здесь честно проходит граница знания. Установлено: параметры модели, тайминги как опубликованные, классификация лицензии и объёмные квоты, режимы правок, цена за мегапиксель. Вероятно: серийные правки создадут узкое место либо на GPU, либо на операторе - но какое именно, зависит от режима и потока. Неизвестно до замера: реальные длительности, повторы и поток. Нормативная часть - «пропускная способность очереди важнее средней цены кадра» - это моя позиция, поддержанная ценой за мегапиксель, но не доказанная ею одной.

Как это соотносится с внешним маршрутом?

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

from openai import OpenAI client = OpenAI(api\_key="ВАШ\_КЛЮЧ", base\_url="https://api.provod.ai/v1")

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

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

FAQ

Можно ли запустить продакшн edit-очередь прямо на скачанных весах Klein 9B?

По умолчанию нет. Веса идут под FLUX Non-Commercial License, доход-генерирующее и end-user-развёртывание запрещено без отдельной коммерческой лицензии (bfl.ai, 2026-07-18). Сначала лицензия, потом очередь.

Хватит ли RTX 4080 на 16 ГБ?

Как минимум поддерживается, но по данным сообщества (DeepWiki) практический батч там - одна картинка, а рекомендуется 4090 на 24 ГБ. При серийных правках одиночный батч быстрее упрётся в сериализацию очереди.

Distilled или base под поток?

Считай оба режима в калькуляторе на своих числах. По замерам Comfy Org distilled даёт ~2с против ~35с у base; при высоком потоке base насыщает GPU намного раньше.

Почему нельзя просто взять цену за мегапиксель как стоимость правки?

Потому что цена docs.bfl.ai - «от $0.015» за первый мегапиксель, дальше инкрементально. Реальная сумма зависит от разрешения, и одна логическая правка может быть несколькими проходами.

Заменяет ли этот расчёт бенчмарк?

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

provod.ai — один контур от первого теста до рабочего продукта

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

В одном каталоге — актуальные модели для текста и медиа: GPT от OpenAI, Claude от Anthropic, Gemini от Google, Grok от xAI, DeepSeek, Qwen, GLM, Kimi и MiniMax; для изображений — Nano Banana 2 Pro и GPT Image; для видео — последние версии Seedance, Kling, Veo и Google Omni. Также доступны модели для reasoning, поиска, документов, эмбеддингов, музыки и аудио.

Тестовые и боевые запросы оплачиваются по одной прозрачной логике: официальная цена модели 1:1, без собственной маржи provod.ai.

Доведите AI-сценарий до production: форма регистрации · цены на модели · защита данных по 152-ФЗ · API и интеграции

Источники

• Black Forest Labs, FLUX.2 Klein blog, доступ 2026-07-18: bfl.ai/blog/flux2-klein-towards-interactive-visual-intelligence (режимы правок).
• Hugging Face, FLUX.2-klein-9B, доступ 2026-07-18 (параметры, файл, Qwen3-энкодер, отсутствие спецификаций по конкурентности).
• Hugging Face, LICENSE.md, доступ 2026-07-18 (FLUX Non-Commercial License).
• Comfy Org blog, доступ 2026-07-18 (шаги, тайминги, VRAM на RTX 5090).
• bfl.ai/licensing, доступ 2026-07-18 (тарифы Builder 10K, Platform 100K/месяц).
• docs.bfl.ai/quick_start/pricing, доступ 2026-07-18 (цена от $0.015/мегапиксель).
• DeepWiki, доступ 2026-07-18 (минимальное железо и батч; вторичная сверка сообщества, не первичный документ).