Как GLM 5.3 Flash и GLM 5.3 ведут себя в BlenderMCP при локальном запуске на RTX PRO 6000 WS

Что вы узнаете из этого разбора

• Как связаны GLM 5.3 и GLM 5.3 Flash с BlenderMCP и где в цепочке «модель → инструмент → Blender» теряется время.
• Что публично известно о GLM-5.3 и варианте Flash, а что пока остаётся заявлениями разработчика без независимой проверки.
• Почему RTX PRO 6000 WS сам по себе не гарантирует предсказуемую скорость и как на неё влияют VRAM, KV cache и offload.
• Готовое ТЗ на интерьер, чек-лист метрик и минимальный протокол, чтобы собрать собственные логи сравнения.

Сразу обозначим границу: раздельных замеров GLM 5.3 Flash и GLM 5.3 в одном BlenderMCP-сценарии в доступных материалах нет. Ниже — что уже известно, что можно проверить своими руками и каких данных не хватает для полноценного бенчмарка.

Короткий ответ: чего ждать от GLM 5.3 Flash и GLM 5.3 в BlenderMCP

По переданному описанию нельзя честно назвать модель, которая быстрее запускается, точнее строит интерьер или тратит меньше токенов. В материалах нет логов с временем до первого вызова BlenderMCP, длительностью сценария, количеством ошибок и расходом токенов для GLM 5.3 Flash и GLM 5.3.

Подтверждён другой практический вывод: в агентной связке BlenderMCP качество сцены сильно зависит от точности запроса. Расплывчатое пожелание быстро приводит к произвольному масштабу, несогласованным высотам, неверным пропорциям и абстрактной 3D-каше. Жёсткое техническое задание с размерами помещения, координатами объектов, высотой потолка и материалами делает результат заметно более управляемым.

Сценарий с локальными GLM 5.3 на RTX PRO 6000 WS стоит рассматривать как практический кейс, а не как полноценный бенчмарк. Он помогает понять логику работы моделей с BlenderMCP, требования к постановке задачи и список параметров, которые нужно записывать при собственном сравнении.

Что именно сравнивается

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

Элемент сравнения	Что должно оцениваться	Статус в переданных материалах
Модели	GLM 5.3 Flash и GLM 5.3	Названия указаны, точные сборки не указаны
Инструмент	BlenderMCP, вызовы операций в Blender	Сценарий обозначен, версия не указана
Задача	Построение интерьера с измеримыми ограничениями	Сценарий описан, исходный промпт не передан
Железо	RTX PRO 6000 WS	Модель GPU указана, остальные параметры стенда отсутствуют
Метрики	Скорость, ошибки, итерации, токены, точность геометрии	Числовые значения отсутствуют

Главный вывод без лишних обещаний

Локальные GLM 5.3 могут подходить для агентных 3D-задач, если пользователь задает проверяемые ограничения и готов контролировать результат. Название модели само по себе не гарантирует корректную сцену: BlenderMCP исполняет конкретные команды, а неоднозначная команда дает модели слишком много свободы.

Практическое правило для выбора простое. Сначала нужно собрать одинаковые логи для обеих моделей, затем сравнить время до первого действия, число вызовов инструментов, расход токенов и количество исправлений. Без этих записей выбор между Flash и базовой GLM 5.3 будет предположением.

Что известно о GLM 5.3 до разбора локального запуска

GLM-5.3 и GLM-5.2: что заявляет Z.ai

Z.ai представила GLM-5.3 как новую версию своей флагманской модели. По описанию компании, прирост возможностей связан с масштабированием post-training и reinforcement learning. Базовая модель при этом осталась той же, что использовалась в GLM-5.2.

Такой подход переносит часть работы с этапа предварительного обучения на последующую настройку модели. Reinforcement learning помогает учить модель последовательнее решать длинные задачи и лучше следовать заданному процессу. Это полезный контекст для BlenderMCP, где ответ состоит из цепочки действий, однако он не подтверждает конкретное качество GLM-5.3 в Blender.

