Генерация текста — основная задача языковых моделей: на вход подаётся диалог, на выходе получается следующее сообщение. Через эндпоинт /v1/chat/completions доступна любая текстовая модель каталога, независимо от того, кто её создал.

Диалог передаётся списком messages. У каждого сообщения есть роль и содержимое:

РольКто говоритЗачем нужна
systemИнструкция для моделиЗадаёт правила: тон, язык, формат ответа, ограничения
userЧеловекВопрос или задание
assistantМодельЕё предыдущие ответы

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

Каждый запрос обрабатывается независимо: предыдущие обращения модели недоступны. Чтобы диалог продолжался, всю историю нужно отправлять заново — вместе с ответами модели в роли assistant.

{
    "model": "openai/gpt-5-mini",
    "messages": [
        {"role": "system", "content": "Отвечай одним предложением."},
        {"role": "user", "content": "Назови столицу Австралии."},
        {"role": "assistant", "content": "Столица Австралии — Канберра."},
        {"role": "user", "content": "А сколько там жителей?"}
    ]
}

Без третьего сообщения модель не поняла бы, о каком городе идёт речь в четвёртом.

Длина истории ограничена размером контекста модели. Когда переписка перестаёт помещаться, старые сообщения обычно отбрасывают или заменяют кратким пересказом.

Кроме model и messages запрос принимает параметры, управляющие ответом:

ПараметрЧто делает
temperatureРазброс ответов. Ближе к 0 — предсказуемо и однообразно, выше — свободнее и неожиданнее
top_pАльтернативный способ управления разбросом. Меняют либо его, либо temperature, но не оба сразу
max_tokensВерхний предел длины ответа в токенах
stopСтрока или список строк, на которых генерация обрывается

Пример запроса с системным сообщением и параметрами:

curl "https://api.proxyapi.ru/v1/chat/completions" \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer <КЛЮЧ>" \
    -d '{
        "model": "openai/gpt-5-mini",
        "messages": [
            {"role": "system", "content": "Ты редактор. Отвечай кратко."},
            {"role": "user", "content": "Сократи: длинное предложение о погоде."}
        ],
        "temperature": 0.3,
        "max_tokens": 200
    }'

Текст лежит в choices[0].message.content. Рядом приходят finish_reason и usage:

{
    "choices": [
        {
            "index": 0,
            "message": {"role": "assistant", "content": "Завтра тепло."},
            "finish_reason": "stop"
        }
    ],
    "usage": {
        "prompt_tokens": 24,
        "completion_tokens": 3,
        "total_tokens": 27
    }
}

finish_reason объясняет, почему модель остановилась:

ЗначениеЧто произошло
stopОтвет завершён полностью
lengthУпёрлись в max_tokens или в предел модели, ответ оборван
tool_callsМодель просит вызвать функцию
content_filterОтвет заблокирован фильтром конечного сервиса

usage показывает расход токенов: prompt_tokens — то, что ушло на вход вместе со всей историей, completion_tokens — сгенерированный ответ. По этим числам считается стоимость запроса.

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

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

Помнит ли модель предыдущие сообщения?

Нет. Каждый запрос обрабатывается отдельно, состояние между обращениями не сохраняется. Чтобы модель видела контекст разговора, всю историю нужно передавать в поле messages при каждом запросе.

Почему ответ обрывается на полуслове?

Скорее всего, сработало ограничение длины: в поле finish_reason будет значение length. Помогает увеличить max_tokens или попросить модель отвечать короче.

Что менять — temperature или top_p?

Что-то одно. Оба параметра управляют разбросом ответов, и если задать их вместе, результат становится непредсказуемым. Обычно достаточно temperature.

Одинаково ли работают модели разных вендоров на этом эндпоинте?

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

Последняя редакция: 2 сентября 2026 г.