Как я построил мультитенантный шлюз LLM, чтобы предотвратить мошеннические счета за ИИ (OTel и жесткие ограничения)

Если вы предоставляете LLM нескольким пользователям, клиентам или внутренним командам, вы сидите на бомбе замедленного действия. Без строгого распределения затрат на уровне арендатора и жестких ограничений API один мошеннический пользователь — или плохо написанный необработанный цикл сценария — может в одночасье накопить катастрофические счета за OpenAI или Anthropic. Управление этими затратами в настоящее время является опасным «черным ящиком» для большинства инженерных команд. В этом руководстве я расскажу вам, как создать мультитенантный шлюз LLM, который полностью исключает этот риск. Мы рассмотрим атрибуцию затрат OpenTelemetry (OTel), динамическое ограничение скорости, резервные варианты с несколькими поставщиками и визуализацию всего этого на панели мониторинга Streamlit. 1. Узкое место: почему коммерческие решения не оправдывают ожиданий Когда инженеры понимают, что им необходимо контролировать затраты на LLM, они обычно обращают внимание на коммерческие шлюзы искусственного интеллекта. Хотя такие платформы, как Helicone или Portkey, невероятно мощны, они создают несколько узких мест: Масштабное ценообразование: оплата процента от ваших расходов на ИИ или платы за каждый запрос к вашему шлюзу быстро становится дороже, чем сами LLM. Отсутствие жестких ограничений. Многие инструменты предлагают оповещения, но не синхронные жесткие ограничения, которые мгновенно отключают арендатора в середине цикла до того, как произойдет повреждение.