API & workloads
Один API для разных классов AI-задач
Gateway унифицирует клиентский контракт, но сохраняет различия моделей: modality, chat template, context policy и post-processing настраиваются отдельно.
Главный принципGateway не эмулирует возможности, которых нет у модели. Он маршрутизирует, ограничивает и приводит поддерживаемый результат к знакомому контракту.
Новое в v0.6.0
Изображения, visual usage и правила reasoning
01V4.1 Flash · vLLM 0.32DeepSeek: изображения по opt-in
Текст включён по умолчанию. Chat image_url и Responses input_image требуют совместимого vision-checkpoint, tokenizer и явной политики модели. Этот optional backend не принимает audio, video, PDF или embeddings; GPU-инференс нужно проверить отдельно.
02available · partial · unavailableФактический visual usage
Проверенные processor embedding_positions дают фактические счётчики отдельно для основного запроса и preprocessing. Оценочные резервы Gateway остаются отдельными. Неизвестное значение не равно нулю; эти счётчики не измеряют стоимость или GPU-время.
03reasoning.effort_mapМодельное переназначение effort
Одношаговая подстановка действует только для выбранной модели; целевой effort проверяется её шаблоном. Отсутствие effort сохраняет defaults. Нужен включённый thinking; constrained JSON отключает его.
04triton-gateway status / restartОтдельное обслуживание Gateway
CLI показывает состояние и перезапускает только Gateway, сохраняя Triton и загруженные модели. Текущие HTTP/SSE прерываются; это не zero-downtime restart.
API surface
Поддерживаемый API surface и роль gateway
Проведите влево, чтобы увидеть остальные столбцы →
Поддерживаемый API surface и роль gateway| Класс | Endpoint | Назначение | Streaming | Что делает gateway |
|---|
| OpenAI-compatible subset | POST /v1/responses · /responses | Текст, изображения и функции | Responses SSE | Stateless input, text.format, token budget, LoRA и cancellation |
| OpenAI-compatible | POST /v1/chat/completions | Chat, tools и media | SSE | Chat template, response_format (json_object · json_schema), seed, context, reasoning, media routing, cancellation |
| OpenAI-compatible | GET /v1/models | Список моделей | — | Нормализует модели, известные Triton repository |
| OpenAI-compatible | POST /v1/embeddings | Text embeddings | — | Маршрутизирует pooling-модель и OpenAI-style input |
| Gateway extension | POST /v1/hybrid_embeddings | BGE-M3 dense + sparse | — | Проверяет output_types и маршрутизирует native pooling или Python fallback |
| Gateway API | POST /rerank · /v1/rerank · /v2/rerank | Reranking | — | Bounded micro-batching, scoring, selection strategy, metadata и threshold |
| Operations | GET /health · /ready · /metrics · /docs | Эксплуатация | — | Process health, Triton readiness, gateway metrics и OpenAPI docs |
Workload matrix
Как обрабатываются разные входы
Проведите влево, чтобы увидеть остальные столбцы →
Как обрабатываются разные входы| Нагрузка | Backend / поддержка | Pipeline | Ключевое ограничение |
|---|
| Text chat | Triton vLLM / multimodal | Messages → chat template → tokens | Context и output reserve должны помещаться в max_model_len |
| Images | Нативный vLLM input; DeepSeek — opt-in | Fetch/decode → limits → model input | Совместимая vision-модель и явная политика; DeepSeek требует совместимого vision-checkpoint |
| Video · Chat | Native или frame pipeline | Frames → chunking → reduce | FPS, frames и pixel budget ограничиваются |
| Audio · Chat | Native или local ASR | Decode → ASR → chat | Нужна audio-capable модель или настроенная ASR |
| PDF · Chat | Text / vision / retrieval | Extract/render → chunks → map/reduce | Pages, pixels, chunks и token budget ограничиваются |
| Embeddings | Pooling models | Input → Triton pooling | Зависит от загруженной embedding-модели |
| Hybrid embeddings | BGE-M3 | Input → dense + lexical sparse | Расширение gateway; для LiteLLM нужен явный pass-through |
| Rerank | Rerank models | Micro-batches → score all → selection | Selection не заменяет качество scoring-модели |
Honest boundaries
Что проект намеренно не делает
×Функции выполняет клиент
Chat возвращает tool_calls; Responses — function_call. Клиент выполняет функцию и возвращает role: tool или function_call_output с call_id.
×Responses не хранит историю
store=false по умолчанию. История, instructions и результаты функций передаются каждый раз; store=true, background=true и previous_response_id не поддерживаются.
×Thinking по запросу — через Chat
Responses принимает текст и изображения, но не настройки thinking отдельного запроса. Аудио, видео, PDF и per-request thinking используйте через Chat; поддержка зависит от модели.
×Инфраструктура остаётся у оператора
Веса, GPU и model repository предоставляете вы. TLS, authentication, authorization и tenant quotas находятся на внешнем proxy.
◇Telemetry без payload по умолчаниюМетрики и traces не передают prompts, media, ответы, tool results или reasoning content. DEBUG_LOG_PAYLOADS включайте только для контролируемой диагностики: preview может содержать пользовательские данные.
Посмотрите, где проходит граница ответственности
Архитектурная страница показывает trust boundary, flow запроса и роль каждого компонента.