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