Головна / Статті / Як обрати LLM-провайдера: обмеження, маршрутизація та оборотні рішення

Як обрати LLM-провайдера: обмеження, маршрутизація та оборотні рішення

П'ять обмежень, які вирішують вибір між закритими, open-weight і self-hosted моделями, а також код, не прив'язаний до провайдера, рівні маршрутизації, розрахунок вартості й чек-лист із безпеки.

1597 слів

Команди й далі питають, яка модель найкраща, ніби вибір — це дегустація. У такого питання короткий термін придатності. Ціни провайдерів за першу половину 2026 року змінювалися двічі, і всі великі лабораторії за той самий час випустили нові версії моделей. Компанія, яка в січні намертво прив'язалася до одного вендора, уже побачила, як ця ставка застаріла.

Краще питання складається з трьох частин. Чого вимагає це навантаження? Який клас моделей ці вимоги закриває? І наскільки дешево ми зможемо перемкнутися через пів року? Якщо перехід до іншого провайдера означає переписування, то ви зробили не архітектурний вибір. Ви набули залежність.

Далі — про обмеження, які насправді вирішують справу, і про структуру коду, що зберігає вибір оборотним.

П'ять обмежень, які все вирішують

Пройдіться по них до того, як відкривати будь-які таблиці бенчмарків.

Куди можуть іти ваші дані. Закриті API-моделі з кожним запитом пропускають дані через інфраструктуру вендора. Для регульованих галузей, медичних карток чи держконтрактів одного цього факту буває досить, щоб закрити обговорення. Тоді self-hosting або розгортання в потрібному регіоні перестає бути питанням грошей і стає питанням комплаєнсу.

Вартість на продакшен-обсягах. Демо-трафік приховує розкид. Бюджетні моделі коштують близько $0.10 за мільйон вхідних токенів, а флагманські сягають $25–30 за мільйон вихідних. За приблизно мільйона діалогів на місяць хостингові моделі обходяться десь у $15 000–75 000 щомісяця. Невелика донавчена модель на власному залізі може тягнути те саме навантаження за кілька сотень доларів — за умови, що задача вузька й повторювана.

Реальна складність задачі. Більшість бізнес-навантажень — це сортування, видобування, підсумовування та маршрутизація. Жодному з них не потрібне міркування флагманського рівня, тож дорогий рівень лишіть для складної меншості.

Допустима затримка. Людина, яка чекає відповіді в чаті, і нічна пакетна обробка не мають нічого спільного. Платити за швидкість, яка вам не потрібна, — найчастіша тиха переплата.

Готовність до експлуатації. Open-weight моделі завантажуються безкоштовно, але їхній запуск означає оренду GPU — приблизно від $0.50 до $5.00 на годину зі зростанням моделей — і зарплати інженерам, які розгортатимуть, патчитимуть і моніторитимуть увесь стек.

Крок 1: спершу побудуйте шов

Визначте абстракцію до того, як когось обирати. Увесь інший код має спілкуватися з вашим інтерфейсом і ніколи — з SDK вендора.

class ModelProvider(Protocol):
    def complete(self, messages, *, max_tokens, tools=None) -> Completion: ...

class Router:
    def __init__(self, providers: dict[str, ModelProvider]):
        self.providers = providers
    def complete(self, messages, *, tier="standard", **kw):
        name = MODEL_FOR_TIER[tier]                # config, not code
        try:
            return self.providers[name].complete(messages, **kw)
        except (RateLimited, ProviderDown):
            fallback = FALLBACK_FOR_TIER[tier]     # different vendor entirely
            return self.providers[fallback].complete(messages, **kw)

Це дає дві речі. Зміна провайдера перетворюється на правку конфігу, а не на проєкт. І падіння одного вендора більше не валить ваш продукт — команди недооцінюють це рівно до того дня, коли воно стається.

Тримайте особливості вендорів усередині кожного адаптера. Щойно назви параметрів якогось провайдера просочуються в бізнес-логіку, шва більше немає.

Крок 2: маршрутизуйте за задачею, а не за улюбленцем

Надсилати кожен запит в одну модель — найдорожча звичка в продакшен-AI. Розбийте роботу на рівні.

MODEL_FOR_TIER = {
    "bulk":     "small_local",      # classification, extraction, tagging
    "standard": "mid_hosted",       # summaries, drafting, most chat
    "hard":     "frontier_hosted",  # multi-step reasoning, ambiguous cases
    "sensitive":"self_hosted",      # data that cannot leave your estate
}

def choose_tier(task, payload):
    if contains_regulated_data(payload):
        return "sensitive"                      # compliance overrides cost
    if task in {"classify", "extract", "tag", "route"}:
        return "bulk"
    if task == "reason" or payload.get("complexity") == "high":
        return "hard"
    return "standard"

Перевірка комплаєнсу стоїть першою навмисно. Вартість і якість можна розмінювати одну на одну. Те, де дозволено обробляти дані, — ні.

Крок 3: вимірюйте на своєму навантаженні

Публічні лідерборди показують, як моделі виступають на публічних лідербордах. З тим, як модель упорається з вашими документами, вашим жаргоном і вашими мовами, вони корелюють доволі слабко.

Влаштуйте власне порівняння на тому самому golden set, що захищає від регресій.

def bake_off(candidates, cases):
    results = {}
    for name, provider in candidates.items():
        passed, cost, latencies = 0, 0.0, []

for case in cases:
            t0 = time.monotonic()
            out = provider.complete(case["messages"], max_tokens=800)
            latencies.append((time.monotonic() - t0) * 1000)
            passed += grade(out.text, case["expected"])
            cost += price(name, out.usage)
        results[name] = {
            "accuracy": passed / len(cases),
            "cost_per_1k_calls": (cost / len(cases)) * 1000,
            "p95_latency_ms": percentile(latencies, 95),
        }
    return results

