Параметры LLM: как понимать размер модели и настраивать ответы

Параметры LLM — это и обученные веса модели, и настройки, с которыми приложение запрашивает ответ. У большой языковой модели (LLM) размера 70B примерно 70 миллиардов обученных параметров. Если установить temperature на 0.2 в API, который поддерживает эту настройку, изменится способ выбора токенов для ответа, а число весов останется прежним. Поэтому сначала нужно выбрать модель под задачу, а затем настроить только те параметры генерации, которые поддерживает конкретная версия её API.

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

Параметры LLM: веса модели и настройки запроса

Параметры модели — часть обученной нейросети. Параметры генерации — часть запроса к ней. Изменение настроек запроса не переобучает модель.

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

Что понимают под параметрами LLM?

Когда речь идёт о размере модели, параметры — это выученные при обучении числовые значения, прежде всего веса, от которых зависят вычисления внутри нейросети. Во время обучения эти значения корректируются на основе данных. В контексте API «параметрами» также называют настройки, влияющие на генерацию ответа. В объяснении IBM обученные значения отделены от внешних настроек.

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

Что представляет собой отдельный параметр модели?

Отдельный обученный параметр — это число, которое используется внутри нейросети. Например, вес определяет, насколько сильно один внутренний сигнал влияет на другой. Параметр нельзя представить как аккуратно подписанный факт, документ или слово в отдельной ячейке памяти.

Есть и ещё одна категория — гиперпараметры обучения. Это настройки вроде скорости обучения, которые определяют ход самого процесса. Бизнес-приложение, обращающееся к готовой модели, обычно не управляет ни гиперпараметрами обучения, ни обученными весами.

Токены — отдельное понятие. Это единицы, на которые разбиваются входной текст и ответ; часто они представляют собой части слов. Больше токенов в промпте не означает больше параметров у модели. В руководстве по токенам в ИИ разобрана эта единица текста, а в руководстве по системным промптам — то, как инструкции направляют поведение модели, не меняя её весов.

Часть первая: что число параметров говорит о масштабе модели

Число параметров помогает оценить объём хранения и вычислений, но само по себе не позволяет выбрать лучшую модель для бизнес-задачи. С него удобно начинать планирование инфраструктуры. Решение же нужно принимать по результатам проверки на конкретной задаче.

Что означают миллиарды параметров LLM?

Буква «B» обозначает миллиард обученных значений. У модели 70B примерно 70 миллиардов параметров; «T» означает триллион. Числа в названиях могут быть округлены, поэтому для точной оценки ресурсов нужны конкретный чекпойнт и формат хранения его весов.

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

Для заказчика полезнее другой вопрос: выполняет ли модель критерии приёмки? Правильно ли извлекает итоговую сумму счёта, сохраняет ли идентификатор клиента, выдаёт ли патч, который проходит нужные проверки? Большее число параметров на эти вопросы не отвечает.

Сколько памяти занимают веса модели 70B: расчёт

Объём хранения самих весов равен числу параметров, умноженному на число байтов на параметр. Для условной модели ровно с 70 миллиардами весов расчёт выглядит так. Это арифметика, а не результат измерения работающей системы.

Здесь используются десятичные гигабайты. Объём 140 GB — это примерно 130.4 GiB в двоичных единицах, которые показывают некоторые инструменты мониторинга памяти. При пересчёте меняется единица измерения, а не модель.

В документации Hugging Face объясняется, как квантование — хранение весов с меньшей точностью — сокращает требования к памяти при попытке сохранить точность модели. Форматы и компромиссы разобраны в нашем руководстве по квантованию LLM.

Длинные промпты и одновременные запросы тоже меняют нагрузку при обслуживании модели. В документации оценщика памяти Hugging Face загрузка модели прямо отделена от инференса — процесса генерации ответов.

Как число параметров связано со стоимостью и качеством

