Свой LLM-прокси: как перестать гадать и начать видеть, что происходит

Вы работаете над идеей, над куском кода или над SaaS-сервисом, который приносит миллионы. В одном из ваших рабочих процессов вы берёте картинки свежих релизов игрушек, прогоняете их через ComfyUI, превращаете 2D в 3D-модель через CAD и запускаете производство реплик — китайский Новый год на носу, а мировые фабрики тормозят.

В другой момент вы тратите токены, чтобы найти информацию о питании McRib. Или что-то другое столь же полезное.

Почти наверняка вы общаетесь с интерфейсом, который привязан к платной подписке выбранного вами провайдера. TUI, GUI, голосовой звонок — неважно. Ваши данные уходят туда, их ответ возвращается обратно. Именно это они и продают. Автор статьи Джар Сигел честно признаётся: он с удовольствием покупает именно это.

Но вместе с подпиской вы получаете картинку в духе плюшевой игрушки с переливающимся шаром и оранжевого маскота в котелке. Показывают, что всё прошло отлично.

Это отвлекающий манёвр.

Почему панель расхода токенов вам не поможет

Разбор того, что вы видите в панели провайдера, не содержит статистики расхода токенов с временным рядом, то есть с графиком по времени. А именно такой график нужен инженеру, чтобы принять решение.

С картинкой в стиле «смотрите, какая милашка» решение принять нельзя. Вы видите, что траты идут. Вы не видите, куда именно они уходят и почему.

Кажется, что лаборатории должны были подумать о том, кто копается в их панели аналитики, и поделиться чем-то полезным. Автор скептичен: скорее всего, нет.

«Но ведь есть экспорт в OpenTelemetry!»

Это возражение приходит в голову сразу. И да, такой экспорт существует.

Только это один довод из шести. И вот ещё пять, которые автор приводит сразу:

• несколько провайдеров и несколько моделей доступны через одну точку входа, которой управляете вы;
• ведётся журнал: какой ключ какую модель каким клиентом в какой момент вызвал и с каким статусом;
• можно использовать виртуальные ключи, чтобы не засорять свой единственный основной ключ по рабочим задачам, агентам и обвязке;
• это инфраструктура, которой управляете вы;
• можно очень быстро сменить модель и провайдера, не пересобирая всё с нуля (снова, вероятно, уже в третий раз).

Пятый пункт стоит отдельного разговора. Модели и провайдеры меняются постоянно. Условия меняются. Лимиты меняются. Переезд с одного провайдера на другой обычно означает, что надо перенастроить все инструменты, все скрипты и все окружения. Своя прокси-обвязка превращает этот переезд в правку одной строки конфигурации.

Что на практике даёт одна своя точка входа

Когда все обращения к моделям идут через один адрес, который вы контролируете, у вас появляется несколько новых возможностей. Все они вытекают из того же самого механизма — из единой точки, где можно принять решение, куда отправить запрос.

Маршрутизация по задаче. Один и тот же адрес может отправлять быстрые интерактивные запросы на одну модель, а тяжёлые фоновые задачи — на другую. Переключение происходит в конфигурации прокси, а не в каждом вызывающем коде.

Запасной вариант. Если основной провайдер не отвечает, прокси может отдать запрос другому. Ваш код об этом не знает и ничего не меняет.

Сравнение моделей. Один и тот же промпт можно отправить двум моделям через один адрес и сравнить ответы в одном месте, в одном журнале. Раньше для такого сравнения нужны были отдельные ключи и отдельные скрипты.

Смена провайдера без миграции. Это, пожалуй, главный эффект. Один провайдер закрывается, другой поднимает лимиты или меняет цены — вы правите одну настройку, и вся ваша система продолжает работать.

Что такое виртуальные ключи и зачем они нужны

Это отдельная деталь, на которой автор останавливается специально.

Ключ API — это один секретный токен, который даёт доступ к вашему счёту у провайдера. Обычно у разработчика он один. И он размазывается по проектам: по рабочим скриптам, по агентам, по обвязке, по личным экспериментам.

Дальше начинаются проблемы. Нужно понять, кто именно потратил токены. Нужно отозвать доступ у одного проекта, не сломав остальные. Нужно посмотреть, какой из агентов внезапно съел половину бюджета.

Виртуальный ключ решает эту задачу: прокси выдаёт вам несколько разных ключей, а настоящий ключ провайдера хранится в одном месте. Каждый ключ привязан к своему потребителю. В журнале видно, кто что вызывал. Отзыв занимает секунду.

Прокси — это точка, которую вы меняете под себя

Автор не советует конкретного провайдера прокси. Его мысль проще: запускайте его сами, там, где контролируете.