Оцінюйте одразу три речі: точність, ціну та швидкість. Модель на два пункти точніша, але вчетверо дорожча, — не очевидно краща. Трохи дешевша, але втричі повільніша провалить клієнтську функцію, хоч би що казав її бал.

Оцінюйте також дотримання інструкцій і надійність виклику інструментів. У більшості продакшен-систем викликати потрібну функцію з валідними аргументами важливіше, ніж голий інтелект.

Крок 4: порахуйте ціну, перш ніж зобов'язуватися

def monthly_estimate(name, calls_per_month, avg_in, avg_out, cache_hit_rate=0.0):
    p = PRICING[name]                              # per million tokens
    billable_in = avg_in * (1 - cache_hit_rate) + avg_in * cache_hit_rate * p["cache_ratio"]

return calls_per_month * (
        (billable_in / 1_000_000) * p["input"]
        + (avg_out / 1_000_000) * p["output"]
    )
# Always run it at 10x expected volume before signing anything.

Два важелі сильно змінюють підсумок, і про них часто забувають. Пакетна обробка зазвичай удвічі знижує тариф для нетермінової роботи. Кешування промптів може скоротити вартість повторюваного входу приблизно на 90 відсотків, а це величезна різниця, коли кожен виклик несе той самий довгий контекст.

Три родини моделей

Закриті API-моделі найшвидше доводять до продакшену й лідирують на передовій, до того ж сервери тримати не треба. Натомість ваші дані проходять через їхні системи, рахунок росте лінійно й без межі, а їхні рішення щодо цін і виведення моделей з експлуатації вам доведеться просто приймати.

Open-weight моделі через хостинг-провайдера коштують дешевше, легше переносяться й швидко покращуються. Медіанна стартова ціна флагманських відкритих моделей зросла приблизно з $0.48 у 2024 році до $1.35 у 2026-му, але це все одно набагато нижче за закриті тарифи. Одне застереження: сторонні хостинги часто запускають моделі зі зниженою числовою точністю задля економії, що може трохи зрізати якість, а їхні обіцянки щодо надійності відрізняються від обіцянок вихідної лабораторії.

Self-hosting дає повний контроль над даними й жодної плати за токени. Платите ви потужностями GPU та часом інженерів, а патчі, масштабування й аптайм — на вас. Це виправдано вимогами суверенітету даних або вузькими задачами з великим обсягом, де невелика донавчена модель обходить універсальну і за ціною, і за точністю.

Більшість зрілих систем використовують усі три, і це не нерішучість. Так і задумано.

Безпека

  • Вважайте вимоги до розміщення даних вхідними даними для проєктування. Вирішіть, які типи даних де можна обробляти, ще до вибору провайдера. Якщо додати це наприкінці, проєкт помирає на перевірці комплаєнсу.
  • Уважно читайте умови обробки даних: строки зберігання, чи використовуються вхідні дані для навчання майбутніх моделей, список субпроцесорів і який регіон насправді відповідає на ваші запити. Корпоративні договори зазвичай відрізняються від умов за замовчуванням, а умови за замовчуванням — це те, що ви отримаєте, якщо ніхто не спитає.
  • Промпт — це вихідний потік даних. Усе, що в ньому є, уже залишило ваш периметр, тож вичищайте зайве до надсилання, а не після.
  • Self-hosting переміщує ризик, а не усуває його. Тепер захищати ваги — ваша турбота, кожен ендпоінт інференсу відкритий для атак, а оновлення стають вашою роботою. Внутрішній ендпоінт інференсу без автентифікації — часта й серйозна знахідка.
  • Поводьтеся з API-ключами як із продакшен-обліковими даними: окремий ключ на кожне оточення й сервіс, ротація, вузькі права й ліміти витрат. Ключ, що витік, — це ризик для даних плюс рахунок без стелі.
  • Фіксуйте версії моделей. Провайдери тихо виводять моделі з експлуатації та оновлюють їх, і модель, що змінилася у вас під ногами, може зламати поведінку, яку ви перевірили кілька місяців тому. Зафіксуйте версію й проганяйте golden set, перш ніж прийняти будь-яку зміну.

Чек-лист

  • Один інтерфейс, не прив'язаний до провайдера, а деталі вендорів — лише в адаптерах
  • Вибір моделі живе в конфігу й змінюється без деплою
  • Фолбек на іншого вендора на випадок збоїв і лімітів
  • Робота розподіляється за рівнями, питання комплаєнсу — раніше за питання ціни
  • Golden set проганяється на кожному кандидаті: точність, вартість і затримка p95
  • Виклик інструментів і дотримання інструкцій оцінюються нарівні з якістю відповідей
  • Вартість прорахована для обсягу вдесятеро більшого за очікуваний
  • Пакетна обробка й кешування всюди, де дозволяє навантаження
  • Розміщення даних визначене для кожного класу даних до вибору провайдера
  • Версії зафіксовані й перевіряються перед оновленням
  • Ключі обмежені за сервісами й мають ліміти витрат

Наостанок

Хто каже, що відповідь — одна конкретна модель, описує поточний місяць, а не вашу систему.

Сильні команди ставляться до вибору моделі як до рішення про маршрутизацію всередині стабільної архітектури. Дешева робота йде в дешеві моделі, регульовані дані лишаються там, де їм дозволено бути, оцінка відбувається на власних задачах, а не на чужому лідерборді, і все це можна змінити за пів дня.

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

Обирайте під кожне навантаження, будуйте шов і перераховуйте цифри щокварталу.