При прочих равных больше весов обычно означает больше ресурсов на хранение и работу модели. Но оговорка «при прочих равных» существенна: на результат влияют точность, архитектура, оборудование, объединение запросов в пакеты и объём обрабатываемого текста.

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

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

Общее число и активные параметры в моделях MoE

Общее число параметров описывает всю модель, а число активных — заявленный объём параметров, задействованных при обработке токена. Для архитектуры «смесь экспертов» (mixture-of-experts, MoE) важны оба показателя.

Модель MoE содержит экспертные подсети и маршрутизатор, который выбирает, какие из них обработают очередной токен. «Эксперты» здесь — математические компоненты, а не специалисты, которым можно поручить бухгалтерию или юридическую работу. Активация меньшего подмножества параметров может сократить вычисления по сравнению с использованием всей модели, но остальные веса всё равно должны где-то храниться. В объяснении MoE от PyTorch разобраны маршрутизация и необходимый для неё обмен данными.

У формулировки «104B активных параметров» есть конкретный пример, опубликованный разработчиком: в анонсе Kimi K3.1 Pro компания Moonshot AI указывает 2.8T параметров всего и 104B активных. Если выразить общее число как 2,800B, получим 104 ÷ 2,800 — примерно 3.7% активных параметров. Этот процент — наш расчёт по заявленным значениям, а не измерение ускорения и не оценка качества.

Другой пример — карточка модели Qwen3-235B-A22B от Qwen: в ней указаны 235B параметров всего и 22B активируемых. На иллюстрации неактивные помещения остаются видимыми: необходимость хранить их не исчезает, когда конкретный токен идёт по другому маршруту.

Перед развёртыванием выясните, как хранится и распределяется вся модель, как эксперты размещаются на оборудовании и какой будет производительность при вашем реальном числе одновременных запросов. Число активных параметров не определяет требования к памяти графического процессора (GPU). Эта инфраструктурная сторона подробнее разобрана в статье об архитектуре «смесь экспертов».

Часть вторая: как параметры генерации управляют ответом

Настройки генерации определяют выбор токенов и остановку ответа в пределах возможностей модели. API — это интерфейс, через который приложение запрашивает ответ. Его настройки не могут восполнить недостающие исходные данные, устранить неоднозначность инструкции или гарантировать правильный результат.

Temperature: насколько вероятные варианты получают преимущество

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

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

Даже запрос с нулевой температурой не гарантирует воспроизводимость во всех случаях. В глоссарии Anthropic прямо сказано: при нулевой температуре одинаковые входные данные всё равно могут давать разные результаты. Воспроизводимость нужно оценивать для всей системы обслуживания модели.

Top-p: какие кандидаты остаются доступны

Top-p, или nucleus sampling, ограничивает набор кандидатов по их суммарной вероятности. Это порог вероятности, а не число кандидатов и не доля словаря.

Допустим, вероятности следующих токенов составляют 0.60, 0.25, 0.10 и 0.05. При top-p, равном 0.9, нужны первые три кандидата: сумма вероятностей первых двух — 0.85, а первых трёх — 0.95. Эти числа приведены для объяснения, а не получены из реального ответа модели.

Temperature меняет сами вероятности; top-p отсекает часть доступных кандидатов. При первоначальной настройке для бизнес-задачи меняйте по одному параметру сэмплирования. Тот же подход рекомендует OpenAI в справочнике Chat Completions.

Лимит токенов LLM: верхняя граница, а не заказанная длина

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

Слишком маленький лимит может оборвать JSON-объект, предложение или патч. Большой лимит сам по себе не делает ответ полезным. Укажите желаемую длину в промпте, а под верхней границей оставьте достаточно места для завершённого результата.

Для рассуждающих моделей нужно учитывать ещё одно различие. В справочнике Responses от OpenAI сказано, что лимит выхода включает и видимый ответ, и токены рассуждения. Согласно справочнику Messages от Anthropic, токены размышления тоже входят в max_tokens. Не рассчитывайте бюджет такого запроса так, будто каждый разрешённый токен попадёт в итоговый ответ.