И при выборе не забудьте главное: прокси можно модифицировать под свои настоящие потребности. У автора его версия доработана для более удобного анализа данных, для собственных адресов MCP-серверов и для дополнительных возможностей.

Это важный момент. Прокси — не только просмотрщик логов. Это слой, в который можно встроить то, чего нет ни в одном готовом тарифе. Например, правила маршрутизации: тяжёлые фоновые задачи отправлять на одну модель, быстрые интерактивные — на другую. Или автоматический откат на резервного провайдера, когда основной не отвечает.

Через MCP-серверы подключаются внешние инструменты. Если адреса этих серверов задаются в конфигурации прокси, вы можете переопределить их под своё окружение — например, на локальный запуск.

Промах кеша: двадцать секунд на диагностику

Вот конкретный пример из практики.

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

Промах кеша означает, что модель не нашла готовый ответ и посчитала всё заново. Это дорого и медленно. Причины бывают разные: другой префикс промпта, изменившийся системный промпт, другой клиент, иная версия модели, другой пользователь.

Если у прокси есть журнал запросов, большинство этих причин видно сразу: вот запрос, вот его префикс, вот модель, вот клиент, вот статус. Вопрос «почему кеш не сработал» превращается из расследования в чтение одной таблицы.

Автор признаётся, что не автоматизировал это. Но у его прокси есть API, так что автоматизация — вопрос времени.

Своя инфраструктура, своя видимость, свои данные

Автор формулирует это так: владейте своей инфраструктурой, видимостью своего приложения, маршрутизацией данных и их хранением.

Дома он этим занимается, потому что это интересно и так он учится. На работе — потому что иначе он делает свою работу неправильно.

Здесь важно не перегнуть. Собственный прокси не превращает вас в инфраструктурного инженера. Это не значит, что вы должны сами обслуживать кластер. Прокси обычно лёгкий: один процесс, который слушает порт, хранит логи и пересылает запросы дальше. Развернуть его можно на домашнем сервере, на VPS или на той же машине, где идёт ваша работа.

Что вы получаете в обмен на эту небольшую возню:

• полную видимость: кто, когда, какую модель вызвал и чем закончилось;
• одну точку входа вместо россыпи прямых обращений к разным API;
• возможность менять провайдера и модель без переписывания всего подряд;
• логи, которые остаются у вас и не зависят от чужой панели;
• API, к которому можно прикрутить собственную автоматику.

Видимость приложения, а не только модели

Отдельно стоит разобрать формулировку про видимость приложения. Это не только про то, как модель отвечает. Это про то, как модель ведёт себя внутри вашей системы.

Когда вызов идёт напрямую в API провайдера, у вас нет общей точки, где можно связать запрос к модели с тем, что происходило в вашем коде. Вы знаете, что в какой-то момент вызвали модель, но не знаете, из какой функции, из какого задания, после каких предыдущих шагов.

Собственный прокси даёт эту точку. В его журнале для каждого вызова есть ключ, модель, клиент, время и статус. Когда запрос идёт от вашего приложения, вы знаете, каким клиентом он был отправлен, а значит, можете сопоставить его с конкретным местом в коде.

Тот же приём работает в обратную сторону. Вы видите в журнале аномалию — скажем, внезапный рост числа запросов к дорогой модели — и идёте смотреть, какой именно клиент за это отвечает. Без прокси вы ловили бы только рост суммы в конце месяца.

Честное ограничение

Автор заканчивает признанием, которое стоит прочитать отдельно.

Он говорит, что, возможно, никогда до конца не поймёт, как большая языковая модель работает внутри. Настолько, чтобы нарисовать это на доске на собеседовании.

Но он может приручить её, заставить отчитываться и убедиться, что во время инференса всё инструментировано и видно.

Это важное разграничение. Знать внутреннее устройство модели и уметь видеть, как с ней работает твоя система, — это две разные задачи. Вторую можно решить инженерно, без лицензии на исследование в области ML.

Если вам этого не хватает, материал на смежную тему: Don't make me use your harness — о том, почему агенту не стоит навязывать чужую обвязку.

Итог

Панель провайдера отвечает на вопрос «сколько я заплатил». Свой LLM-прокси отвечает на вопрос «что именно происходит и почему».

Разница в том, что первое — отчёт для бухгалтерии. Второе — инструмент, с которым можно принимать решения: где переключить модель, какой клиент зря тратит токены, почему кеш не сработал и что случится, когда основной провайдер ляжет.

Если вы работаете с LLM не как с игрушкой, а как с частью продакшна, эта прослойка стоит того, чтобы потратить на неё вечер.