LLM API в России: когда использовать зарубежный API, прокси или локальную LLM

Если коротко: прямой API зарубежной LLM стоит использовать, когда у компании есть законный доступ, понятная оплата, допустимая передача данных и нужны лучшие модели с минимальным временем запуска. Прокси или LLM-агрегатор вроде Polza.ai удобен, когда важны рублевая оплата, единый API и быстрый старт из России. Локальная LLM на своих или арендованных GPU нужна, когда данные чувствительные, нагрузка стабильная и большая, а бизнес готов содержать инфраструктуру.

Оглавление

• AI Summary
• Короткая матрица выбора
• Когда использовать API зарубежных LLM
• Когда использовать прокси и агрегаторы вроде Polza.ai
• Когда покупать или арендовать серверы под локальные LLM
• Главные ограничения и риски
• Практические сценарии для бизнеса
• Итоговый алгоритм выбора

AI Summary

• Прямой зарубежный API лучше для прототипов, сложного reasoning, кодинга, мультимодальности и задач, где качество модели важнее полной инфраструктурной независимости.
• Прокси или LLM-агрегатор лучше для российских команд, которым нужны рублевые платежи, OpenAI-совместимый API, fallback между моделями и запуск без VPN.
• Локальная LLM лучше для персональных данных, коммерческой тайны, on-premise требований, низкой задержки внутри контура и больших стабильных объемов запросов.
• Главный риск API и прокси - не цена, а контроль данных, юридическая допустимость доступа, блокировки, условия провайдера и прозрачность обработки.
• Главный риск локальной LLM - скрытая стоимость: GPU, DevOps/MLOps, обновления моделей, мониторинг, безопасность, деградация качества и простаивающая мощность.

Короткая матрица выбора

Ключевые выводы: лучший вариант зависит от данных, объема, требований к качеству и юридической модели. Универсального ответа нет: многие компании приходят к гибридной схеме.

Вариант	Когда выбирать	Плюсы	Минусы
Зарубежный LLM API	Нет чувствительных данных, нужен максимум качества, важна скорость запуска	Лучшие модели, быстрый старт, обновления без своей инфраструктуры, готовые SDK	Доступность из РФ ограничена, оплата и комплаенс сложнее, данные уходят внешнему провайдеру
Прокси или агрегатор	Нужны рубли, единый API, быстрый запуск, несколько моделей в одном месте	OpenAI-совместимость, пополнение российской картой, fallback, единый договор	Посредник видит трафик, возможна наценка, нужно проверять договор, логи и upstream-провайдеров
Локальная LLM	Конфиденциальные данные, большой стабильный объем, on-premise, низкая задержка	Контроль данных, независимость от внешних API, кастомизация, предсказуемость при высокой загрузке	Дорогой запуск, нужны GPU и инженеры, качество слабее топовых закрытых моделей, сложная эксплуатация

[Факт]: В списке поддерживаемых стран OpenAI API Россия не указана; OpenAI предупреждает, что доступ из неподдерживаемых стран может привести к блокировке или приостановке аккаунта (OpenAI Help Center).

[Факт]: Anthropic публикует отдельный список стран для коммерческого API; Россия в нем также не указана (Anthropic Supported Countries).

[Факт]: Google указывает, что Gemini API и AI Studio доступны только в перечисленных регионах; Россия в видимой части списка поддерживаемых стран отсутствует (Google AI for Developers).

Когда использовать API зарубежных LLM

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

Зарубежные API - это OpenAI, Anthropic, Google Gemini и другие поставщики, к которым приложение обращается напрямую. Такой подход особенно силен на старте продукта: не нужно покупать GPU, поднимать inference-серверы, настраивать батчинг и следить за обновлениями весов. Команда получает модель, документацию, SDK, лимиты, биллинг и часто дополнительные инструменты: web search, embeddings, vision, audio, structured outputs, tool calling.

Прямой API лучше выбирать в пяти случаях.

1. Нужен максимум качества. Для сложного программирования, аналитики, агентных сценариев, генерации качественных текстов, мультимодальности и reasoning закрытые frontier-модели часто дают результат лучше локальных моделей того же бюджета.
2. Проект еще проверяет гипотезу. Если продукт не доказал спрос, покупка сервера превращает эксперимент в капитальные расходы. API позволяет платить за фактическое использование.
3. Нагрузка неровная. Сегодня 100 запросов, завтра 100 тысяч, потом снова спад. В API это операционная переменная стоимость, а локальный сервер в простое продолжает стоить денег.
4. Важны обновления моделей. Провайдеры выпускают новые версии, улучшают latency, контекст, инструменты и стоимость. Свою локальную инфраструктуру придется обновлять вручную.
5. Данные можно отправлять наружу. Это ключевое условие. Если в промптах нет персональных данных, коммерческой тайны, закрытых договоров, медицинских сведений или банковской информации, риск ниже.