Стоп-последовательности: где завершить генерацию

Стоп-последовательность завершает генерацию при появлении заданной строки. Используйте её только тогда, когда у приложения есть надёжный признак окончания — например, явный маркер, который не может встретиться в самом содержимом.

Перенос строки не годится как универсальный стоп для многострочного отчёта. Закрывающая фигурная скобка не годится для вложенного JSON: первое совпадение может оборвать ответ раньше времени. При извлечении структурированных данных лучше использовать поддерживаемый провайдером механизм задания схемы и проверять возвращённые поля.

Обычно разумно начинать без пользовательских стоп-последовательностей. При этом лимит выходных токенов и проверка результата по-прежнему нужны.

Штрафы за повторения: применять осторожно

Presence penalty учитывает, встречался ли токен раньше. Frequency penalty — как часто он встречался. Положительные значения штрафа подавляют повторное использование, отрицательные могут его поощрять, если эндпоинт поддерживает такие значения.

Повторяющийся текст не всегда означает ошибку. Код товара, имя клиента, ключ JSON или идентификатор в программе может требоваться повторить в точности. Штраф за такой повтор способен помешать задаче.

При извлечении данных и работе с кодом начинайте без штрафов за повторения. Для текстовых черновиков сначала исправьте инструкцию, которая провоцирует однообразную структуру. Только затем пробуйте небольшой поддерживаемый штраф и проверяйте, становится ли текст лучше без изменения обязательных терминов. В справочнике Google по генерации также есть предупреждение: отрицательный frequency penalty может приводить к зацикленному повторению токенов.

Диапазоны и значения по умолчанию в API OpenAI, Anthropic и Google

Допустимые настройки определяются эндпоинтом, моделью и версией API. Одинаковое имя поля в SDK не доказывает, что все провайдеры реализуют один и тот же механизм.

В таблице данные OpenAI относятся к Chat Completions, Anthropic — к Messages API версии 2026-10-21, Google — к Gemini Developer API generateContent. Настройки из Google Vertex AI и Interactions API сюда не переносятся.

NS означает, что в приведённой актуальной документации поля не указан числовой диапазон или значение по умолчанию. Это не означает ноль, отсутствие ограничений или отсутствие поддержки. Совет «не передавать» ниже — рекомендация для приложения, а не придуманное значение по умолчанию у провайдера.

Источники: схема запроса OpenAI, схема запроса Anthropic, переход на новую версию Anthropic API, схема генерации Google, метаданные моделей Google и диапазон top-p у Google.

В общей таблице Google по устранению ошибок указан более узкий диапазон температуры, чем в справочнике поля генерации. Ориентируйтесь на справочник поля вместе с maxTemperature выбранной модели; для значений конкретной модели используйте Model.temperature, Model.topP и Model.outputTokenLimit. Значение из примера запроса нельзя считать документированным значением по умолчанию.

OpenAI: сначала проверьте совместимость с режимом рассуждения

Актуальное руководство OpenAI по GPT-6 предписывает убрать temperature и top_p, если уровень усилий на рассуждение отличается от none. GPT-6 Astra и GPT-6.1 Sol не поддерживают none; GPT-6 Sol и GPT-6 Luna поддерживают. Это ограничение совместимости, а не указание фиксированной числовой температуры.

Эндпоинт тоже имеет значение. В Responses используется max_output_tokens; в актуальной схеме для него установлен минимум 16, но числовое значение по умолчанию и единый максимум не указаны. В схеме создания запроса Responses нет полей Chat Completions stop, presence_penalty и frequency_penalty. В справочнике Chat Completions отдельно отмечено, что o3 и o4-mini не поддерживают stop, а max_tokens объявлен устаревшим в пользу max_completion_tokens.

Практическое правило: сначала сформируйте запрос для выбранного эндпоинта, затем учтите ограничения конкретной модели. Не копируйте всю таблицу в один запрос.

Anthropic: новая версия API может убрать настройку

