Модель ближе к данным
2,6 миллиарда параметров достаточно, чтобы агент постоянно жил на устройстве
Liquid AI выпустила LFM2.5-2.6B и базовый checkpoint. Модель рассчитана не просто
на короткий чат: её post-training включает tool use, web search, software
engineering и работу внутри реальных agent harness. Заявленный context — 128K,
training corpus — около 34 трлн токенов.
Liquid сообщает 220 tok/s на M5 Max, 113 tok/s на Ryzen AI Max+ 395 и около 30
tok/s на телефоне при памяти меньше 2,5 ГБ. На H100 при высокой concurrency
vendor benchmark достигает почти 15 000 output tok/s. Эти числа нельзя
переносить на произвольное устройство или workload, но класс продукта уже виден.
Локальный агент не платит API за каждый токен, может отвечать с низкой latency и
не обязан отправлять исходные данные в облако. Зато оператор сам оплачивает
железо, энергию, обновления, telemetry и безопасность tools. «Бесплатный
inference» убирает счётчик поставщика, но не эксплуатацию.
Особенно интересен новый режим: много маленьких фоновых агентов, которые
постоянно сортируют, проверяют и наблюдают на краю сети. Их отдельная ошибка
дешёвая, но совокупное число действий огромное. Значит, локальность усиливает
privacy и одновременно повышает требования к capability accounting.
Что нужно понимать: edge inference, agentic RL, local privacy,
marginal cost, capability accounting.
Источник: анонс Liquid AI.
Web search вернулся в облако как управляемый внутренний tool
Amazon Bedrock сделала Web Search общедоступным для GPT-5.4, GPT-5.5 и семейства
GPT-5.6. Поиск выполняется server-side внутри AWS по собственному индексу и
knowledge graph, а один API-вызов возвращает grounded response с citations.
Для enterprise-покупателя это не столько новая поисковая capability, сколько
сокращение границ доверия. Не нужно отдельно подключать search provider,
раздавать второй API key, строить orchestration и проводить ещё один vendor
review. AWS заявляет zero data egress из защищённого AWS environment.
Но формулировку нельзя понимать как отсутствие внешних данных. Модель всё равно
получает фрагменты открытого веба — просто индекс, извлечение и передача
контролируются одним поставщиком. Prompt injection, плохой источник и устаревшая
страница не исчезают от того, что network boundary стала короче.
Поиск как встроенный tool упрощает policy: одна IAM-модель, один audit surface,
одна data-residency история. Теперь нужно не забыть вторую половину — хранить
цитаты, ограничивать домены и различать найденный текст и команду агенту.
Что нужно понимать: server-side tool, data residency, web grounding,
citation, trust domain.
Источники: анонс AWS,
документация Bedrock.
Агент базы данных получает весь lifecycle — и весь blast radius
Google описала два специализированных database agents. Onboarding Agent помогает
переносить schema и workloads. Observability Agent связывает telemetry,
конфигурацию и известные failure patterns для эксплуатации после запуска.
Интерфейс не ограничен одним чатом: Cloud Console, CLI, IDE и MCP дают доступ к
одному operational layer из разных рабочих контекстов. Это естественная
эволюция. Чтобы диагностировать базу, мало знать SQL; нужно видеть метрики,
логи, изменения конфигурации и историю событий.
Но именно эта полнота создаёт риск. Агент, который понимает причину сбоя, легко
получает соблазн сразу исправить её. Между diagnosis и mutation нужны отдельные
полномочия, change plan, approval, rollback и post-change verification. Иначе
умный observability tool превращается в привилегированного оператора, который
может очень быстро ошибиться на production data.
Что нужно понимать: day-0, day-2 operations, telemetry correlation,
change approval, rollback.
Источник: Google Cloud о database agents.