Представьте, что у вас уже есть интерфейс чата. Поле ввода, кнопка «Отправить» и место для ответа. Осталось сделать так, чтобы на сообщение пользователя отвечала настоящая нейросеть.
Для первого эксперимента не обязательно покупать доступ к дорогой модели или разворачивать LLM на своём компьютере. Можно использовать бесплатный API и отправлять запросы через собственный сервер.
Разберём этот путь на Python и OpenRouter.
Что значит бесплатный LLM API
LLM API позволяет обращаться к языковой модели из своего кода. Приложение отправляет текст, модель формирует ответ, а сервер возвращает его пользователю.
В OpenRouter есть модели с нулевой стоимостью обработки токенов. Есть и специальный маршрутизатор openrouter/free, который подбирает доступную бесплатную модель для запроса.
Но «бесплатно» не означает «без ограничений». У сервиса действуют лимиты, доступность моделей меняется, а отдельные запросы могут завершаться ошибкой.
Можно проверить идею и понять, как вообще работает подключение нейросети.
Как связаны страница, сервер и модель
В простом AI-чате всего три основные части.
Интерфейс принимает сообщение пользователя.
Ваш сервер обращается к провайдеру LLM.
Модель генерирует ответ, который сервер передаёт обратно на страницу.
Например, пользователь пишет «Придумай название для магазина кофе». Браузер отправляет сообщение вашему backend. Backend обращается к OpenRouter и получает текст ответа.
Почему не отправить запрос в OpenRouter прямо из браузера?
Потому что для API нужен секретный ключ. Если поместить его в клиентский JavaScript, посетители смогут его увидеть и использовать. Поэтому внешний API вызывается с сервера.
Делаем первый запрос на Python
Сначала создайте ключ в кабинете OpenRouter. Не вставляйте его прямо в исходный код.
Для локального эксперимента сохраните ключ в переменной окружения OPENROUTER_API_KEY.
Установите библиотеку requests.
pip install requestsТеперь отправим модели обычный вопрос.
import os
import requests
url = "https://openrouter.ai/api/v1/chat/completions"
response = requests.post(
url,
headers={
"Authorization": f"Bearer {os.environ['OPENROUTER_API_KEY']}",
"Content-Type": "application/json",
},
json={
"model": "openrouter/free",
"messages": [
{
"role": "user",
"content": "Придумай название для магазина кофе"
}
],
},
timeout=30,
)
response.raise_for_status()
data = response.json()
answer = data["choices"][0]["message"]["content"]
print(answer)Здесь происходит всего несколько действий.
messages содержит сообщение пользователя. model указывает бесплатный маршрутизатор. Ключ подтверждает доступ к API. После успешного запроса мы извлекаем текст из ответа.
raise_for_status() не позволит молча принять HTTP-ошибку за нормальный результат. Если запрос не удался, Python сообщит об этом.
Сам ответ будет зависеть от выбранной OpenRouter модели. Два одинаковых запроса не обязательно дадут одинаковый текст.
Переносим запрос в собственное приложение
Теперь вместо фиксированного вопроса можно принимать сообщение от пользователя.
В Django эту логику удобно поместить в серверный обработчик API. Frontend отправляет ему текст, а backend обращается к OpenRouter.
На этом этапе не требуется сложная архитектура. Достаточно понимать границу между браузером и сервером.
Но у рабочего чата появятся новые обязанности. Нужно ограничивать размер входящих сообщений, проверять доступ пользователя, хранить историю диалога и возвращать понятные ошибки.
И главное, не следует считать любой текст, полученный от модели, проверенным фактом.
Почему бесплатная модель иногда не отвечает
Самая неприятная ситуация возникает, когда вчера всё работало, а сегодня запрос возвращает ошибку.
Причин может быть несколько.
429. Достигнут лимит запросов.
403. Доступ запрещён. Нужно проверить условия доступа и сообщение API.
Модель недоступна. Провайдер временно не обслуживает запросы или выбранный вариант больше не подходит.
Нет ожидаемого текста. Формат ответа или состояние запроса требует отдельной обработки.
Для начала достаточно вывести HTTP-статус и безопасно обработать сообщение ошибки на сервере. Сам API-ключ в логи записывать не нужно.
Позже можно добавить запасные модели. Если одна не ответила, сервер попробует другую и сообщит интерфейсу, какая именно модель сформировала ответ.
Эта задача подробно разобрана в моей статье на Habr о выборе бесплатных LLM и переключении моделей.
От первого ответа до настоящего AI-чата
Один запрос к модели легко уместить в несколько строк. Но у приложения с пользователями появляются авторизация, серверное API, управление моделями, история переписки и обработка сбоев.
Посмотрите AI-Chat. Это пример того, во что может вырасти простой эксперимент с LLM API.
В курсе «AI на Django и Next II» мы последовательно собираем такие механизмы на Django и Next.js. От серверных запросов к моделям до интерфейса полноценного AI-приложения.
Для разработчиков, уже собравших первый прототип с помощью ИИ, это возможность разобраться в его backend и API.
Начните с одного запроса. Когда он заработает, будет гораздо проще разобраться, из каких частей собирается весь сервис.