В руководстве Anthropic по переходу на версию от 21 октября сказано, что передача temperature, top_p или top_k с версией API 2026-10-21 вызывает ошибку 400, даже если передано значение по умолчанию. Без этих полей применяется, в частности, температура 1.0.

Старая версия API не обязательно возвращает свободу настройки любой модели. В документации Anthropic по размышлению сказано, что ряд моделей, включая Claude Sonnet 5.5, отклоняет значения сэмплирования, отличные от значений по умолчанию, независимо от того, включён ли режим размышления. Для этих моделей указан top-p по умолчанию 0.99 и прямо отмечено, что значение 1 отклоняется. Прежний общий диапазон не отменяет ограничение конкретной модели.

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

Google: принятая настройка может ни на что не влиять

В руководстве Google по миграции на Gemini 3.6 Flash и 3.5 Flash-Lite сказано, что эти модели игнорируют устаревшие настройки temperature, top-p и top-k. Разработчикам предписано убрать их; будущие поколения моделей будут отклонять такие запросы с ошибкой 400.

Здесь возникает иной сбой, чем при отклонении запроса: приложение как будто принимает изменение температуры, а модель ведёт себя по-прежнему. Прежде чем считать успешный ответ доказательством работы настройки, проверьте документацию выбранной модели.

С каких настроек начинать в бизнес-задачах

Начните с поведения, которое поддерживает провайдер, и измеримых критериев успеха. Числа ниже — наши отправные точки для эндпоинтов с доступными настройками. Это не значения провайдеров по умолчанию, не измеренные оптимумы и не универсальные наборы настроек. Описанные выше правила совместимости важнее этих рекомендаций.

Извлечение данных: сохранить значения в точности

Для полей счёта, классификации обращений в поддержку или метаданных договоров попробуйте temperature 0 или 0.2, только если настройка поддерживается. Top-p не меняйте. Пользовательские стоп-последовательности и штрафы за повторения не передавайте; для модели в OpenAI Chat Completions, поддерживающей эти штрафы, можно также явно установить оба штрафа на 0, чтобы задать исходный режим без штрафов.

В запросах к актуальному Anthropic API и к упомянутым моделям Gemini Flash параметры сэмплирования нужно убрать. Задайте явные определения полей, допустимые категории, примеры отсутствующих данных и используйте поддерживаемую провайдером функцию структурированного вывода. Проверяйте содержание результата отдельно от его формата.

Для короткой записи с извлечёнными данными можно начать эксперимент с лимита в 1,000 выходных токенов — в совместимом запросе без рассуждения. Это не универсальное ограничение: проверяйте обрезанные ответы и фактический расход, а при наличии рассуждения учитывайте его бюджет отдельно. Просите маркер отсутствующего значения вместо выдуманного номера счёта.

Критерий приёмки: все обязательные поля присутствуют, значения совпадают с источником, отсутствующие сведения не додуманы. Одной проверки корректности JSON недостаточно.

Подготовка текстов: менять формулировки, сохранять факты

Для письма потенциальному клиенту или описания товара начните с поддерживаемого моделью поведения по умолчанию. Если эндпоинт позволяет настраивать генерацию, сравните его с temperature 0.7, оставив top-p без изменений. В промпте укажите аудиторию, длину, тон, обязательные факты и недопустимые утверждения.

На первом этапе не задавайте штрафы. Если поддерживающая их модель OpenAI Chat Completions постоянно повторяет нежелательные фразы, frequency penalty 0.2 — небольшой эксперимент в пределах документированного диапазона. Оставляйте его только в том случае, если проверка показывает улучшение; обязательные названия продуктов должны сохраняться в точности.

У моделей, в которых параметры сэмплирования убраны, прямо просите разные подходы: например, краткий фактологический вариант и вариант с повествовательной подачей. Оценивайте различия по полученным текстам.

Критерий приёмки: полезное разнообразие без новых фактических утверждений. «Неожиданнее» не означает «лучше для бизнес-текста».

