Техзадание на локальную LLM: пять противоречий, которые мы находим почти в каждом ТЗ
Требования к формату весов, времени ответа, бюджету, масштабу и срокам аттестации по отдельности разумны, а вместе часто невыполнимы. Разбираем пять связок из техзаданий этого года и формулировки, при которых проект остаётся реализуемым.
Коротко
Большая часть проблем локальных LLM-проектов, которые мы видим на пресейле, заложена ещё в техзадании. Требования по отдельности разумны: модель без потерь качества, быстрый ответ, фиксированный бюджет, работа на весь штат, аттестация к сроку. Вместе они часто физически невыполнимы, и выясняется это после публикации закупки, когда исправление стоит месяцев.
Ниже пять таких связок и формулировки, которые их разводят.
Главное: в ТЗ стоит задавать проверяемый результат — качество на своём тестовом наборе и время ответа под заданной нагрузкой — и разбивать проект на этапы со своими сроками. Решения о реализации лучше оставить исполнителю и потребовать доказать их на приёмке.
По состоянию на 28 сентября 2026 года. Нормы о закупках приведены в редакциях 44-ФЗ и 223-ФЗ на эту дату.
Сводный портрет техзадания этого года. В разделе о модели — «запуск в BF16 без квантования». В спецификации — сервер на один-два ускорителя. В требованиях к нагрузке — «все сотрудники организации». В сроках — квартал, включая аттестацию. В начальной цене — сумма, утверждённая год назад. Каждую строку писал разумный человек, но вместе они не сходятся.
Техническое задание на внедрение LLM обычно пишут несколько человек. Конфигурацию оборудования готовит ИТ-архитектор, раздел о защите информации — служба ИБ, сумму — финансовая служба по лимиту, утверждённому задолго до ТЗ, требования к скорости и числу пользователей — владелец процесса. Сводить их друг с другом обычно некому, а у интегратора, который мог бы это сделать, до публикации закупки роли в проекте нет.
Поэтому противоречия, о которых пойдёт речь, трудно назвать ошибками конкретных авторов. Это стыки между разделами, за которые никто не отвечает. Мы взяли те, что повторяются от техзадания к техзаданию, и для каждого предлагаем формулировку, которую можно выполнить и проверить. Если модель ещё не выбрана, начать лучше со сравнения отечественных LLM — здесь речь уже о том, как записать требования к ней в ТЗ на языковую модель.
Почему разводить требования нужно до публикации
Пока ТЗ остаётся внутренним документом, правка стоит одного совещания. После публикации поле для манёвра сужается. По 44-ФЗ изменения в извещение вносятся не позднее чем за рабочий день до окончания подачи заявок, срок подачи при этом продлевается так, чтобы после изменений оставался установленный законом минимум, а наименование объекта закупки менять нельзя. По 223-ФЗ после изменений до окончания подачи заявок должно оставаться не меньше половины срока, установленного положением о закупке.
Формально поправить можно многое. На практике, если противоречие затрагивает суть, например класс оборудования или сумму, закупку чаще отменяют и объявляют заново, а с ней заново проходят внутренние согласования.
Хуже, когда противоречие находят только на приёмке: исполнитель поставил ровно то, что записано, а записанное не даёт нужного результата. Как распределять такие риски между заказчиком и исполнителем, мы разбирали в материале об ответственности за ошибку ИИ.
Разрядность и ускоритель
В одном разделе ТЗ записано «запуск модели в BF16 без квантования», в другом — конкретное число ускорителей и требование обслуживать заданное число одновременных пользователей с определённой скоростью генерации. Логика понятна: заказчик опасается заплатить за модель и получить её урезанную версию.
Упирается всё в память. BF16 занимает два байта на параметр, FP8 — один. На тех же картах модель в BF16 оставляет под KV-кэш заметно меньше места, а значит, меньше одновременных сессий и короче допустимый контекст. Страдает и скорость: на каждом шаге генерации движок читает веса из памяти ускорителя, поэтому при прочих равных вдвое больший объём весов даёт ощутимо меньше токенов в секунду. Бывает, что модель в BF16 на заданное число карт не помещается вовсе — как это посчитать, мы показали в расчёте видеопамяти.
К тому же «без квантования» не всегда означает то, что под этим подразумевают. У части актуальных открытых моделей родной формат — FP8: в нём они обучались, и в нём разработчики рекомендуют их запускать. BF16-версия такой модели нужна прежде всего для дообучения. Для моделей, выпущенных в BF16, переход на FP8 обычно даёт небольшие потери, но проверять их нужно на своих задачах, и именно проверку стоит записать в ТЗ.
Как часто пишут: «Модель должна работать в формате BF16 без квантования».
Как переписать: «Доля правильных ответов — не ниже P% на тестовом наборе заказчика из N вопросов с эталонными ответами. Скорость генерации — не менее X токенов в секунду на сессию при K одновременных сессиях. Формат весов определяет исполнитель. При использовании формата с пониженной разрядностью исполнитель на приёмке подтверждает, что качество на тестовом наборе не ниже порога».
Числа P, N, X и K заказчик подставляет свои. Спорить о них по существу проще, чем о разрядности: они описывают то, что нужно пользователям.
Время ответа и длина цепочки
В нескольких ТЗ этого года рядом стоят два требования. Система должна работать как агент: искать в документах, обращаться к СЭД и справочникам. И она же должна отвечать не дольше заданного числа секунд. Второе обычно переносят из опыта с чат-ботом, где вопрос равен одному вызову модели.
В агентном сценарии один ответ пользователю складывается из цепочки шагов. Поиск по индексу, вызов модели, которая решает, что делать дальше, обращение к внешней системе, второй вызов модели с полученными данными, генерация итогового ответа. Шаги идут последовательно, потому что каждый зависит от результата предыдущего, и их время суммируется.
В одном из техзаданий этого года противоречие удалось поймать только при расчёте коммерческого предложения. На пользовательский запрос там приходилось около десятка вызовов модели и несколько сотен выходных токенов, скорость генерации требовалась порядка сотни токенов в секунду, а 95% ответов должны были укладываться примерно в десять секунд. По отдельности всё разумно, и время ответа задано правильно — через перцентиль. Из текста только нельзя было понять, к чему относятся эти сотни токенов: к каждому вызову или ко всему запросу.
Если к каждому, цепочка генерирует несколько тысяч токенов, то есть под минуту одной генерации — ещё до поиска и обращений к учётной системе. Мы проверили и щадящий вариант: вызовов вдвое меньше, промежуточные ответы — по сотне токенов. Выходит около тысячи токенов и порядка десяти секунд только на генерацию, то есть весь лимит. При такой трактовке требование не выполнил бы ни один участник, сколько бы ускорителей он ни предложил. Дополнительные карты увеличивают прежде всего число параллельных сессий, а скорость одной последовательной цепочки растёт намного слабее.
До расчёта конфигурации мы предложили заказчику развести показатели. Скорость генерации и время до первого токена — для отдельного обращения к модели. Общий лимит времени — для прямых и RAG-запросов. Время многошаговых сценариев — отдельно по их типам, после нагрузочного теста. Время внешних систем исполнитель при этом не контролирует вовсе: СЭД отвечает так, как отвечает, и в конце квартала медленнее обычного. Как число шагов агента превращается в нагрузку на ускорители, мы разбирали в статье об ИИ-агентах в закрытом контуре.
Отдельный вопрос — что считать временем ответа. При потоковой выдаче пользователь видит первые слова задолго до конца генерации, и для него важнее время до первого токена. А «не более стольких-то секунд» без перцентиля означает, что один медленный запрос в пиковый час проваливает испытания целиком.
Как часто пишут: «Время ответа системы — не более 10 секунд».
Как переписать: «Для справочных запросов (поиск и один вызов модели) время до первого токена — не более T1 секунд для 95% запросов при K одновременных сессиях. Для многошаговых сценариев время выполнения — не более T2 секунд для 95% сценариев без учёта времени ответа внешних систем, которое фиксируется в журнале отдельно. Объёмы входных и выходных токенов указываются раздельно для одного обращения к модели и для запроса целиком. Замер проводится на стенде заказчика по методике, согласованной до начала испытаний».
Бюджет и конфигурация
Самое прямолинейное противоречие. В ТЗ задана конкретная конфигурация — число и класс ускорителей, объём памяти, сеть, иногда модель, — а сумма, которую готовы на неё потратить, меньше в разы. В закупке по 44-ФЗ такой разрыв всплыл бы ещё на обосновании начальной цены: предложения поставщиков не уложились бы в лимит. В закупках по 223-ФЗ и в коммерческих закупках начальная цена чаще опирается на внутренний лимит, и разрыв первыми замечают участники.
Обычно сумму и конфигурацию определяют в разное время. Лимит закладывают в бюджет за год, под задачу поменьше или по ценам того момента, а конфигурацию технический специалист пишет позже, по актуальным рекомендациям для выбранной модели. Открытым флагманам на сотни миллиардов параметров нужен сервер на несколько ускорителей, а самым крупным — узел на восемь карт или кластер. Модели среднего класса хватает одной-двух, и разница в стоимости легко становится кратной.
Бывает и проще. Сумму считали только по оборудованию, а в ТЗ, кроме поставки, записаны монтаж, настройка, интеграции, аттестация и год поддержки. Или считали без НДС, который с 1 января 2026 года составляет 22%.
Развести противоречие можно двумя способами, и выбирать между ними нужно до утверждения суммы.
ТЗ описывает результат: сценарии, число одновременных пользователей, качество на тестовом наборе, время ответа. Конфигурацию предлагает исполнитель и обосновывает расчётом, а заказчик сравнивает предложения по тому, что они обеспечивают.
До утверждения бюджета нужна оценка стоимости по коммерческим предложениям нескольких поставщиков, с работами и НДС. Цены на ускорители меняются быстро, поэтому оценку обновляют непосредственно перед расчётом начальной цены.
Зафиксировать и то и другое тоже можно, если одно посчитано из другого. Ориентиры по статьям бюджета собраны в разборе стоимости on-premise LLM.
Пилотный сервер и весь штат
В спецификации — сервер с одним-двумя ускорителями, в требованиях — «обеспечить работу всех сотрудников организации». Оба требования реальны, просто относятся к разным этапам проекта, которые в ТЗ склеились в один.
Рядом обычно живёт путаница с тем, какое число пользователей имеется в виду. Зарегистрированных пользователей всегда больше, чем активных за день, а активных больше, чем тех, кто работает одновременно в пиковый час, и разница между крайними значениями кратная. Для расчёта оборудования нужно последнее число, в ТЗ чаще стоит первое.
Закупить сразу под весь штат соблазнительно, но до пилота неизвестны ни реальная нагрузка, ни то, какая модель нужна. Если пользователи не видят разницы между моделью среднего класса и флагманом, оборудование под флагман на всю организацию будет простаивать. Поэтому проект разбивают на этапы.
Метрики перехода пишутся так же конкретно, как требования к качеству. «По результатам пилота принимается решение о масштабировании» ничего не фиксирует. «Переход ко второму этапу — при доле правильных ответов не ниже P% и при том, что с системой регулярно работает не меньше половины пилотной группы» — уже договорённость, которую можно проверить.
Аттестация внутри общего срока
Этот конфликт возникает там, где система будет обрабатывать информацию, для которой нужна аттестация объекта информатизации. В ТЗ стоит короткий общий срок исполнения, в пределах квартала, и в него же включена аттестация.
По нашим оценкам, разработка документации на объект занимает около восьми недель, сама аттестация — ещё три-пять недель; эти ориентиры мы приводили в разборе 243-ФЗ. Только аттестационный блок — от 11 до 13 недель, почти весь квартал, а в худшем случае весь. Часть документации готовят параллельно с развёртыванием, но испытания проводятся на системе в рабочей конфигурации, то есть после поставки, монтажа и настройки. Добавьте поставку ускорителей — и квартал заканчивается раньше, чем начинаются испытания.
У этой связки есть обратная сторона. Аттестация нужна не каждой системе, и иногда её вписывают в ТЗ по аналогии с соседним проектом. Нужна ли она, определяется категорией обрабатываемой информации и требованиями к конкретной системе. Решают это до ТЗ, вместе со службой ИБ.
Как часто пишут: «Срок выполнения работ — 90 календарных дней с даты заключения контракта, включая аттестацию объекта информатизации».
Как переписать: «Этап 3. Аттестация объекта информатизации. Начинается после подписания акта о завершении этапа 2 (развёртывание). Срок этапа — T3 недель. Исходные данные предоставляет заказчик по перечню из приложения к ТЗ в течение D рабочих дней с начала этапа; при задержке срок этапа продлевается на период задержки. Результат этапа — проведённые аттестационные испытания и решение по их итогам».
Положительный результат аттестации заранее гарантировать нельзя, поэтому обещать его в ТЗ бессмысленно.
Памятка: пять связок в одной таблице
| Противоречие | Как выглядит в ТЗ | Чем грозит | Как переписать |
|---|---|---|---|
| Разрядность и ускоритель | «Запуск в BF16 без квантования» рядом с фиксированным числом карт и требованием к скорости | Модель не помещается или генерирует медленнее требуемого | Требование к качеству на тестовом наборе и к скорости под нагрузкой; формат весов выбирает исполнитель и подтверждает на приёмке |
| Время ответа и цепочка | Агентные сценарии и единый лимит времени ответа для всех запросов | Многошаговые сценарии не проходят приёмку; спор о том, что именно измерять | Раздельные требования для простых и многошаговых запросов, перцентиль, объём токенов отдельно на вызов и на запрос, внешние системы — отдельно |
| Бюджет и конфигурация | Конкретная конфигурация и начальная цена, которая её не покрывает | Закупка без заявок или расхождения, которые всплывают при исполнении | Зафиксировать бюджет и описать результат либо зафиксировать конфигурацию и оценить её до утверждения бюджета |
| Пилот и весь штат | Сервер на один-два ускорителя и «работа всех сотрудников организации» | Система не выдерживает расширения или оборудование простаивает | Пилот на ограниченной группе с метриками перехода, затем расчёт по измеренной нагрузке |
| Аттестация и сроки | Аттестация объекта внутри короткого общего срока исполнения | Срыв срока контракта при добросовестной работе исполнителя | Аттестация — отдельный этап со своим сроком, начинается после развёртывания |
Что ещё обычно выпадает из ТЗ
Эти пункты не противоречат остальным требованиям. Их просто нет, и отсутствие обнаруживается позже всего.
Тестовый набор. Требования к качеству без него непроверяемы. Набор — это вопросы из реальной работы с эталонными ответами и документами-источниками. Собирает его заказчик, потому что только он знает, какой ответ считать правильным. Часть набора разумно держать закрытой до приёмки: если исполнитель видел все вопросы, он настроит систему под них, и приёмка покажет качество на наборе, а не в работе. У набора покрытие важнее размера: в нём нужны типовые вопросы, трудные, где ответ требует нескольких документов, и такие, на которые правильный ответ — «в документах этого нет».
Порядок обновления модели. За срок поддержки по контракту у выбранной модели почти наверняка выйдет новая версия: DeepSeek, например, выпустила V4.1 Flash через шесть недель после финальных весов V4 Flash. Кто решает о переходе, на каком наборе проверяется новая версия, кто повторяет приёмку — эти вопросы лучше закрыть в ТЗ. Для аттестованного сегмента смена версии модели — ещё и изменение программной среды, которое может потребовать повторной оценки. Поэтому версию разумно сделать объектом приёмки.
Права на данные дообучения. Если ТЗ предусматривает дообучение, в нём должно быть сказано, кому принадлежат подготовленные наборы данных и полученные веса или адаптеры, может ли исполнитель использовать их в других проектах и что с ними происходит после окончания контракта. Без этих строк права определяются по умолчанию, и не обязательно в пользу заказчика.
И одно противоречие, которое в пятёрку не вошло. В разделе ИБ требуется сертифицированная операционная система и оборудование из реестра, в техническом — актуальные версии движков для запуска модели. Вместе нужна проверка, что драйверы ускорителей и выбранная версия движка работают на этой ОС. В ТЗ стоит прямо указать, кто отвечает за совместимость и как она подтверждается до поставки.
Что дальше
Порядок действий до публикации закупки. На что смотреть, когда ТЗ готово и выбирается исполнитель, мы разбирали в материале о выборе ИИ-подрядчика.
Частые вопросы
Что обязательно указать в ТЗ на локальную LLM?
Сценарии и пиковое число одновременных пользователей, качество на тестовом наборе заказчика, скорость под заданной нагрузкой с методикой замера, требования к защите информации и этапы с критериями приёмки. Если предусмотрено дообучение — ещё порядок обновления модели и права на результаты дообучения.
Нужно ли указывать конкретную модель в ТЗ?
Обычно надёжнее описать требования к модели: язык, длину контекста, лицензию, возможность развёртывания в контуре заказчика, при необходимости — статус по 243-ФЗ. Конкретную модель предлагает исполнитель, и она проверяется на тестовом наборе. В закупках по 44-ФЗ указание конкретного продукта к тому же ограничено правилами описания объекта закупки.
Как задать требования к скорости ответа?
Раздельно для простых запросов и для многошаговых сценариев, через перцентиль — например, для 95% запросов — и при заданном числе одновременных сессий. Объёмы токенов указывают отдельно для одного обращения к модели и для запроса целиком. Время ответа внешних систем фиксируют в журнале отдельно.
Можно ли совместить пилот и промышленную эксплуатацию в одной закупке?
Этапы в одном контракте предусмотреть можно, но тогда объём второго этапа фиксируется до того, как пилот покажет реальную нагрузку, а возможности изменить объём по заключённому контракту ограничены. Чаще практичнее провести пилот отдельной закупкой с метриками перехода, а масштабирование — следующей, по его результатам.
Когда закладывать аттестацию объекта информатизации?
В план проекта — с самого начала, потому что от неё зависят архитектура и состав средств защиты. В ТЗ — отдельным этапом со своим сроком, который начинается после развёртывания. По нашим оценкам, разработка документации занимает около восьми недель, аттестация — ещё три-пять недель.
Нужно ли требовать запуск модели в BF16, чтобы не потерять качество?
Надёжнее требовать само качество: порог на тестовом наборе заказчика. У части актуальных открытых моделей родной формат — FP8, и BF16-версия нужна им прежде всего для дообучения.
Шаблон ТЗ на локальную LLM
PDF, 15 страниц для ИТ, ИБ, закупок и владельца процесса. Двенадцать разделов техзадания с готовыми формулировками и полями, таблица нагрузки, этапы пилота и аттестации, самопроверка из пятнадцати вопросов перед публикацией закупки.
Проверим ваше ТЗ до публикации закупки
AZONE-AI может посмотреть техзадание до публикации: сверить конфигурацию с нагрузкой и бюджетом, требования к скорости с устройством сценариев, сроки с аттестационным блоком и предложить формулировки, которые проверяются на приёмке. Если проект только начинается, поможем спланировать пилот с метриками перехода.