Как оценить AI API Gateway: Production Checklist

Оценивайте AI API Gateway через реальный Protocol Contract: принудительно создавайте важные Failure Modes и проверяйте Request-level Evidence. Список функций и успешный «hello world» не доказывают корректность Streaming, совместимость Tools, безопасность Fallback, точность стоимости, границы доступа и пригодный Exit Path.

Надёжный процесс разделяет два типа критериев: обязательные Gates, при провале которых кандидат исключается, и операционные качества, которые оцениваются только после прохождения всех Gates.

Сначала определите Workload Contract

Не начинайте с таблицы Vendors. Выберите репрезентативный Workload и запишите инварианты:

• точный Endpoint: Responses, Chat Completions, Embeddings, Images или другой API;
• точные Model IDs и допустимость Aliases;
• используемые Streaming и Non-streaming Modes;
• обязательные Structured Outputs, Function Calling, Hosted Tools, Reasoning и Fields;
• типичная и высокоперцентильная длина Input/Output;
• Concurrency, Request Rate, Region и User-facing Deadline;
• необходимые Usage, Cache, Cost и Request-correlation Fields;
• разрешённые Fallback Routes и запрет Model Substitution;
• требования Data Retention, Access, Residency и Deletion;
• Application Operations, создающие Side Effects.

Один Gateway может пройти для внутреннего текстового помощника и провалиться для Streaming Coding Agent. «OpenAI-compatible» недостаточно: совместимость различается по Endpoint, Event Type, Tool, Schema Keyword и Provider Route.

Если команда ещё выбирает между Proxy и Model-aware Control Plane, начните с LLM Proxy и AI Gateway. Этот Checklist предполагает, что Gateway уже нужен, и проверяет конкретную реализацию.

Примените быстрые критерии исключения

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

Gate	Условие немедленного исключения	Требуемое доказательство
Protocol	Необходимый Request Field, Output Item или Stream Event теряется либо неверно преобразуется	Очищенная Request/Response пара и Parser Result
Model Identity	Requested Model незаметно меняется	Attempt Record с запрошенной и фактической моделью
Streaming	Полный Buffering, потеря Cancellation или повреждение Tool Argument Fragments	Timestamped Event Sequence и Cancel Trace
Authentication	Browser или Workload Client получает Provider Credentials	Credential Flow и реальная Key Rotation
Tenant Isolation	Один Project видит или использует Keys, Usage, Logs другого	Проверка с реально изолированными Accounts
Cost Evidence	Final Charge нельзя связать с Model, Route, Price Basis и Usage	Reconciled Ledger одного Request
Failure Safety	Partial Stream прозрачно повторяется или Cancel запускает новый Attempt	Принудительные Partial Stream и Cancellation Traces
Export and Exit	Configuration и Contract нельзя восстановить без переписывания приложения	Export Sample и Provider-native Rollback Drill

Провал Mandatory Gate нельзя компенсировать высоким общим баллом. Хороший Dashboard не исправляет Tenant Isolation, низкая цена — неверный Tool Contract.

Создайте небольшой Protocol Conformance Corpus

Используйте детерминированные несекретные Inputs и храните Expected Wire Behavior под Version Control. Corpus должен вызывать реальный Endpoint; не Mock Provider и не копируйте Conversion Logic как Test Oracle.

Case	Request	Обязательное наблюдение
Basic Non-streaming Text	Pinned Model и фиксированный Prompt	Корректные Status, Model Identity, Text Location, Usage, Request ID
Streaming Text	Тот же Prompt со Streaming	Упорядоченные Events, First Effective Output, Final Event, Cancellation
Structured Output	Strict Schema с Required и additionalProperties: false	Валидный Output или явный Unsupported Error, без Silent Downgrade
Function Calling	Одна Read-only Function и возвращённый Result	Function Name, JSON Arguments, Call ID Correlation, Final Answer
No-tool Path	Tools объявлены, но не нужны	Обычный Text без выдуманного Tool Call
Invalid Field	Намеренно Unsupported или Malformed Request	Стабильный Client Error, Fallback не скрывает дефект
Long Input Boundary	Input ниже и выше Limit	Документированное принятие или явный отказ, без Silent Truncation
Usage Detail	Request с Cache или Reasoning Usage	Fields проходят Route и сходятся с Billing Record
Cancellation	Cancel после подключения и после First Output	Upstream Work прекращается, новый Fallback Attempt не начинается
Partial Stream	Ошибка после Effective Output	Один явный Partial Failure, без невидимого второго ответа

Запускайте Cases на каждой Route, способной обслужить Workload. Успех Primary Route не квалифицирует Fallback. Structured Outputs Guide и Function Calling Comparison дают Field-level Cases.

