> Для получения чистого Markdown любой страницы добавьте .md к URL страницы.  
> Для полного индекса документации см. https://api.vega.chat/docs/llms.txt.  
> Для полного содержания документации см. https://api.vega.chat/docs/llms-full.txt.  
> Для интеграции AI‑клиентов (Claude Code, Cursor и др.) подключитесь к MCP‑серверу по адресу https://api.vega.chat/docs/_mcp/server.

# Интеграция провайдера

## Для провайдеров

Если вы хотите стать поставщиком моделей и продавать вывод на VEGA, [заполните нашу форму](https://api.vega.chat/how-to-list), чтобы начать.

Чтобы иметь право предоставлять вывод на VEGA, вы должны иметь следующее:

### 1. Конечная точка списка моделей

Вы должны реализовать конечную точку, которая возвращает все модели, которые должны обслуживаться VEGA. На этой конечной точке, пожалуйста, верните список всех доступных моделей на вашей платформе. Ниже приведён пример формата ответа:

```json
{
  "data": [
    {
      // Required
      "id": "anthropic/claude-sonnet-4",
      "hugging_face_id": "", // required if the model is on Hugging Face
      "name": "Anthropic: Claude Sonnet 4",
      "created": 1690502400,
      "input_modalities": ["text", "image", "file"],
      "output_modalities": ["text", "image", "file"],
      "quantization": "fp8",
      "context_length": 1000000,
      "max_output_length": 128000,
      "pricing": {
        "prompt": "0.000008", // pricing per 1 token
        "completion": "0.000024", // pricing per 1 token
        "image": "0", // pricing per 1 image
        "request": "0", // pricing per 1 request
        "input_cache_read": "0" // pricing per 1 token
      },
      "supported_sampling_parameters": ["temperature", "stop"],
      "supported_features": [
        "tools",
        "json_mode",
        "structured_outputs",
        "web_search",
        "reasoning"
      ],
      // Optional
      "description": "Anthropic's flagship model...",
      "deprecation_date": "2025-06-01T15:00:00Z", // ISO 8601 date or UTC hour
      "is_ready": true, // false to keep the model staged-but-hidden on VEGA
      "openrouter": {
        "slug": "anthropic/claude-sonnet-4"
      },
      "datacenters": [
        {
          "country_code": "US" // `Iso3166Alpha2Code`
        }
      ]
    }
  ]
}
```

Поле `id` должно быть точным идентификатором модели, который VEGA будет использовать при вызове вашего API.

Поля `pricing` указаны в строковом формате, чтобы избежать проблем с точностью плавающей запятой, и должны быть в RUB.

Допустимые значения квантизации: `int4`, `int8`, `fp4`, `fp6`, `fp8`, `fp16`, `bf16`, `fp32`.

Допустимые параметры семплинга: `temperature`, `top_p`, `top_k`, `min_p`, `top_a`, `frequency_penalty`, `presence_penalty`, `repetition_penalty`, `stop`, `seed`, `max_tokens`, `logit_bias`.

Допустимые функции: `tools`, `json_mode`, `structured_outputs`, `logprobs`, `web_search`, `reasoning`.

#### Тарифные уровни

Для моделей с разным ценообразованием в зависимости от длины контекста (например, цены за длинный контекст) вы можете предоставить `pricing` в виде массива уровней вместо одного объекта:

```json
{
  "pricing": [
    {
      "prompt": "0.000002", // базовый уровень цены за 1 токен
      "completion": "0.000012", // базовый уровень цены за 1 токен
      "image": "0.01", // цена за 1 изображение (только базовый уровень)
      "request": "0", // цена за 1 запрос (только базовый уровень)
      "input_cache_read": "0.000001" // базовый уровень цены за 1 токен
    },
    {
      "prompt": "0.000004", // уровень цены за длинный контекст за 1 токен
      "completion": "0.000018", // уровень цены за длинный контекст за 1 токен
      "input_cache_read": "0.000002", // уровень цены за длинный контекст за 1 токен
      "min_context": 200000 // минимальное количество входных токенов, при котором применяется этот уровень
    }
  ]
}
```

При использовании тарифных уровней первый уровень (индекс 0) — базовое ценообразование, которое применяется, когда количество входных токенов ниже порога `min_context`. Второй уровень применяется, когда количество входных токенов достигает или превышает значение `min_context`.

Ограничения:

* В настоящее время VEGA поддерживает до 2 тарифных уровней.  
* Поля `image` и `request` поддерживаются только в базовом уровне (индекс 0) и будут игнорироваться, если они указаны в других уровнях.

#### Дата устаревания

Если модель запланирована к устареванию, включите поле `deprecation_date` в формате ISO 8601. VEGA принимает либо только дату, либо конкретный час UTC:

```json
{
  "id": "anthropic/claude-2.1",
  "deprecation_date": "2025-06-01"
}
```

* Используйте `YYYY-MM-DD` для дат без времени. Даты без времени по умолчанию считаются 13:00 UTC в указанный день.  
* Используйте `YYYY-MM-DDTHH:00:00Z`, чтобы указать конкретный час UTC, например `2025-06-01T15:00:00Z`.

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

#### Управление запуском с помощью `is_ready`

По умолчанию, когда монитор провайдера VEGA обнаруживает новую модель в вашем ответе `/v1/models`, он автоматически ставит её в очередь, запускает базовые тесты и делает её доступной (разворачивает) после успешного прохождения тестов и настройки цен. Если вам нужно загрузить модель до анонса — или временно вывести модель из сети — установите необязательное булево поле `is_ready`:

```json
{
  "id": "your-org/upcoming-model",
  "is_ready": false
}
```

Поведение:

* `is_ready: false` оставляет только что поставленные в очередь конечные точки скрытыми, даже если все базовые тесты пройдены, и автоматически скрывает любые совпадающие конечные точки, которые сейчас находятся в сети. Используйте это, чтобы загрузить модель заранее или временно вывести живую модель из сети в координации с нами.  
* `is_ready: true` и отсутствие поля сохраняют поведение по умолчанию — автоматическое развёртывание и автоматическое раскрытие.

### 2. Автопополнение или выставление счёта

Чтобы VEGA могла использовать провайдера, мы должны иметь возможность автоматически оплачивать вывод. Это можно сделать через автопополнение или выставление счёта.

### 3. Мониторинг доступности и маршрутизация трафика

VEGA автоматически мониторит надёжность провайдера и корректирует маршрутизацию трафика на основе метрик доступности. Доступность вашей конечной точки рассчитывается как: **успешные запросы ÷ общее количество запросов** (исключая ошибки пользователей).

**Ошибки, влияющие на доступность:**

* Проблемы аутентификации (401)  
* Ошибки оплаты (402)  
* Модель не найдена (404)  
* Все серверные ошибки (500+)  
* Ошибки в середине потока  
* Успешные запросы с ошибочными причинами завершения

**Ошибки, НЕ влияющие на доступность:**

* Плохие запросы (400) — ошибки ввода пользователя  
* Переполненные полезные нагрузки (413) — ошибки ввода пользователя  
* Ограничение скорости (429) — отслеживается отдельно  
* Географические ограничения (403) — отслеживается отдельно

**Пороги маршрутизации трафика:**

* **Минимальные данные**: требуется ≥ 100 запросов, прежде чем начнётся расчёт доступности  
* **Нормальная маршрутизация**: ≥ 95 % доступности  
* **Сниженный статус**: 80‑94 % доступности → получает более низкий приоритет  
* **Статус «Отключено»**: < 80 % доступности → используется только как резерв

Эта система гарантирует, что трафик автоматически направляется к самым надёжным провайдерам, давая временным проблемам время для решения.

### 4. Метрики производительности

VEGA публично отслеживает TTFT (время до первого токена) и пропускную способность (токены/секунда) для всех провайдеров на каждой странице модели.

Пропускная способность рассчитывается как: **выходные токены ÷ время генерации**, где время генерации включает задержку получения (время от запроса до первого ответа сервера), TTFT и время стриминга. Это значит, что любые очереди на вашей стороне отразятся в метриках пропускной способности.

Чтобы ваши метрики оставались конкурентоспособными:

* При высокой нагрузке возвращайте 429 сразу, а не ставьте запросы в очередь  
* Стримьте токены, как только они становятся доступны  
* Если обработка занимает время (например, у моделей рассуждения), отправляйте комментарии SSE как keep‑alive, чтобы мы знали, что вы всё ещё работаете над запросом. Иначе мы можем отменить запрос из‑за таймаута и переключиться на другого провайдера

### 5. Auto Exacto: маршрутизация трафика с вызовами инструментов

[Auto Exacto](/docs/guides/routing/auto-exacto) — это шаг маршрутизации, который автоматически переупорядочивает провайдеров для всех запросов, включающих инструменты. Он запускается по умолчанию для каждого запроса с вызовом инструмента и может изменить объём трафика, приходящего к вашим конечным точкам.

#### Как меняется трафик

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

Трафик без вызовов инструментов **не затрагивается** Auto Exacto — он продолжает следовать стандартной [маршрутизации, основанной на цене](/docs/guides/routing/provider-selection#price-based-load-balancing-default-strategy).

#### Как определяются факторы ранжирования

Auto Exacto использует три класса сигналов, все полученные из реального трафика и оценок ваших конечных точек:

* **Пропускная способность** — реальное количество токенов в секунду, измеренное по фактическим запросам, проходящим через вашу конечную точку (видно на вкладке [Performance](/aimodels) любой страницы модели).  
* **Успешность вызовов инструментов** — насколько надёжно ваша конечная точка завершает вызовы инструментов без ошибок (также видно на вкладке Performance).  
* **Данные бенчмарков** — результаты внутренних оценок, которые мы проводим над конечными точками провайдеров. Мы активно собираем эти данные и скоро сделаем их доступными в вашем личном кабинете VEGA, чтобы вы могли просматривать их и запускать те же бенчмарки у себя.

Эти же метрики доступны в вашем личном кабинете VEGA. После подключения мы можем предоставить вам к ним доступ.

#### Как работают пороги понижения приоритета

Для каждой модели мы сравниваем значения сигналов каждого провайдера с группой провайдеров, обслуживающих эту модель. Мы используем подход **медиана + MAD** (медианное абсолютное отклонение), а не простые средние, что делает пороги стабильными даже при наличии сильных выбросов.

Каждый сигнал имеет свою чувствительность:

* **Точность бенчмарка** — провайдеры, отстающие более чем **1 стандартное отклонение** от медианы, понижаются в приоритете. Это самый строгий порог, потому что оценки бенчмарков сильно сгруппированы, и небольшие различия имеют значение.  
* **Пропускная способность** — провайдеры, отстающие более чем **1,5 стандартных отклонения** от медианы, понижаются. Более широкий порог учитывает естественные колебания пропускной способности из‑за нагрузки в разное время суток.  
* **Успешность вызовов инструментов** — провайдеры, отстающие более чем **2 стандартных отклонения** от медианы, понижаются. Успешность вызовов инструментов обычно близка к 100 %, поэтому более широкий порог помогает избежать штрафов за обычный шум, но всё же ловит действительно сломанные конечные точки.

Для расчёта статистических порогов требуется минимум **4 провайдера**, обслуживающих одну и ту же модель. При меньшем количестве ни один сигнал не понижается.

Конечные точки распределяются по одной из трёх категорий:

1. **Хорошие** — достаточно данных и нет сигналов ниже порога. Эти получают высший приоритет маршрутизации.  
2. **Недостаточно данных** — недостаточно недавнего трафика для оценки. Они идут после известных хороших провайдеров, но перед пониженными. Для оценки требуется минимум 100 общих запросов (за 30‑минутный интервал) и 200 запросов с вызовами инструментов (за 2‑часовой интервал).  
3. **Пониженные** — один или несколько сигналов упали ниже порога. Эти маршрутизируются последними.

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

#### Как улучшить ваш рейтинг

Чтобы максимизировать объём трафика с вызовами инструментов, направляемого к вашим конечным точкам:

* **Поддерживайте высокую надёжность вызовов инструментов** — обеспечьте, чтобы ваша конечная точка постоянно возвращала корректно сформированные ответы на вызовы инструментов.  
* **Оптимизируйте пропускную способность** — минимизируйте очереди и стримьте токены, как только они доступны (см. раздел [Метрики производительности](#4-метрики-производительности) выше).  
* **Возвращайте 429 при нагрузке** — вместо очереди и снижения пропускной способности возвращайте ошибки ограничения скорости, чтобы мы могли переключиться на другого провайдера, а ваши метрики оставались здоровыми.

Для полной пользовательской документации по Auto Exacto см. [Auto Exacto](/docs/guides/routing/auto-exacto).