В разборе изменений GLM-5.3 такой статус стоит отделять от результатов независимых запусков. Заявление разработчика описывает подход к обучению, а сцена в Blender требует отдельной проверки геометрии, инструментальных вызовов и восстановления после ошибок.

Статус весов и локальных вариантов

В доступном описании GLM-5.3 сказано, что модель уже использовалась в продуктах Z.ai, тогда как полноценные веса на тот момент ещё не были опубликованы. Их ожидали после дополнительной оценки безопасности, ориентировочно через две недели после объявления. Это заявление разработчика, а не подтверждённый независимыми запусками факт: перед повторением кейса проверьте актуальную дату публикации весов и точное имя файла — сама формулировка «ожидаются через две недели» быстро устаревает.

Статус GLM 5.3 Flash в переданных материалах не раскрыт достаточно подробно: нет источника весов, формата, уровня квантизации, токенизатора и сервера инференса. Название Flash нельзя использовать как замену полной спецификации локальной сборки — два файла с похожим именем могут работать с разными квантами, контекстом и настройками offload.

Отдельный материал о локальной поддержке GLM-5.3 Flash полезен как ориентир для проверки совместимости, RAM, VRAM и KV cache, но его параметры нельзя выдавать за настройки этого BlenderMCP-кейса.

Чем Flash обычно отличается от базовой модели

В семействах GLM суффикс Flash традиционно обозначает облегчённый вариант: меньше параметров или более агрессивная оптимизация под скорость, ниже требования к памяти и ниже стоимость инференса в обмен на часть качества на сложных задачах. Заявленные отличия GLM-5.3 Flash от базовой модели описывает именно разработчик; независимых замеров в открытых источниках в доступных материалах нет.

Практический вывод для BlenderMCP: если Flash хуже держит численные ограничения и длинные цепочки вызовов, он может быстрее отвечать, но требовать больше итераций на исправление геометрии. Пока это гипотеза для проверки, а не результат. Полезный ориентир — сравнение Flash-вариантов разных семейств: оно помогает понять, что именно стоит фиксировать в логе помимо скорости.

Почему общий контекст модели важен для BlenderMCP

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

Z.ai ранее использовала контекстное окно объемом 1 миллион токенов и большую MoE-архитектуру. Эти сведения описывают общий подход компании к моделям. Они не доказывают, что конкретная локальная сборка GLM 5.3 Flash или GLM 5.3 получила тот же контекст, помещается в VRAM конкретной системы или лучше строит интерьер.

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

Что известно о BlenderMCP

BlenderMCP — это MCP-сервер, который даёт языковой модели доступ к Blender через вызовы инструментов. Модель не редактирует .blend-файл напрямую: она формирует команду, сервер передаёт её в Blender, а результат операции возвращается в диалог как ответ инструмента.

Типовой набор операций, который ожидается от такой связки:

• создание и удаление объектов — стен, примитивов, мебели;
• изменение габаритов, позиции и поворота объектов;
• назначение и правка материалов;
• работа со светом и камерой;
• чтение состояния сцены и возврат отчёта с параметрами объектов.

Для запуска связки нужны как минимум установленный Blender с соответствующим аддоном, Python-окружение с MCP-сервером и настроенный канал связи между сервером и Blender. Точные требования к версиям Blender, Python и зависимостей зависят от конкретной реализации — их нужно сверять с документацией проекта, а не выводить из названия.

Две особенности BlenderMCP важны для сравнения моделей. Во-первых, операции дискретны: «создать куб», «назначить материал», «сдвинуть объект». Во-вторых, сбой на одном шаге ломает последующие, если модель не умеет корректно читать ответ Blender и восстанавливаться. Поэтому качество сцены — это в первую очередь качество цепочки вызовов, а не отдельного текстового ответа.

Стенд и схема GLM 5.3 BlenderMCP локального запуска

Конфигурация рабочей станции

Из переданных данных подтверждена только видеокарта RTX PRO 6000 WS. Объем ее VRAM, процессор, оперативная память, накопитель, операционная система и версия драйвера не указаны. Число GPU тоже не зафиксировано.