[Факт]: OpenAI на странице цен указывает разные режимы обработки, включая Batch API со скидкой 50%, Flex processing с более низкой ценой за счет скорости и доступности, а также enterprise-опции вроде data residency и reserved capacity (OpenAI Pricing).

[Факт]: Anthropic публикует цены Claude API в долларах за миллион токенов, включая отдельные ставки для input, output и cache (Claude API Pricing).

Когда прямой API не подходит

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

Также прямой API слабее в задачах, где нужна гарантированная автономность. Например, внутренний помощник в закрытом контуре завода, банка, медицинской организации или юридической фирмы не должен зависеть от того, доступен ли зарубежный endpoint сегодня.

Когда использовать прокси и агрегаторы вроде Polza.ai

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

Прокси и LLM-агрегаторы решают не модельную, а операционную проблему. Российская команда хочет использовать GPT, Claude, Gemini, Qwen, Llama или image/audio/video-модели через один интерфейс, оплачивать в рублях и не переписывать код под каждого поставщика. На этом строится ценность агрегатора.

Polza.ai позиционирует себя как российский LLM-агрегатор с единым API для 400+ моделей, поддержкой OpenAI Chat Completion API, оплатой в рублях и работой без VPN (Polza.ai docs). На главной странице сервис заявляет работу с OpenAI, Anthropic, DeepSeek, Google, Meta и другими моделями, пополнение российской банковской картой, fallback при сбоях и один API для сотен моделей (Polza.ai).

Агрегатор лучше выбирать в таких ситуациях.

1. Нужен быстрый запуск в России. Команда получает API-ключ, рублевую оплату и OpenAI-совместимость без долгой закупочной процедуры.
2. Нужно тестировать несколько моделей. Для SEO, копирайтинга, поддержки, классификации заявок и RAG полезно сравнить GPT, Claude, Gemini, DeepSeek, Qwen и Llama на своих данных.
3. Нужен fallback. Если один upstream недоступен, маршрутизатор может переключить запросы на другую модель. Это особенно важно для пользовательских продуктов.
4. Нет команды для LLM-инфраструктуры. Агрегатор дешевле, чем сразу нанимать инженеров под vLLM, Kubernetes, GPU monitoring и model serving.
5. Оплата и документы важнее минимальной цены. На малых и средних объемах наценка агрегатора может быть дешевле управленческих затрат на прямые договоры.

[Факт]: В документации Polza.ai указано, что сервис использует стандарт OpenAI Chat Completion API и что пользователю "не требуется прокси или VPN" для работы с API (Polza.ai docs).

[Факт]: В политике обработки персональных данных Polza.ai указано, что оператор хранит персональные данные с использованием баз данных, находящихся на территории РФ (Polza.ai privacy policy).

Что обязательно проверить у агрегатора

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

Проверьте:

• кто является оператором сервиса и с кем заключается договор;
• хранит ли сервис промпты, ответы, файлы и логи;
• можно ли отключить логирование или задать срок хранения;
• передаются ли персональные данные третьим лицам и куда именно;
• есть ли список subprocessors или upstream-провайдеров;
• гарантирует ли сервис конкретную модель или может заменить ее аналогом;
• есть ли SLA, rate limits, возврат средств при сбоях;
• поддерживаются ли streaming, function calling, JSON mode, embeddings, vision;
• можно ли ограничить модели проектом, бюджетом и ключами;
• есть ли корпоративный режим, NDA, DPA и аудит безопасности.

Когда агрегатор не подходит

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

Есть и технический риск: если API совместим "почти полностью", часть функций может вести себя иначе. У разных провайдеров отличаются system prompts, tool calling, JSON schema, лимиты контекста, модерация, stop sequences и стабильность output. Для простого чата это терпимо; для агентной системы с инструментами это может ломать бизнес-логику.

Когда покупать или арендовать серверы под локальные LLM

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

Локальная LLM - это модель, которая работает на сервере компании, в российском дата-центре, в частном облаке или на арендованной GPU-машине. Это может быть Qwen, Llama, DeepSeek, Mistral, Gemma или специализированная модель. Для serving обычно используют vLLM, SGLang, Text Generation Inference, Ollama, llama.cpp или похожие инструменты.

