Зменшіть витрати на LLM за допомогою маршрутизатора токенів LiteLLM
LiteLLM знаходиться між додатками та постачальниками, направляючи короткі запити до дешевих моделей, а складні — до Opus; це дозволяє заощадити близько 28% протягом одного симульованого місяця роботи інженера.
Джерела: Reduce your LLM token costs using LiteLLM model router
LiteLLM — це відкритий гейтвей, який формує запити у форматі OpenAI для багатьох постачальників. Він ефективно виконує кілька функцій; у цій статті ми зосередимося на маршрутизації моделей — надсиланні кожного запиту до достатньо дешевої моделі, щоб витрати на токени залишалися під контролем.
Що робить маршрутизатор моделей
Маршрутизатор знаходиться між вашим додатком та постачальниками. Клієнт все одно автентифікується один раз через гейтвей. Гейтвей перевіряє кожен запит та, використовуючи політику, яку ви визначили, обирає модель, яка має надати відповідь. Можна розглядати його як легкий шар прийняття рішень: прості запити не потребують найдорожчих моделей.
Інтуїція маршрутизації на основі токенів
LiteLLM може підрахувати кількість вхідних токенів перед тим, як надіслати запит. Практична евристика:
- Короткі завдання типу «прочитати сторінку та узагальнити» → моделі класу Haiku
- Складні завдання з використанням Python, що потребують глибоких міркувань → моделі класу Opus
Цей підхід називається маршрутизацією на основі токенів. Короткі запити коштують дешево; довгі — дорого. У продакшн-системах часто додають класифікацію наміру для більшої точності, але навіть сама гіпотеза на основі токенів може зменшити витрати приблизно на тридцять відсотків.
Без маршрутизації
Кожен запит потрапляє на одну дорогу модель. Витрати зростають лінійно з обсягом — без урахування складності завдання.
З маршрутизацією
Той самий трафік класифікується та розподіляється між різними рівнями. Інженери продовжують використовувати один URL-адреса шлюзу; проксі вирішує, яка саме модель буде запущена.
Симульований місяць інженерного трафіку
Я протестував обидві конфігурації за допомогою LiteLLM. Спочатку усі запити потрапляли на модель Opus. Приблизно сімсот запитів призвели до рахунку близько 60 доларів.
Потім я увімкнув роутер. Opus отримував запити лише тоді, коли кількість токенів вхідних даних перевищувала 300. Скрипт для обліку, який реалізує цю політику, виглядає так:
from litellm.integrations.custom_logger import CustomLogger
import litellm
import random
class TokenRouter(CustomLogger):
async def async_pre_call_hook(self, user_api_key_dict, cache, data, call_type):
# Skip routing for mock models - simulation handles model selection
if "mock" in data.get("model", ""):
return data
# SMART ROUTING based on token complexity
messages = data.get("messages", [])
token_count = litellm.token_counter(
model="gpt-3.5-turbo",
messages=messages
)
if token_count < 50:
data["model"] = "haiku"
tier = "HAIKU (5%)"
elif token_count < 300:
data["model"] = "sonnet"
tier = "SONNET (30%)"
else:
data["model"] = "opus"
tier = "OPUS (65%)"
print(f"[ROUTER] Tokens: {token_count} → {tier}")
return data
proxy_handler_instance = TokenRouter()
Із 741 запиту 494 (приблизно 66%) все ще надійшли до Opus. Решта розподілилася між Sonnet та Haiku, причому Haiku отримав найменшу частку. Вартість обробки аналогічного обсягу роботи знизилася до $43 — спосіб написання запитів розробниками не змінився.
Висновки з цифр
- 741 запит — це реалістичний показник місячного використання інженерами
- $60 як базова вартість — Opus для всього
- $43 з використанням роутингу — та сама робота, але розумніший вибір
- ~28% економії — це досягнуто повністю за рахунок проксі, що залишається непомітним для клієнтів
Збереження коштів зростає у міру додавання інженерів, дорожчих моделей та більших обсягів токенів. Не кожному запиту потрібна найсильніша модель з каталогу.
Маршрутизатор LiteLLM ефективно вирішує цю проблему. Інженери залишаються з клієнтом у форматі OpenAI; відділ фінансів бачить меншу рахунку.
У цих тестах використовувалася версія LiteLLM v1.98 локально з альтернативами від Ollama та рекомендовані ціни від Anthropic для розрахунку витрат. Фактична економія залежить від того, як розподіляється набір ваших запитів за рівнем складності.