Коли успішний запит — усе одно збій
Уяви, що ти тижнями розмовляєш з одним і тим самим персонажем. Його голос тобі знайомий. Його мова послідовна. Його відповіді гострі й живі.
А потім, хоча ні персонаж, ні модель не змінилися, щось ніби не так.
Наступна відповідь починається лише через десять секунд. Функція, яка залежить від структурованого виводу, раптом ламається. Персонаж починає верзти казна-що, вставляє фрагменти іншою мовою або відповідає в стилі, що ніби належить значно слабшій моделі.
З погляду сервера нічого не зламалося. API повернув 200 OK. Токени надійшли. Запит підлягав оплаті.
З погляду користувача модель просто стала гіршою.
Саме через цей розрив ми створили для Reverie систему канаркових перевірок провайдерів і карантину маршрутизації.
Одна назва моделі, багато середовищ обслуговування
OpenRouter — наш основний шлюз до моделей. Одна з його сильних сторін у тому, що одну модель можуть обслуговувати багато незалежних провайдерів інференсу. Якщо один провайдер недоступний, запит може прийняти інший. Це дає нам більше потужностей, конкурентні ціни й кращу стійкість, ніж залежність від однієї кінцевої точки.
Водночас це створює приховану змінну.
Назва моделі може залишатися тією самою, але інфраструктура, яка її обслуговує, може змінюватися від запиту до запиту. Кожен провайдер може використовувати інший рушій інференсу, конфігурацію обладнання, рівень квантизації, парсер, шаблон чату, чергу або додатковий шар політик.
У документації OpenRouter про маршрутизацію між провайдерами пояснюється, що маршрутизація за замовчуванням враховує нещодавню доступність і ціну, а інші провайдери слугують резервними. Це важливі сигнали — але кінцева точка може бути онлайн, недорогою і все одно давати неприйнятний для конкретного продукту результат.
OpenRouter також публічно писав про вимірювані відмінності між провайдерами, які обслуговують ту саму модель. Теоретично однакові ваги з однаковою точністю мали б поводитися однаково. На практиці обслуговування великої моделі — складна справа, і відмінності виникають.
Що ми маємо на увазі під «деградацією моделі»
«Деградація моделі» — це не один стандартизований діагноз, і вона не означає автоматично, що провайдер навмисно підмінив модель на меншу.
Ми використовуємо цей термін в операційному сенсі: кінцева точка обслуговування деградувала, коли вона більше не зберігає поведінку, можливості чи інтерактивну швидкодію, яких ми очікуємо від запитаної моделі на репрезентативних промптах, — навіть якщо технічно запит може бути успішним.
Для Reverie найочевидніші форми такі:
- Деградація затримки — з'єднання встановлюється, але час до першого токена стає настільки довгим, що руйнує відчуття живої розмови.
- Деградація можливостей — кінцева точка, від якої очікується підтримка структурованого виводу, повертає пошкоджений текст або перестає відповідати схемі.
- Поведінкова деградація — відповіді стають пошкодженими, незв'язними, несподівано повторюваними або помітно зсуваються в іншу мову.
- Розбіжність політик — хост вище за ланцюжком додає власний шар фільтрації, перетворюючи сцену, яку підтримує Reverie, на відмову, порожню відповідь або обрізану репліку.
Причин може бути багато. Квантизація з нижчою точністю може впливати на складні промпти, як зазначають і документація OpenRouter, і опубліковані дослідження квантизації. Але квантизація — не універсальне пояснення: баги рушіїв інференсу, парсери інструментів, помилки токенізатора чи шаблону чату, перевантажені черги та проміжне ПЗ на боці провайдера можуть бути не менш важливими. OpenRouter помітив, що саме для викликів інструментів реалізації парсерів часто є більшим джерелом відмінностей, ніж сама лише точність.
Важливе запитання не «Яка причина звучить найпідозріліше?», а «Чи можемо ми ізолювати кінцеву точку й відтворити збій?»
Два випадки, які зробили проблему відчутною
Для нас це не було теоретичним питанням.
В одному порівнянні із закріпленим провайдером той пошкоджував початок 19 із 20 відповідей, вставляючи розділовий знак або фрагмент стороннього токена. На чотирнадцяти інших хостах, що обслуговували ту саму модель, проблема виникла 0 разів із 49 відповідей. У рольовій грі, де першим символом часто є Markdown-маркер виділення, один зайвий байт міг ще й зламати форматування всієї відповіді.
В іншому тесті одна кінцева точка видала сильне змішування португальської та іспанської в 3 із 3 генерацій. Той самий промпт залишався португальською на офіційному хості моделі та на інших протестованих хостах із тим самим класом точності. Тож пояснення «модель просто непослідовна» не годилося; дефект ішов за кінцевою точкою обслуговування.
Ці збої підступні, бо не обов'язково викидають винятки. Традиційний моніторинг аптайму бачить здоровий API. Користувач бачить персонажа, який раптом не може нормально говорити.
Наша відповідь: тестувати кожен маршрут, а не лише модель
Кожні тридцять хвилин наша канаркова перевірка знаходить активних провайдерів, які обслуговують стандартну модель чату Reverie. Потім вона надсилає невеликий набір синтетичних запитів кожному провайдеру, закріплених лише за ним, із вимкненими резервними маршрутами.
Закріплення має значення. Якщо дозволити перевірці перейти на резервний маршрут, здоровий другий провайдер може приховати збій першого. Нам потрібно точно знати, яке середовище обслуговування дало результат.
Система перевіряє чотири вузькі контракти, які можна оцінити автоматично.
1. Час до першого токена
Для потокової розмови пропускна здатність — лише половина досвіду. Перший токен визначає, як довго користувач дивиться на індикатор завантаження.
Ми вимірюємо його безпосередньо з потоку. Провайдер, який не видає тексту протягом десяти секунд, не проходить перевірку затримки. Поріг навмисно щедрий, і одного повільного раунду недостатньо, щоб прибрати хост; тимчасове навантаження на чергу трапляється.
2. Фільтрація та мовчазні відмови
Ми надсилаємо фіксоване продовження рольової гри, репрезентативне для трафіку, який підтримує Reverie. Перевірка аналізує причину завершення, шаблони відмов із високою впевненістю та порожній вивід.
Також ми запускаємо цю перевірку на хостах, про які відомо, що вони фільтрують, як на позитивних контролях. Якщо контроль несподівано проходить, ми не вітаємо всіх інших провайдерів — ми позначаємо слабкою саму перевірку. Тест, який більше не може виявити свій відомий режим збою, не є доказом здоров'я.
3. Структурований вивід
Ми запитуємо невеликий об'єкт із фіксованою схемою й валідуємо результат. Транспортну помилку та пошкоджений вивід ми розглядаємо по-різному: обірване з'єднання свідчить про те, що провайдер був недосяжний, а успішна генерація, яка не відповідає схемі, — це доказ регресії можливостей.
Ця відмінність важлива. «Кінцева точка заявляє, що підтримує параметр» і «кінцева точка надійно його дотримується» — це не та сама обіцянка.
4. Мовна цілісність
Reverie підтримує 17 мов інтерфейсу, тож тест лише англійською пропустив би частину збоїв, з якими реально стикаються наші користувачі.
Канаркова перевірка по черзі проходить підтримувані локалі, використовуючи синтетичні промпти для рольової гри. Локальний детермінований детектор мови шукає впевнене перемикання мови всієї відповіді, стійке змішування мов і очевидне пошкодження кодування. Він не надсилає на перевірку реальні розмови й не просить іншу модель винести суб'єктивне судження.
Неоднозначний або дуже короткий вивід вважається непереконливим, а не збоєм. Коли виявлено мовний збій, канаркова перевірка одразу запускає дві підтверджувальні спроби й вимагає більшості. Та сама локаль повторюється в наступному раунді, щоб провайдер не міг уникнути правила послідовних раундів лише тому, що ротація пішла далі.
Ми спроєктували систему так, щоб вона не довіряла власним висновкам
Автоматичне вилучення потужностей інференсу корисне, але хибне спрацювання може спричинити більший збій, ніж дефект, який воно мало усунути. Тож канаркова перевірка має кілька гальм:
- Транспортні помилки не вважаються збоями якості. Тайм-аути, обмеження частоти запитів і відповіді 5xx заморожують оцінку замість того, щоб подовжувати серію до призупинення.
- Одного поганого раунду недостатньо. Провайдер має провалити два послідовні півгодинні раунди.
- Спостереження і застосування розділені. Ми можемо запускати всю систему в режимі спостереження, фіксувати, які хости було б призупинено, сповіщати адміністраторів і вимірювати хибні спрацювання, перш ніж увімкнути автоматичні дії.
- Потужності мають нижню межу. Канаркова перевірка не призупинить провайдера, якщо після цього залишиться менше ніж два продакшн-хости. Натомість вона сповістить адміністратора.
- Відновлення перевіряється. Призупинені провайдери залишаються доступними для перевірок. Два послідовні чисті раунди достроково повертають хост.
- Повторні збої посилюються поступово. Призупинення триває один день за перший інцидент, три дні за наступний і сім днів за кожен подальший. Після чотирнадцяти чистих днів історія порушень забувається, і шкала скидається.
Мета — не покарати провайдерів. Мета — відвести трафік користувачів від маршруту, який відтворювано нездоровий, залишивши чіткий шлях назад, коли проблему виправлять.
Три рівні захисту
Остаточне рішення про маршрутизацію поєднує три види виключень:
- Перевірені вбудовані виключення для дефектів або розбіжностей політик, які ми виміряли й не хочемо випадково повернути.
- Виключення через інциденти під час роботи, які адміністратор може додати негайно, не чекаючи на розгортання.
- Тимчасові призупинення за канарковою перевіркою для провайдерів, які перетнули автоматичний поріг збоїв.
Коли Reverie формує запит, ці списки об'єднуються в параметр OpenRouter provider.ignore. Користувачеві не треба повторювати спроби, доки випадок не обере кращого провайдера; нездоровий маршрут просто вилучається з розгляду.
Кожне автоматичне рішення записується, адміністратори отримують сповіщення про суттєві зміни стану, а призупинення можна зняти вручну, коли це потрібно.
Що ця система гарантує — і чого не гарантує
Канаркова перевірка навмисно вузька. Вона може за допомогою коду оцінити затримку, валідність схеми, фільтрацію з високою впевненістю, мовну цілісність і стан кодування. Вона не вдає, що може оцінити, чи достатньо персонаж смішний, чи достатньо він емоційно чуйний або чи вірний складній особистості.
Ці ширші питання й далі потребують оцінювань, побудованих на репрезентативних промптах, людської перевірки, телеметрії з продакшну і — найголовніше — повідомлень від користувачів.
Ця система також не означає, що кожна дивна відповідь доводить деградацію моделі. Генеративні моделі ймовірнісні. У довгій розмові може накопичуватися суперечливий контекст. Опис персонажа може містити інструкції, що конкурують між собою. Іноді дивна відповідь — це просто дивна відповідь.
Змінилося те, що «та сама модель» більше не є кінцем нашого розслідування. Тепер ми можемо ізолювати маршрут обслуговування, відтворити об'єктивні збої й тримати від нього подалі уражений трафік.
Надійність — це збереження досвіду
Маршрутизація через кількох провайдерів і далі цінна. Вона дає Reverie потужності й стійкість, щоб розмови залишалися доступними, коли окремі кінцеві точки падають.
Але стійкість — це не просто отримання HTTP-відповіді. Відповідь, яка надходить надто пізно, втрачає потрібну структуру, відмовляє в підтримуваному контенті або раптом перемикає мову, не є здоровим результатом лише тому, що в рахунку написано, що запит був успішним.
Для продукту з AI-персонажами надійність означає щось людяніше: персонаж має залишатися собою, хоч би яка машина говорила за нього.
Саме цей стандарт і захищають наші нові запобіжники маршрутизації.
Якщо ти помітиш раптову зміну якості чи мови відповідей, будь ласка, надішли нам повідомлення з назвою моделі й приблизним часом. Такі повідомлення допомагають нам пов'язати те, що ти побачив, із конкретним маршрутом, який обслуговував запит.