Управление ИИ в компании с LiteLLM: отделы, доступ к моделям и расходы

Для единой работы предприятия с ИИ ИТ-команда может развернуть LiteLLM в качестве внутреннего шлюза, выдавать отдельные ключи отделам и приложениям, а подключаться к модельным API через Crazyrouter. Так бизнес-команды используют общую систему подключения к внешним сервисам, при этом предприятие по-прежнему может отдельно управлять тем, кто может выполнять вызовы, какие модели разрешены, сколько допускается тратить и на кого относятся расходы.¹²

Crazyrouter — сервис доступа к API нескольких моделей, который может выступать апстримом для LiteLLM и экспортировать конфигурации моделей и цен; в этой статье проверен экспорт конфигурации для 4 моделей. LiteLLM отвечает за внутренние политики команд, ключей и бюджетов предприятия.

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

Почему работа предприятия с ИИ упирается в управление аккаунтами, правами и расходами?#

На этапе пилота один человек запрашивает Key, подключает модель — если возвращается ответ, это уже успех.

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

Предприятию нужно превратить эти проблемы в конкретные управленческие действия.

Виртуальные ключи, бюджеты команд и записи использования LiteLLM служат основой для этих управленческих действий; конкретные политики прав необходимо настроить и проверить при развертывании на предприятии.¹³⁴

Как один API Key обслуживает несколько отделов и моделей?#

«Один Key для доступа к нескольким моделям» корректно описывает способ подключения к апстриму. Внутри предприятия нужно дополнительно выдавать разным вызывающим сторонам отдельные учетные данные.

Рекомендуется следующая структура:

На схеме отделы вызывают адрес собственного LiteLLM предприятия. Ключ апстрима хранится на шлюзе, бизнес-приложения используют виртуальные Key, выданные LiteLLM.

Кому передаются три типа ключей?#

Кодовый ассистент разработки, контентный workflow маркетинга, бот заявок поддержки — у каждого свой Key. Когда приложение нужно отключить, обрабатываются соответствующие учетные данные; изменения конфигурации апстрима централизованно вносит платформенная команда.¹²

Единый аккаунт не означает, что все используют один и тот же ключ. Для крупных предприятий можно дополнительно разделить учетные данные апстрима по продуктивным и тестовым средам, бизнес-подразделениям или уровню риска. Общий аккаунт апстрима упрощает расчеты, но также означает, что баланс, квоты или сбои аккаунта могут затронуть несколько отделов — это нужно учитывать в проектировании емкости и доступности.

Сначала спроектируйте отделы, аккаунты и приложения, затем выдавайте ключи#

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

Отделы удобно отображать в Team LiteLLM; приложения обычно используют сервисные учетные данные с четкой принадлежностью; когда нужна персональная принадлежность, создаются соответствующие пользователи и участие в командах.¹³

Имена тоже должны быть понятными. Например, marketing-copy-prod — продуктивное приложение контентной генерации маркетинга, support-summary-test — тестовое приложение резюме заявок поддержки. Для каждого Key фиксируются ответственное лицо, назначение, среда и срок пересмотра — иначе через полгода накопятся десятки ничейных ключей.

Нужно ли обычным сотрудникам входить в LiteLLM?#

Не обязательно. LiteLLM выполняет в основном функции шлюза и управления. Обычные сотрудники могут использовать ИИ в существующих чатах предприятия, ассистентах базы знаний, инструментах офисной автоматизации или бизнес-системах, а бэкенд приложения уже вызывает LiteLLM.

Предприятию следует отдельно спроектировать два контура:

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

Если все запросы сотрудников выполняются от одного ключа приложения, шлюз прежде всего распознает именно это приложение. Чтобы детализировать статистику до отдельного человека, бэкенд приложения должен передавать проверенный идентификатор пользователя, а также следует подтвердить поддержку соответствующей версией шлюза, его функциями и отчетами. Не рассматривайте заполняемый пользователем параметр user или ярлык отдела как подтверждение прав.⁴

Права на ИИ на предприятии: минимум три уровня#

Первый уровень: кто управляет аккаунтами и бюджетами?#

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

Это проект ролей для предприятия; он не означает, что после установки LiteLLM такое разделение заработает автоматически. Возможности SSO, SCIM, администраторов организаций и команд, журналы аудита имеют требования к версии и лицензии. При проверке официальная страница тарифов LiteLLM относит ряд расширенных функций управления к Enterprise; документация SSO дополнительно предусматривает исключение для небольшого числа пользователей — следует сверять каждый пункт с численностью персонала и планом закупки.⁵⁶