Параметр	Что известно	Что нужно записать для повтора
GPU	RTX PRO 6000 WS	Точный вариант карты и число GPU
VRAM	Нет подтвержденного значения в описании	Общий объем, свободная память перед стартом и пик во время работы
CPU	Не указан	Модель и число потоков
RAM	Не указана	Объем и занятое место перед запуском
ПО	Версии не указаны	ОС, драйвер, Blender, BlenderMCP и сервер модели
Нагрузка	Не описана	Параллельные процессы и состояние Blender перед тестом

RTX PRO 6000 WS задает мощную отправную точку, однако по одному названию GPU нельзя рассчитать фактическую скорость. На нее влияют размер весов, тип квантизации, хранение KV cache, offload на CPU, длина контекста и нагрузка самого Blender. Отдельный разбор как подбирать железо и движок под новые LLM полезен, чтобы не путать имя GPU с реальной конфигурацией стенда.

Какая сборка модели реально запускалась

Для воспроизводимого сравнения нужны шесть записей по каждой модели:

1. полное имя релиза или файла весов;
2. источник и дата получения весов;
3. формат, например GGUF или другой поддерживаемый формат;
4. уровень квантизации;
5. рантайм и его версия;
6. раскладка слоев между GPU и CPU, размер контекста и параметры генерации.

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

Особенно критична разница между названием модели и локальной сборкой. Квантованный файл может занимать меньше памяти, но менять скорость, точность и доступный размер контекста. Даже одинаковое число параметров не гарантирует одинаковую нагрузку на видеопамять. Выбор между llama.cpp и vLLM здесь тоже влияет на результат: разные рантаймы по-разному ведут себя с MoE-моделями и большим контекстом.

Как модель связана с BlenderMCP

Типовая цепочка выглядит так:

1. Пользователь передает промпт с требованиями к сцене.
2. Модель формирует план или код для создания объектов.
3. Сервер принимает вызов BlenderMCP и передает операцию в Blender.
4. Blender создает или меняет объект и возвращает результат.
5. Модель получает сообщение о выполнении, ошибке или состоянии сцены.
6. При расхождении с заданием модель формирует исправление.

Задержка может появиться на каждом участке цепочки. Загрузка весов и первый ответ относятся к инференсу. Выполнение Python-кода или другой операции относится к Blender. Ошибка в имени инструмента, параметре или формате вызова относится к MCP-связке.

Переданные материалы не уточняют, какие шаги выполнялись автоматически и где требовалось ручное вмешательство. Этот пробел нужно закрыть в логе, иначе общее время сценария нельзя корректно разделить на работу модели и работу Blender.

Один сценарий для сравнения: интерьер в Blender

Что должна построить модель

Фраза «создай интерьер» слишком расплывчата для честного теста. Контрольный сценарий должен превращать каждое пожелание в проверяемый пункт. Ниже приведен пример технического задания, а не описание фактического промпта из кейса.

Единицы измерения: метры. Начать с пустой сцены.
Помещение: 6 x 4 м, высота потолка 2.8 м, толщина стен 0.2 м.
Пол: плоскость 6 x 4 м на высоте z=0.
Дверь: восточная стена, ширина 0.9 м, высота 2.1 м, нижняя точка на полу.
Окно: северная стена, ширина 1.8 м, высота 1.4 м, подоконник на высоте 0.9 м.
Диван: 2.2 x 0.9 x 0.85 м, центр в координатах x=0, y=-1.2.
Стол: 1.2 x 0.6 x 0.75 м, центр в координатах x=0, y=0.
Светильник: центр над столом, высота нижней точки 2.1 м.
Материалы: стены матовые светлые, пол под натуральное дерево,
диван серый текстильный, стол под темный орех, металлические детали черные.
Камера: показать все помещение и сохранить отдельный вид сверху.
После создания вывести список объектов и их габариты.

Для каждого пункта нужен критерий проверки. Например, помещение должно иметь четыре стены, дверь должна находиться в восточной стене, высота дивана должна соответствовать заданному значению, а материал пола должен быть назначен объекту пола. Визуальное впечатление можно оценивать отдельно.

