Спасибо за рекомендацию. Посмотрю, если сохраню интерес к Ornith. А по-поводу 3090. Я тоже рассматривал, но не стал. Blackwell с NVFP4, которой нет и не было у 3090 - это сила :) По-крайней мере у карты есть перспектива на ближайшие лет 5.
На сервере с GPU RTX PRO 4000 Blackwell (24 Gb) тоже сегодня сравнивал две модели в llama.cpp router: текущую продовую qwen36-nvfp4-turbo (Qwen3.6-35B-A3B) и новую ornith15-nvfp4 (Ornith-1.5-35B-A3B, квант NVFP4 Q5K, mmproj для vision, MTP). Условия одинаковые: температура 0.2, по два прогона на каждый промпт, контекст 32k.
Ornith сначала вообще не загрузилась. В логе llama.cpp ошибка на draft-модели frspec: тензор output.weight имел размерность 32768 вместо ожидаемых 248320 (vocab). Отдельный файл mtp-…-frspec-owngen32768.gguf оказался несовместим с текущей версией llama.cpp. Решение такое же, как у Qwen: убрали model-draft из пресета, потому что MTP уже вшит в основной файл *-mtp.gguf. После этого Ornith нормально поднялась.
По скорости Qwen выиграл на всех содержательных промптах примерно в полтора–два раза. На коротком «ответь одним словом» разницы почти нет (0.11 с у обоих). На продуктовом промпте Qwen генерировал около 139 tok/s за 0.9 с, Ornith — 81 tok/s за 1.9 с. На RAG-стиле (проблема, три причины списком) — 156 против 85 tok/s, 1.2 с против 2.7 с. На JSON-задаче разрыв самый большой: 181 против 81 tok/s, 0.2 с против 0.9 с. MTP accept у Qwen на длинных ответах тоже лучше (например, 74/156 против 51/498 на rag-промпте).
По качеству картина другая, но не в пользу Ornith как замены prod. Qwen короче и точнее следует инструкции. На «кратко объясни клиенту про проблему» дала компактный абзац на три–четыре предложения. Ornith развернула ответ с заголовками, списками и пояснением терминов — смысл тот же, но ответ в полтора раза длиннее. На «верни только JSON с steps ["a","b","c"]» Qwen вернула ровно то, что просили. Ornith сохранила JSON-обёртку, но вместо букв a, b, c подставила три полноценных предложения. Для RAG и API, где важны краткость и предсказуемый формат, это минус. Ornith сильнее там, где нужен «разговорный» текст с markdown-структурой — но это решается промптом, а не сменой модели.
Итог: prod оставил на qwen36-nvfp4-turbo. ornith15-nvfp4 остаётся для ручных и vision-экспериментов, но в проде переключаться не стал.
А что такого? Было бы удивительно если бы этого не было. Инструмент есть и его нужно использовать. Сайты в зоне .com - прекрасный показатель (com была введена одной из первых, но именно для коммерческих сайтов. Да в неё лезли все из-за популярности, но коммерция основное предназначение.) коммерсанты ценят быстрый и релевантный контент получаемый с наименьшими затратами. Всё продуктивности и эффективности на единицу вложенных средств.
Однако с появлением AI я могу делать вещи, в которых совершенно не разбираюсь. Как и любой другой - не программист.
На самом деле не Вы делаете эти вещи, а принимаете на веру ответ модели и запускаете его в работу. Часто бывает полезно запросить модель (ту же самую) проверить безопасность кода. Она такое бывает сама за собой находит... Но работает же. Для обычного человека без специфических знаний в БД например, или сетевом стеке или даже в вёрстке сайтов этого вполне достаточно. Его потребность удовлетворена. Ладно если это локально крутится, не касается чувствительных вещей и не выносится в открытый Интернет. А вопрос поддержки? А апгрейды? А поддержка пользователей? Вот это я и имею ввиду под высокоуровневым приложением. Не будем далеко ходить - Хабр навайбкодили или руками писали? А проект его уровня Вы готовы вайбкодить и делать публичным не понимая в конечном итоге, что с ним происходит в каждый момент времени?
Вопрос тот же - как оценить "моё" творение, понять, улучшить эффективность, найти уязвимости и слабые места.
Для человека, который не разбирается - либо при помощи той же модели, либо при помощи приглашённых экспертов. Но в первом случае придётся принимать на веру ответ модели, в код которой Вы уже поверили. То есть опять оставаться в неведении относительно истинного положения вещей.
Совершенно верно! AI не ограничитель, а расширитель возможностей. Секьюрити? Ну попроси его проверить код (лучше сильной моделью), а потом исправить и отчитаться. Не доверяешь? Запроси diff и проверяй сам. В остальном полная свобода творчества.
Я просто начал с основ, показал, что программист в любом случае остаётся программистом. Только переходит в иное качество. А развиваться? Здесь нет стандартного рецепта. Кто-то ходит на курсы по промптингу. Кто-то слушает гуру. Кто-то сам в процессе работы набирает опыт. Пути разные. И для каждого эффективны по своему.
Валентина, LLM-модели сами говорят, что программист в их понимании - это сейчас Архитектор. Именно так, с большой буквы. Но для того чтобы быть Архитектором системы/приложения нужно быть программистом, нужно иметь его знания, и, желательно - опыт. Без этого высокоуровневого приложения, даже при помощи AI, не создашь. Ну вот смотрите, вайб-кодинг доступен уже давно, а 2 февраля 2025 года Карпати ввёл этот термин в обращение. Много мы выдающихся приложений увидели с тех пор? То-то же. Оказывается, не может стая мартышек, даже вооружившись инструментами для вайб-кодинга написать эстетически и функционально законченное произведение.
Слушайте, ну как можно доверять для zdr какому-то левому расширению в браузере даже без сертификации и аудита исходников? Какая нормальная СБ это пропустит? А если это расширение поставлено исключительно с целью сбора всех ПДн и отправки их на свой сервер? Бойтесь данайцев дары приносящих!
А агрегатор откуда знает какие модели применять для пользовательского окружения? Пользователю будет дозволено выбрать модели для своего пайплайна или за него всё решат?
А не проще локальный инференс поднять? У вас с расчётом сметы только Gemini 3.1 Pro может справиться? Или если совсем жалко денег - купить токены у российских провайдеров (Яндекс, Сбер, MWS)?
Существует ли вообще решение этой проблемы, можно ли создать модель, способную системно находить инсайты? Я не знаю. И ChatGPT, который помог мне посчитать стоимость «похода в душ» для LLM, в обсуждении природы инсайта в основном поддакивал или говорил банальности. Видимо, и моя, и его семантическая сетка пока не содержит ответа.
Существует. И работает. На любой уже существующей модели.
Вменяемые разработчики ИИ-агентов всегда прописывают проверку нескольких независимых источников. То, что "сырая" модель "повелась" на фейк ни о чём не говорит. Это просто хайп недалёкого "умника". Вероятно, в базовые системные промпты Claude изначально заложена установка проверки и перепроверки источников. В принципе, это хороший стиль разработчиков Claude, который и выделяет их модели на рынке.
Вот три фундаментальные ошибки в аргументации «LLM не хранит, а согласия достаточно»:
Ошибка 1: «LLM не хранит данные»
Это опасное упрощение. Даже если сама модель не запоминает промпты навсегда, инфраструктура вокруг неё — почти наверняка хранит:
Логи и телеметрия: API-провайдеры (OpenAI, Anthropic, Google и др.) логируют запросы и ответы для мониторинга, отладки и борьбы со злоупотреблениями.
Улучшение моделей: Многие провайдеры по умолчанию используют пользовательские данные для дообучения моделей, если это явно не запрещено в настройках Enterprise-тарифа.
Кеширование и бэкапы: Данные могут временно или постоянно сохраняться на стороне провайдера.
Итог: Даже если вы не сохраняете данные у себя, их получает и обрабатывает третья сторона. С точки зрения закона, это не отменяет факта обработки.
Ошибка 2: «Согласия субъекта достаточно»
Нет, недостаточно. Ни в РФ (152-ФЗ), ни в ЕС (GDPR).
В контексте 152-ФЗ (Россия):
Локализация (ст. 18(5)): Первичный сбор и хранение персональных данных граждан РФ должны осуществляться на серверах, физически находящихся в России. Отправка данных в API иностранной LLM нарушает это требование, даже при наличии согласия.
Трансграничная передача: Если данные уходят за рубеж, это отдельный юридический процесс. Он требует либо наличия страны в «белом списке» Роскомнадзора, либо обеспечения адекватной защиты, либо выполнения ряда бюрократических процедур. Просто «получить галочку согласия» здесь не работает.
Комплекс мер: Закон также требует обеспечения безопасности (шифрование, доступы), уведомления Роскомнадзора, назначения ответственного и т.д.
Вывод: Согласие — это лишь одно из условий начала обработки, но оно не отменяет требования локализации и безопасности.
Ошибка 3: «Нет хранения = нет регулирования»
Законы о персональных данных регулируют обработку (processing), а не только хранение.
Определение: Обработка — это любое действие с данными: сбор, запись, передача, систематизация, использование, обезличивание, блокирование, удаление.
Транзит — это тоже обработка: Сам факт отправки промпта с персональными данными (например, «Пациент Иванов, диагноз...») на сервер в другую юрисдикцию уже является трансграничной передачей и подпадает под регулирование.
Почему для российской команды это критично?
Если российский сервис отправляет пользовательские данные (ФИО, телефоны, историю обращений) в API иностранной LLM:
Нарушается требование локализации баз данных.
Возникает неконтролируемая трансграничная передача.
Провайдер LLM может использовать эти данные для обучения, что делает невозможным выполнение требования об удалении данных по запросу пользователя («право на забвение»).
Резюме: Использование иностранных LLM для работы с персональными данными граждан РФ возможно только в обезличенном виде, либо через специальные шлюзы/прокси, обеспечивающие локализацию и юридическую чистоту передачи. В противном случае выбор действительно сводится к российским решениям или self-hosted моделям, развернутым внутри контура компании.
Надеюсь, теперь Вы видите разницу между «технически модель не запоминает» и «юридически мы передали данные третьей стороне». Безопасность и комплаенс — это про архитектуру целиком, а не только про веса модели.
Спасибо за рекомендацию. Посмотрю, если сохраню интерес к Ornith. А по-поводу 3090. Я тоже рассматривал, но не стал. Blackwell с NVFP4, которой нет и не было у 3090 - это сила :) По-крайней мере у карты есть перспектива на ближайшие лет 5.
Спасибо, её и жду.
На сервере с GPU RTX PRO 4000 Blackwell (24 Gb) тоже сегодня сравнивал две модели в llama.cpp router: текущую продовую qwen36-nvfp4-turbo (Qwen3.6-35B-A3B) и новую ornith15-nvfp4 (Ornith-1.5-35B-A3B, квант NVFP4 Q5K, mmproj для vision, MTP). Условия одинаковые: температура 0.2, по два прогона на каждый промпт, контекст 32k.
Ornith сначала вообще не загрузилась. В логе llama.cpp ошибка на draft-модели frspec: тензор output.weight имел размерность 32768 вместо ожидаемых 248320 (vocab). Отдельный файл mtp-…-frspec-owngen32768.gguf оказался несовместим с текущей версией llama.cpp. Решение такое же, как у Qwen: убрали model-draft из пресета, потому что MTP уже вшит в основной файл *-mtp.gguf. После этого Ornith нормально поднялась.
По скорости Qwen выиграл на всех содержательных промптах примерно в полтора–два раза. На коротком «ответь одним словом» разницы почти нет (0.11 с у обоих). На продуктовом промпте Qwen генерировал около 139 tok/s за 0.9 с, Ornith — 81 tok/s за 1.9 с. На RAG-стиле (проблема, три причины списком) — 156 против 85 tok/s, 1.2 с против 2.7 с. На JSON-задаче разрыв самый большой: 181 против 81 tok/s, 0.2 с против 0.9 с. MTP accept у Qwen на длинных ответах тоже лучше (например, 74/156 против 51/498 на rag-промпте).
По качеству картина другая, но не в пользу Ornith как замены prod. Qwen короче и точнее следует инструкции. На «кратко объясни клиенту про проблему» дала компактный абзац на три–четыре предложения. Ornith развернула ответ с заголовками, списками и пояснением терминов — смысл тот же, но ответ в полтора раза длиннее. На «верни только JSON с steps ["a","b","c"]» Qwen вернула ровно то, что просили. Ornith сохранила JSON-обёртку, но вместо букв a, b, c подставила три полноценных предложения. Для RAG и API, где важны краткость и предсказуемый формат, это минус. Ornith сильнее там, где нужен «разговорный» текст с markdown-структурой — но это решается промптом, а не сменой модели.
Итог: prod оставил на qwen36-nvfp4-turbo. ornith15-nvfp4 остаётся для ручных и vision-экспериментов, но в проде переключаться не стал.
А что такого? Было бы удивительно если бы этого не было. Инструмент есть и его нужно использовать. Сайты в зоне .com - прекрасный показатель (com была введена одной из первых, но именно для коммерческих сайтов. Да в неё лезли все из-за популярности, но коммерция основное предназначение.) коммерсанты ценят быстрый и релевантный контент получаемый с наименьшими затратами. Всё продуктивности и эффективности на единицу вложенных средств.
На самом деле не Вы делаете эти вещи, а принимаете на веру ответ модели и запускаете его в работу. Часто бывает полезно запросить модель (ту же самую) проверить безопасность кода. Она такое бывает сама за собой находит... Но работает же. Для обычного человека без специфических знаний в БД например, или сетевом стеке или даже в вёрстке сайтов этого вполне достаточно. Его потребность удовлетворена. Ладно если это локально крутится, не касается чувствительных вещей и не выносится в открытый Интернет. А вопрос поддержки? А апгрейды? А поддержка пользователей? Вот это я и имею ввиду под высокоуровневым приложением. Не будем далеко ходить - Хабр навайбкодили или руками писали? А проект его уровня Вы готовы вайбкодить и делать публичным не понимая в конечном итоге, что с ним происходит в каждый момент времени?
Для человека, который не разбирается - либо при помощи той же модели, либо при помощи приглашённых экспертов. Но в первом случае придётся принимать на веру ответ модели, в код которой Вы уже поверили. То есть опять оставаться в неведении относительно истинного положения вещей.
Совершенно верно! AI не ограничитель, а расширитель возможностей. Секьюрити? Ну попроси его проверить код (лучше сильной моделью), а потом исправить и отчитаться. Не доверяешь? Запроси diff и проверяй сам. В остальном полная свобода творчества.
Я просто начал с основ, показал, что программист в любом случае остаётся программистом. Только переходит в иное качество. А развиваться? Здесь нет стандартного рецепта. Кто-то ходит на курсы по промптингу. Кто-то слушает гуру. Кто-то сам в процессе работы набирает опыт. Пути разные. И для каждого эффективны по своему.
Валентина, LLM-модели сами говорят, что программист в их понимании - это сейчас Архитектор. Именно так, с большой буквы. Но для того чтобы быть Архитектором системы/приложения нужно быть программистом, нужно иметь его знания, и, желательно - опыт. Без этого высокоуровневого приложения, даже при помощи AI, не создашь. Ну вот смотрите, вайб-кодинг доступен уже давно, а 2 февраля 2025 года Карпати ввёл этот термин в обращение. Много мы выдающихся приложений увидели с тех пор? То-то же. Оказывается, не может стая мартышек, даже вооружившись инструментами для вайб-кодинга написать эстетически и функционально законченное произведение.
Слушайте, ну как можно доверять для zdr какому-то левому расширению в браузере даже без сертификации и аудита исходников? Какая нормальная СБ это пропустит? А если это расширение поставлено исключительно с целью сбора всех ПДн и отправки их на свой сервер? Бойтесь данайцев дары приносящих!
Зачем доводить проект до залежалого легаси? Раз в полгода - нормальный срок для пересмотра проекта и его оптимизации под современные архитектуры.
Работает. Результаты очень хорошие. Даже лучше, чем у Sol.
А агрегатор откуда знает какие модели применять для пользовательского окружения? Пользователю будет дозволено выбрать модели для своего пайплайна или за него всё решат?
Проверил. 5 минут на решение проблемы с уведомлениями от PWA в iOS.
del
Сборная солянка моделей.
А не проще локальный инференс поднять? У вас с расчётом сметы только Gemini 3.1 Pro может справиться? Или если совсем жалко денег - купить токены у российских провайдеров (Яндекс, Сбер, MWS)?
Сомнительная идея запускать на своей машине бинарники, которые шарятся по системе и отправляют телеметрию.
Существует. И работает. На любой уже существующей модели.
Вменяемые разработчики ИИ-агентов всегда прописывают проверку нескольких независимых источников. То, что "сырая" модель "повелась" на фейк ни о чём не говорит. Это просто хайп недалёкого "умника". Вероятно, в базовые системные промпты Claude изначально заложена установка проверки и перепроверки источников. В принципе, это хороший стиль разработчиков Claude, который и выделяет их модели на рынке.
Вот три фундаментальные ошибки в аргументации «LLM не хранит, а согласия достаточно»:
Ошибка 1: «LLM не хранит данные»
Это опасное упрощение. Даже если сама модель не запоминает промпты навсегда, инфраструктура вокруг неё — почти наверняка хранит:
Логи и телеметрия: API-провайдеры (OpenAI, Anthropic, Google и др.) логируют запросы и ответы для мониторинга, отладки и борьбы со злоупотреблениями.
Улучшение моделей: Многие провайдеры по умолчанию используют пользовательские данные для дообучения моделей, если это явно не запрещено в настройках Enterprise-тарифа.
Кеширование и бэкапы: Данные могут временно или постоянно сохраняться на стороне провайдера.
Итог: Даже если вы не сохраняете данные у себя, их получает и обрабатывает третья сторона. С точки зрения закона, это не отменяет факта обработки.
Ошибка 2: «Согласия субъекта достаточно»
Нет, недостаточно. Ни в РФ (152-ФЗ), ни в ЕС (GDPR).
В контексте 152-ФЗ (Россия):
Локализация (ст. 18(5)): Первичный сбор и хранение персональных данных граждан РФ должны осуществляться на серверах, физически находящихся в России. Отправка данных в API иностранной LLM нарушает это требование, даже при наличии согласия.
Трансграничная передача: Если данные уходят за рубеж, это отдельный юридический процесс. Он требует либо наличия страны в «белом списке» Роскомнадзора, либо обеспечения адекватной защиты, либо выполнения ряда бюрократических процедур. Просто «получить галочку согласия» здесь не работает.
Комплекс мер: Закон также требует обеспечения безопасности (шифрование, доступы), уведомления Роскомнадзора, назначения ответственного и т.д.
Вывод: Согласие — это лишь одно из условий начала обработки, но оно не отменяет требования локализации и безопасности.
Ошибка 3: «Нет хранения = нет регулирования»
Законы о персональных данных регулируют обработку (processing), а не только хранение.
Определение: Обработка — это любое действие с данными: сбор, запись, передача, систематизация, использование, обезличивание, блокирование, удаление.
Транзит — это тоже обработка: Сам факт отправки промпта с персональными данными (например, «Пациент Иванов, диагноз...») на сервер в другую юрисдикцию уже является трансграничной передачей и подпадает под регулирование.
Почему для российской команды это критично?
Если российский сервис отправляет пользовательские данные (ФИО, телефоны, историю обращений) в API иностранной LLM:
Нарушается требование локализации баз данных.
Возникает неконтролируемая трансграничная передача.
Провайдер LLM может использовать эти данные для обучения, что делает невозможным выполнение требования об удалении данных по запросу пользователя («право на забвение»).
Резюме: Использование иностранных LLM для работы с персональными данными граждан РФ возможно только в обезличенном виде, либо через специальные шлюзы/прокси, обеспечивающие локализацию и юридическую чистоту передачи. В противном случае выбор действительно сводится к российским решениям или self-hosted моделям, развернутым внутри контура компании.
Надеюсь, теперь Вы видите разницу между «технически модель не запоминает» и «юридически мы передали данные третьей стороне». Безопасность и комплаенс — это про архитектуру целиком, а не только про веса модели.