Второй уровень: кто какие модели может вызывать?#

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

В LiteLLM приложения вызывают зарегистрированный model_name. При настройке области моделей для команд и виртуальных Key используйте соответствующие имена и проверяйте фактически применяемые правила.¹

При использовании маршрутизации или fallback кандидаты также должны удовлетворять требованиям задачи по данным, возможностям и стоимости. Разрешение вызывать бизнес-псевдоним не должно означать, что этот псевдоним можно произвольно перенаправить на неутвержденные модели.

Третий уровень: кто может читать какие данные предприятия?#

Белый список моделей контролирует, «какие модели можно вызывать», а бизнес-системы дополнительно должны контролировать, «какие данные можно передавать модели».

Оператор поддержки, способный использовать модель резюме, не должен автоматически читать все клиентские контракты; сотрудник с доступом к корпоративному ассистенту базы знаний не должен искать зарплатные материалы других отделов. Доступ к данным должен контролироваться по личности сотрудника в бизнес-системе, слое поиска и слое исполнения инструментов — нельзя полагаться только на инструкцию в промпте, требующую от модели соблюдать права.

Самостоятельный хостинг шлюза также не означает, что инференс полностью остается во внутренней сети предприятия. В архитектуре этой статьи запросы проходят через корпоративный LiteLLM, далее к Crazyrouter и фактической цепочке модельных сервисов. Подходит ли отправка чувствительных данных, нужно решать с учетом конкретных условий обслуживания, классификации данных и требований корпоративного согласования.

Как должны сочетаться бюджеты отделов, лимиты приложений и ограничение частоты?#

Меры контроля можно рассматривать как три разных вопроса:

Официальная документация LiteLLM описывает настройку бюджетов и лимитов для команд, виртуальных Key и др.; бюджеты зависят от данных об использовании в базе. В продуктивном развертывании следует настроить постоянное хранение в PostgreSQL — нельзя считать прокси без базы данных законченной системой бюджетов.³

Стоит также обратить внимание на детали, влияющие на результат:

1. Key должен принадлежать правильной команде. Если у отдела несколько ключей приложений, убедитесь, что они действительно учитываются в одной Team.
2. Не предполагайте, что ограничения всех уровней суммируются. Правила применения для командных Key, личных бюджетов и бюджетов участников команды различаются — проверяйте по развернутой версии.³
3. Период бюджета должен соответствовать финансовому календарю. budget_duration, многопериодные бюджеты и время сброса могут иметь разную семантику; сверяйте фактический budget_reset_at и часовой пояс — недостаточно увидеть 30d, чтобы считать это полностью совпадающим с финансовым календарным месяцем.
4. Оповещение и отклонение запроса — два разных поведения. Правила вроде предупреждения на 80% и остановки на 100% возможны как управленческий дизайн, но соответствующие функции нужно настроить и протестировать уведомления и блокировку.
5. При конкурентных запросах проверяйте границы. Выполняющиеся запросы, оценка стоимости, синхронизация цен и состояние нескольких инстансов влияют на контроль бюджета; не обещайте, что после установки суммы ни одна лишняя копейка не будет потрачена.³⁴

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

Как учитывать расходы на ИИ по отделам, проектам и моделям?#

Месячный отчет предприятия должен отвечать минимум на вопросы: какой отдел и сколько потратил, на какие приложения в основном, какие модели вызывались и какие бизнес-результаты дали эти вызовы.

Рекомендуется начать со следующих полей отчета:

LiteLLM может учитывать расходы по Key, пользователям и командам и вести журналы вызовов; доступность анализа по меткам, отчетов и расширенного контроля доступа следует сверять по версии и лицензии. Такие показатели, как доля принятия бизнесом, предприятие должно фиксировать в собственных приложениях и затем связывать с данными вызовов.⁴⁵

Если видны токены, почему расходы все равно могут быть неточными?#

Потому что между количеством токенов и суммой стоит набор правил ценообразования.

Входные данные, выходные данные, чтение и запись кэша могут тарифицироваться по-разному; длинный контекст или разное время суток могут попадать в разные тарифные категории; группировка аккаунтов и скидки также могут влиять на фактический расчет. Если для пользовательских моделей нет корректной информации о ценах, расходы в шлюзе могут отсутствовать, быть нулевыми или расходиться со счетом апстрима.²⁴⁷

