Архитектура LLM: проектирование системы для промышленного применения ИИ
Запуск модели — это проблема инфраструктуры. Получение ценности от модели — это проблема архитектуры.
Инфраструктурный слой — среды выполнения, оборудование, конечные точки API — определяет, что возможно. Архитектурный слой определяет, что происходит с запросом на самом деле: какая модель его обрабатывает, сколько это стоит, как происходит валидация и как отрабатываются ошибки.
Большинство систем начинаются с одной модели и полного отсутствия архитектуры. Это верно для прототипирования. Но в продакшене это становится уязвимостью.
Архитектура LLM охватывает проектные решения, которые превращают «модель, которую я могу вызвать», в «систему, на которую я могу полагаться».
Где архитектура LLM находится в стеке
Архитктура LLM находится в центре трехслойной модели:
| Слой | Что он охватывает | Смежная область |
|---|---|---|
| Модели | Среды выполнения, хостинг, настройка GPU | Хостинг LLM · Производительность LLM |
| Архитектура | Маршрутизация, стоимость, ограждения (guardrails), оркестрация | Вы здесь |
| Приложения | AI-ассистенты, конвейеры RAG, агенты | AI-системы · RAG |
Архитектурный слой часто пропускается на ранних этапах. Он становитсяessential, когда у вас больше одной модели, больше одного типа задач или больше одного пользователя. Каждый архитектурный паттерн в этом кластере существует потому, что подход «одна модель на всё» перестал работать.
Карта кластера
Пять тем в этом кластере дополняют друг друга. Читайте в этом порядке для наиболее логичного пути:
- Вы здесь — эта статья: что такое архитектура LLM, как компоненты соединяются
- Промпты — Написание эффективных промптов для LLM — основа: формирование того, что получает модель
- Маршрутизация — Стратегии маршрутизации моделей — диспетчер: какая модель обрабатывает что
- Стоимость — Оптимизация затрат для систем LLM — бюджетирование токенов, кэширование, экономика локальных моделей против API
- Безопасность — Ограждения (Guardrails) LLM на практике — валидация ввода, фильтрация вывода, соответствие требованиям
- Оркестрация — Проектирование систем с несколькими моделями — последовательные, параллельные, иерархические и ансамблевые паттерны
Если времени хватает только на одну тему, начните с маршрутизации. Это точка принятия решений, где начинается архитектура.
Инжиниринг промптов
Инжиниринг промптов — это слой, ближайший к модели. До маршрутизации, до кэширования, до ограждений — есть промпт. То, что вы отправляете модели, определяет то, что вы получите в ответ.
Практические техники, которые имеют значение:
- Ясность и структура — четкие инструкции превосходят хитрое форматирование
- Конкретные примеры — примеры few-shot фиксируют поведение модели
- Назначение роли — промпты на основе ролей уточняют тон и ограничения
- Разнообразие подходов — разные форматы показывают, на что реагирует модель
- Управление контекстом — то, что вы включаете, формирует то, что модель учитывает
Инжиниринг промптов — это не разовая задача. Это непрерывная калибровка между требованиями вашей задачи и поведением модели.
Углубленное изучение:
- Написание эффективных промптов для LLM — практические техники для повышения производительности языковых моделей
Маршрутизация моделей
Слой маршрутизации решает, какая модель обрабатывает какой запрос. Без него каждый запрос идет к одной и той же модели — часто слишком большой для простых задач и слишком маленькой для сложных.
Четыре стратегии маршрутизации покрывают большинство продакшен-кейсов:
| Стратегия | Оптимизация по | Лучше всего, когда |
|---|---|---|
| На основе возможностей | Качество задачи | Нагрузки смешанной сложности |
| С учетом стоимости | Затраты на токены | Системы с ограниченным бюджетом |
| С учетом задержки | Время ответа | Интерактивные инструменты и чат в реальном времени |
| Гибридная | Все три | Продакшен-системы с реальными ограничениями |
Цепочка резервного переключения (fallback chain) обрабатывает ошибки: упорядочьте модели от лучших к наиболее надежным, завершая локальной моделью, которую нельзя ограничить по частоте запросов или отключить из-за сбоя API.
Углубленное изучение:
- Стратегии маршрутизации моделей: Локальные vs API, с учетом стоимости, с учетом задержки — маршрутизация на основе возможностей, с учетом стоимости и задержки с примерами кода на Python
Оптимизация затрат
Затраты на LLM растут линейно с использованием. Стратегии, которые действительно снижают счет:
Бюджетирование токенов устанавливает лимиты на сессию, задачу или адаптивные ограничения. Адаптивные бюджеты отслеживают реальное использование и со временем ужесточают распределение.
Локальный инференс полностью меняет структуру затрат. После амортизации оборудования локальные модели работают за счет затрат на электроэнергию. GPU при умеренной нагрузке окупается за месяцы.
Кэширование — самая недооцененная оптимизация. Кэширование точных совпадений захватывает повторяющиеся промпты. Семантическое кэширование захватывает промпты, означающие одно и то же. Для систем с высоким трафиком семантическое кэширование устраняет значительную часть вызовов API до их совершения.
Цепочки резервного переключения снижают среднюю стоимость запроса: предпочитайте дорогие модели, когда позволяет бюджет, переключайтесь на более дешевые или локальные по мере прогресса сессии.
Углубленное изучение:
- Оптимизация затрат для систем LLM: Бюджетирование токенов, резервные модели, кэширование — реальные цифры по оборудованию, таблицы окупаемости и рабочие паттерны на Python
Ограждения (Guardrails)
LLM по умолчанию непредсказуемы. Ограждения ограничивают то, что входит, и то, что выходит — без снижения возможностей модели.
Три слоя ограждений имеют значение на практике:
Валидация ввода останавливает проблемы до того, как они достигнут модели. Санитизация промптов захватывает попытки инъекции. Лимиты длины предотвращают расход токенов. Фильтры контента блокируют нарушения политик до того, как инференс что-либо стоит.
Фильтрация вывода захватывает проблемы после генерации. Структурная валидация обеспечивает ожидаемые формы ответов. Проверки контента блокируют вредоносный вывод. Фактчекинг (для критических доменов) валидирует утверждения против базы знаний.
Механизмы безопасности защищают систему со временем: ограничение частоты запросов предотвращает злоупотребления, бюджеты токенов ограничивают затраты на запрос, управление окном контекста предотвращает переполнение и утечку данных между ходами.
Для систем с жесткими требованиями к соответствию (GDPR, HIPAA, SOC 2) добавьте аудит-логирование со структурированными, только-дополняемыми записями и контролем резиденции данных.
Ограждения обрабатывают разговор с моделью, но когда агенты вызывают инструменты и делегируют работу другим агентам, становится необходим второй слой безопасности: кто может действовать, от чьего имени и с каким аудиторским следом. Это безопасность протоколов, а не фильтрация ввода/вывода модели.
Углубленное изучение:
- Ограждения LLM на практике: Валидация ввода, фильтрация вывода, безопасность — практические паттерны ограждений и примечания по соответствию требованиям
- Безопасность агентов A2A и MCP: Идентичность, делегирование и аудиторские следы — безопасность протоколов агентов за пределами безопасности промптов: идентичность, авторизация, шлюзы и контроль делегирования
Проектирование систем с несколькими моделями
Когда одной модели недостаточно, архитектурный вопрос заключается в том: как оркестрировать несколько моделей, не создавая сложность, которая стоит дороже, чем экономит?
Пять паттернов покрывают пространство:
| Паттерн | Задержка | Стоимость | Качество | Используйте, когда |
|---|---|---|---|---|
| Одна модель | Самая низкая | Самая низкая | Переменная | Прототипирование, однородные нагрузки |
| Последовательный (Конвейер) | Высокая | Средняя | Высокая | Многошаговые рабочие процессы со специализацией |
| Параллельный (Вентилятор) | Низкая | Высокая | Высокая | Независимые задачи, A/B тестирование |
| Иерархический (Планировщик-Исполнитель) | Высокая | Высокая | Самое высокое | Сложное рассуждение со специализированным исполнением |
| Ансамбль | Средняя | Самая высокая | Самое высокое | Критические решения, требующие консенсуса |
Правило большого пальца: начинайте с самого простого паттерна, который справляется с вашими реальными ограничениями. Большинство продакшен-систем достигают параллельного или иерархического уровня только после того, как маршрутизация на основе возможностей перестает быть достаточной.
Углубленное изучение:
- Проектирование систем с несколькими моделями: Когда использовать какую модель и почему — все пять паттернов с рабочим кодом на Python и таблицами компромиссов
Фреймворк принятия архитектурных решений
Используйте это как быструю триагу для того, что добавить и когда:
| Проблема | Решение | Когда добавить |
|---|---|---|
| Счет слишком высокий | Маршрутизация с учетом стоимости, кэширование, локальный инференс | Когда затраты на API становятся реальной статьей бюджета |
| Задержка слишком высокая | Маршрутизация с учетом задержки, меньшие модели | Когда пользователи замечают замедление |
| Качество нестабильно | Маршрутизация на основе возможностей, цепочка резервного переключения | Когда простые задачи получают дорогие модели, а сложные — дешевые |
| Пользователи злоупотребляют системой | Валидация ввода, ограничение частоты | Когда вы открываете доступ за пределами доверенной команды |
| Ответы небезопасны или вне политики | Фильтрация вывода, ограждения контента | Когда вы обслуживаете обычных пользователей |
| Одна модель обрабатывает всё | Проектирование с несколькими моделями | Когда нагрузки достаточно расходятся, чтобы оправдать сложность |
| Промпты не работают | Итерации инжиниринга промптов | Всегда — промпты都需要 настройки по мере эволюции задач |
Стройте архитектуру снизу вверх. Инжиниринг промптов всегда в сфере внимания. Добавляйте маршрутизацию, когда компромиссы цена/качество становятся реальными. Добавляйте ограждения, когда вы обслуживаете внешних пользователей. Добавляйте оркестрацию нескольких моделей последней.
Как архитектура LLM связана с другими темами
Архитектура LLM находится на пересечении нескольких связанных кластеров:
Инфраструктура (ниже этого слоя):
- Хостинг LLM в 2026 году: Сравнение локальной, самохостинговой и облачной инфраструктуры — среды выполнения (Ollama, llama.cpp, vLLM), оборудование и решения по хостингу. Архитектурные паттерны зависят от доступной инфраструктуры. Маршрутизация с учетом стоимости имеет смысл только если у вас запущены как локальные, так и API-модели.
- Производительность LLM в 2026 году: Бенчмарки, узкие места и оптимизация — цифры задержки, лимиты VRAM, измерения пропускной способности. Это эмпирические входные данные для решений по маршрутизации и выбору моделей.
Слои приложений (выше этого слоя):
- AI-системы: Самохостинговые ассистенты, RAG и локальная инфраструктура — системы, которые потребляют решения по маршрутизации, ограждениям и оркестрации. Архитектура с несколькими моделями является предварительным условием для продакшен-ассистентов AI.
- Руководство по генерации, дополненной извлечением (RAG) — RAG сам по себе является архитектурным паттерном: конвейер извлечения, подающий контекст в LLM. Паттерны маршрутизации, стоимости и ограждений из этого кластера также применяются внутри конвейеров RAG.
Операционный слой:
- Наблюдаемость: Мониторинг, метрики, Prometheus и руководство по Grafana — продакшен-архитектуре LLM нужна наблюдаемость. Отслеживание затрат, мониторинг задержек и метрики нарушений ограждений требуют инструментации на архитектурном слое, а не только на инфраструктурном.