[Факт]: vLLM описывает себя как fast and easy-to-use library for LLM inference and serving (vLLM docs).

[Факт]: Модель Qwen3-235B-A22B опубликована на Hugging Face с лицензией Apache-2.0, поддерживает 100+ языков и имеет примеры запуска через vLLM/SGLang с OpenAI-совместимым endpoint (Qwen3 model card).

Локальную модель стоит выбирать в семи случаях.

1. Есть чувствительные данные. Персональные данные, закрытые договоры, коммерческая тайна, внутренние базы знаний, код, инциденты безопасности.
2. Есть регуляторные требования. Финансы, медицина, госзаказ, промышленность, HR и любые процессы, где важно доказать, где обрабатываются данные.
3. Нагрузка высокая и стабильная. Если миллионы токенов идут каждый день, собственный inference может стать дешевле API после достижения порога загрузки.
4. Нужна низкая задержка внутри контура. Например, ассистент оператора, классификация обращений в CRM, локальный RAG по базе знаний.
5. Нужна кастомизация. Дообучение, LoRA, специальные системные промпты, собственные фильтры, контроль версий модели.
6. Нужна автономность. Система должна работать при проблемах с внешними API, платежами, санкциями или интернет-каналом.
7. Есть инженерная команда. Нужны люди, которые понимают GPU, quantization, batching, KV cache, observability, безопасность и обновления.

Арендовать или покупать

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

Критерий	Аренда GPU	Покупка сервера
Старт	Быстрый	Долгий: закупка, поставка, настройка
CAPEX	Низкий	Высокий
OPEX	Платите каждый месяц	Электричество, стойка, обслуживание, амортизация
Гибкость	Можно менять GPU и модель	Железо фиксировано
Контроль данных	Зависит от провайдера	Максимальный при on-premise
Экономика	Лучше для пилотов	Лучше при стабильной высокой загрузке

Почему локальная LLM не всегда дешевле

Локальная модель кажется бесплатной, потому что за каждый токен не приходит счет от API-провайдера. Но фактическая стоимость складывается из GPU, CPU, RAM, NVMe, сети, стойки, электроэнергии, резервирования, мониторинга, DevOps/MLOps, безопасности, обновлений и простоев.

Если сервер загружен 10-20% времени, API или агрегатор почти всегда проще. Если сервер загружен 70-90%, а задачи допускают модель open-weight качества, локальная экономика начинает выглядеть лучше.

Главные ограничения и риски

Ключевые выводы: выбор LLM-инфраструктуры - это не только "где дешевле токены". В России нужно отдельно смотреть доступность, договоры, персональные данные, санкционные риски, безопасность и воспроизводимость результата.

Доступность и условия сервисов

У зарубежных API есть списки поддерживаемых стран. Если страна или территория не поддерживается, доступ может быть ограничен. OpenAI прямо пишет, что доступ или предложение доступа к API вне перечисленных стран может привести к блокировке или приостановке аккаунта. Anthropic также публикует список поддерживаемых регионов для коммерческого API и оставляет за собой право не предоставлять сервисы организациям, чье majority ownership связано с неподдерживаемыми странами.

Вывод простой: если российская компания использует прямой зарубежный API, ей нужно не только "чтобы работало", но и чтобы схема доступа соответствовала условиям провайдера, договору, платежной модели и внутреннему комплаенсу.

Персональные данные и трансграничная передача

Если в промптах есть данные физлиц, российская компания должна оценивать требования 152-ФЗ, локализацию баз, уведомления, согласия, поручение обработки, трансграничную передачу и договоры с обработчиками. Это не означает, что любой внешний API всегда запрещен. Но означает, что нельзя незаметно отправлять клиентские анкеты, медицинские выписки, резюме, записи разговоров или договоры в неизвестный endpoint.

Практическое правило: если данные можно обезличить - обезличивайте. Если нельзя - используйте российский контур, агрегатор с понятным договором или локальную модель. Если данные высокой чувствительности - сначала юридическая и ИБ-оценка, потом интеграция.

Риск прокси как посредника

Прокси видит запрос на прикладном уровне: prompt, system message, tool calls, файлы, ответы, иногда метаданные. Это естественная часть работы маршрутизатора. Поэтому вопрос не в том, "плохой ли прокси", а в том, есть ли у него прозрачные правила обработки и технические гарантии.

Красные флаги:

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

Риск локальной модели

