Як використовувати LLM-маршрутизацію для оптимізації витрат на AI запити

Якщо ти щомісяця платиш сотні доларів за API запити до GPT-4o або Claude Opus, але більшість із них — це прості питання, які міг би обробити дешевший модель, то ти буквально спалюєш гроші. LLM-маршрутизація вирішує саме цю проблему: вона автоматично визначає складність запиту і відправляє його до оптимальної моделі — дешевої чи потужної. Цей туторіал займе близько 2 годин, а на виході ти матимеш робочу систему маршрутизації, яка може скоротити витрати на 60–80%. Для старту потрібен базовий досвід з Python та API ключі від хоча б двох LLM-провайдерів.

🛠️ Що знадобиться

• Python 3.11+ — основне середовище виконання; безкоштовний, встанови з python.org якщо ще немає
• RouteLLM — відкрита бібліотека від LMSys для інтелектуальної маршрутизації між моделями; безкоштовна, open-source
• OpenAI API ключ — для доступу до GPT-4o (сильна модель) та GPT-4o-mini (дешева модель); платний, від $0.15/1M токенів
• Anthropic API ключ — опційно, для маршрутизації до Claude Haiku як альтернативи дешевої моделі; платний
• LangSmith — для моніторингу та аналітики витрат у реальному часі; безкоштовний план до 5000 трейсів/місяць
• VS Code або PyCharm — редактор коду; VS Code безкоштовний і достатній для цього проекту

📋 Покрокова інструкція

Крок 1: Встановлення залежностей і налаштування середовища

Відкрий термінал і створи новий проект: введи mkdir llm-router && cd llm-router, потім python -m venv venv і активуй середовище командою source venv/bin/activate (на Windows: venv\Scripts\activate). Тепер встанови всі потрібні пакети однією командою: pip install routellm[serve] openai anthropic langsmith python-dotenv. Створи файл .env у корені проекту і додай туди свої ключі: OPENAI_API_KEY=sk-..., ANTHROPIC_API_KEY=sk-ant-... та LANGCHAIN_API_KEY=ls__... — усі ключі знайдеш у відповідних особистих кабінетах провайдерів.

Крок 2: Розуміння логіки маршрутизації і вибір стратегії

RouteLLM підтримує кілька роутерів — алгоритмів, які вирішують, до якої моделі відправити запит. Найкращий баланс між точністю і швидкістю дає mf (matrix factorization) роутер — він навчений на 80 тисячах пар порівнянь моделей з Chatbot Arena. Є також causal_llm (використовує окрему LLM для класифікації, але повільніший) і bert (найшвидший, але менш точний). Ключовий параметр — threshold від 0.0 до 1.0: чим вище значення, тим частіше запити йдуть до сильної моделі. Починай з порогу 0.11635 — це значення дає приблизно 50% запитів до дешевої моделі зі збереженням 95% якості, згідно з бенчмарками команди RouteLLM.

Крок 3: Написання базового роутера

Створи файл router.py і встав наступний код. Спочатку імпорти та ініціалізація: завантаж змінні середовища через load_dotenv(), потім створи клієнт RouteLLM — client = RouteLLMClient(routers=["mf"], strong_model="gpt-4o", weak_model="gpt-4o-mini"). Далі напиши функцію smart_query(prompt, threshold=0.11635), всередині якої викликай client.chat.completions.create(model="router-mf-{threshold}", messages=[{"role": "user", "content": prompt}]) — так само як звичайний OpenAI виклик, але модель замінена на рядок роутера. Додай логування: перед викликом збережи час, після — виведи в консоль яка модель була обрана (поле response.model) і скільки токенів витрачено. Запусти тест командою python router.py з тестовим промптом “Яка столиця Франції?” — має відповісти gpt-4o-mini.

Крок 4: Підключення моніторингу через LangSmith

Без моніторингу ти не знатимеш, чи справді заощаджуєш. Зайди на smith.langchain.com, зареєструйся, натисни Settings → API Keys → Create API Key і скопіюй ключ у свій .env. У файлі router.py додай на початку три рядки: import os, os.environ["LANGCHAIN_TRACING_V2"] = "true" та os.environ["LANGCHAIN_PROJECT"] = "llm-router-demo". Тепер кожен виклик автоматично трекується — поверни браузер на LangSmith, перейди у розділ Projects → llm-router-demo і ти побачиш дашборд із розбивкою: скільки запитів пішло до якої моделі, вартість кожного виклику в доларах і час відповіді. Це твій головний інструмент для калібрування порогу маршрутизації.

Крок 5: Калібрування порогу під свій use-case і тестування на реальних даних

Збери 50–100 реальних запитів зі свого продукту і запусти їх через роутер з різними значеннями threshold — спробуй 0.05, 0.11635 і 0.25. Створи файл calibrate.py, де в циклі для кожного порогу викликаєш smart_query для всіх тестових промптів і зберігаєш результати у CSV: модель, токени, вартість, відповідь. Порахуй вартість кожного сценарію: помнож кількість токенів від gpt-4o-mini на $0.15/1M і від gpt-4o на $2.50/1M, підсумуй. Порівняй результати з базовою лінією — якби всі запити йшли до gpt-4o. У більшості продуктових сценаріїв поріг 0.11635 дає 60–70% економії без помітної втрати якості — але якщо твої запити складні (код, аналіз, юридичні тексти), підвищ поріг до 0.2–0.3. Фінальний результат: в LangSmith ти бачиш графік витрат, який різко падає відносно гіпотетичної кривої “тільки GPT-4o”.