Одинаковые условия для GLM 5.3 Flash и GLM 5.3

Обе модели нужно запускать с одним исходным файлом Blender и одним текстом задания. В сцене не должно быть заранее созданных объектов, камер или материалов, если они не предусмотрены методикой.

Для каждого прогона фиксируются:

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

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

Один удачный запуск недостаточен. Для каждого варианта желательно записать несколько повторов с очищенным состоянием Blender и сохранить исходные логи. В переданных материалах число повторов не указано.

Какие показатели записывать

Минимальный набор метрик должен разделять время модели и время инструментов:

Метрика	Как фиксировать	Зачем нужна
Загрузка весов	Секунды от старта сервера до готовности	Показывает цену запуска, но не скорость работы в диалоге
Время до первого ответа	Секунды от отправки промпта до первого содержательного ответа	Отделяет задержку инференса от Blender
Время до первого вызова	Секунды до первого вызова BlenderMCP	Показывает, как быстро модель переходит к действию
Полное время	Секунды до выполнения всех условий	Учитывает повторные запросы и работу Blender
Вызовы инструментов	Общее число и список операций	Показывает длину агентной цепочки
Ошибки	Число неудачных вызовов и тип каждой ошибки	Помогает отделить проблемы модели от проблем интеграции
Токены	Входные, выходные и суммарные токены по одинаковому счетчику	Позволяет оценить стоимость итераций
Геометрия	Фактические размеры, координаты, высоты и материалы	Заменяет субъективное впечатление проверяемыми данными

Показатель «скорость» без уточнения может вводить в заблуждение. Модель может быстро напечатать план, но долго создавать сцену из-за большого числа вызовов. Для BlenderMCP полезнее записывать минимум две величины: время до первого вызова и полное время до приемлемого результата.

Почему GLM 5.3 для 3D задач упирается в точность промпта

Что происходит с расплывчатым запросом

В описании кейса расплывчатые запросы приводили к произвольным решениям по масштабу, высотам, пропорциям и составу сцены. Модель могла формально выполнить просьбу о создании интерьера, но результат быстро уходил в абстрактную 3D-структуру, которую трудно использовать дальше.

Причина связана с природой команды. BlenderMCP получает конкретную операцию: создать куб, назначить материал, переместить объект, задать размеры или изменить камеру. Слова «просторная комната», «уютный диван» и «гармоничное освещение» не задают координаты, размеры и критерий готовности.

Такой результат нельзя автоматически считать недостатком GLM 5.3. При одинаково расплывчатом запросе разные модели могут выбрать разные масштабы и порядок действий. Для вывода о качестве нужна проверка нескольких запусков с одинаковыми условиями.

Промпт с размерами, высотами и материалами

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

• Единицы: метры или сантиметры, без смешивания систем.
• Габариты: ширина, глубина и высота каждого обязательного объекта.
• Высоты: уровень пола, потолка, подоконника, сиденья и светильников.
• Координаты: начало отсчета, оси и положение объектов относительно стен.
• Материалы: назначение материала конкретному объекту, а не общее пожелание по стилю.
• Допуск: например, отклонение размеров не больше 1-2 см для контрольной сцены.
• Порядок: сначала помещение, затем проемы, мебель, материалы, свет и камера.
• Проверка: список объектов, размеры и материалы в финальном ответе.

Каждый пункт должен допускать ответ «выполнено» или «не выполнено». Формулировка «сделай красивую комнату» подходит для творческого эксперимента. Для сравнения моделей нужен набор численных условий.

Итеративное исправление сцены

Рабочий цикл с BlenderMCP состоит из проверки, точного сообщения об отклонении и повторной проверки. Вместо фразы «исправь комнату» лучше написать: «стена северной стороны имеет длину 5.6 м вместо 6 м, замени ее на объект длиной 6 м и сохрани остальные размеры».

Полезно исправлять одну группу ошибок за шаг:

1. проверить наличие всех обязательных объектов;
2. исправить размеры помещения и стен;
3. исправить координаты мебели и проемов;
4. проверить материалы;
5. настроить свет и камеру;
6. получить финальный отчет с параметрами объектов.

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

Сравнение GLM 5.3 Flash и GLM 5.3 в BlenderMCP

Скорость старта и время до первого действия

Для ответа на вопрос о скорости нужно разделить три события: завершение загрузки весов, первый содержательный ответ и первый вызов BlenderMCP. Эти интервалы могут заметно отличаться.

В переданных материалах нет значений ни для GLM 5.3 Flash, ни для GLM 5.3. Поэтому нельзя утверждать, что Flash быстрее начала работу или что базовая модель дольше планировала интерьер. Название облегченной версии само по себе не заменяет замер.

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

Точность геометрии и соблюдение ограничений

Доступное описание фиксирует зависимость результата от промпта, но не дает раздельного протокола для двух моделей. Поэтому по нему нельзя определить победителя по геометрии.

Проверять нужно конкретные признаки:

• созданы ли все обязательные объекты;
• совпадает ли размер помещения с заданными 6 x 4 м в контрольном примере;
• соблюдены ли высота потолка 2.8 м и толщина стен 0.2 м;
• находятся ли дверь, окно, диван и стол в заданных зонах;
• назначены ли материалы нужным объектам;
• сохранилась ли сцена после повторного вызова инструмента.

Визуальная оценка полезна для света, композиции и общего вида. Она не заменяет измерение габаритов. Сцена может выглядеть убедительно на рендере и при этом содержать неверный масштаб или пересекающиеся объекты.

Токены, ошибки и цена итераций

Число токенов в кейсе не зафиксировано. Нет и данных о количестве неудачных вызовов BlenderMCP, повторных запросов или сообщений с исправлениями. Расход GLM 5.3 Flash и GLM 5.3 сравнить нельзя.

При сборе статистики нужно отдельно записывать входные и выходные токены. Во вход могут входить системная инструкция, история диалога, описания инструментов и ответы Blender. В выход попадают рассуждение, код, параметры вызова и текстовый отчет. Если рантайм считает токены собственным токенизатором, это нужно указать в методике.

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

Итоговая таблица наблюдений

Критерий	GLM 5.3 Flash	GLM 5.3	Надежность вывода
Время загрузки	Не зафиксировано	Не зафиксировано	Сравнение отсутствует
Время до первого вызова BlenderMCP	Не зафиксировано	Не зафиксировано	Сравнение отсутствует
Полное время сценария	Не зафиксировано	Не зафиксировано	Сравнение отсутствует
Соблюдение размеров	Отдельное значение отсутствует	Отдельное значение отсутствует	Нет раздельного протокола
Материалы и состав сцены	Отдельное значение отсутствует	Отдельное значение отсутствует	Нет раздельного протокола
Число итераций	Не зафиксировано	Не зафиксировано	Сравнение отсутствует
Токены	Не зафиксированы	Не зафиксированы	Нужны логи рантайма
Чувствительность к промпту	Общий вывод по сценарию, без раздельной оценки	Общий вывод по сценарию, без раздельной оценки	Качественное наблюдение

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

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

Почему RTX PRO 6000 WS не означает отсутствие ограничений

Размеры весов GLM 5.3 и ее вариантов могут предъявлять высокие требования к памяти. Точные объемы для использованных файлов в переданных материалах отсутствуют, поэтому приводить конкретные значения VRAM или требования к системе нельзя.

Потребление памяти складывается из нескольких частей:

• веса модели;
• буферы рантайма и рабочая память GPU;
• KV cache, который растет вместе с контекстом;
• память Blender и создаваемой сцены;
• дополнительная память для инструментов, графики и фоновых процессов.

Квантизация уменьшает размер весов, но может менять качество и скорость. Offload на CPU снижает давление на VRAM, зато добавляет обмен данными и способен увеличить задержку. Контекст на 1 миллион токенов нельзя считать доступным режимом для любой локальной сборки: нужны конкретный файл весов, совместимый сервер и достаточный запас памяти.

