Короткий ответ: существуют ли файнтюны LLM под .glb/glTF
Подтверждённых файнтюнов размером около Qwen 27B, которые сами генерируют и редактируют .glb/glTF, в доступных материалах нет. Тема началась с вопроса в сообществе LocalLLaMA: пользователь ищет дообученные модели в диапазоне Qwen 3.8 27B и Qwen 3.8 Flash Next, которые заметно усиливают 3D-моделирование и создание ассетов, в основном для видеоигр. Это именно запрос: автор прямо спрашивает, работает ли кто-то ещё в этом направлении, и не называет ни одной готовой модели.
Второй факт оттуда же: автор считает Qwen 27B достаточной для кодинга, но сомневается, что её хватит для моделирования. Фронтирные модели, по его оценке, расходуют слишком много токенов, чтобы делать что-то осмысленное в масштабе. Оба утверждения - личный опыт и гипотеза конкретного пользователя, а не измеренный результат.
Дальше разбираем проверяемое: какие задачи стоят за запросом, почему 3D хуже поддаётся LLM, чем код, как считать бюджет токенов и VRAM, по каким признакам отличить реальный файнтюн от красивого README и какую связку можно собрать уже сейчас, не дожидаясь релиза.
Что подтверждено, а что остаётся открытым вопросом
Граница проходит по источнику. Обсуждение подтверждает сценарии и мотивацию автора, но ничего не говорит о существовании готовых весов.
- Подтверждено: набор задач, которые пользователь хочет закрыть через LLM, - генерация ассетов по описанию и референсам, правка купленных моделей, риггинг с анимациями, конвертация форматов.
- Подтверждено: размерный ориентир. Qwen 27B и Qwen 3.8 Flash Next упомянуты как пример планки по числу параметров, а не как проверенные 3D-модели.
- Не подтверждено: существование конкретных файнтюнов с открытыми весами, которые стабильно выдают валидный .glb по текстовому ТЗ.
- Не подтверждено: любые 3D-бенчмарки, цены, лицензии и замеры качества для таких моделей. В материалах их нет вообще.
Практический вывод из этой границы: тему стоит читать как карту задач и способов проверки, а не как обзор релизов. Всё, что ниже, описывает механику работы, а не анонс готового решения.
Какие задачи на самом деле стоят за запросом
Четыре сценария из запроса различаются по сложности на порядок. В каждом полезно разделить три слоя: что делает языковая модель, что делает инструмент и что остаётся человеку.
Генерация ассета по ТЗ и референсам
Сценарий выглядит так: есть markdown-спека с описанием объекта и набор референсных изображений, которые с ней согласуются, на выходе нужен готовый .glb. Здесь обязательна поддержка vision, иначе модель не сверит картинку с текстом: пропорции, количество элементов, стиль, материалы.
Что реально даёт LLM в такой цепочке: разбор спеки, декомпозицию на шаги, список объектов с размерами и иерархией, генерацию скрипта под Blender Python API. Модель не рисует геометрию напрямую - её выход это код или промежуточное описание, которое исполняет 3D-редактор. Реалистичный результат первого прохода: болванка сцены с правильными пропорциями и единицами измерения, примитивы на местах, материалы-заглушки, корректная иерархия объектов. Топологию, UV-развёртку и детализацию доводит человек либо специализированный инструмент. Ждать «модель по тексту в один клик» на уровне продакшн-ассета не стоит.
Редактирование лицензированных моделей
Пример из запроса - вырезать откидные двери на дирижабле, который пользователь купил или лицензировал. Здесь два независимых риска. Юридический: лицензия ассета может запрещать распространение производных версий, и никакая LLM этого не отменит. Технический: правка меша требует булевых операций, аккуратной топологии после выреза, переработки UV и переназначения материалов.
LLM полезна как автор скрипта и как проверяющий логику: найти нужный объект по имени, применить boolean-вырезание, пересчитать нормали, обновить UV, не потерять модификаторы. Приёмку всё равно делает человек в Blender - ни одна текстовая модель не скажет, аккуратно ли выглядит кромка выреза и не поехали ли швы текстуры.
Риггинг, анимации и конвертация FBX в gLTF
Риггинг в запросе идёт как «плюс», не как основное требование, и это честная оценка сложности. Скелет, веса вершин, ограничения суставов - область, где ошибка видна только в движении: модель может предложить иерархию костей и скрипт их расстановки, но проверить деформации можно лишь прокруткой анимации.
Конвертация FBX в gLTF наполовину задача кодинга: LLM напишет вызов конвертера и проверит, что в выходном файле остались нужные узлы, материалы и клипы. Понять, потерялась ли деформация или слетела привязка, без знания спецификации и без валидатора нельзя. Форумный разбор экспорта в glb/glTF показывает, где именно рвётся: не поддерживаются smart bones, привязка точек к костям и маскирование. То есть часть потерь заложена в формате, а не в модели, которая писала скрипт.
| Задача | Что реально делает LLM | Что делает инструмент | Кто принимает результат |
|---|---|---|---|
| Ассет по ТЗ и референсам | Разбирает спеку, сверяет с картинками, пишет Blender Python-скрипт, задаёт пропорции и иерархию | Blender строит меш, назначает материалы, делает glTF-экспорт | Художник проверяет топологию, UV и силуэт |
| Правка лицензированной модели | Пишет скрипт булевых операций, пересчёта нормалей, правки UV | Blender выполняет, валидатор проверяет структуру файла | Человек смотрит вырез и сверяет условия лицензии |
| Риггинг и анимации | Предлагает иерархию костей и скрипт расстановки | Blender и аддоны автоскелета, просмотр в движении | Аниматор проверяет деформации на клипах |
| FBX в gLTF | Пишет вызов конвертера и проверки наличия узлов, клипов, материалов | Конвертер и glTF-валидатор | Человек сравнивает исходник и результат |
Почему 3D - тяжёлая ниша для LLM
Причина не в том, что 3D «сложнее» текста вообще, а в типе данных и способе проверки результата.
Текст, код и геометрия - разные типы данных
Код проверяем механически: запустил, получил ошибку или рабочий результат. Компилятор, линтер и тесты выступают внешним оракулом, который не даёт модели обмануть саму себя. Геометрия проверяется иначе: топология (квады, треугольники, N-гоны, плотность сетки), UV без растяжений, направление нормалей, масштаб в метрах, ориентация объекта, число полигонов под бюджет платформы.
LLM работает с последовательностью токенов. Меш - это набор вершин, индексов и атрибутов, где связность задаётся топологией, а не порядком слов. Чтобы модель «понимала» геометрию, нужен либо мультимодальный вход (изображения, воксели, облако точек), либо внешний инструмент, который выполнит проверку за неё. Файнтюн на текстах и скриптах даёт аккуратный код, но не пространственное понимание.
Ограничения формата glTF и потери при экспорте
glTF - строгая спецификация, и это одновременно плюс и ограничение. Плюс в том, что glb встраивается в HTML, управляется через JavaScript и держит несколько сцен и несколько анимаций в одном файле - для веб-игр и интерактивных страниц это удобно.
Ограничение в том, что возможности исходного редактора переносятся не полностью. В том же обсуждении автор упирается в невозможность скриптовой конвертации движения точек, управляемых костями, в ключи на каждом кадре, потому что кривизну точек пока нельзя ключевать. Для LLM это означает: даже идеально написанный скрипт не спасёт, если нужная функция не выражена в целевом формате. Проверять надо не только код, но и саму принципиальную выполнимость переноса.
Экономика токенов: почему 27B, а не фронтир
Мотивация в запросе прозрачная: фронтирные модели слишком дороги по токенам для объёмной работы, а локальная модель на 27 млрд параметров уже помещается на домашнюю видеокарту и не тарифицируется за каждый запрос.
Что значит «хватает для кода, не хватает для 3D»
Для кода цепочка короткая: сгенерировал функцию, прогнал тест, получил ответ. Для 3D цепочка итеративная и длинная: разобрал ТЗ, написал скрипт, выполнил в Blender, отрендерил превью, посмотрел, поправил. Каждая итерация тащит в контекст историю, фрагменты спеки и вывод ошибок. Токен-бюджет растёт не линейно, а по числу попыток.
Гипотеза автора запроса звучит разумно: 27B хватит на написание скриптов, но она не заменит 3D-редактор. Оракул в 3D-пайплайне существует (Blender плюс валидатор glTF), его нужно только собрать и дать модели право вызывать инструменты. Без этого любая модель, хоть 27B, хоть фронтирная, будет угадывать.
Требования к VRAM и локальному запуску
Арифметика простая. 27 млрд параметров в 4-битной квантизации занимают примерно 13,5 ГБ только под веса. Сверху идёт KV-cache, который растёт с длиной контекста: чем больше спека, референсов и логов ошибок в промпте, тем больше памяти. Плюс сама сцена в Blender и операционная система. Отсюда ориентир: 24 ГБ дают запас на длинный контекст и параллельную работу, 16 ГБ требуют экономить на длине промпта и числе итераций. Это расчёт из размера модели, а не замеры; реальное потребление зависит от рантайма и формата квантизации.
Смежный вопрос - насколько мощной карты вообще достаточно. Разбор локальных LLM для 3D-моделирования на примере RTX 5090 показывает, что одной видеопамяти мало и исход решают другие факторы сборки. А если сравниваете архитектуры и стоимость инференса, полезен материал о том, как контекстное окно и KV-cache влияют на VRAM и цену запроса.
Как самостоятельно проверить, есть ли подходящий файнтюн
Поиск стоит вести по конкретным признакам, а не по слову «3D» в названии модели.
Где искать: Hugging Face, GitHub, сообщества
На Hugging Face фильтруйте по базовой модели (семейство Qwen, размерность около 27B) и по тегам вроде 3d, gltf, blender, mesh. На GitHub ищите связки Blender + LLM: аддоны, MCP-серверы, скрипты пакетного экспорта. Профильные форумы дают то, чего нет в README, - реальные ограничения форматов и экспорта.
Отдельно проверяйте формат весов: если модель выложена только в GGUF, её поведение зависит от конкретной сборки и версии инференс-движка. Как это выглядит на практике и что вообще значит публикация GGUF-версии, разобрано в материале про GGUF-модель Raon-1-mini-preview и проверку модели на своём железе.
Красные флаги и критерии оценки
Быстрая проверка карточки модели экономит часы:
- Красный флаг: заявлена «полная генерация 3D» без валидатора glTF и без единого примера вход/выход.
- Красный флаг: не указана базовая модель, датасет и лицензия весов.
- Красный флаг: нет ни одного публичного замера качества, только скриншоты в твите.
- Зелёный флаг: указана базовая модель и точный датасет, включая то, откуда взяты пары «спека - скрипт».
- Зелёный флаг: в репозитории есть воспроизводимый пайплайн и примеры готовых .glb, которые можно скачать и открыть.
- Зелёный флаг: ограничения описаны честно: какие задачи модель не решает и где нужен человек.
Финальный тест - собственное небольшое ТЗ. Сгенерируйте простой объект, попробуйте отредактировать готовый ассет, прогоните конвертацию FBX в gLTF и сравните результат с исходником в валидаторе. Если модель уверенно пишет скрипты и проходит этот круг, у вас рабочий инструмент. Если выдаёт красивые тексты про «автоматическое 3D», это не файнтюн под 3D.
Рабочий пайплайн уже сейчас: LLM + Blender + валидация
Ждать релиза не обязательно. Связка из языковой модели, 3D-редактора и валидатора закрывает часть задач уже сегодня - с поправкой на то, что делает каждый участник.
- LLM разбирает спеку и референсы и возвращает план: список объектов, размеры, иерархию, требования к материалам.
- Там же генерируется Blender Python-скрипт: создать примитивы, найти нужный меш по имени, применить операции, выставить единицы измерения.
- Blender выполняет скрипт; ошибки из консоли возвращаются в модель для следующей итерации.
- Результат осматривается в вьюпорте: топология, UV, силуэт, направление нормалей.
- glTF-экспорт и прогон через валидатор: проверяются узлы, материалы, клипы анимации.
- Для конвертации FBX в gLTF тот же цикл: скрипт конвертации, затем сравнение списка объектов, клипов и материалов до и после.
Роль LLM, роль инструментов, роль человека
LLM отвечает за декомпозицию, код и проверку логики. Инструменты отвечают за исполнение: Blender, конвертеры, валидатор glTF. Человек отвечает за приёмку визуала и топологии, а также за юридическую проверку лицензий на исходные ассеты.
Опыт из смежной области показывает цену такой связки. В кейсе с 3D-персонажем для веб-сервиса через Claude, GPT и Blender понадобилось больше 200 итераций по промтам и около 14 часов работы. Это не аргумент против подхода, а честный ориентир по трудозатратам: итеративность здесь встроена в процесс.
Что LLM не сделает и какие есть риски
Список ограничений стоит держать перед глазами до начала работы, а не после.
- Не заменит 3D-редактор: модель пишет код для Blender, но не работает с мешем напрямую.
- Не гарантирует валидную топологию: кривые N-гоны и лишние полигоны придётся искать руками.
- Не обойдёт ограничения формата: smart bones, привязка точек к костям и маскирование в glb/glTF не переносятся, сколько бы итераций ни было.
- Галлюцинирует в скриптах: вызовы несуществующих операторов и параметров - обычное дело на первых проходах.
- Не решает лицензионные вопросы: правка купленного ассета может нарушать условия распространения.
- Не проверяет потери при конвертации без валидатора и ручного сравнения исходника с результатом.
Отдельный риск - время. Итеративный цикл «сгенерировал, выполнил, посмотрел, поправил» на сложной модели легко съедает больше времени, чем ручная правка в редакторе. Считать надо не стоимость токенов, а стоимость часа работы.
Кому это актуально и как следить за направлением
Запрос точнее всего описывает боль небольших команд: инди-разработчики, геймдев-студии без отдельного 3D-отдела, специалисты на 3D-аутсорсе с потоком однотипных правок и энтузиасты локальных LLM, которым интересно собрать пайплайн на своём железе. Для крупного продакшна с налаженным пайплайном выгода от такой автоматизации ниже: там уже есть свои скрипты и технические художники.
Следить за направлением можно по трём точкам: новые файнтюны на базе моделей Qwen-класса на Hugging Face, репозитории Blender + LLM на GitHub и профильные обсуждения, где люди выкладывают реальные ограничения экспорта и конвертации. Ориентир для оценки - не громкость названия, а наличие воспроизводимого пайплайна и примеров .glb.
Сейчас подтверждённых файнтюнов под 3D с открытыми весами нет, и запрос сообщества это фиксирует. Зато связка «локальная модель на 27B, скрипты для Blender и валидатор glTF» уже даёт практическую пользу и не требует ждать релиза. Начните с одного тестового ассета: спека, скрипт, проверка в редакторе, экспорт в glb. Так вы получите собственные данные о том, где модель справляется, а где упирается в формат. Если хочется посмотреть, как такие связки выглядят в других задачах, пригодится подборка сценариев с Blender, Three.js и 3D-сайтами.