Автор блога: свой прокси для LLM нужен, чтобы видеть токены и ключи
Автор заметки на jrdsgl.com (имя в тексте не указано) пишет, что название материала уже передаёт всю идею: если вы не запускаете собственный прокси для больших языковых моделей, вы не знаете, что на самом деле происходит с вашими запросами. Он начинает с иронии: неважно, чем вы заняты, будь то SaaS-приложение на много миллиардов в год, перевод картинок игрушек Labubu в 3D-модели через ComfyUI или поиск калорийности McRib, чаще всего вы общаетесь с неким интерфейсом, привязанным к платной подписке провайдера. Ваши данные уходят туда, их данные возвращаются; это то, что продают, и автор готов это покупать.
Проблема в том, что в качестве доказательства проделанной работы провайдеры показывают панель с отображением использования. Автор называет это отвлекающим манёвром: это не статистика расхода токенов с временными рядами, рассчитанная на инженеров, и принимать решения на её основе он не может. Он саркастически замечает, что крупные лаборатории якобы припасли ценные сведения для любопытного пользователя, дошедшего до раздела аналитики. На ожидаемое возражение «есть же экспорт OTel!» автор отвечает «Круто, наверное» и называет это лишь одной причиной, к которой добавляет ещё пять.
Пять причин из текста: несколько провайдеров и моделей за единой точкой входа, которую вы контролируете; логи о том, какой ключ вызывал какую модель, каким клиентом, когда и с каким статусом; виртуальные API-ключи, чтобы не размазывать единственный основной ключ по рабочим проектам, агентам и обвязкам; инфраструктура под вашим контролем; возможность очень быстро сменить модель и провайдера без повторной настройки всего заново (автор иронизирует, что, вероятно, уже в третий раз).
Конкретный прокси автор не рекомендует: он советует лишь запускать его самостоятельно там, где вы это контролируете, и не забывать, что выбранный прокси можно дорабатывать под свои нужды. Сам он доработал свой: для более глубокой наблюдаемости, для собственных точек подключения MCP-серверов и для дополнительных функций. Какой бы вариант вы ни выбрали, по его словам, данные вы должны получать примерно такого вида (иллюстрации в тексте не описаны).
Как пример пользы автор приводит промах кэша во время сеанса программирования: по данным своего прокси он может вручную выяснить причину примерно за 20 секунд. Автоматизировать это он пока не стал, но у используемого им прокси есть API, так что автоматизация возможна.
Итог, призыв владеть своей инфраструктурой, видимостью работы приложений, маршрутизацией данных и хранилищем. Дома автор делает это ради удовольствия и обучения, на работе, потому что иначе, по его словам, он плохо выполняет свою работу. Он признаётся, что, возможно, никогда не поймёт устройство большой языковой модели настолько, чтобы нарисовать его на доске на собеседовании, но может «укротить» её и обеспечить измерения при обслуживании запросов к ней.
Ключевые факты
- Автор считает, что панели использования у провайдеров нейросетей не дают инженерной статистики по токенам с временными рядами, и решений на них он принимать не может.
- Довод в пользу собственного прокси: единая точка входа для нескольких провайдеров и моделей, логи по ключам, клиентам, времени и статусам запросов.
- Виртуальные API-ключи позволяют не раздавать единственный основной ключ по рабочим проектам, агентам и обвязкам; смена модели и провайдера делается без повторной настройки.
- Конкретный прокси автор не рекомендует, но говорит, что свой доработал: под более глубокую наблюдаемость, собственные точки MCP-серверов и дополнительные функции.
- Причину промаха кэша при программировании он находит вручную за 20 секунд; автоматизация возможна, так как у его прокси есть API.
Почему это важно
Заметка выражает позицию, которая встречается среди тех, кто много работает с нейросетями: данные об использовании в интерфейсах провайдеров устроены не для инженерного анализа. Автор предлагает не полагаться на аналитику поставщика, а поставить между собой и провайдерами собственный прокси и самому владеть логами, ключами и маршрутизацией запросов. Это мнение одного практика, а не исследование.
Кому это важно
Разработчикам и командам, которые пользуются несколькими моделями или провайдерами, запускают агентов и обвязки с одним и тем же ключом и хотят понимать, какой запрос куда ушёл и почему сработал или не сработал кэш. Автор пишет в первую очередь для тех, кто принимает инженерные решения о расходе токенов.
Как это применить
Автор предлагает: поднять прокси у себя, в среде, которую вы контролируете; вести через него логи по ключам, моделям, клиентам, времени и статусу запросов; выдавать виртуальные ключи под отдельные проекты и агентов вместо единственного основного; при необходимости дорабатывать прокси под свои задачи, как это сделал он сам. Конкретное решение он не называет и не советует, так что выбор прокси остаётся за читателем.
Можно ли доверять
Это эссе-мнение в разговорном, местами грубом стиле, а не расследование и не обзор. Имя автора в тексте не указано. Из чисел есть только оценка в 20 секунд на разбор промаха кэша, подтверждений и замеров нет; затраты, выгода и сравнения не приводятся. Почему экспорт OTel от провайдеров недостаточен, автор отдельно не объясняет и лишь отмахивается от этого возражения. Иллюстрации, на которые он ссылается, в тексте не описаны.
Риски и подводные камни
Совет носит общий характер: конкретный прокси не назван, оценки затрат на собственную установку в тексте нет, так что решение придётся принимать самостоятельно. Утверждение о том, что провайдерская аналитика бесполезна, оценка автора, а не проверенный факт. Выгоду от своего прокси автор подтверждает лишь собственным примером с промахом кэша, ещё и разобранным вручную.
«Владейте своей инфраструктурой, видимостью работы своих приложений, маршрутизацией данных и их хранилищем.»
— автор заметки на jrdsgl.com