Про route.yaml, авторство в пайплайнах и почему open source без экономики рискует снова стать кормом для платформ
ИИ меняет масштаб возможного для одиночки не теоретически, а практически.
Раньше один человек мог написать текст, нарисовать картинку, собрать прототип. Но если речь шла о фильме, визуальной системе, звуке, анимации, интерактивной среде — нужна была студия: команда, бюджет, производственная цепочка, доступ к софту и каналам распространения.
Сейчас эта граница размывается. Один человек с нормальным стеком — LLM, генерация изображений/видео/звука, Blender, compositing, локальные пайплайны, немного скриптинга — может делать вещи, которые недавно требовали цеха.
Я это ощущаю руками: работаю с визуальным искусством, купольными фильмами, мэппингом, генеративной графикой, 3D, монтажом. ИИ не «заменяет художника» — он убирает часть производственного трения: рутину, перебор вариантов, черновую сборку, перевод между форматами и часть инфраструктурных издержек.
Плохая новость: эта свобода арендованная.
Кто владеет этой студией?
Новый контроль выглядит не как старый индустриальный. Он аккуратнее, мягче и неприятнее.
Раньше хозяин говорил: работай на меня.Теперь: твори свободно. Вот подписка, лимит, кредит, API, правила.
Если ты делаешь серьёзную работу, ты завязан на чужой слой.
Новый феод эпохи ИИ — это не земля, не фабрика и даже не социальная сеть. Это связка из весов модели, доступа к inference, API, датасетов и политики использования.
Модель — это не просто исполняемый файл. Это набор весов, полученный из огромного массива человеческих текстов, изображений, кода и звука. В ней статистически упакованы языковые, визуальные и культурные паттерны. Поэтому контроль над моделью — это контроль не только над инструментом, но и над пространством возможных результатов.
Это глубже, чем контроль дистрибуции.
Раньше корпорации владели каналом: площадкой, трафиком, лентой, поиском, рекламой. Теперь есть шанс, что они будут владеть самим языком производства — не тем, как ты распространяешь результат, а тем, как ты его формулируешь и получаешь.
Кто контролирует этот слой, тот контролирует:
- какие запросы вообще имеют шанс на хороший ответ,
- какие темы режутся фильтрами,
- какие стили поощряются, а какие становятся дорогими или невозможными.
Это уже не просто платформа. Это инфраструктурный уровень ниже — контроль над языком производства.
Почему open source пока не закрывает проблему
Первый рефлекс понятен: есть open source, локальные модели, ComfyUI, Hugging Face. Зачем драматизировать?
Потому что open source сейчас закрывает только часть задачи.
ComfyUI— отличная штука для локальных визуальных пайплайнов. Но это рабочий стол, не универсальный протокол взаимодействия между независимыми участниками. Он не решает вопрос авторства, provenance, лицензирования и распределения ценности между участниками цепочки.
n8nавтоматизирует процессы. Прекрасно. Но он не решает вопрос: кто создал маршрут, кто внёс вклад, как это учесть, как перенести между средами.
Hugging Faceдействительно близок к этой области: Hub уже стал одной из главных точек сборки моделей, датасетов, Spaces и API. Но это ещё не открытый протокол маршрутов. Там есть хранилище и интерфейсы доступа, но нет стандарта, который описывает, как результат одной модели структурно и воспроизводимо передаётся следующей — с provenance, авторством и экономикой. И главное: это всё ещё центральная платформа, а не нейтральный слой.
Проблема:у нас пока нет общего стандарта, который описывает не просто модель или workflow, амаршрут— как задача проходит через несколько моделей, что сохраняется, кто автор, где лицензия, что получилось, кто внёс вклад, как это воспроизводится.
Open source сейчас решает доступ к инструментам, но не решает совместимость между ними:
- нет общего формата маршрута, который можно передать от одной модели к другой;
- нет единого слоя provenance;
- нет стандартного способа описать, кто внёс вклад;
- нет общего механизма для обнаружения и повторного использования маршрутов.
Open source сегодня — это скорее набор мастерских, чем сеть производства.
Георгий, который убил дракона, и потом стал им
В истории это повторялось много раз: структуры, созданные как защита от старой власти, со временем сами становились центрами контроля.
Венеция — вольная коммуна, убившая феодального дракона. Через двести лет — торговая империя, эксплуатирующая Средиземноморье. Амстердам — бунт против Габсбургов. Через поколение — VOC, первая корпорация с правом вести войну. Буквально дракон с акционерным капиталом. City of London — вольный город внутри монархии. Сегодня — один из центров глобального финансового контроля.
Это не морализаторство, а обычная гравитация власти. Ганза работала, пока была нужна как форма сопротивления. Потом превращалась в систему собственных интересов.
Вывод:союз как организация почти неизбежно начинает производить центр.
Именно поэтому идея «давайте создадим мощную платформу для независимых творцов» меня не убеждает. Через некоторое время вы просто построите ещё одну платформу — с более приятным интерфейсом, но той же структурой подчинения.
Поэтому вопрос не в том, как построить "добрую платформу", а в том, как не строить центр там, где можно обойтись протоколом.
Протокол против платформы
Если не хотим строить очередного дракона, надо смотреть не на платформу, а на протокол.
Платформа— это центр. У неё есть владелец, правила, модерация, API, доступ, бан, тариф, лимит, политика.
Протокол— это язык взаимодействия. У него может быть спецификация, но не обязан быть хозяин.
Примеры: email, HTTP, RSS, ActivityPub, Bitcoin.
Ни один не идеален. У каждого свои ограничения, компромиссы и костыли. Но принцип важен: если у системы есть общий язык, она может жить без единого центра контроля.
Протокол — это система, которая может работать без единого владельца, если у неё есть:
- открытая спецификация,
- несколько независимых реализаций,
- нет единственного обязательного узла,
- есть возможность локального исполнения,
- есть право на форк без потери совместимости.
Если без одной компании вся система умирает — это не протокол, а централизованная платформа с хорошим маркетингом.
Вот это и нужно сейчас творческой ИИ-инфраструктуре: не новая платформа для демиургов, аоткрытый машиночитаемый формат обмена между независимыми мирами— что было на входе, какие модели участвовали, какие были промежуточные артефакты, кто автор маршрута, какая лицензия, как фиксируется provenance и как при необходимости считается вознаграждение.
Если у системы нет хотя бы такого формата, она остаётся метафорой, а не инфраструктурой.
Единица ценности — не модель, а маршрут
Полезное слово:маршрут.
Не модель сама по себе, а маршрут между моделями и инструментами — это будущая единица ценности.
Не «я использовал вот эту модель», а:задача → промежуточный результат → следующая модель → проверка → ручная доработка → итог.
Маршрут — это не абстрактная "цепочка мышления", а формализованный объект, который можно передать между системами.
Допустим, у тебя пайплайн для купольного фильма: LLM превращает бриф в структурированную сцену, image model генерирует ключевые кадры, video model анимирует, локальный скрипт приводит всё к нужной геометрии купола, а человек вручную чистит артефакты.
В этом случае ценность — не в одной модели. Ценность — в воспроизводимой последовательности решений, параметров, проверок и ручных вмешательств. Это и есть маршрут.
Минимальный маршрут должен описывать:
- что было на входе,
- какая модель это обработала,
- какой был тип выхода,
- какие параметры использовались,
- кто автор маршрута,
- как фиксируется provenance,
- как задаётся лицензия и, при необходимости, распределение вознаграждения.
Без этого "маршрут" остаётся красивым словом для workflow.
Черновой формат маршрута
Примерно так это может выглядеть на первом приближении:
Важно:это не готовый стандарт, а минимальный скетч структуры для обсуждения.
Здесь пока нет:
- механики разрешения конфликтов,
- модели исполнения,
- security layer,
- стратегии версионирования,
- механизма валидации,
- способа обработки ошибок.
Но даже этот скелет уже лучше, чем обсуждать "протокол" без полей, по которым можно спорить и дополнять предложение.
Что можно собрать уже сейчас
Минимальный MVP такого протокола — это не новая платформа, а набор очень скучных вещей:
1. JSON/YAML-схема маршрутаЧтобы можно было описать цепочку обработки формально.
2. CLI-валидаторЧтобы проверять маршрут на соответствие схеме.
3. Reference converterНапример, импорт из ComfyUI workflow вroute.yaml.
4. Manifest результатаЧтобы вместе с итоговым артефактом сохранялись:
- author,
- model chain,
- provenance,
- license,
- параметры запуска.
5. Публичный репозиторий спецификацииС примерами, тестами и обратной связью от людей, которые реально строят пайплайны.
Потому что после этого статья перестаёт быть «давайте построим язык между мирами» и становится:«вот первый болт, который можно прикрутить к реальной машине».
Экономика должна быть в ДНК формата
Самая неприятная ошибка интернета была не техническая, а архитектурная.
Базовые интернет-протоколы были спроектированы без встроенного слоя авторства и микроэкономики. Это не "ошибка интернета" как такового, а исторический выбор архитектуры: маршрутизация и доставка есть, а нативного механизма учёта вклада и перераспределения ценности — нет.
Из-за этого позже пришлось наращивать поверх протокола авторское право, платформенные комиссии и DRM.
С ИИ есть риск повторить ту же ошибку.
Если в протоколе маршрута с самого начала нет полей для автора, лицензии, attribution, распределения долей, провенанса и возможной оплаты, потом это будет почти невозможно добавить без боли, потерь и сломанной совместимости.
Важно:я не говорю про web3-евангелизм и не предлагаю спасать всё блокчейном. Тут не нужен культ. Нужна архитектурная трезвость.
Можно использовать:
- DID (Decentralized Identifiers),
- кошельки,
- подписи,
- provenance chains,
- optional payments,
- любые аккуратные механизмы атрибуции.
Но это должно быть подчинено протоколу, а не наоборот.
Экономика не обязательно должна запускаться сразу.Поля могут быть нулевыми, опциональными, выключенными. Но они должны быть в ДНК формата с первого дня.
Потому что если маршрут ценен, рано или поздно его начнут использовать и за него начнут платить. Если к этому моменту в спецификации нет места для авторства и распределения, всё придётся ломать и переписывать.
Что конкретно не хватает Hugging Face
Hugging Face действительно близок: Hub стал одной из главных точек сборки моделей, датасетов, Spaces и API, недавно добавили MCP-интеграцию.
Но не хватает трёх вещей:
1. Экономического слояУ Hugging Face есть бесплатные и open слои, но это не экономика маршрутов. Создатель workflow или маршрута не получает встроенного механизма attribution и распределения ценности просто потому, что его цепочка оказалась полезной. Протокол без экономики — это RSS. Работает, пока кто-то добровольно поддерживает. Потом умирает или поглощается.
2. Децентрализованного управленияHugging Face — центральная платформа. Они решают что остаётся, что удаляется. Это очень добрый феодал. Добрый феодал всё равно феодал.
3. Стандарта на маршрутыHugging Face хранит модели и даёт к ним доступ. Но как одна модель передаёт результат другой, в каком формате, с каким контекстом, как фиксируется provenance, как учитывается вклад — этого стандарта нет. Каждый строит свои трубы сам.
Лакуна конкретная:не хранилище моделей, а открытый стандарт на маршруты между ними с встроенной экономикой и без центра.
Одиночка может создать мир, но не может удержать его жизнь
Одиночки всегда создавали миры: Толкин, Лавкрафт, Герберт, Лем.
Но раньше одиночка мог создать мир только в тексте. Чтобы мир стал визуальным, звуковым, пространственным — нужна была армия. И тут приходил дракон: армия у меня, хочешь мир — отдай права.
ИИ впервые даёт одиночке шанс удержать не весь жизненный цикл мира, а его производственную основу:текст, визуал, аудио, прототипы, вариации.
Это не значит, что один человек сможет контролировать всё культурное развитие мира, если он станет популярным. Но раньше он даже не мог нормально довести мир до состояния, в котором такой контроль вообще возможен.
Но управлять живым миром — миром, в котором тысячи людей живут, генерируют, обсуждают — одиночка не может.
Под "миром" здесь я имею в видуне художественную вселенную в романтическом смысле, а наб без центра, без разрешения владельца и без потери совместимости между участниками.
Лавкрафт, возможно, не проектировал это как протокол, но на практике его мифы работают как открытая система: у них есть синтаксис, точки входа и возможность расширения другими авторами. Любой автор может подключиться в принципе, если понимает синтаксис мира и принимает его правила.
На практике это не означает отсутствие барьеров: есть порог входа, культурная совместимость, вопрос качества и риск того, что мир быстро засорится низкосигнальным контентом. Поэтому "открытый протокол" ещё не решает модерацию и не гарантирует живость сообщества.
Дракон не смог колонизировать этот мир полностью именно потому, что протокол был открыт до того, как дракон успел.
Мы сейчас в окне возможностей
Прямо сейчас инструменты доступны, платформы конкурируют, open source существует, контроль не консолидирован.
Классическая ситуация: пока старый дракон судится с новым, есть время строить инфраструктуру, которая не принадлежит ни одному из них. Параллельно идут иски со стороны крупных медиакомпаний против ИИ-сервисов по поводу авторских прав и использования персонажей и франшиз. Это может ускорять интерес к локальным и open source-инструментам, но это не автоматический закон истории.
Судебные войны копирайта объективно толкают в сторону open source. ComfyUI, Stable Diffusion, локальные LLM — это не просто технический выбор, это политический жест. Люди строят гаражи, которые не арендованы.
Но главная задача фазы свободы — построить не просто инструменты, апротокол дистрибуции и взаимодействия, который позволяет одиночке дотянуться до аудитории без посредника-платформы.
Может ли один человек показать фильм миллиону людей, не отдав копеечку дракону? Сегодня — пока нет.
Возможно, я переоцениваю роль открытого формата и недооцениваю проблему вычислений. Протокол не отменяет монополию на GPU, не решает discovery и не гарантирует качество. Но без общего формата маршрутов все эти проблемы всё равно будут решаться внутри чужих платформ.
Что строить практически
Нам нужен не союз творцов (который быстро станет платформой), аоткрытый стандарт маршрутов между моделями, с provenance, лицензированием и встроенной, но опциональной экономикой.
Не платформа.Не новый «маркетплейс для креаторов».Не союз, который через год сам станет драконьей администрацией.
А протокол.
Минимальный набор того, что должен описывать маршрут:
- input schema,
- output schema,
- model id,
- parameters,
- provenance chain,
- license,
- author (DID или кошелёк),
- cost / credits (опционально),
- validation status.
Что это не решает:
- модерацию,
- discovery,
- adoption,
- монополию на вычисления,
- гарантию качества.
Это не магия, а инфраструктурный слой.
Вопрос к сообществу
Это не готовый стандарт и не законченный продукт. Это попытка описать архитектурную лакуну: если мы строим ИИ-инструменты, но не строим открытый протокол маршрутов между ними, то в итоге снова оказываемся в чужой платформе.
- кто уже делает что-то близкое?
- какие проекты ближе всего к этой идее?
- где я ошибаюсь архитектурно?
- что здесь уже решено, а что я по инерции считаю нерешённым?
- существует ли вообще шанс сделать маршрут между моделями открытым протоколом, а не очередной платформой?
Если у вас есть примеры, ссылки, возражения или уже готовые куски такой инфраструктуры — покажите. Это как раз тот случай, когда карта важнее красивого тезиса.