Записывайте Gateway Version, Route Configuration Version, Model ID, Provider, Region, Timestamp и Sanitized Result Hash. Повторяйте перед Rollout и после существенного Route Change.

Тестируйте Routing и Failure Behavior, а не только успех

Reliability Claim имеет смысл лишь при видимой Failure Policy. До Production создайте:

• недоступность Primary Route до Headers;
• Provider Rate Limit с Retry-After и без него;
• Upstream Authentication или Account Failure;
• Slow Headers и Slow First Effective Output;
• Malformed Provider Response;
• Caller Cancellation при Pending Upstream;
• Connection Loss после начала видимого Output;
• исчерпание всех допустимых маршрутов.

Для каждого Case сохраните Attempt Order, Selected Route, Status, Timing, факт начала Output, Terminal Reason, Usage и Cost. Requested Model и Protocol должны сохраняться без отдельной Model-substitution Policy.

Измерьте Attempt Amplification между SDK, Application, Gateway и Provider. Один слой отвечает за немедленный Same-contract Fallback, а Application решает, можно ли повторять User Action целиком. AI API Fallback Strategy содержит фазовую Failure Matrix и Retry Budget.

Latency тоже требует точности: сравнивайте Upstream Headers, First SSE Event, First Effective Output, First Visible Text, Completion и Visible Output Speed при реалистичной Concurrency. Не принимайте единую среднюю «Latency» без определения. См. AI API Latency Metrics.

Согласуйте Usage и Cost на уровне Request

Проследите несколько завершённых Requests по всей цепочке:

application request ID
  → gateway attempt sequence
  → selected model and route
  → provider or normalized usage
  → applicable price basis
  → final recorded charge

Оценка должна ответить:

• Представлены ли Input, Output, Cached, Reasoning и Tool-related Units?
• Какие значения пришли от Provider, а какие Estimated?
• Когда выбирается Model Price и фиксируется ли для Request?
• Как Group, Service Tier, Discount или Surcharge меняют User Charge?
• Какие Failed Attempts создают Provider Cost и как учитываются?
• Скрывает ли успешный Fallback предыдущие Billable Attempts?
• Явны ли Currency Conversion и Rounding Rules?
• Может ли Finance воспроизвести Daily Total из Immutable Records?

Проверьте Normal Completion, Same-contract Fallback, Cancelled Request и Upstream Error. Dashboard Total недостаточен; требуется защищаемый Per-request Record. AI API Cost Tracking разделяет Provider Usage, Platform Pricing, Customer Charge и Supplier Cost.

Не сравнивайте Savings без фиксации Model, Workload, Cache Behavior, Output Length, Failure Rate и Provider Price Basis. Кажущаяся низкая стоимость может означать Missing Usage или Silent Model Substitution.

Проверьте Security и Data Boundary

Нарисуйте реальный Data Flow от Client через Gateway к каждому Provider. Для каждого Hop отметьте доступ к Credentials, Request/Response Content, Metadata и Administrative Configuration.

Как минимум проверьте:

• Provider Credentials хранятся Server-side, At-rest Encrypted и не возвращаются обычным Clients;
• Application Keys имеют Scope по Project/Workload и независимый Revoke;
• Authorization выполняется Server-side на всех Management и Log Endpoints;
• Logs не содержат полные API Keys, а Prompt/Response Retention явно управляется;
• Support Access ограничен и привязан к Actor;
• Configuration Changes содержат Actor, Time, Before/After и Rollback Evidence;
• Exported Traces очищены от Secrets и личных/проприетарных данных;
• Deletion и Retention можно продемонстрировать;
• Region и Subprocessor Claims соответствуют реально использованной Route;
• Abuse Limits по возможности применяются до дорогой Upstream Work.

Уточните поведение при Key Rotation, Operator Departure, компрометации Application Key и утечке Provider Key. Проведите Rotation/Revocation с реальными изолированными Test Credentials, не копируя Production Secret.

Gateway не делает небезопасные Application Tools безопасными. Tool Authorization, Transactionality, Approval и Idempotency остаются Application Responsibilities. AI API Key Security and Cost Controls разделяет Credentials и Workload Limits.

Оцените Operational Control Plane

Data Plane может работать, а Control Plane — создавать операционный риск.

Область	Обязательные вопросы
Versioning	Версионируется или атрибутируется ли каждый Route, Price, Policy и Key Change?
Validation	Отклоняются ли Invalid Route и Incompatible Model до Activation?
Rollout	Можно ли сначала применить Change к малому Workload/Percentage?
Rollback	Быстро ли восстанавливается Last-known-good Configuration?
Availability	Что происходит с Existing/New Requests при недоступной Control Plane?
Health	Использует ли Channel Health свежие Evidence и виден ли Auto-disable?
Incidents	Можно ли восстановить один Request без несвязанных систем?
Limits	Остаются ли Rate/Quota Decisions корректными при Concurrency?
Change Ownership	Отделены ли Emergency Edits от Product Configuration?

