Рег.облако AI API — 30+ моделей с оплатой по токенам

27 августа 2026 года Рег.облако добавило на свою ИИ-платформу доступ к моделям с оплатой по фактически обработанным токенам.

Пользователю больше не обязательно заранее арендовать выделенный GPU и самостоятельно поддерживать inference-сервер. Провайдер предлагает два способа работы:

• OpenAI-compatible API для приложений;
• Sandbox UI для ручного тестирования моделей в браузере.

На старте заявлены более 30 моделей. В анонсе перечислены GPT 5.5, Claude Sonnet 5, Gemini 3.1 Pro, Kimi K2.6 и Qwen 3.7 Max.

Названия из пресс-релиза нельзя автоматически использовать как model в коде. Точные model IDs, доступные endpoints и цены нужно брать из панели и актуальной документации.

• Карточка REG.RU и Рег.облака
• Каталог провайдеров
• Timeweb Cloud AI Gateway

Что изменилось

Ранее основным вариантом ИИ-платформы Рег.облака было выделенное GPU-окружение с vLLM. Пользователь выбирал GPU-сервер, модель и оплачивал выделенные ресурсы почасово.

Новая схема отделяет API-доступ от аренды собственного inference-сервера:

приложение
    ↓
OpenAI-compatible API Рег.облака
    ↓
выбранная модель
    ↓
оплата входящих и исходящих токенов

Это подходит для:

• прототипов;
• чат-ботов;
• генерации и анализа текста;
• coding assistants;
• исследований;
• нерегулярной нагрузки;
• сравнения нескольких моделей;
• проектов, которым невыгодно постоянно оплачивать GPU.

Выделенные GPU при этом не закрываются. Они остаются отдельным вариантом для задач, где важны приватный контур, контроль инфраструктуры, собственные модели и предсказуемая постоянная нагрузка.

Что подтверждено официальным анонсом

Возможность	Что заявлено
Модель оплаты	за фактически обработанные входящие и исходящие токены
Способ подключения	OpenAI-compatible API
Ручной интерфейс	Sandbox UI
Каталог	более 30 моделей на старте
API-ключи	создание и управление ключами пользователем
Статистика	учёт использования и расхода input/output tokens
Доступность	модели доступны для запросов без ожидания запуска собственного GPU
Альтернативный режим	выделенные GPU-серверы сохраняются

Что пока нельзя считать подтверждённым

Публичный анонс сам по себе не даёт полного API contract.

До интеграции нужно найти в панели или запросить у поддержки:

• Base URL;
• точные model IDs;
• публичную таблицу цен;
• контекстное окно каждой модели;
• максимальный output;
• rate limits;
• ограничения параллельных запросов;
• поддерживаемые методы API;
• streaming;
• tool calling;
• structured output / JSON Schema;
• Responses API;
• embeddings;
• изображения и аудио;
• retry policy;
• SLA;
• регионы обработки;
• правила хранения request/response logs.

Не следует переносить свойства оригинального API поставщика на агрегатор без теста. Одна и та же модель через gateway может иметь другой набор параметров, лимитов и форматов ошибок.

Токенная оплата и выделенный GPU

Сценарий	Токенный API	Выделенный GPU
Нерегулярные запросы	обычно удобнее	GPU простаивает, но продолжает тарифицироваться
Быстрый прототип	не нужно разворачивать inference	требуется создание и настройка сервера
Несколько моделей	проще переключать через единый API	каждую модель нужно размещать отдельно или менять окружение
Постоянная высокая нагрузка	стоимость может быстро расти	может быть выгоднее при высокой загрузке
Собственная модель	нужно проверить поддержку	можно загрузить в окружение vLLM, если модель совместима
Приватный контур	требует договорной и технической проверки	больше контроля над сервером и локальным хранением
Масштабирование	выполняет провайдер, но действуют limits	клиент управляет мощностью и числом серверов

Выбор нужно делать по реальной нагрузке, а не по цене одного миллиона токенов.

Стоимость успешной задачи

Полезно считать не только стоимость токенов, но и итоговую стоимость результата, прошедшего проверку качества.

стоимость успешной задачи =
    стоимость всех попыток, retries и fallback
    ÷
    число ответов, прошедших evaluation

Например, более дешёвая модель может потребовать:

• повторных запросов;
• дополнительной проверки;
• большого prompt;
• исправления JSON;
• переключения на более сильную модель.

В итоге её реальная стоимость задачи может оказаться выше.

Как подготовить тест стоимости

Для каждой модели сохраните:

Поле	Для чего
model	точный ID модели
input tokens	стоимость prompt и истории
output tokens	стоимость ответа
retries	повторные расходы
latency	пользовательский опыт
результат eval	задача решена или нет
итоговая стоимость	сравнение моделей

Проверять нужно один и тот же набор задач и одинаковые требования к ответу.

Базовая конфигурация клиента

Точные значения нужно получить в панели Рег.облака. Не копируйте примерный endpoint из чужой статьи.

import os

from openai import OpenAI

client = OpenAI(
    api_key=os.environ["REGCLOUD_AI_API_KEY"],
    base_url=os.environ["REGCLOUD_AI_BASE_URL"],
)

response = client.chat.completions.create(
    model=os.environ["REGCLOUD_AI_MODEL"],
    messages=[
        {
            "role": "system",
            "content": "Отвечай кратко и явно указывай допущения.",
        },
        {
            "role": "user",
            "content": "Составь checklist восстановления сайта из backup.",
        },
    ],
)

print(response.choices[0].message.content)

Этот пример проверяет только базовую совместимость Chat Completions. Он не доказывает поддержку streaming, tools, Responses API или structured output.

Контрактные тесты API

OpenAI-compatible означает знакомую форму подключения, но не полную идентичность OpenAI API.

Минимальная матрица:

Проверка	Что сравнить
Обычный chat	поля ответа, роли, finish reason
Streaming	порядок chunks, финальное событие, обрыв соединения
Usage	input/output tokens в ответе и биллинге
Tool calling	schema, arguments, несколько tools, ошибки
JSON	валидность и соблюдение schema
Большой контекст	фактический limit и поведение около границы
Errors	HTTP status, тело, retryability
Timeout	можно ли безопасно повторить запрос
Rate limit	429, headers и время восстановления
Мультимодальность	поддерживаемые форматы и лимиты

Тест нужно повторять для каждой реально используемой модели. Наличие функции у одной модели не гарантирует её поддержку другой.

Проверка ошибок

Специально отправьте запросы с:

• неверным API-ключом;
• удалённым или истёкшим ключом;
• неизвестным model ID;
• слишком большим prompt;
• превышением rate limit;
• неверным JSON;
• неподдерживаемым параметром;
• timeout клиента;
• разрывом streaming-соединения.

Приложение должно различать:

ошибка пользователя
ошибка авторизации
лимит
временный upstream incident
несовместимый параметр
неизвестная модель

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

API-ключи

Для production:

• создавать отдельный ключ на каждый проект;
• разделять staging и production;
• не использовать ключ в frontend;
• хранить его в secret manager или переменной окружения;
• задавать лимит расходов, если панель это позволяет;
• регулярно ротировать ключи;
• удалять ключ после закрытия проекта;
• не выводить Authorization header в логи;
• фиксировать владельца и назначение каждого ключа.

Если доступна статистика по ключу, её полезно связывать с внутренним project ID и бюджетом.

Privacy и персональные данные

Российский провайдер и рублёвая оплата не доказывают, что запрос к каждой зарубежной модели полностью обрабатывается внутри России.

Перед отправкой персональных данных, коммерческой тайны или клиентских документов нужно получить ответы на вопросы:

• кто является оператором и обработчиком данных;
• какие upstream providers участвуют;
• в каких странах выполняется inference;
• сохраняются ли prompts и ответы;
• срок хранения технических логов;
• используются ли данные для обучения;
• можно ли отключить logging;
• как выполняется удаление данных;
• какие договоры и приложения регулируют обработку;
• соответствует ли конкретная схема требованиям 152-ФЗ проекта.

Не отправляйте в prompt:

• пароли;
• API-ключи;
• private keys;
• полные production .env;
• платёжные данные;
• персональные данные без правового основания;
• документы, которые нельзя передавать внешнему обработчику.

Gateway как дополнительная зависимость

Единый API упрощает интеграцию, но добавляет ещё один уровень:

приложение
    ↓
Рег.облако AI API
    ↓
маршрутизация / биллинг / ограничения gateway
    ↓
upstream model

