Параметры генерации LLM — напоминалка
Play ITЗагрузка интерактивного демо…
После обучения модель на каждом шаге выдаёт распределение вероятностей по словарю токенов. Параметры ниже задают, как из этого распределения выбирать следующий токен и когда остановиться. Они не меняют веса модели — только стратегию декодирования (inference). Теория авторегрессии — в больших языковых моделях; локальный запуск и примеры кода — в локальных моделях и Ollama. В полном LLM-стеке эти настройки относятся к слою 5 — инференс (обзор семи слоёв).
Сводная таблица
| Параметр | За что отвечает | Типичный диапазон |
|---|---|---|
| max_tokens | Верхняя граница длины ответа (число генерируемых токенов) | 256–4096 и выше, по задаче |
| temperature | "Острота" распределения — случайность и креативность | 0–2 (часто 0.1–1.0) |
| top_p | Nucleus sampling — пул токенов с суммарной вероятностью ≥ p | 0–1 (часто 0.9–0.95) |
| top_k | Ограничение пула k самых вероятных токенов | 1 … размер словаря |
| frequency_penalty | Штраф за повторное появление токена (чем чаще в тексте, тем сильнее) | −2 … 2 |
| presence_penalty | Штраф, если токен уже встречался хотя бы раз | −2 … 2 |
| stop | Строки (или токены), при которых генерация обрывается | список по задаче |
Для кода, фактов и RAG обычно хватает низкой temperature (0.1–0.3), умеренного top_p (0.9) и явного max_tokens. Для идей и черновиков температуру поднимают; frequency_penalty / presence_penalty помогают убрать зацикливание на одних словах.
max_tokens
max_tokens — лимит на количество токенов, которые модель дописывает в ответ за один вызов (не путать с размером всего контекста окна).
- Слишком маленькое значение обрежет ответ посередине мысли.
- Слишком большое увеличит время и стоимость API без пользы.
Ориентиры: короткий ответ в чате — 256–512; развёрнутое объяснение или фрагмент кода — 1024–2048; длинный отчёт — по лимиту модели и бюджету.
В OpenAI-совместимых API поле часто называется max_tokens или max_completion_tokens (зависит от версии API и модели).
temperature
temperature масштабирует логиты перед softmax: чем выше значение, тем ровнее распределение и тем чаще выбираются маловероятные токены.
| Значение | Поведение | Когда уместно |
|---|---|---|
| 0–0.3 | Почти детерминированно, опора на самые вероятные варианты | Код, SQL, JSON, ответы по документам (RAG) |
| 0.4–0.7 | Баланс точности и вариативности | Объяснения, перефразирование |
| 0.8–1.0+ | Больше разнообразия, выше риск "ухода" от фактов | Идеи, сторителлинг, мозговой штурм |
При temperature = 0 (или эквиваленте "жёсткого" режима у провайдера) повторные запросы с тем же промптом дают максимально стабильный вывод — но не гарантируют идентичность между версиями модели или сервера.
top_p (nucleus sampling)
top_p отсекает "хвост" маловероятных токенов: в пул попадает минимальное множество самых вероятных токенов, у которых сумма вероятностей ≥ p.
Пример: при top_p = 0.9 модель сначала сортирует кандидатов по убыванию вероятности и набирает их, пока сумма не достигнет 90%; остальные токены в выборку не попадают.
- 0.9–0.95 — распространённый компромисс.
- Значение ближе к 1.0 расширяет пул и добавляет вариативность.
top_p и top_k решают похожую задачу разными способами; в одном запросе обычно задают один из них или комбинируют осторожно — смотрите документацию конкретного API.
top_k
top_k оставляет только k токенов с наибольшей вероятностью на текущем шаге, независимо от их суммарной доли.
top_k = 1близко к жадному выбору (argmax) на шаге.- Большие k смягчают отсечение.
Удобен, когда нужно жёстко ограничить "бредовые" хвосты распределения без подбора top_p под каждую модель.
frequency_penalty и presence_penalty
Оба параметра (в API OpenAI) уменьшают логит токена, который уже встречался в сгенерированной части ответа. Разница в учёте повторов:
| frequency_penalty | presence_penalty | |
|---|---|---|
| Логика | Штраф растёт с числом появлений токена | Штраф один раз, если токен уже был |
| Эффект | Сильнее бьёт по словам вроде "и", "также", "кроме того" при зацикливании | Подталкивает к новым словам и темам |
| Диапазон | обычно −2 … 2 | обычно −2 … 2 |
Положительные значения (например 0.3–0.8) снижают повторы. Отрицательные усиливают склонность к повторению — на практике почти не используют.
В экосистеме llama.cpp / Ollama близкий эффект даёт repeat_penalty (множитель, часто 1.0–1.2), а не отдельные поля frequency/presence — имена полей зависят от сервера.
stop
stop — список строк (иногда отдельных токенов), при появлении которых в потоке генерации модель сразу прекращает вывод.
Типичные случаи:
- обрезать ответ до конца JSON или блока кода;
- запретить модели "дописывать" диалог за пользователя (стоп-последовательности вроде
\nUser:); - остановиться перед служебным маркером в шаблоне промпта.
Стоп-срабатывание зависит от токенизатора: одна и та же фраза в API и в локальной модели может разбиваться на токены по-разному. Почему так — в разделе от текста к числам.
Готовые профили
| Задача | temperature | top_p | max_tokens | Штрафы / прочее |
|---|---|---|---|---|
| Код, рефакторинг | 0.1–0.2 | 0.9 | по размеру патча | stop на закрывающий fence ``` при необходимости |
| RAG / поддержка по базе | 0.1–0.3 | 0.9 | 512–1024 | низкая температура важнее штрафов |
| Черновик текста | 0.7–0.9 | 0.95 | 1024+ | presence 0.3–0.6 при "заезженных" формулировках |
| JSON по схеме | 0–0.2 | 0.9 | с запасом | response_format / валидатор схемы у провайдера |
Пример (OpenAI-совместимый API)
Код ITЗагрузка примера кода…
Тот же набор идей для Ollama / llama.cpp передаётся в теле запроса или аргументах библиотеки (temperature, top_p, num_predict вместо max_tokens, repeat_penalty и т.д.) — см. локальные модели.
Что дальше
- Промпты и проверка кода — Генерация кода — ChatGPT, Gemini и DeepSeek.
- Параметры в коде — OpenAI / API — готовые промпты и вызовы (
temperature,max_tokens, streaming, JSON mode). - Шаблоны system/user — Prompt engineering — библиотека.
- Агенты с tool calls и политики безопасности — Агенты ИИ.
- Ответственная отправка данных в облако — Применение ИИ.