Куда на самом деле движется индустрия LLM (спойлер: вы выбираете не модель - вы выбираете стек).
Пост навеян свежим
релизом Opus 4.5, а именно ее доп фичами как
Context Editing - нам показывают действительно
впечатляющие демки… Но постойте - это же (очередная) не-фича foundation модели.
Это не что-то в весах. Это инфраструктурный middleware, который живет между вами и моделью. И если вы проанализируете (особенно глазами разработчика) релизы последнего года, то вы увидите что мы все дальше
от бога от LLM как модели, и тем ближе к LLM как infrastructure-as-a-service. Давайте поговорим, куда нас ведет индустрия и что из этого следует, но начнем с начала.
Большинство людей (в том числе многие разработчики) когда говорят про условный ChatGPT не видят весь спектр между "моделью" и "продуктом" - ведь это одновременно и foundation model, и старый добрый completions API, и вполне себе агентный Responses API c Code Interpreter, File Search (RAG прямо в "модельке", ага) и т.д.
Что на самом деле продают вендорыOpenAI Responses API - это целая инфра, включая NoSQL БД для истории, хранилище файлов и тд. Вы отдали им state management.
Code Interpreter и
Code Execution - это PaaS: managed sandbox - $0.03 за сессию платите за инфру, не за "умную модель".
Claude Context Editing - middleware с настраиваемой стратегией pruning (keep last 3 tool uses, clear 5000+ tokens). Оркестрация, а не интеллект.
Google Grounding и
Maps tool - dynamic retrieval: модель решает нужен ли поиск, генерит queries, получает доступ к индексу (глубже публичного API), делает reranking, отдает с citations. Вы покупаете gateway к индексу, не модель.
Даже
Structured Outputs - это частично заслуга инфры, а не весов - constrained decoding через CFG (конвертит JSON Schema в грамматику, маскирует невалидные токены). Компилятор поверх модели.
Большинство не осознают, как растет пропасть между проприетарными infrastructure-as-a-service от OpenAI/Google/Anthropic и голыми весами open-source моделей. Проприетарные LLM превращаются из inference провайдеров в операционки для intelligence.
Что из этого следует и что следует иметь в виду1. Понимать уровни зависимости, я выделяю три:
- State (Threads, File API, memory) - критический lock-in, вы не владеете памятью системы
- Execution (Code Interpreter, sandboxes) - средний lock-in, нужна своя инфра для рантайма
- Behavior (Grounding, Computer Use) - средне-высокий, модель часто обучена под "свои" инструменты
Перед использованием любой фичи спрашивайте: "Где живут данные? Кто контролирует логику? Смогу ли я воспроизвести это сам?"
2. Integration Tax vs Migration Tax - ключевая асимметрия. Проприетарные фичи дают быстрый старт, но стоимость выхода растет экспоненциально. Это не обязательно плохо - это trade-off, который нужно делать осознанно.
3. Разделять Core и периферию
Core (ваша уникальная ценность, основа продукта) - инвестируйте в независимость: свой state management, своя оркестрация и тд.
Пример: AI-агент для support как продукт - владение историей диалогов критично, а вот Code Interpreter для внутренней аналитики - это ок.
4. Есть обратная сторона. Чем глубже расходятся продуктовые слои провайдеров, тем сложнее делать model-agnostic продукты, которые работают так же хорошо. Manus поняли это рано - выжали максимум из Anthropic, не пытаясь быть совместимыми со всеми, и сделали продукт-звезду. Возможно, по той же причине Claude Code так хорош?
5. Учитывайте свою стадию. 0→1 (поиск PMF) - максимально используйте проприетарные фичи, скорость важнее. Когда растете - можно строить абстракции: gateway, свой state для core функций. На стадии масштабирования - еще больше контроля и взаимозаменяемости компонентов (interoperability это дорого).
ГлавноеПроприетарные AI-платформы - это managed infrastructure, как AWS. Вы платите не только деньгами, но и зависимостью. И этот тренд будет расти. Часто это правильный trade-off, особенно на старте. Но это решение нужно принимать с открытыми глазами - понимать, какую часть системы отдаете "в управление", и делать это осознанно для каждого компонента продукта.