Ошибка может возникнуть:

• у приложения;
• на gateway;
• у поставщика модели;
• в сети;
• при биллинге или лимите;
• из-за удаления модели из каталога.

Для критичной функции нужны:

• timeout;
• ограниченный retry с backoff и jitter;
• circuit breaker;
• резервная модель;
• при необходимости резервный provider;
• наблюдаемость по model ID;
• degraded mode без LLM.

Fallback между моделями

Fallback нельзя делать простой заменой строки model.

У моделей могут различаться:

• context window;
• tool calling;
• JSON Schema;
• системные ограничения;
• мультимодальность;
• качество русского языка;
• latency;
• цена;
• формат usage;
• политика безопасности.

Безопасная схема:

primary model
    ↓ timeout / 429 / retryable 5xx
классификация ошибки
    ↓
fallback model с совместимым contract
    ↓
валидация результата
    ↓
метрика degraded mode

Производительность

Для каждой модели измеряйте:

• DNS/TLS/connect time;
• time to first token;
• полное время ответа;
• tokens per second;
• p50/p95/p99;
• долю 429 и 5xx;
• стабильность streaming;
• скорость в разные часы;
• маршруты из нужных регионов;
• изменение latency при большом контексте.

Один быстрый запрос в Sandbox не описывает production-поведение API.

Сравнение с Timeweb AI Gateway

У SEO Recipes уже есть отдельный материал про Timeweb Cloud AI Gateway.

Сравнивать сервисы стоит по одной методике:

Критерий	Что проверить
Каталог	реальные model IDs и скорость обновления
Цена	input/output, дополнительные комиссии, валюта
API	Chat Completions, Responses, tools, JSON, embeddings
Ограничения	context, output, RPS/RPM, concurrency
Качество	единый evaluation-набор
Производительность	TTFT, p95, tokens/sec
Надёжность	429/5xx, fallback, status page
Privacy	upstream, логирование, регионы обработки
Биллинг	детализация usage и лимиты по ключам
Поддержка	скорость и качество технического ответа

Не стоит выбирать gateway только по числу моделей в рекламном анонсе.

План практического теста

1. Получить Base URL, model IDs и актуальные цены.
2. Создать отдельный staging API-ключ.
3. Выбрать 3–5 моделей разных ценовых классов.
4. Подготовить одинаковый evaluation-набор.
5. Проверить обычный chat и streaming.
6. Проверить JSON и tools, если они нужны проекту.
7. Отправить граничные и ошибочные запросы.
8. Сверить usage в ответе и панели.
9. Измерить p50/p95 и time to first token.
10. Проверить лимит расходов и ротацию ключа.
11. Уточнить privacy и upstream providers.
12. Проверить fallback на другую модель и другого поставщика.
13. Посчитать стоимость успешной задачи.

Влияние на категорию провайдера

REG.RU / Рег.облако остаётся в категории «Норм».

Новый AI API расширяет продуктовую платформу и может быть удобен для рублёвой оплаты и единой интеграции с несколькими моделями. Но он не отменяет уже зафиксированные инфраструктурные риски, включая два сбоя S3 Рег.облака 25 и 27 августа 2026 года.

AI API нужно оценивать отдельно от VPS и S3: у него другой набор upstream-зависимостей, лимитов, биллинга и требований к privacy.

Checklist

• [ ] Получены актуальные Base URL и model IDs.
• [ ] Найдена полная таблица цен input/output.
• [ ] Созданы отдельные staging и production keys.
• [ ] Проверены Chat Completions и streaming.
• [ ] Проверены tools, JSON Schema и Responses API, если нужны.
• [ ] Usage сопоставлен с биллингом.
• [ ] Измерены TTFT, p50/p95 и tokens/sec.
• [ ] Обработаны timeout, 429 и retryable 5xx.
• [ ] Fallback проверен на совместимость результата.
• [ ] Уточнены upstream providers и регионы обработки.
• [ ] Уточнены logging, retention и использование данных.
• [ ] Настроены лимиты расходов и алерты.
• [ ] Посчитана стоимость успешной задачи.

Источники

• Рег.облако перевело доступ к нейросетям на оплату по токенам, 27 августа 2026 года
• Рег.облако запустило собственную ИИ-платформу, 17 апреля 2026 года
• Карточка REG.RU и Рег.облака