Поэтому при подключении в этом решении следует одновременно импортировать подключения моделей и ценовую информацию из model_info. Одного получения списка /v1/models для завершения настройки учета расходов недостаточно.²

Для чего используются статистика LiteLLM и счет Crazyrouter?#

Данные о расходах LiteLLM используются для внутренней атрибуции, бюджетов и анализа трендов; фактические записи списаний Crazyrouter — для сверки расчетов с апстримом.

Задержка обновления снимков цен, особые позиции тарификации, округление, повторы и границы периодов могут вызывать расхождения; нельзя по умолчанию считать, что суммы обеих систем всегда совпадают по каждой операции.²

Рекомендуется сохранять дату, часовой пояс, модель, объем использования, request ID приложения и доступный request ID апстрима, сначала сверять дневные итоги, затем разбирать запросы с существенными расхождениями. Если несколько приложений используют один ключ апстрима, а записи обеих сторон нельзя связать по каждой операции, нельзя заявлять, что достигнута точная разбивка расчетов на уровне приложений.

Шаги внедрения: подключение LiteLLM к api.crazyrouter.com#

1. Определите модели и рамки бизнеса#

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

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

2. Подготовьте выделенный вышестоящий ключ и экспортируйте конфигурацию моделей и цен#

Базовый URL для подключения, совместимого с OpenAI:

https://api.crazyrouter.com/v1

Сначала безопасно задайте на серверной стороне переменную CRAZYROUTER_API_KEY. Приведённый ниже пример на Python получает конфигурацию четырёх моделей с этого сайта, сохраняет из ответа только поле config и проверяет, что реальный ключ не был записан в файл. Требуется зависимость requests; запускайте в новом каталоге — при наличии файла с тем же именем перезапись не выполняется.²

import json
import os
from pathlib import Path
import requests

api_key = os.environ["CRAZYROUTER_API_KEY"]
response = requests.get(
    "https://api.crazyrouter.com/v1/litellm/config",
    headers={"Authorization": f"Bearer {api_key}"},
    params={
        "provider": "openai",
        "models": "claude-opus-5-5,gpt-6-astra,glm-5.3,deepseek-v4.1-flash",
    },
    timeout=30,
    allow_redirects=False,
)
if response.status_code != 200:
    raise SystemExit(f"Config export failed: HTTP {response.status_code}")

config = response.json()["config"]
if not config.get("model_list"):
    raise SystemExit("No models exported")

config.setdefault("general_settings", {})["master_key"] = (
    "os.environ/LITELLM_MASTER_KEY"
)
config["general_settings"]["database_url"] = "os.environ/DATABASE_URL"
output = json.dumps(config, ensure_ascii=False, indent=2)
if api_key in output:
    raise SystemExit("Refusing to write an API key into the config")

with Path("crazyrouter.config.json").open("x", encoding="utf-8") as file:
    file.write(output + "\n")
print("Saved config; review, import and reload LiteLLM explicitly.")

В ходе этой проверки подтверждено, что интерфейс экспорта для четырёх указанных моделей возвращает корректные конфигурации. Для корпоративного развёртывания также нужно передать процессу или контейнеру LiteLLM переменные CRAZYROUTER_API_KEY, LITELLM_MASTER_KEY и реальный DATABASE_URL, а после настройки базы данных, аутентификации и сети — явно загрузить конфигурацию. Полный порядок установки и проверки описан в руководстве по подключению LiteLLM от Crazyrouter.

Запись openai/<model> в экспорте означает, что LiteLLM использует OpenAI-совместимый адаптер, и не означает, что все эти модели принадлежат OpenAI. Если нужен нативный протокол Claude, соответствующую конфигурацию следует экспортировать отдельно по руководству; произвольно смешивать пути API нельзя.²

3. Создайте отделы, выдайте ключи приложений, затем подключайте бизнес-системы#

В LiteLLM с базой данных создайте Team для пилотного отдела, затем для каждого приложения создайте виртуальный Key, привязанный к этой команде, с указанием разрешённых моделей, бюджета и лимитов скорости.¹³

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

Адрес внутреннего API: https://ai-gateway.example.com/v1
Ключ приложения: отдельный LiteLLM Virtual Key для этого приложения
Разрешённые модели: значения model_name, разрешённые для этого ключа
Учёт затрат: Team, к которой привязан этот ключ
Ответственные: владелец приложения и владелец бюджета подразделения