Локальная LLM дает контроль, но не гарантирует качество. Модель может хуже следовать инструкциям, ошибаться в русском языке, слабее писать код, хуже работать с длинным контекстом, не поддерживать нужные tool calls или выдавать нестабильный JSON. Придется строить eval-наборы, сравнивать модели и фиксировать версии.

Также появляется риск "сервер купили, пользы нет". Он возникает, когда компания начинает с железа, а не с задач. Правильный порядок обратный: сценарии, данные, требования, тест моделей, расчет нагрузки, пилот на аренде, только потом покупка.

Практические сценарии для бизнеса

Ключевые выводы: для большинства компаний стартовая архитектура гибридная: агрегатор или API для экспериментов, локальная модель для чувствительных и массовых задач, маршрутизация по уровню риска.

Сценарий	Лучший старт	Почему
SEO-тексты, метатеги, контент-планы	Агрегатор или прямой API	Нужны разные модели, качество текста, низкий порог входа
Внутренний чат по базе знаний без ПДн	API или агрегатор + RAG	Быстрый запуск, можно оценить спрос
Поддержка клиентов с персональными данными	Агрегатор с договором или локальная LLM	Нужно контролировать логи и обработку
Юридический помощник по договорам	Локальная LLM или закрытый корпоративный контур	Высокая чувствительность документов
Кодовый ассистент для закрытого репозитория	Локальная LLM или enterprise API после ИБ-оценки	Исходный код часто является коммерческой тайной
Массовая классификация обращений	Локальная LLM при высокой нагрузке	Стабильный объем может окупить GPU
Агент с web/tool calling	Прямой API или качественный агрегатор	Важна совместимость tool calling и стабильность
Пилот нового продукта	API или агрегатор	Минимальные капитальные затраты
Производственный on-premise контур	Локальная LLM	Автономность и контроль данных важнее простоты

Рекомендация для малого бизнеса

Малому бизнесу редко нужно начинать с покупки GPU. Лучше начать с агрегатора или прямого API, собрать реальные сценарии и понять экономику. Если через 2-3 месяца видна стабильная нагрузка, чувствительные данные и регулярная стоимость API становится заметной статьей расходов, можно тестировать локальную модель на арендованном сервере.

Рекомендация для среднего бизнеса

Среднему бизнесу стоит строить маршрутизацию. Публичные и обезличенные задачи идут в API или агрегатор. Чувствительные задачи идут в локальную модель или закрытый контур. Для каждой категории данных нужен свой policy: что можно отправлять наружу, что только после маскирования, что нельзя никогда.

Рекомендация для enterprise

Enterprise-командам лучше начинать с AI governance: классификация данных, реестр моделей, договоры, DPA/NDA, логирование, eval-наборы, мониторинг качества, бюджетные лимиты. Архитектура почти всегда будет гибридной: несколько внешних моделей, один или два агрегатора/роутера, локальные модели для закрытого контура и собственный слой оркестрации.

Итоговый алгоритм выбора

Ключевые выводы: сначала определите риск данных и объем нагрузки, потом выбирайте инфраструктуру. Не покупайте сервер до пилота и не отправляйте чувствительные данные в API без проверки.

1. Опишите задачи. Генерация текстов, классификация, RAG, код, аналитика, поддержка, документы, голос, изображения.
2. Разделите данные. Публичные, внутренние, персональные, коммерческая тайна, регулируемые данные.
3. Проверьте доступность и договоры. Страны поддержки, условия сервиса, оплата, SLA, обработчики, логирование.
4. Сделайте eval. Возьмите 50-200 реальных примеров и сравните 3-5 моделей на качестве, цене и скорости.
5. Посчитайте нагрузку. Токены в день, пиковые RPS, длина контекста, доля streaming, latency.
6. Начните с API или агрегатора. Это быстрее и дешевле для проверки гипотез.
7. Пилотируйте локальную LLM на аренде. Только после понятного спроса и требований к данным.
8. Покупайте сервер при стабильной загрузке. И только если есть команда, которая будет его поддерживать.
9. Сделайте гибридную маршрутизацию. Не все задачи должны идти в одну модель.
10. Регулярно пересматривайте выбор. Цены, модели, доступность и законы меняются.

Финальный практический вывод: в России прямые зарубежные LLM API подходят для легально доступных, обезличенных и качественно сложных задач; прокси и агрегаторы - для быстрого коммерческого запуска с рублевой оплатой и несколькими моделями; локальные LLM - для чувствительных данных, большого стабильного объема и инфраструктурной независимости. Начинайте с самого простого варианта, но проектируйте систему так, чтобы модель можно было заменить без переписывания продукта.