Код: дать место для полного ответа и проверить поведение

Для точечного патча в эндпоинте с доступной настройкой temperature 0 или 0.2 — разумная отправная точка для сравнения. У рассуждающей модели соблюдайте поддерживаемую конфигурацию и убирайте неподдерживаемые поля сэмплирования. Не добавляйте штрафы за повторения и пользовательские стоп-последовательности, если они не требуются проверенным протоколом.

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

Критерий приёмки: патч соответствует требованиям и проходит необходимые проверки. Повторяющиеся идентификаторы для кода нормальны, а правдоподобный ответ ещё не доказывает, что код работает.

Чего нельзя обещать по числу параметров и настройкам

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

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

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

Что делать заказчикам, ответственным за эксплуатацию и разработчикам

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

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

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

1. 1

   Соберите примеры задач, которые должны выполняться успешно

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

2. 2

   Явно зафиксируйте конфигурацию запроса

   Запишите эндпоинт, модель и версию API. Проверьте поддержку настроек, уберите лишние и выберите бюджет выходных токенов, достаточный для полного результата. Обязательные термины и правила работы с отсутствующими данными задайте в промпте.

3. 3

   Измените что-то одно и оцените результат

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

Частые вопросы

Как работает параметр temperature в LLM?

Он меняет степень концентрации распределения вероятностей следующего токена. Низкие значения усиливают преимущество вероятных вариантов, высокие допускают больше разнообразия. Меняется сэмплирование, а не обученные веса; некоторые актуальные API отклоняют или игнорируют эту настройку.

Сколько примерно памяти занимает модель 70B?

Для ровно 70 миллиардов весов объём хранения самих весов составляет около 140 GB при 16 битах, 70 GB при 8 битах или идеальные 35 GB при 4 битах. Эти десятичные значения не включают рабочую память и накладные расходы квантования. Реальные требования к развёртыванию определяются конкретным чекпойнтом и нагрузкой.

Какие четыре типа параметров бывают?

Универсальной классификации параметров LLM на четыре типа нет. Для понимания системы полезно различать обученные параметры модели, настройки архитектуры, настройки обучения и настройки генерации. Это смысловые категории, а не утверждение, что у каждого API есть четыре регулятора.

Чем GPT отличается от LLM?

LLM означает «большая языковая модель» — это общая категория. GPT расшифровывается как «генеративный предобученный трансформер» и обозначает конкретное семейство моделей и подход внутри этой категории. Другие семейства языковых моделей тоже относятся к LLM.

Какие четыре типа LLM существуют?

Единого стандартного списка из четырёх типов нет. Разделение на плотные модели и модели со смесью экспертов описывает архитектуру; разделение на модели с открытыми и закрытыми весами — доступность. Эти признаки отвечают на разные вопросы, и объединять их в мнимый рейтинг качества не следует.

ChatGPT — это LLM или ИИ?

ChatGPT — приложение на основе ИИ, которое использует модели. Различайте само приложение, выбранную в нём модель и настройки API, доступные разработчикам: это разные уровни системы.

Какой ИИ не относится к LLM?

ИИ — более широкое понятие, чем языковые модели. Классификатор мошеннических операций или система компьютерного зрения могут использовать методы машинного обучения без LLM. Число параметров тоже характеризует не только языковые модели.

Какая языковая модель ИИ самая умная?

Универсального ответа для любых задач, который можно вывести из числа параметров, нет. Сравнивайте модели на характерных примерах своей работы, с одинаковыми критериями приёмки и зафиксированной конфигурацией. Результат одного бенчмарка не определяет выбор для всех бизнес-задач.

К какой области ИИ относятся LLM?

LLM — модели глубокого обучения для обработки и генерации языка. Обученные параметры принадлежат самой модели, а temperature и похожие настройки запроса определяют, как приложение её использует.

Практические объяснения ИИ-систем и решений, на которых они основаны, — в рассылке: подпишитесь.