Выполните настоящий Configuration Rollback и удаление Unhealthy Route. Посчитайте Operator Steps и проверьте Data-plane Behavior. Скриншот кнопки не является Drill.

Проверьте Exit Path до подписания договора

Gateway может создать зависимости от Model Aliases, Custom Headers, Proprietary Route Names, Log APIs, Normalized Error Shapes и Hosted Prompt/Tool Configuration. Определите, является каждая зависимость полезной намеренно или случайным Lock-in.

Практический Exit Drill должен:

1. экспортировать Route, Key Policy, Price и Audit Configuration в документированном формате;
2. перевести один Workload на Provider-native Test Endpoint;
3. заменить Gateway-only Headers/Aliases явной Application Configuration;
4. сохранить Request Correlation и Usage Reconciliation;
5. описать функции, требующие Redesign;
6. оценить Exit Engineering по выполненной работе, а не Sales Claim.

Exit Path не означает взаимозаменяемость со всеми Providers. Команда должна понимать своё Ownership, Ownership Gateway и способ восстановить исходный Protocol Contract.

Оценивайте только после прохождения Gates

Используйте pass/fail для Hard Boundaries и небольшую шкалу Evidence:

Балл	Значение
0	Unsupported или опровергнуто тестом
1	Claimed или показано вручную один раз, слабое Evidence
2	Воспроизводимо с Request-level Evidence
3	Воспроизводимо, Monitored и Recoverable через проверенный Control

Оценивайте Protocol Coverage, Route Reliability, Attempt Evidence, Latency Diagnostics, Usage Accuracy, Cost Reconciliation, Key Isolation, Auditability, Configuration Rollback, Supportability и Exit Effort. Взвешивайте по Workload и храните Raw Evidence рядом с каждым баллом.

Избегайте ложной точности вроде 87.4/100. Документируйте Gates, Evidence Links, Accepted Gaps и Owner, Remediation Deadline, Cost/Contract Assumptions, выбранных и отклонённых кандидатов, а также Review Date после первого Production-месяца.

Сравнивайте Build и Buy по Ownership

Важна не стоимость лицензии внутреннего решения, а ответственность, которую команда может нести постоянно.

Ответственность	Внутренняя разработка	Purchased или Managed
Protocol Updates	Отслеживать Provider Schemas и Regressions	Проверять Vendor Updates и Route Compatibility
Routing and Retry	Проектировать State Machine и Failure Evidence	Настраивать Policy и аудировать реальные Attempts
Usage and Billing	Нормализовать Usage и поддерживать Pricing Logic	Согласовывать Vendor Records и Finance Truth
Security	Хранить Secrets, изолировать Tenants, аудировать Access	Проверять Vendor Boundary и Least Privilege
Reliability	Эксплуатировать Data Plane, Control Plane и On-call	Мониторить Vendor и Integration, сохранять Exit Path
Product Support	Диагностировать все Application/Provider взаимодействия	Разделять сбои Gateway, Provider и Application

Не используйте общие зарплаты или «сэкономленные часы». Оценивайте по собственным On-call Load, Protocol-change History, Incident Frequency, Finance Requirements и Compliance Work. Managed Product также требует Accountable Internal Owner.

Точно примените Checklist к Modelflare

Текущая граница оценки Modelflare должна быть явной. Платформа предоставляет Workload API Keys, Routing Requested Model по допустимым Groups и Channels, Ordered Group Fallback для обычных Keys, Strategy-based Group Selection для Smart API Keys, Pre-upstream Group RPM Admission и Request-level Records для Usage, Cost, Status и Timing.

GPT, Codex и OpenAI Traffic являются целью полной адаптированной совместимости. Другие OpenAI-compatible Model Families следует оценивать как Raw Chat Completions Pass-through до отдельной проверки. Общая Base URL не доказывает одинаковую работу Responses, Hosted Tools, Structured Outputs или Function Calling на каждой Route.

Fallback Modelflare должен искать допустимый Path для Requested Model, а не незаметно выбирать другую модель. Channel Failover прекращается после начала Downstream Output. Проверяйте эти Claims Corpus и Failure Drills, а не принимайте как Marketing Statements.

Используйте Models & Pricing для текущей Model/Group Surface и Modelflare Docs для изолированного Test Key. Запросы должны быть несекретными, модель — точно закреплённой, а Request IDs — сохранёнными для анализа Attempts.

Финальное решение должно быть воспроизводимым: другой Engineer запускает тот же Corpus, проверяет те же Evidence Categories и понимает, почему кандидат прошёл. Это медленнее страницы сравнения, но быстрее обнаружения несовместимого Tool Contract, непроверяемого счёта или небезопасного Fallback после запуска Production Traffic.