LLM API и интеграция
API нейросети в мобильном приложении: как встроить
Мобильное приложение — самая недоверенная среда из всех, куда встраивают модель: оно устанавливается на устройство пользователя, и всё, что внутри, поддаётся анализу. Ключ, зашитый в сборку, достают за десять минут независимо от обфускации, а дальше вашим балансом пользуется кто угодно. Поэтому схема здесь единственная: приложение обращается к вашему серверу, сервер — к модели. Это не перестраховка, а единственное место, где вообще возможны лимиты на пользователя, обновление промптов без релиза и остановка дорогого сценария. Разбираем архитектуру, экономику на пользователя и то, что стоит предусмотреть до подачи в стор.
Почему ключ нельзя класть в приложение
Три причины, и они не про паранойю.
Сборку можно разобрать. Приложение — это файл на устройстве пользователя. Строки из него извлекаются стандартными средствами.
Обфускация не помогает. Даже если ключ спрятан, он всё равно попадает в исходящий запрос, а трафик приложения на своём устройстве просматривается без особых усилий.
Системное хранилище не для этого. Оно защищает данные пользователя на его устройстве от других приложений, а не ваш секрет от самого пользователя.
Тот же принцип, что и с браузером: всё, что попало на устройство пользователя, ему доступно — где хранить ключи и где нельзя.
Правильная схема
Три части, средняя обязательна.
Приложение. Интерфейс, история диалога локально, обращение только к вашему серверу.
Ваш сервер. Принимает запрос, проверяет пользователя, добавляет системный промпт и нужные данные, обращается к модели своим ключом, возвращает ответ.
Ключ. Только на сервере, в переменных окружения.
Что вы получаете вместе с сервером, помимо безопасности:
Лимиты на пользователя. Единственное место, где их можно реально применить.
Обновление промпта без релиза. Иначе каждая правка формулировки — это новая сборка и недели ожидания модерации.
Смена модели без релиза. Особенно важно, потому что модели отключают: слаг может перестать отвечать или начать обслуживаться другой моделью — календарь отключений.
Логи и метрики. Что спрашивают, где отказы, сколько стоит.
Третий и четвёртый пункты обычно и оказываются решающими: приложение с зашитой моделью и промптом становится неуправляемым сразу после релиза.
Что ограничить обязательно
Пять пунктов, каждый написан чьим-то счётом.
Сообщений на пользователя в сутки. Без этого один человек расходует месячный бюджет за вечер.
Длину диалога. История переотправляется на каждом шаге, поэтому пятидесятое сообщение стоит заметно дороже первого.
Длину одного сообщения. Иначе в поле ввода вставят книгу.
Длину ответа. Прямой рычаг на счёт и на время ожидания.
Общий расход по ключу. Отдельный ключ под приложение с собственным пределом ограничивает ущерб суммой, а не вашей внимательностью.
Отдельно: проверяйте пользователя на сервере. Приложение, обращающееся к вашему серверу без авторизации, — это тот же открытый ключ, только с лишним звеном.
Сколько это стоит на пользователя
Считать надо не так, как подсказывает интуиция.
Интуиция говорит: расход равен числу вопросов. На деле в каждый запрос уходят:
Системный промпт — при каждом сообщении, а не один раз за сессию.
История диалога — вся, потому что модель ничего не помнит между запросами.
Данные для ответа, если ассистент отвечает по вашим материалам.
И сам вопрос — обычно самая маленькая часть.
Отсюда следствие: активный пользователь с длинными диалогами стоит непропорционально дороже среднего. Прикидка «средний расход × число пользователей» занижает счёт, потому что распределение неравномерное — небольшая доля пользователей создаёт основную часть нагрузки.
Практический минимум: считайте не средний расход, а расход по перцентилям, и ставьте лимит по 95-му. Как переводить объём в рубли — как считать токены и стоимость миллиона токенов.
Как сократить расход
Четыре приёма, работающие именно в мобильном сценарии.
Обрезайте историю на сервере. Держать весь диалог обычно не нужно: хватает последних реплик плюс короткая сводка.
Не отправляйте всё подряд из приложения. Клиент может присылать полную историю, а сервер решает, что из неё уйдёт в модель.
Отвечайте на частые вопросы без модели. В типовом ассистенте несколько вопросов повторяются постоянно; готовый ответ стоит ноль и приходит мгновенно.
Берите недорогую модель. Для диалогового ассистента разница между дешёвой и дорогой позицией обычно невелика, а в цене — кратная. В каталоге на 5 сентября 2026 года 54 позиции, платные текстовые от 1 ₽ за миллион — как выбрать.
Что важно для интерфейса
Три вещи, специфичные для мобильного.
Потоковая передача. На телефоне ожидание ощущается острее, чем на десктопе. Ответ, появляющийся по мере генерации, воспринимается быстрее того же ответа целиком — когда нужен стриминг.
Поведение при плохой сети. Обрыв посреди ответа — норма в мобильном сценарии. Нужны понятное состояние и возможность повторить, а не пустой экран.
Честное сообщение при отказе. Модель может отказаться отвечать, и это приходит как обычный успешный ответ — как отличить и что показывать.
Про офлайн
Короткий и честный ответ на частый вопрос.
Обращение к API требует сети. Полностью офлайновый ассистент возможен только с моделью на самом устройстве — это другая задача со своими ограничениями по размеру модели и по расходу батареи, и запускаются так только модели с открытыми весами — когда локальный запуск оправдан.
Практичный компромисс: офлайн-заглушка с понятным сообщением и очередь на отправку, когда сеть вернётся. Пытаться уместить полноценную модель в приложение ради офлайна обычно не окупается.
Что предусмотреть до подачи в стор
Четыре пункта, о которых вспоминают на модерации.
Описание того, как обрабатываются данные пользователя. Что уходит на сервер и дальше провайдеру модели — что вообще уходит.
Возможность удалить историю. Ожидаемая функция для любого ассистента.
Обозначение, что отвечает ИИ. Пользователь должен понимать, с чем разговаривает.
Поведение при недоступности сервиса. Приложение не должно выглядеть сломанным, когда модель недоступна — как строить повторы и запасные маршруты.
Конкретные требования различаются между сторами и меняются; читайте актуальные правила площадки.
Что показать пользователю
Четыре решения интерфейса, которые определяют, будет ли ассистент использоваться.
Состояние ожидания. Не просто индикатор, а понятное «думает». В мобильном сценарии ожидание в три секунды без обратной связи воспринимается как зависание.
Понятная граница возможностей. Пустое поле ввода с приглашением «спросите что угодно» порождает вопросы, на которые ассистент не отвечает. Несколько готовых примеров запросов задают ожидания и заодно снижают долю бесполезных обращений.
Выход к человеку. Кнопка «написать в поддержку» рядом с ответом. Её наличие снижает раздражение даже у тех, кто ею не пользуется.
Управление историей. Возможность начать новый диалог и удалить старый. Первое ещё и экономит ваши деньги: новый диалог не тащит за собой контекст.
И одно про доверие: обозначайте, что отвечает ИИ. Не мелким шрифтом в настройках, а там, где человек это увидит. Попытка выдать ассистента за оператора работает ровно до первой ошибки, а потом стоит дороже, чем честная пометка с самого начала.
Чего мы не утверждаем
Не даём кода. Реализация зависит от платформы и стека.
Не советуем по правилам сторов. Они меняются; проверяйте на площадке.
Не даём юридических советов по обработке персональных данных пользователей.
Не сравниваем модели по качеству. Своих замеров мы не делали.
Что нужно, чтобы начать
Ключ заводится за минуту на keydealer.ru/login — почта и пароль, без документов и без зарубежной карты. Оплата российской картой в рублях, один ключ на весь каталог: 54 позиции в шестнадцати семействах, переключение между ними — правка конфигурации на вашем сервере, без релиза приложения.
Платные текстовые модели доступны сразу на приветственном бонусе: собрать прототип сервера и проверить сценарий можно без пополнения. Отдельный ключ под приложение с собственным пределом расхода стоит завести с первого дня.
Что держать в голове
Ключ в приложении — это не риск, а вопрос времени. Сервер посередине обязателен, и он же единственное место, где возможны лимиты, логи и смена модели без релиза.
И про деньги: платите вы за системный промпт и историю переписки, а не за вопросы пользователей. Обрезка истории на сервере даёт больше экономии, чем выбор модели подешевле.
Как мы проверяем факты и что храним из запросов — на странице о проекте и в llms.txt. Завести ключ с отдельным лимитом: keydealer.ru/login.
Частые вопросы
Можно ли обращаться к API нейросети прямо из мобильного приложения?
Технически можно, но тогда ключ окажется внутри приложения, а достать его оттуда несложно. Правильная схема — свой сервер между приложением и моделью.
Почему ключ в приложении небезопасен?
Приложение устанавливается на устройство пользователя, и его содержимое доступно для анализа. Ни обфускация, ни хранение в системном хранилище не спасают: ключ всё равно уходит в запросе.
Сколько стоит нейросеть в приложении на одного пользователя?
Считается по объёму диалогов. Основной расход — не вопросы, а история переписки и системный промпт, которые отправляются заново при каждом сообщении.
Как ограничить расход на одного пользователя?
Лимитом на своём сервере: число сообщений в сутки, длина диалога, максимальная длина ответа. На стороне приложения ограничения не работают.
Работает ли это без интернета?
Нет. Обращение к API требует сети. Офлайн возможен только с небольшой моделью прямо на устройстве, и это другая задача.