Как получить ключ API для DeepSeek
У DeepSeek есть API для тех случаев, когда модель нужно встроить в продукт или рабочий процесс. Чтобы отправлять запросы из кода, нужен ключ API — секретный токен из DeepSeek API Platform. Разберем, как создать ключ, выбрать актуальную модель, выполнить первый запрос через curl, Python и Podman. Заодно покажем, как проверять ошибки и где хранить токен, чтобы он не оказался в репозитории или логах.
Зачем нужен DeepSeek API
Веб-интерфейс хорош для ручной работы: задать вопрос, уточнить вводные, скопировать ответ. API в свою очередь нужен для программных запросов. Сервис отправляет HTTP-запрос с текстом, параметрами модели и ключом авторизации, а в ответ получает JSON, который можно обработать в коде.
Для использования API нужен API-ключ, который подтверждает, что запрос пришел от вашей учетной записи. По этому ключу платформа применяет доступные лимиты, считает расход и связывает запросы с аккаунтом.
Представим сервис поддержки. Он получает обращение, передает его модели и просит определить тему, срочность и черновик ответа. Или внутренний поиск по документации: приложение находит подходящие фрагменты, отправляет их в DeepSeek и просит ответить только на основе найденного. В обоих случаях человеку не нужно вручную открывать чат и копировать текст туда-обратно.
Системную инструкцию можно использовать и в веб-версии DeepSeek. Но в чате ее приходится заново задавать под каждый сценарий или держать отдельный диалог, иначе строгий промпт для ревью кода, заданный на системном уровне, может повлиять на обычный разговор. В API проверенную системную инструкцию можно хранить в коде и отправлять при каждом вызове. Для продукта это удобнее, чем каждый раз искать нужный промт, руками копировать его в браузер и писать самостоятельно текст запроса. Настроенный сервис в этом случае работает самостоятельно и каждый раз работает по одному и тому же правилу.
Доступен ли DeepSeek API в России
Для пользователя из России доступность DeepSeek API складывается из нескольких частей. Сайт может открываться, но запросы из приложения все равно могут не проходить. Или ключ создан, но аккаунт пока не готов к платным запросам.
Перед первым запуском проверьте:
- открывается ли DeepSeek API Platform из вашей сети;
- получается ли войти в аккаунт и открыть раздел с API-ключами;
- есть ли в кабинете баланс, достаточный для тестового запроса;
- проходит ли запрос к https://api.deepseek.com из той среды, где будет работать приложение.
На последний пункт стоит обратить особое внимание. На локальной машине запрос может проходить, а из корпоративной сети или продакшен-окружения — нет. На это могут влиять прокси, файрвол и правила исходящего трафика.
Перед рабочим запуском также проверьте биллинг учетной записи в кабинете DeepSeek: доступный баланс, лимиты и правила списаний. В DeepSeek API Platform оплата доступна в долларах США и китайских юанях.
Если проект зависит от стабильной работы LLM, заранее подготовьте резервный вариант: другой официальный API, российскую платформу или собственный эндпоинт с open source-моделью. Для эксперимента это может быть избыточно, но для рабочего сервиса — нет. Если модель помогает обрабатывать заявки, код или внутренние документы, план на случай недоступности внешнего API очень важен.
Какие модели DeepSeek доступны через API
В запросе к DeepSeek есть поле model. Это имя модели, которую должен вызвать API. По нему платформа понимает, какой вариант LLM использовать, какие режимы включить и как считать расход. Значение берут из официальной документации DeepSeek или из ответа API со списком моделей, если проект проверяет доступные варианты программно.
В примерах ниже model указан явно. Остальные параметры запроса разберем в разделе «Как подключить DeepSeek API к проекту».
В июле 2026 года в документации DeepSeek указаны две основные модели: deepseek-v4-flash и deepseek-v4-pro. Обе поддерживают контекст до 1 млн токенов, JSON Output, Tool Calls и режим рассуждения. Стоимость считается за 1 млн токенов и зависит от модели, типа токенов и попадания в кеш контекста.
deepseek-v4-flash
deepseek-v4-flash — быстрый и более экономичный вариант. Один короткий запрос сразу покажет, правильно ли настроены ключ, эндпоинт, JSON и обработка ответа, поэтому начинать удобнее с него.
Модель подходит для задач с большим потоком однотипных запросов: классификации обращений, кратких пересказов, извлечения сущностей. Например, можно передать обращение пользователя и попросить вернуть JSON с категорией, тоном сообщения и признаком срочности. Для такой задачи будет более важным стабильный формат ответа и низкая задержка, чем максимальная глубина рассуждений. Плюс ко всему запросы к этой модели будут дешевле.
deepseek-v4-pro
deepseek-v4-pro лучше подходит для сложных запросов. К ним можно отнести анализ кода, работу с длинными документами, длинные пошаговые инструкции и задачи с инструментами. В таких задачах ошибка модели может стоить дороже, чем экономия на токенах.
Для короткого комментария к функции часто хватит Flash-модели. Pro-модель выглядит уместнее, если нужно разобрать архитектурный фрагмент, найти риски и предложить безопасный план миграции. Но всегда помните: модель готовит основу, а финальное решение всегда остается за человеком.
В рабочем проекте модели можно разделять по маршрутам. Простые запросы отправлять в deepseek-v4-flash, сложные — в deepseek-v4-pro.
deepseek-chat и deepseek-reasoner
В интернете можно встретить упоминание deepseek-chat и deepseek-reasoner. Это устаревающие имена моделей: первая использовалась для обычных диалоговых запросов, вторая — для запросов с рассуждением.
В документации DeepSeek эти имена помечены как устаревшие. Для совместимости deepseek-chat соответствует режиму без рассуждения у deepseek-v4-flash, а deepseek-reasoner — режиму с рассуждением у той же модели. Для новых проектов лучше сразу использовать deepseek-v4-flash или deepseek-v4-pro и явно задавать параметры рассуждения в запросе.
Если в проекте уже есть старый код, проверьте модель и параметры thinking / reasoning_effort. После замены модели прогоните несколько типовых сценариев для проверки.
Как создать API-ключ для DeepSeek
API-ключ создается в панели DeepSeek API Platform. Лучше выпустить его до того, как вы начнете писать клиентский код. Так получится сразу проверить доступ, дать ключу понятное имя и сохранить токен в безопасное место. В этом разделе разберем только путь к ключу, а первый запрос выполним ниже.
Регистрация и учетная запись
Откройте DeepSeek API Platform и войдите в аккаунт. Если учетной записи нет, создайте ее и подтвердите регистрацию. После входа проверьте, что в панели доступны основные разделы:

- Usage — статистика использования API. Здесь удобно смотреть расход и понимать, какие запросы создают основную нагрузку;
- API keys — управление API-ключами. В этом разделе можно создавать новые ключи, смотреть существующие и удалять те, которые больше не нужны;
- Top up — пополнение денежного баланса аккаунта;
- Billing — история пополнений и списаний. Этот раздел помогает сверять расходы и разбирать неожиданные траты.
Если ключ нужен для командного проекта, не начинайте с личного аккаунта разработчика. Сразу определите, кому принадлежит доступ, кто может выпускать ключи и кто отзывает их при утечке или смене владельца проекта.
Создание API-ключа
Создавайте отдельные ключи для проектов и тестовых окружений. Так будет проще понять, где используется конкретный токен и какой ключ нужно отозвать, если доступ больше не нужен.
Чтобы получить ключ, в панели DeepSeek API Platform откройте раздел API Keys.
Нажмите кнопку Create new API key.

Задайте имя ключа и подтвердите создание.

Скопируйте токен сразу после создания. После закрытия окна платформа может показывать только идентификатор или последние символы ключа. Если токен не будет сохранен сразу, его потребуется удалить и сгенерировать новый.
Имя ключа должно помогать в эксплуатации, поэтому старайтесь не использовать имена по типу test и new-key — они быстро потеряют смысл. Лучше указывать проект, окружение и назначение, например: support-bot-stage, rag-demo-dev, backend-prod.
Где хранить токен
В локальной разработке ключ удобно хранить в файле .env и читать через переменную окружения:
DEEPSEEK_API_KEY="sk-..."
Файл .env должен быть добавлен в .gitignore. В репозиторий можно положить только пример .env.example без реального значения:
DEEPSEEK_API_KEY=""
В CI/CD ключ передают через секреты платформы: GitLab CI/CD variables, GitHub Actions secrets, Kubernetes Secrets, Vault или другой secret manager. В продакшене токен не должен лежать в конфигурационном файле рядом с приложением.
Как подключить DeepSeek API к проекту
DeepSeek API поддерживает OpenAI-совместимый формат. Если проект уже работает с OpenAI SDK или совместимыми инструментами, достаточно заменить base_url, указать ключ DeepSeek и выбрать актуальную модель.
Минимальная конфигурация
Минимальная конфигурация состоит из четырех частей:
- base_url — адрес API. DeepSeek использует https://api.deepseek.com;
- api_key — токен из DeepSeek API Platform. Обычно его не пишут в коде напрямую, а читают из переменной окружения, например DEEPSEEK_API_KEY;
- model — имя модели, например deepseek-v4-flash. Как выбрать модель, смотрите в разделе Какие модели DeepSeek доступны через API;
- messages — массив сообщений для модели. Сообщение с ролью system задает общие правила поведения, user содержит запрос пользователя, а assistant используют, когда нужно передать в контекст предыдущий ответ модели.
Еще один важный параметр, стоящий отдельно — stream. Он отвечает за потоковую выдачу ответа. Если указать stream: true, приложение будет получать ответ небольшими фрагментами по мере генерации и сможет показывать текст пользователю постепенно. Если указать stream: false, API вернет один JSON-объект после завершения генерации. Такой режим удобнее для пакетной обработки, логирования и простых проверок.
Режим рассуждения включайте под задачу. Для классификации, короткого пересказа или генерации одного заголовка он часто дает лишнюю задержку. Для анализа кода, планирования и работы с противоречивыми документами рассуждение может улучшить результат.
Запрос через curl
Самая быстрая проверка — запрос через curl. Он не требует писать приложение и сразу показывает, где проблема: в ключе, сети, недостатке денежных средств на балансе, JSON-теле запроса или имени модели.
curl https://api.deepseek.com/chat/completions \
-H "Content-Type: application/json" \
-H "Authorization: Bearer ${DEEPSEEK_API_KEY}" \
-d '{
"model": "deepseek-v4-flash",
"messages": [
{
"role": "system",
"content": "Ты помогаешь проверить подключение к API."
},
{
"role": "user",
"content": "Ответь одним предложением: API работает."
}
],
"thinking": {"type": "disabled"},
"stream": false
}'
В этом запросе используются несколько важных частей.
- Authorization передает API-ключ в заголовке запроса;
- Content-Type сообщает серверу, что тело запроса отправлено в формате JSON.
- model выбирает LLM, к которой нужно обратиться;
- messages содержит инструкцию и пользовательский запрос;
- thinking отключает режим рассуждения для короткой проверки, чтобы ответ пришел быстрее.
Для проверки режима рассуждения можно отправить такой же curl-запрос, но заменить несколько полей в JSON-теле:
"model": "deepseek-v4-pro",
"thinking": {"type": "enabled"},
"reasoning_effort": "high"
Первый запрос к модели лучше сделать коротким. Если запрос простой, легче понять причину ошибки.
Запрос на Python
В Python можно использовать официальный OpenAI SDK, потому что DeepSeek поддерживает формат Chat Completions API, совместимый с OpenAI. В клиенте нужно указать ключ DeepSeek и заменить стандартный адрес API на base_url платформы DeepSeek.
Установите пакет openai. Он нужен, чтобы отправлять запросы через готовый Python-клиент, а не собирать HTTP-запросы вручную:
pip install openai
Для проверки работоспособности можно использовать следующий минимальный запрос:
import os
from openai import OpenAI
api_key = os.getenv("DEEPSEEK_API_KEY")
if not api_key:
raise RuntimeError("Переменная окружения DEEPSEEK_API_KEY не задана")
client = OpenAI(
api_key=api_key,
base_url="https://api.deepseek.com",
)
response = client.chat.completions.create(
model="deepseek-v4-flash",
messages=[
{
"role": "system",
"content": "Ты помогаешь проверить подключение к API.",
},
{
"role": "user",
"content": "Ответь одним предложением: API работает.",
},
],
stream=False,
extra_body={"thinking": {"type": "disabled"}},
)
print(response.choices[0].message.content)
Обратите внимание на extra_body. OpenAI SDK не всегда знает дополнительные параметры конкретного провайдера. Через extra_body можно передать поля DeepSeek и при этом оставить привычный клиентский код.
Диагностический Python-скрипт
Если базовый пример на Python не сработал, полезно запустить диагностический вариант. Он отправляет такой же короткий запрос, но дополнительно показывает HTTP-статус и тело ответа при ошибке.
import os
import sys
from openai import APIStatusError, OpenAI
api_key = os.getenv("DEEPSEEK_API_KEY")
if not api_key:
sys.exit("DEEPSEEK_API_KEY не задана")
client = OpenAI(
api_key=api_key,
base_url="https://api.deepseek.com",
)
try:
response = client.chat.completions.create(
model="deepseek-v4-flash",
messages=[
{"role": "user", "content": "Ответь коротко: ключ работает."},
],
stream=False,
extra_body={"thinking": {"type": "disabled"}},
)
except APIStatusError as error:
print(f"HTTP {error.status_code}")
print(error.response.text)
raise
print(response.choices[0].message.content)
Типовые ошибки:
- 400 — неверное тело запроса: сломан JSON, неправильная структура messages или неподдерживаемое поле;
- 401 — ключ не передан, введен с ошибкой, отозван или относится к другой учетной записи;
- 402 — на аккаунте недостаточно денежных средств для запроса;
- 422 — параметры не проходят проверку, например указано неподдерживаемое значение;
- 429 — приложение отправляет слишком много запросов или уперлось в лимит;
- 500 и 503 — проблема на стороне сервиса.
В production добавьте таймауты, ограничение повторов, backoff и метрики по статусам. Ошибки 401 и 402 нужно обрабатывать отдельно: если ключ отозвали или на аккаунте закончились деньги, бесконечные повторы только засорят логи.
Проверка через Podman
Podman имеет смысл использовать, если будущая интеграция будет работать в контейнере. В таком случае важно проверить не только сам API-ключ, но и окружение: собирается ли образ, есть ли внутри нужные зависимости, видит ли контейнер внешний API и можно ли передать ключ без записи в исходный код.
Сначала создайте небольшой Python-скрипт для проверки соединения с DeepSeek:
from pathlib import Path
from openai import APIStatusError, OpenAI
api_key_path = Path("/run/secrets/deepseek_api_key")
api_key = api_key_path.read_text(encoding="utf-8").strip()
client = OpenAI(
api_key=api_key,
base_url="https://api.deepseek.com",
)
try:
response = client.chat.completions.create(
model="deepseek-v4-flash",
messages=[
{"role": "user", "content": "Ответь коротко: ключ работает."},
],
stream=False,
extra_body={"thinking": {"type": "disabled"}},
)
except APIStatusError as error:
print(f"HTTP {error.status_code}")
print(error.response.text)
raise
print(response.choices[0].message.content)
Сохраните рядом с ним Containerfile:
FROM python:3.12-slim
RUN pip install --no-cache-dir openai
WORKDIR /app
COPY deepseek_api_check.py .
CMD ["python", "/app/deepseek_api_check.py"]
Создайте секрет Podman из локальной переменной окружения:
printf '%s' "$DEEPSEEK_API_KEY" | podman secret create deepseek_api_key -
Соберите образ и запустите контейнер:
podman build -t deepseek-api-check .
podman run --rm \
--secret deepseek_api_key \
deepseek-api-check
Внутри контейнера ключ будет доступен как файл /run/secrets/deepseek_api_key. Его не нужно добавлять в образ, передавать аргументом команды или хранить рядом с кодом.
Если проверка прошла успешно, скрипт выведет короткий ответ модели. Если API вернул ошибку, скрипт покажет HTTP-статус и тело ответа. Так можно проверить поведение приложения ближе к реальному запуску.
После проверки удалите секрет:
podman secret rm deepseek_api_key
Podman удобен, когда на машине не хочется ставить Python, Node.js или SDK. Достаточно запустить контейнер с curl и передать ключ через переменную окружения.
podman run --rm -i \
-e DEEPSEEK_API_KEY \
docker.io/curlimages/curl:8.10.1 \
sh -c 'curl -sS https://api.deepseek.com/chat/completions \
-H "Content-Type: application/json" \
-H "Authorization: Bearer ${DEEPSEEK_API_KEY}" \
-d @-' <<'JSON'
{
"model": "deepseek-v4-flash",
"messages": [
{"role": "user", "content": "Скажи: ключ работает."}
],
"thinking": {"type": "disabled"},
"stream": false
}
Если все в порядке, API вернет JSON с массивом choices. Внутри будет ответ модели и служебная информация: идентификатор запроса, выбранная модель, статистика токенов, если она есть в ответе.
Если контейнер не запускается, проблема не в DeepSeek. Проверьте, установлен ли Podman, доступен ли образ curlimages/curl и передана ли переменная DEEPSEEK_API_KEY.
Как можно использовать DeepSeek API
DeepSeek API полезен в тех случаях, где одну и ту же текстовую задачу нужно выполнять регулярно. Не вручную копировать текст в чат, а встроить обработку в сервис (бота, админ-панель, внутренний инструмент).
Например, в поддержке модель может прочитать обращение, определить тему, отметить срочность и подготовить черновик ответа для оператора. Человек все равно принимает решение и отправляет финальный ответ, но модель помогает быстрее разобрать входящий поток и не начинать каждое письмо с пустого листа.
В разработке API можно использовать для разбора stack trace, подготовки тестов, краткого объяснения чужого кода или черновика инструкции по миграции. Здесь стоит заранее договориться какие данные разрешено отправлять во внешний сервис. Секреты, приватные ключи и закрытый код нельзя передавать модели просто потому, что так быстрее.
В редакционных задачах модель помогает быстрее готовить контент — выровнять стиль текста, сделать краткую версию длинного материала, предложить заголовки или собрать черновик письма. Но факты, ссылки, юридические формулировки и продуктовые обещания должен проверять человек. LLM хорошо ускоряет подготовку текста, но не снимает ответственность за публикацию.
Еще один частый сценарий — корпоративный поиск по документам. Система получает вопрос, находит релевантные фрагменты в базе знаний, передает их модели и просит ответить только на основе найденного. Такой подход называют RAG (Retrieval-Augmented Generation), то есть генерацией с дополнением из найденных источников. Он справляется с задачами лучше, в сравнении с ситуацией, когда вы просто отправляете всю документацию в модель: в запрос попадает меньше лишнего, а ответ проще проверить по исходным фрагментам.
Нужно ли оплачивать API, если модель запущена локально
Официальный API DeepSeek и локально запущенная модель — разные способы использовать LLM.
- Если запрос уходит в https://api.deepseek.com, расход считается по правилам провайдера.
- При локальном запуске модель не становится бесплатной, просто меняется статья расходов. Вместо оплаты токенов появляются GPU, CPU, RAM, диск, мониторинг, обновления, безопасность и время команды. Иногда это выгодно, а иногда — нет. Все зависит от нагрузки, требований к данным и готовности обслуживать инфраструктуру.
Для небольшого эксперимента официальный внешний API обычно проще. Не нужно поднимать сервер для запуска модели, подбирать GPU, следить за памятью и разбираться с форматами квантования. Для регулярной нагрузки или чувствительных данных собственное развертывание может быть разумнее, но тогда команда берет на себя настройку, обновление, мониторинг и защиту сервиса.
Есть промежуточный вариант: модель запущена как отдельный инференс-сервис в облаке. Такой сервис предоставляет API эндпоинт, к которому обращается приложение. По коду это похоже на внешний OpenAI-совместимый API, но инфраструктура, локация данных, правила доступа и стоимость контролируются выбранной платформой.
Безопасность данных и кода при работе с API
ИИ-интеграции часто начинаются с маленького скрипта. Потом этот скрипт незаметно начинает обрабатывать реальные заявки, код или документы. Правила безопасности лучше ввести до этого момента, пока проект еще легко менять.
Что нельзя отправлять в модель
Во внешний API нельзя бездумно отправлять персональные данные, коммерческую тайну, закрытые договоры, дампы баз, приватные ключи, токены, пароли, cookie, внутренние логи и production-конфиги. Запрос покидает ваш инфраструктурный контур, даже если провайдер обещает аккуратную обработку данных.
Для пользовательских данных нужна отдельная проверка: что уходит в модель, где это обрабатывается, попадает ли в логи и кто имеет доступ к результату. В России для персональных данных дополнительно важны требования 152-ФЗ и внутренние регламенты организации.
Рабочий принцип простой: отправлять только то, что нужно для ответа. Если модель классифицирует обращение, ей часто не нужны телефон, email, номер договора и полный лог переписки. Если она делает краткое резюме документа, чувствительные поля можно удалить до запроса.
Как защитить ключ API для DeepSeek
Базовые правила хранения ключа мы уже разобрали выше. В этом разделе — практические действия, которые помогают не потерять контроль над доступом после запуска интеграции.
- Не выводите токен в stdout, логи, сообщения об ошибках и отладочные панели.
- Не вставляйте ключ в скриншоты, задачи, переписки и документацию.
- Ограничьте круг людей и сервисов, которые могут читать production-ключ.
- Регулярно проверяйте список активных ключей в панели DeepSeek и удаляйте лишние.
- Отзывайте ключ сразу, если есть подозрение на утечку.
Важно. Если ключ попал в Git, удаление строки в новом коммите не решит проблему. Считайте токен скомпрометированным: отзовите его в платформе, выпустите новый и только потом чистите историю репозитория, если это нужно по внутренним правилам.
Что логировать, а что нет
Логи должны помогать разобраться, что происходит с интеграцией, но они не должны превращаться в копию переписки пользователя с моделью.
Безопасный минимум — показывать технические поля, например время запроса, имя модели, HTTP-статус, длительность, идентификатор запроса, примерный размер входа и выхода, признак повторной попытки и код ошибки. Обычно этого хватает, чтобы найти проблему в эксплуатации и в то же время не сохранить лишние данные.
Полный промпт и полный ответ модели стоит логировать только там, где это действительно нужно: в тестовом окружении, на синтетических данных и на ограниченное время.
Если ответы модели нужно хранить как часть бизнес-процесса, отделите их от технических логов. У таких данных обычно другие права доступа, сроки хранения и правила маскирования.
LLM с бесплатным или доступным из РФ API: какие есть варианты
Если официальный DeepSeek API неудобен для проекта, сравните несколько вариантов. Смотреть стоит не только на доступность из России, но и на качество модели, цену, лимиты, юридические условия, хранение данных и совместимость с SDK.
- Официальный DeepSeek API подходит для быстрого старта, тестов и задач, где допустимо обращение к внешнему зарубежному сервису. Плюс — прямой доступ к моделям DeepSeek. Минусы — зависимость от доступности сервиса из вашей сети, внешнего биллинга и правил обработки данных провайдера.
- Российские LLM-сервисы, например GigaChat или YandexGPT, могут быть удобнее, если важны доступ из РФ, договорной контур и работа с российскими юридическими лицами. Плюсы — проще встроить в корпоративные процессы. Минусы — отличающееся поведение моделей и необходимость отдельно проверять качество на ваших задачах.
- Selectel AI Router удобен, когда нужен единый доступ к нескольким моделям через один API-ключ и OpenAI-совместимый интерфейс. Такой вариант полезен для экспериментов, сравнения моделей и централизованного контроля лимитов, но перед production-запуском нужно проверить список доступных моделей, правила тарификации и требования к данным.
- Foundation Models Catalog в Selectel подходит, когда нужен отдельный inference-сервис с выделенным эндпоинтом и API-ключами. Это ближе к контролируемой инфраструктуре: модель развертывается как сервис, а приложение обращается к ней через API.
- Open source-модели в собственной инфраструктуре требуют больше работы на старте, зато дают максимум контроля. Команда сама выбирает модель, локацию, железо, политику логирования и правила доступа.
Практический способ выбора простой: возьмите 20–30 типовых запросов из вашего продукта, прогоните их через несколько вариантов и сравните не только качество ответов, но и задержку, стоимость, стабильность формата, удобство SDK, поддержку сервиса и требования безопасности.
API для LLM в российской инфраструктуре
В Selectel для работы с LLM есть два близких сценария: ИИ-роутер и Foundation Models Catalog. Оба дают API-доступ к моделям, но решают разные задачи.
ИИ-роутер
ИИ-роутер — это единая точка доступа к более чем 300 ведущим генеративным моделям со всего мира. Иными словами, это сервис с каталогом моделей искусственного интеллекта, централизованным управлением ключами, квотами, отчетностью и аналитикой. Для разработчика главный плюс в том, что приложение работает с OpenAI-совместимым API. Модель можно выбирать в теле запроса, без полной переделки клиентского кода под каждого поставщика. Для бизнеса плюс в другом: доступ к моделям идет через Selectel, оплата выполняется в рублях, а отдельные договоры с каждым вендором не нужны.
В панели это выглядит как отдельный ресурс. Сначала создается ИИ-роутер, затем выпускается API-ключ (можно создать несколько ключей для разных пользователей) и открывается доступ к огромному количеству моделей.
Запрос отправляется на единый эндпоинт ИИ-роутера, а в самом теле запроса указываются имя модели, сообщения и дополнительные параметры.
Foundation Models Catalog
Foundation Models Catalog — это каталог преднастроенных ML-моделей с готовым API. В отличие от ИИ-роутера, здесь фокус не на единой точке доступа к внешним моделям, а на запуске отдельного inference-сервиса в облаке Selectel. Модель развертывается на выделенных ресурсах в инфраструктуре Selectel, получает свой эндпоинт и собственные API-ключи.
Такой вариант подходит для сценариев, где обязателен контролируемый контур. Например, когда нужно понятнее управлять доступом, учитывать требования информационной безопасности и не отправлять запросы в API внешнего зарубежного провайдера.
API-ключи у inference-сервиса индивидуальные. Их можно добавлять, переименовывать и удалять. Стоимость Foundation Models Catalog считается по ресурсам облачной платформы, а не по токенам. Для пользователя это важное отличие от внешних LLM API: запросов может быть много, но платить нужно за выбранную конфигурацию и время ее работы.
Заключение
Теперь у вас есть базовый маршрут: создать ключ в DeepSeek API Platform, сохранить его в переменной окружения и проверить запрос через curl,Python или контейнерное окружение. Для новых проектов используйте deepseek-v4-flash и deepseek-v4-pro, а старые имена deepseek-chat и deepseek-reasoner лучше заменить.
Перед запуском проверьте ключ, лимиты, обработку ошибок, логи и список данных, которые уходят в модель. Если прямой доступ к зарубежным API неудобен из-за оплаты, договоров, сетевой доступности или других ограничений, посмотрите ИИ-роутер Selectel: он дает единый доступ к 300+ моделям через OpenAI-совместимый API и оплату в рублях. Если важнее требования информационной безопасности и работа модели в российской инфраструктуре, лучше подойдет Foundation Models Catalog.