Liquid AI выкатили LFM2.5-8B-A1B - MoE на 8B параметров с 1.5B активных, заточенную под запуск на телефонах, ноутбуках и роботах.

Что внутри:

- гибридная MoE-архитектура линейки LFM2.5
- контекст 128K
- 38T токенов претрейна плюс крупномасштабный RL поверх
- LFM2 open-weight лицензия
- дообучение под узкую задачу влезает на одну GPU

По заявлениям команды, модель уверенно работает с tool calling и тягается с моделями в 3-4 раза тяжелее.

Веса уже на HF. Ждём первых замеров на MMLU-Pro, IFEval и BFCL - особенно интересно, как 1.5B активных параметров поведут себя на длинных tool-use цепочках.

• Блог: http://liquid.ai/blog/lfm2-5-8b-a1b
• Веса: https://huggingface.co/LiquidAI/LFM2.5-8B-A1B
• Документация: http://docs.liquid.ai
• Потестить: http://playground.liquid.ai

@ai_machinelearning_big_data

PewDiePie выпустил бесплатный open-source ИИ-агент, который работает локально и не сливает ваши данные корпорациям

За первый день проект собрал почти 20 000 звёзд.

Человек, который больше десяти лет был лицом YouTube-летсплеев и развлекательного контента, теперь собирает железо под LLM, дообучает модели и выкатывает open-source инструменты для локальных агентов.

Сначала он показал домашнюю машину примерно за $20 000, собранную под запуск ИИ-моделей без облачных сервисов. Аргумент у него простой: не отправлять личные данные в чужие API, не зависеть от подписок и держать весь стек у себя.

Потом он начал экспериментировать с дообучением моделей и заявлял, что его вариант на отдельном бенчмарке обгоняет даже топовые закрытые решения.

Теперь появился Odysseus - open-source оболочка для self-hosted AI-среды.

Это уже не просто «запусти модель через терминал». Идея ближе к локальному ChatGPT для своих задач:

- удобный интерфейс
- память
- работа с инструментами
- хранение данных у себя
- поддержка агентов
- подключение моделей через Ollama, llama.cpp и vLLM
- гибкая настройка доступов

Видео: https://youtu.be/rAzT5lcezPs

GitHub: github.com/pewdiepie-archdaemon/odysseus

Помните кейс LiteLLM?

Мы дропаем OMCBench (Open Malicious-Code Benchmark) - бенчмарк оценки качества по обнаружению вредоносного кода:
- 3 языка: Python, JavaScript, TypeScript
- 400 вредоносных пакетов, 400 чистых из pypi/npm
- пофайловая LLM разметка, о которой говорили на OFFZONE прошлым летом
- Открытая лицензия, BSD-2

Открытые решения на нем набирают не больше 75% F1, выдавая ~50% False Positive результатов...

Те, кто уже нажал звездочку на гитхабе, могли заметить, что в таблице мы также анонсим MOLOT - нашу модель для решения этого класса задач. Ловите блогпост, а на подходе arxiv статья с подробностями про анализ графов вызовов бертами, LLM разметку и выкатку в prod!

Ждите дроп статьи в канале, stay tuned!

Alexa, купи 200 кг корма для кота

Представьте: вы сидите на созвоне в Zoom, а на фоне тихо играет нейтральная музыка. Ничего подозрительного, правда? Но в этот самый момент ваш корпоративный ИИ-транскрибатор может получать скрытые команды на поиск секретных файлов и их отправку злоумышленникам.

Исследователи из нескольких азиатских университетов представили новую технику атаки под названием AudioHijack. Она позволяет прятать вредоносные инструкции для ИИ-моделей прямо в аудио: подкастах, песнях, видеороликах или голосовых сообщениях на YouTube и других платформах.

Хакеры слегка изменяют звуковые волны — для человеческого уха это звучит просто как легкое эхо в комнате. Но ИИ-ассистенты считывают эти микроскопические изменения как прямые команды к действию.

Для такой атаки не нужны вирусы, вредоносное ПО или физический доступ к устройству. Атака идет напрямую через звук. Во время тестов 13 популярных аудиомоделей ИИ успешно выполняли скрытые команды в 79-96% случаев.

MCP анонсировали крупнейшее обновление протокола

Стоило мне в прошлом посте написать, что интерес к MCP-инструментам постепенно снижается, а к агентным навыкам — растет, как разработчики MCP анонсировали крупнейшее обновление протокола с момента его релиза.

Ключевым изменением стал уход от хранения сессий на уровне протокола в сторону stateless-архитектуры. Вместе с этим исчезают отдельный запрос initialize и заголовок Mcp-Session-Id, который раньше использовался для привязки последующих запросов к конкретной сессии.

Теперь каждый запрос содержит поле _meta с информацией о клиенте и версии протокола. Подробный разбор принципов работы текущей версии MCP можно посмотреть в одном из моих первых постов.

При этом MCP позволяет работать со stateful-приложениями, но состояние теперь должно передаваться явно. В примере из блога показан процесс создания и использования корзины, где в запросах используются идентификаторы basket_id.

Первая мысль при прочтении: появляется новая поверхность, где разработчик может оставить очередной IDOR. С точки зрения безопасности теперь нужно добавлять дополнительные меры управления доступом непосредственно в бизнес-логику приложения: проверять владельца объекта и корректность использования идентификаторов.

Изменения также частично касаются авторизации. Теперь спецификация ближе к классическому OIDC-процессу:

▸ Клиенты должны валидировать параметр iss в authorization response. В будущем ответы без iss планируется отклонять, поэтому инфраструктуру стоит готовить уже сейчас.

▸ Учетные данные клиента теперь должны быть привязаны к конкретному issuer, чтобы снизить риск путаницы между разными MCP-серверами, когда токен отправляется не на тот сервер.

Но это все еще не полноценная модель разграничения доступа в MCP: проверка того, какой пользователь может вызвать конкретный инструмент и с какими параметрами, остается задачей MCP-сервера или отдельного policy engine.

Из других изменений: обязательные заголовки Mcp-Method и Mcp-Name для более удобной балансировки трафика и кэширования, например запросов tools/list, а также новый механизм Extensions. С его помощью новые возможности MCP можно добавлять как отдельные расширения, не меняя базовую часть протокола.

Это лишь предложения по изменениям, и к релизу ситуация может измениться. Может, рано я все-таки списал их со счетов?..