GigaChat 3.5 Reasoning можно проверить в компании как открытую модель на собственном инференсе, если задачи и данные разрешены для такого запуска. План будущего пилота связывает конкретную версию весов с требованиями к серверу и эталоном ошибок. Результаты публичных испытаний помогают выбрать задания, но решение о рабочем применении зависит от проверки ответов специалистом.
Открытая модель
Сбер опубликовал веса GigaChat 3.5 Reasoning для собственного инференса: репозиторий FP8 предназначен для запуска, отдельный BF16 — для дообучения и собственной квантизации. Для компании маршрут начинается с проверки вычислительного контура и разрешённых задач.
Согласно техническому разбору Сбера, модель обучена рассуждать над задачами с несколькими шагами. Открытая публикация весов даёт инженерам возможность развернуть инференс в своём контуре и проверить поведение на собственном наборе заданий. Пригодность для конкретной задачи устанавливают отдельной проверкой. Для такого вывода понадобятся воспроизводимый запуск, эталон ответов и разбор ошибок.
В карточке модели указан репозиторий ai-sage/GigaChat3.5-432B-A28B-Reasoning для инференса в FP8. Там же приведены пример запуска на SGLang, отдельная ветка поддержки vLLM и описание парсеров для рассуждения и вызовов функций. В примере Сбера для FP8 указаны восемь H100; пригодность своего сервера проверяют отдельно. До загрузки весов инженер сверяет лицензию, версию файлов, зависимости и доступный объём памяти.
Коммерческий маршрут GigaChat 3 Ultra через API относится к другой линейке и другому порядку доступа. По документации на 07.10.2026 Ultra доступна через Freemium физлицам; корпоративный доступ к ней в плане пилота отсутствует. Разбор API для приложений есть в материале про интеграцию GigaChat, а обозначения Lite, Pro и Max поясняет гид по версиям. Здесь предмет проверки — опубликованные веса Reasoning.
Границы задачи
Сначала владелец процесса выбирает разрешённую многошаговую задачу с наблюдаемым конечным результатом. Подойдут, например, разбор требований к изменению кода, план ответа на составной вопрос по утверждённым документам или поиск противоречий в обезличенном отчёте. Входные материалы проходят внутреннюю проверку на допустимость использования. Тексты с секретами, персональными данными либо закрытыми условиями допускаются в набор только после разрешения ответственного лица.
Для каждого задания редактор набора фиксирует исходные материалы, ожидаемый результат, допустимые варианты ответа и типичные ловушки. У составного вопроса важно обозначить, где требуется ссылка на источник, где допустима гипотеза, а где правильный ответ звучит как запрос уточнения. Иначе оценка красивого объяснения подменит оценку фактической точности. Расчёты по полной выгрузке выполняет парсер или скрипт; языковая модель объясняет полученные значения и предлагает гипотезы, а специалист сверяет их с первичными записями.
| Рабочая задача | Эталон | Ошибка для разбора |
|---|---|---|
| Составной вопрос по регламентам | Цитируемые фрагменты и вывод владельца документа | Ответ с верным тоном и ложной ссылкой |
| Правка небольшого фрагмента кода | Тесты, требования и просмотр инженера | Прошедший тесты патч с нарушением требования |
| Анализ обезличенного отчёта | Расчёт скрипта и согласованные определения полей | Убедительный вывод из неверной формулы |
Эталон задаёт критерий решения о пилоте и защищает оценку от впечатления. Тестовый набор разделяют на задания для настройки сценария и закрытую проверочную часть. Ответы сохраняют рядом с версией весов и параметрами запуска, чтобы позднее различать ошибку модели, ошибку источника и дефект обвязки. Материал о тестировании ИИ-агентов помогает оформить журнал спорных случаев даже при проверке отдельной модели.
Контур инференса
После отбора данных инженер готовит изолированный контур запуска. Карточка открытых весов приводит рабочие примеры для SGLang и vLLM с поддержкой архитектуры GigaChat 3.5. Поэтому сначала проверяют именно совместимую ревизию движка и репозитория модели. Команда из старого руководства способна запустить модель с иным парсером либо выдать неполный ответ. Версию весов, хеш загруженных файлов, ревизию движка и параметры генерации вносят в карточку эксперимента.
- Инженер сверяет доступ к весам и условия лицензии в карточке модели; ответственный за данные подтверждает допустимость тестового набора.
- Команда оценивает память ускорителей по выбранному формату весов и проверяет совместимость запуска с актуальной инструкцией автора модели.
- Оператор поднимает локальный endpoint внутри разрешённой сети, записывает конфигурацию и проверяет разделение итогового ответа и поля рассуждения.
- Скрипт прогоняет зафиксированные задания, сохраняет ответы, ошибки и служебные сведения без публикации входных материалов.
- Владелец задачи открывает журнал исключений и передаёт спорные ответы профильному специалисту для сверки с эталоном.
Поля рассуждения полезны для диагностики; правильность вывода подтверждает сверка. В прикладном интерфейсе показывают только данные, которые действительно нужны сотруднику; доступ к диагностическим записям задают отдельно. Вызов функций из демонстрационного запроса также остаётся тестом совместимости: права пользователя, допустимость действия и подтверждение записи проверяет сервер. Сервер проверяет права и подтверждения отдельно от промпта.
Инфраструктурный обзор запуска моделей через vLLM пригодится для разговора об эксплуатации. Для этой модели точные параметры запуска берут из её карточки: поддержка специального парсера и выбранная ревизия движка должны совпасть. Дополнительные ограничения на сеть, хранение логов и доступ к endpoint команда записывает в проект пилота до подачи рабочих материалов.
Карта ошибок
Проверку проводят по заранее согласованной карте ошибок. Для каждого ответа фиксируют исходное задание, ожидаемое действие, фактический результат и причину расхождения. Отдельно помечают потерю ограничения, неверную ссылку, сбой формата, ошибку вычисления и попытку выполнить лишнее действие. Оценка по общему впечатлению скрывает важные различия: связный текст может сопровождаться ошибочной датой, а осторожный запрос уточнения может быть верным рабочим ответом.
При задачах с кодом тесты помогают обнаружить часть дефектов, однако инженер просматривает изменение по требованиям и разрешениям репозитория. При документах специалист сверяет цитату с исходным документом и проверяет актуальность редакции.
Для содержательных ответов заранее задают шкалу: принят без правки, принят после исправления, возвращён на уточнение либо отклонён. Разбор ведут по видам задач и тяжести последствий. Сравнение с текущим рабочим способом имеет смысл только на одном наборе входных материалов и по одинаковому эталону. Публичные бенчмарки Сбера описывают испытания с конкретными настройками; для компании это гипотезы, требующие отдельной проверки.
Когда журнал покажет виды ошибок, станет ясно, какой сценарий имеет смысл готовить к ограниченному применению. Проект такого контура и критерии приёмки можно обсудить на странице внедрения ИИ для компании. Стоимость работы зависит от доступа к данным, инфраструктуры, числа проверок и участия профильных специалистов; состав работ обсуждается по вашей задаче.
Хотите сверить эталон ошибок для своей задачи?
Решение о пилоте
Решение о пилоте принимают после просмотра тестового журнала и требований к эксплуатации. Если ошибки сосредоточены в форматировании ответа, команда уточняет схему вывода и повторяет проверку на закрытой части набора. Если модель путает источники либо теряет условия задачи, сначала разбирают качество входных материалов и саму постановку. При ошибках с высокими последствиями сценарий остаётся в режиме подготовки ответа для человека либо выходит из плана внедрения.
Проект пилота описывает границу доступа: какие сотрудники подают задания, кто утверждает входные материалы, кто может просматривать журнал и кто принимает окончательный результат. Отдельно оформляют возможность остановить endpoint и восстановить прежний рабочий порядок. Так команда получает проверяемое основание для дальнейшего решения. Для работы с данными компании полезна схема архитектуры и доступов.
Смету будущего проекта читают по составу задач: подготовка разрешённого корпуса, настройка инференса, проверка ответа специалистом, хранение логов, обслуживание оборудования и пересмотр тестов при изменении процесса. Оценку собственного запуска открытых весов строят отдельно от тарифов коммерческого API GigaChat. Для FP8 и BF16 различаются назначение файлов и требования к ресурсам; инженер выбирает формат под конкретную работу после проверки карточки модели.
Возьмите одну разрешённую составную задачу с известным эталоном и согласуйте список критичных ошибок до запуска весов. При таком старте решение о пилоте опирается на журнал ответов; удачный демонстрационный запрос служит лишь иллюстрацией.
При положительном решении следующий документ фиксирует область применения, владельца результата, порядок проверки человеком и признаки остановки. При отрицательном решении журнал тоже полезен: он показывает, какая часть задачи требует скрипта, более ясного источника или ручного решения. Напишите нам, подготовим смету под вашу задачу после обсуждения данных и требований к безопасности.