Куда на самом деле движется индустрия 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, особенно на старте. Но это решение нужно принимать с открытыми глазами — понимать, какую часть системы отдаете «в управление», и делать это осознанно для каждого компонента продукта.
Добавить комментарий