DeepSeek API: max_tokens и совместимость поля лимита вывода

Разделите желание продукта и поле контракта

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

Не переносите значение из чужой статьи, SDK или старого ответа в production без проверки. Доступный диапазон, имя поля, комбинация с другими настройками и биллинг могут различаться. Страница не устанавливает лимит и не доказывает поддержку: она описывает безопасный способ зафиксировать наблюдение на staging.

Валидируйте вход на своей стороне

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

Храните запрос пользователя отдельно от технического лога. Для диагностики достаточно локального operation ID, выбранной версии адаптера и категории отказа. Не записывайте полный prompt, ключ, Authorization или весь ответ только ради проверки лимита. Защитите конфигурацию server-side allowlist и не передавайте административные параметры в браузер.

Проведите минимальный контрактный тест

Используйте синтетический короткий запрос и одно разрешённое значение budget. Проверьте, что адаптер отправил ожидаемую форму, а ответ читается без предположений о недокументированных полях. Отдельно проверьте невалидное значение: приложение должно остановиться или показать исправление, а не уйти в бесконечный retry.

Фиксируйте дату, версию клиента, модельный alias и условия теста. Это не является бенчмарком качества и не говорит о будущей доступности. Если меняется каталог, SDK или контракт, повторите тест. Пользовательский интерфейс должен объяснять собственный лимит продукта, а не выдавать его за лимит поставщика.

Учитывайте контекст и общий budget

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

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

Тестируйте изменения вместе с tool use

Если приложение использует инструменты, проверяйте лимит вывода отдельно от права выполнять side effect. Модельный текст или неполный ответ не равны разрешению на действие. Введите локальную схему аргументов, подтверждение пользователя там, где оно нужно, и отдельный budget на выполнение инструмента.

Свяжите тему с совместимостью DeepSeek и OpenAI-формата, контекстным окном LLM API и общим deadline budget. Они помогают построить проверку, но не гарантируют конкретный параметр или модель.

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

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

Тестовые данные должны быть синтетическими и обезличенными. Не помещайте в fixture пользовательский prompt, вложение, Authorization, cookie или чужой ключ. Для журнала обычно достаточно времени, версии адаптера, локального operation ID, хэша нормализованной структуры и итоговой категории. Это помогает воспроизвести решение без утечки секрета.

Проверяйте изменение на staging

Сначала запускайте сценарий на staging с ограниченным allowlist. Отделите успешный ответ от неизвестного результата, ошибки валидации, отказа прав и временной сетевой проблемы. Для каждого состояния заранее определите остановку, ручную проверку или безопасный rollback; бесконечный retry не является стратегией миграции.

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

Сделайте решение обратимым

Конфигурация должна позволять отключить новый путь без изменения пользовательских данных. Храните прежний маршрут, короткий журнал принятого решения и явные критерии остановки. Если результат неясен, маркируйте операцию для review вместо повторной отправки: timeout или неполный ответ не доказывают, что побочное действие не произошло.

Разделяйте переключение интерфейса и переключение side effect. Сначала можно показать оператору или небольшой группе диагностический результат, затем расширять охват. Такой порядок не обходит правила поставщика и не гарантирует результат; это обычная дисциплина управления риском в собственном приложении.

Минимальный набор доказательств

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

Полезно отдельно проверить, что лог не содержит секретов и что ошибка не выводится пользователю вместе с техническими деталями. Ссылка на источник объясняет общий принцип, но не заменяет контрактный тест. Никакой пример на странице не просит передавать upstream key: используйте только собственный ключ RussiaAPI на сервере.

Безопасный server-side пример

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

export function validateOutputBudget(value, maxAllowed) {
  const budget = Number(value);
  if (!Number.isInteger(budget) || budget < 1) return { ok: false, reason: 'invalid_budget' };
  if (budget > maxAllowed) return { ok: false, reason: 'local_limit' };
  return { ok: true, budget }; // map to a confirmed provider field server-side
}

Источники и границы

DeepSeek API documentation · OWASP Input Validation Cheat Sheet

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

FAQ

Можно ли назвать один лимит для всех моделей?

Нет. Не публикуйте универсальное число без текущего контрактного подтверждения. Храните локальный product budget и повторяйте тест для выбранного маршрута и конфигурации.

Что делать при ошибке поля?

Остановить конкретный адаптер, показать понятную ошибку и сверить контракт на staging. Ошибка формы не повод для автоматического retry или подбора параметров на production-трафике.

Нужен ли клиенту реальный ключ?

Нет. Ключ RussiaAPI должен оставаться на сервере. Пример показывает локальную валидацию и не содержит реального ключа или upstream credential.

Следующий шаг

Откройте RussiaAPI, подтвердите доступный маршрут и протестируйте сценарий на staging. Затем продолжите с материалами: Совместимость DeepSeek и OpenAI · Контекстное окно LLM API · Общий deadline budget.