Корпоративные приложения используют адрес внутреннего шлюза; в вышестоящей конфигурации LiteLLM используется https://api.crazyrouter.com/v1. Конкретные поля и требования протоколов для каждого инструмента можно проверить в каталоге руководств по подключению, а затем убедиться, что вызов возможен через шлюз вашего предприятия.

4. Включите в приёмку и отказ в доступе, и исчерпание бюджета#

После завершения настройки рекомендуется протестировать как минимум следующие сценарии:

Тесты бюджета и отзыва ключа должны выполняться на выделенных тестовых объектах. Перед выходом в продакшен также нужно проверить состояние нескольких экземпляров, резервное копирование и восстановление базы данных, а также правила доступа к конфиденциальным логам и их хранения.

Что именно было проверено в этом решении?#

27 октября 2026 года мы с помощью https://api.crazyrouter.com выполнили проверку списка моделей, экспорта конфигурации и одного прямого запроса вывода.

Прямой запрос имел вид:

{
  "model": "glm-5.3",
  "messages": [{"role": "user", "content": "Reply with exactly OK."}],
  "max_tokens": 512
}

Конечная точка запроса — POST /v1/chat/completions, request ID — e6d9b321143a4367e53c9e697fa25f1a. Возвращено: 17 входных токенов, 56 выходных, всего 73; использование на выходе включает 54 токена рассуждения. Хотя текст ответа — лишь OK, число выходных токенов больше, чем соответствовало бы двум символам; это ещё один пример того, почему анализ расходов должен считывать usage.

Историческая запись LiteLLM и текущая проверка прямого запроса — это два отдельных свидетельства. В статье историческая проверка совместимости не выдаётся за корпоративную приёмку бюджетов отделов, а также не утверждается покрытие всех моделей, SSO, нагрузки при конкурентных запросах или отказоустойчивости. Действующее руководство по подключению Claude дополнительно явно перечисляет границы возможностей, такие как json_object и принудительный выбор инструментов, — их следует проверять по каждому фактическому бизнес-требованию.²

Внедрение ИИ в компании можно начать с пилотного списка задач#

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

Для каждого приложения зафиксируйте пять вещей: кто отвечает, какие данные используются, какие модели разрешены, каков бюджет и как определить полезность результата. Одновременно создайте Team отдела, Key приложения и поля статистики — и только потом открывайте доступ сотрудникам.

По итогам пилотного цикла расширяйте охват, исходя из «стоимости выполнения одной задачи, доли принятых результатов, объёма ручной проверки и причин неудач». Рост числа вызовов моделей сам по себе не означает улучшения бизнес-эффекта.

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

FAQ#

Как корпоративным пользователям использовать ИИ с одновременным управлением несколькими отделами?#

Пусть сотрудники работают с ИИ через корпоративные приложения, вызовы централизованно обрабатывает внутренний шлюз, а права и распределение расходов назначаются по отделам, приложениям и участникам. Решение из этой статьи использует LiteLLM для управления командами и виртуальными ключами, а доступ к вышестоящим моделям выполняется через Crazyrouter.¹²

Можно ли давать один ключ API Crazyrouter нескольким отделам?#

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

Может ли LiteLLM задавать бюджет по отделам?#

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

Можно ли напрямую использовать статистику расходов по отделам в LiteLLM как финансовый счёт?#

Сначала применяйте её для внутреннего распределения и бюджетного анализа, затем сверяйте с фактическим списанием средств вышестоящим провайдером. Снимки цен, особые статьи тарификации и способ связывания записей влияют на попозиционную согласованность; перед формальным распределением нужно согласовать порядок сверки.²⁴

Достаточно ли отключить учётную запись входа после увольнения сотрудника?#

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

Может ли LiteLLM заменить корпоративную базу знаний или чат-приложение?#

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

Появляются ли SSO, аудит и администраторы отделов сразу после установки?#

Необходимо сверить версию развёртывания и лицензию. LiteLLM официально относит многие расширенные функции управления к возможностям Enterprise; для некоторых сценариев SSO есть отдельные исключения для небольших масштабов. Перед закупкой уточните требования по числу пользователей, распределению ролей и аудиту.⁵⁶

После смены модели не нужно менять бизнес-код?#

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

Справочные материалы#

Следующие документы проверены 27 октября 2026 года; официальная онлайн-документация может обновляться, при внедрении проверяйте её применительно к вашей зафиксированной версии развёртывания.