⚠️ Типові помилки та як їх уникнути

• Занадто низький поріг для критичних задач — якщо роутер відправляє юридичні або медичні запити до дешевої моделі, якість відповідей падає критично; вирішення: створи два клієнти з різними порогами і вибирай між ними залежно від типу запиту через простий if/else на ключових словах
• Відсутність fallback логіки — якщо дешева модель повертає помилку або порожню відповідь, система мовчки фейлиться; завжди обгортай виклик у try/except і при помилці автоматично перенаправляй запит до сильної моделі
• Ігнорування латентності — маршрутизатор сам по собі додає 20–50мс до кожного запиту; для real-time чату це критично, тому використовуй легший bert-роутер замість mf або кешуй рішення роутера для однотипних запитів
• Тестування тільки на синтетичних даних — роутер, відкалібрований на загальних бенчмарках, може погано працювати на твоїй специфічній доменній мові; обов’язково тестуй на реальних запитах зі свого продукту перед деплоєм

💡 Поради для кращого результату

Використовуй каскадну маршрутизацію для складних запитів: спочатку відправ запит до дешевої моделі, потім автоматично перевір якість відповіді простою евристикою (довжина, наявність ключових слів, впевненість моделі) — і лише якщо відповідь незадовільна, надішли той самий запит до GPT-4o. Це дає ще 15–20% додаткової економії.

Додай семантичний кеш через Redis або Upstash: якщо той самий або дуже схожий запит вже приходив, поверни збережену відповідь без виклику API взагалі. Бібліотека semantic-router дозволяє налаштувати це за 30 хвилин і може скоротити кількість API викликів на 30–40% у продуктах з повторюваними запитами.

Встанови алерти в LangSmith: натисни Rules → Create Rule, обери умову “витрати за годину перевищили $5” і підключи Slack webhook — так ти дізнаєшся про аномальне споживання до того, як прийде рахунок.

Логуй рішення роутера у свою базу даних: через місяць у тебе буде датасет з тисяч реальних прикладів “який запит → яка модель → яка якість відповіді”. Це дозволить навчити власний легкий класифікатор і повністю позбутись залежності від RouteLLM.

❓ Часті запитання (FAQ)

1. Чи можна використовувати маршрутизацію з локальними моделями через Ollama?
Так, RouteLLM підтримує будь-який OpenAI-сумісний ендпоінт. Встанови Ollama, запусти модель командою ollama run llama3.2 і вкажи у конфігурації роутера weak_model="ollama/llama3.2" з базовим URL http://localhost:11434/v1. Це дозволяє повністю безкоштовно обробляти прості запити локально.

2. Наскільки реально скоротити витрати і чи є реальні кейси?
За даними команди RouteLLM, на стандартних бенчмарках (MT-Bench, MMLU) система досягає 40–75% скорочення витрат зі збереженням 95% якості порівняно з використанням лише сильної моделі. У реальних продуктах результати варіюються: для чат-підтримки зазвичай 60–70%, для генерації коду — 30–40%.

3. Що робити, якщо мої запити конфіденційні і я не можу надсилати їх до хмарних API?
Використовуй повністю локальне налаштування: слабка модель — Llama 3.2 3B через Ollama, сильна модель — Llama 3.1 70B через Ollama або vLLM на своїх GPU. Роутер RouteLLM теж запускається локально, тому жодних даних назовні не йде.

4. Як маршрутизація впливає на швидкість відповіді?
Mf-роутер додає близько 20–50 мілісекунд до кожного запиту на класифікацію — це непомітно для більшості сценаріїв. Але якщо тобі критично важлива затримка (real-time голосові боти, ігри), використовуй bert-роутер, який класифікує за 5–10 мс, або попередньо обчислюй рішення роутера асинхронно паралельно з введенням користувача.

5. Чи можна маршрутизувати між провайдерами — наприклад, OpenAI і Anthropic?
Так, через LiteLLM як проксі. Встанови pip install litellm, налаштуй litellm.proxy з обома провайдерами і підключи RouteLLM до LiteLLM ендпоінту. Це дозволяє слабкою моделлю зробити Claude Haiku ($0.25/1M токенів), а сильною — GPT-4o або Claude Opus залежно від поточних цін і доступності.

🏁 Підсумок

Ти навчився будувати систему LLM-маршрутизації з нуля: від встановлення RouteLLM і написання базового роутера до підключення моніторингу в LangSmith і калібрування порогу під реальні дані. На виході у тебе є робочий Python-сервіс, який автоматично відправляє прості запити до дешевих моделей і зберігає потужні моделі для дійсно складних задач — з прогнозованою економією 60–80% щомісячних витрат на API.

Прямо зараз відкрий термінал, клонуй репозиторій RouteLLM командою git clone https://github.com/lm-sys/routellm і запусти їхній demo notebook з власними API ключами — це займе 20 хвилин і одразу покаже реальну різницю у вартості на твоїх власних запитах. Не відкладай: кожен день без маршрутизації — це реальні гроші, які йдуть у GPT-4o за відповіді типу “яка погода в Києві”.