При выборе конфигурации полезно сравнивать не одно название GPU, а связку из веса модели, формата, квантизации и длины контекста. Методика из сравнения локальных сборок GLM-5.3-Flash помогает разделять влияние VRAM, квантования и контекста на итоговую скорость и качество ответов.

Минимальный протокол сравнения своими руками

Если хочется получить собственные данные, а не пересказывать чужие, нужен повторяемый мини-протокол. Достаточно восьми шагов, чтобы провести честное сравнение Flash и базовой GLM 5.3.

1. Зафиксировать стенд: GPU, VRAM, CPU, RAM, ОС, драйвер, версия Blender и версия BlenderMCP.
2. Записать спецификацию каждой сборки: имя файла весов, источник, формат, квантизация, рантайм, число GPU и offload-раскладка.
3. Подготовить чистый .blend-файл без объектов, камер и материалов.
4. Взять одно и то же ТЗ на интерьер для обеих моделей, включая единицы, габариты, координаты и материалы.
5. Установить одинаковые системный промпт, лимит контекста, параметры генерации, число попыток и правило ручного вмешательства.
6. Для каждой модели сделать не менее трёх прогонов с очисткой сцены и прогревом сервера в одинаковом режиме.
7. Для каждого прогона заполнить лог: время загрузки, время первого ответа, время первого вызова, полное время, число вызовов, ошибки, входные и выходные токены, фактические габариты и материалы.
8. Свести все строки в одну таблицу и только после этого сравнивать модели — сначала по геометрии, затем по скорости и стоимости итераций.

Поля для лога удобно держать в одной csv-таблице: model, build, quant, runtime, run_id, load_time_s, first_answer_s, first_tool_call_s, total_time_s, tool_calls, errors, tokens_in, tokens_out, geometry_ok, materials_ok. Без такой таблицы спор «Flash против базовой GLM 5.3» останется спором о впечатлениях.

FAQ: GLM 5.3 Flash, GLM 5.3 и BlenderMCP

Можно ли запустить GLM 5.3 локально на RTX PRO 6000 WS?

Технически RTX PRO 6000 WS — мощная карта, но одного её имени недостаточно для ответа. Всё зависит от размера весов, формата, уровня квантизации и длины контекста. Перед запуском проверьте актуальный статус весов GLM-5.3 / Flash, точное имя файла и совместимость с вашим рантаймом. Часть нагрузки может уйти на CPU через offload, но это увеличит задержку.

Чем Flash отличается от базовой GLM 5.3?

Суффикс Flash обычно означает облегчённый вариант: меньше требования к памяти и быстрее инференс за счёт части качества. Для конкретной GLM-5.3 Flash заявленные отличия описывает разработчик; независимых замеров в BlenderMCP-сценариях в доступных материалах нет.

Какие метрики нужны для сравнения в BlenderMCP?

Минимальный набор: время загрузки весов, время до первого содержательного ответа, время до первого вызова BlenderMCP, полное время до выполнения всех условий ТЗ, количество вызовов инструментов, число и типы ошибок, входные и выходные токены, а также фактические габариты и координаты объектов. Визуальная оценка — отдельно.

Почему нельзя просто назвать победителя?

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

Что можно проверить уже сейчас?

Зависимость качества сцены от точности промпта — самый устойчивый вывод из этого кейса. Он воспроизводится независимо от выбора модели: чем конкретнее ТЗ (единицы, габариты, координаты, материалы, критерий готовности), тем управляемее результат в Blender.

Итог

Связка GLM 5.3 Flash и GLM 5.3 с BlenderMCP на RTX PRO 6000 WS — это рабочий сценарий, а не готовый бенчмарк. Что подтверждается: качество интерьера определяется точностью ТЗ и способностью модели держать численные ограничения в длинной цепочке вызовов. Что не подтверждается: конкретное преимущество одной модели над другой по скорости, геометрии и токенам. Пока нет раздельных логов, честная позиция — не выбирать победителя, а собрать собственные замеры по протоколу выше.

Подписаться на канал