/ИИ окупается. Только не у вас/ Главный экономист инвестфонда Apollo Торстен Слок посчитал, кто на самом деле зарабатывает на ИИ. Ответ получился короткий: семь техгигантов. В индексе S&P 500 есть «великолепная семёрка»: Apple, Microsoft, Alphabet, Amazon, Meta, Nvidia и Tesla. У них выручка на одного сотрудника и маржа растут. У остальных 493 компаний обе цифры стоят на месте. Вывод Слока: признаков того, что ИИ ускоряет рост производительности, пока нет, и судьба всей истории про ИИ решится как раз в этих 493 компаниях. Ещё один интересный сдвиг: обычный бизнес начинает воспринимать расходы на ИИ как статью затрат, которая съедает маржу. Модели дорожают, компании переходят на решения подешевле. Даже CEO Goldman Sachs, который только что объявил о вложениях в ИИ на полмиллиарда долларов, сказал инвесторам, что самые мощные модели им почти ни для чего не нужны. Добавим сюда недавний опрос Национального бюро экономических исследований США, где около 90% руководителей сказали, что ИИ за три года не повлиял ни на занятость, ни на продуктивность их компаний. Картинка складывается такая: денег вложено очень много, а отдачи в обычных компаниях пока не видно. Что это значит для нас. Когда вам говорят, что сокращение «из-за ИИ», стоит относиться к этому скептически. Нередко за этим стоят перенайм прошлых лет, урезанные бюджеты или те самые дорогие вложения в ИИ, которые надо чем-то компенсировать. Самая ценная роль сейчас - человек, который умеет довести ИИ до денег в обычном бизнесе. Пользоваться чат-ботом умеют все. А вот найти процесс, где он реально экономит часы или приносит выручку, посчитать эффект и показать его финдиректору умеют единицы. Именно этого сейчас не хватает тем 493 компаниям. И для тех, кто внедряет ИИ у себя: начинайте с вопроса «какую метрику это сдвинет». Без ответа на него проект почти гарантированно превратится в ту самую статью затрат. источник

Один флаг llama.cpp может резко замедлить обработку промпта – без ошибки и предупреждения. В обсуждении #28455 описан случай: при включённом Flash Attention выбор `q5_1` для KV-кэша переносил вычисление внимания с GPU на CPU. Модель продолжала работать, но скорость падала. Причина – отсутствие CUDA-ядер для выбранного формата кэша в стандартной сборке. В замерах автора на RTX 4080 обработка промпта ускорилась с 38 до 1348 токенов/с после замены q5_1 на q8_0. Это скорость чтения входного запроса, а не генерации ответа. Для затронутых сборок обходной вариант:

-fa on -ctk q8_0 -ctv q8_0

Ещё один поддерживаемый вариант – одинаковый q4_0 для K и V. Если нужен q5_1, автор предлагает пересборку с:

-DGGML_CUDA_FA_ALL_QUANTS=ON

Если GPU почти простаивает, а CPU загружен – проверьте формат KV-кэша и параметры сборки. Участник команды llama.cpp подтвердил, что проблема известна. https://github.com/ggml-org/llama.cpp/issues/28455

Когда речь заходит об обучении работников, я почему-то всегда вспоминаю Советскую армию и то, как меня учили работать на коммутаторе связи. В один прекрасный день нам, двум молодым солдатам, объявили, что мы будем телефонистами. Привели в крохотную комнату с работающим полковым коммутатором и дали минут пятнадцать понаблюдать за оператором. Потом наш инструктор и по совместительству без пяти минут дембель, пинком отправил оператора в коридор и посадил нас на его место. С помощью коротких и не всегда цензурных инструкций, подкреплённых подзатыльниками, минут за сорок мы приобрели квалификацию телефонистов. На этом наше обучение закончилось. Примерно так же выглядит обучение операторов во многих небольших компаниях. Если убрать подзатыльники, остаются две составляющие: Теория - «Если горит эта лампочка, нужно дёрнуть эту пимпочку» Практика - «Смотри, как надо делать» Иногда бывает дополнительный урок - «Видел, как я сейчас сделал? Вот так ни в коем случае нельзя!» С одной стороны, армейские методы позволяют фильтровать персонал - работать остаются только морально устойчивые, быстро соображающие и готовые работать в компании люди, которые не убегут при первых трудностях. С другой стороны получить лояльного профессионала таким образом точно не получится. Сейчас занимаюсь анализом сменных отчётов за последний месяц. Статистика показывает, что выработка у опытных печатников выше, чем у остальных в среднем на 20% Поэтому инвестиции в обучение должны окупиться окупиться достаточно быстро. Сейчас разрабатываем большую программу обучения новых и уже работающих печатников. У нас в штате уже есть менеджер по обучению и методист. Обучать будут как наши технологи, так и приглашённый консультант. Однако даже хороший тренер не решит главную задачу за ученика - тот должен сам хотеть научиться. Для меня хороший знак, это когда человек задаёт вопросы. Ещё лучше, когда самостоятельно ищет информацию. Если этот интерес поддерживать, может вырасти специалист очень высокого уровня (правда, потом придётся думать, как его удержать, но это уже другая история) И вот здесь у желающих учиться появился мощный помощник - ИИшки. Можно попросить объяснить непонятное простыми словами, разобрать конкретную задачу, задать хоть двадцать уточняющих вопросов. Поэтому следующий пост будет об искусственном интеллекте. Какие полезные вещи, кроме обучения, нам удалось сделать с его помощью и сколько денег нам это сэкономило. Не переключайтесь Незаметный бизнес

Как в MWS Cloud построили сетевой балансировщик с минимальными потерями производительности На первый взгляд у балансировщика довольно простая работа: принять трафик, распределить его между виртуалками и следить, чтобы запросы не уходили на упавшие серверы. Всё выглядит прекрасно, пока дело не доходит до реальных пакетов, маршрутизации и отказоустойчивости. В MWS Cloud построили собственный NLB и получили разницу всего в 1-2% между прямым обменом виртуальных машин и обменом через балансировщик. Правда, ради этого пришлось пойти на архитектурные компромиссы. Первую схему проверки доступности серверов выбрали за простоту, хотя заранее понимали, что она плохо масштабируется. Следующая избавила от одних проблем, зато принесла другие. Узнаем, как инженеры выстраивали маршруты пакетов, выбирали между производительностью и гибкостью и почему даже удачные решения приходится пересматривать.

Про "комфортный климат", ч.1: комфортная температура воздуха Об этом такие разные мнения! Кому-то нормально в Бангкоке, другому нужна прохлада Копенгагена. Но по этому вопросу есть и объективные данные! 1️⃣ Человек - тропическое животное, и в "базовой" жизни, без одежды и дома, комфортная температура - это 28-30 °C! (pubmed) Выше - тело начинает потеть, ниже - выделять тепло. Жарко? Да! Это потому что мы носим одежду, и даже легкая сводит диапазон комфорта до 22-24 °C. Это справедливо для всех людей. Конечно есть индивидуальные физиологические особенности, но возраст, пол, доля жира или мышц дает лишь 1-2 градуса разброса от комфортных 22-24 °C (pubmed раз, два). 2️⃣ Есть два значимых фактора, влияющих на индивидуальное определение комфортной температуры: а) Уровень активности человека: кому-то нравится бегать по улице в полдень, и конечно в теплых странах это делать сложно. Например для марафона вообще идеальны 10-12 °C (pdf) б) Привычки в одежде: любитель все время носить худи сдвигает комфортную температуру ниже 20-21 °C. Если человек говорит, что ему комфортно в 15 °C, то это можно перевести как "нравится ходить в куртке" и/или "все время бегаю". Есть "калькулятор температурного комфорта" из Беркли, где можно самому оценить вес критериев (в т.ч. одежды). 3️⃣ Часто говорят, что влажность критически важна. Это правда, но только для температур, сильно выходящих за пределы комфортной. Проще говоря, если на улице 30 °C, то влажность меняет многое. Но если 23 °C - то буквально ничего (pdf) 4️⃣ Гендерная разница в ощущениях температуры является следствием того, что просто отличаются характеристики тела мужчин и женщин. Если взять одинаковых по параметрам М и Ж, то разницы в ощущениях почти не будет (pubmed). 5️⃣ Как правильно заметил Антон в комментариях, говорить люди могут много, но в домах у людей температуры почти всегда близки к комфортным. Точнее так: кто может себе позволить, греют до 21-23 °C, а холодные дома - это бедность, старый фонд или культура, за которые люди платят здоровьем (ВОЗ рекомендует минимум 18 °C). Более того, мир много это изучал на предмет производительности труда на рабочих местах, есть отраслевые стандарты по температуре/влажности в помещении. Пик производительности - на 22 °C (pub). 6️⃣ Кстати ощущаемая температура в помещении - это примерно среднее между воздухом и поверхностями вокруг. При 22 °C воздуха и холодных стенах, вокруг ощущается как 19-20. Поэтому кондиционер в испанской квартире может греть, а теплее не становится 🙂 7️⃣ Короче говоря, это типичный пример разницы "что люди говорят vs что они делают". По вопросу комфортной температуры все мы - почти одинаковые человеки, и просто внешними факторами (одеждой, активностью) регулируем микроклимат вокруг тела до комфортных нам тропических 28-30 °C. @kyrillic

Издание ComputerBase протестировало патч для NVIDIA DLSS 5 в NBA 2K27 на платформе RTX Spark. Обновление, выходящее 16 октября, обещает прирост производительности до 40 % за счёт оптимизации нейросети и сокращение расхода видеопамяти на 20 % в 4K. В тестах при разрешении WQHD, трассировке лучей, DLSS Performance и Multi Frame Generation 3× средний FPS вырос с 97,1 до 124,8 (+29%), а показатель 1% Low — с 43,4 до 47,3 FPS. Задержка снизилась с 93,3 до 77,6 мс. При этом отключение нейросетевого рендеринга DLSS 5 выдаёт 210,1 FPS при задержке 55,8 мс — обновлённый алгоритм отстаёт от нативного изображения почти на 41 %. При этом RTX Spark показывает хорошие результаты в локальных ИИ-задачах, опережая решения Apple и AMD. Но в играх ей мешают ограничения процессорных ядер Grace, эмуляция x86 и пропускная способность памяти, отмечает Tom’s Hardware.

Ну че, как вам G0VNO в итоге? От себя скажу одно, я чет особо не впечатлился этими вашими локальными модельками, они как по мне абсолютно не годятся для узконаправленных задач. Их максимум это суммаризация данных, либо использование мультимодалок для перевода текста/аудио в текст. Вот вайбкодить на этом, я думаю, никакого удовольствия не будет. Хз как оно с агентами будет работать, это конечно требует больше тестов. Но тут есть НЮАНСИКИ: Во-первых, производительность, даже 100 ток\сек кажутся чудовищно медленными. Во-вторых, сайд эффекты от квантизации лупят мощно по конечному результату. Иногда модели даже жестко игнорят инструкции, и это на маленьком контексте. Под агентов нужен контекст минимум 100к, а на нем эти проблемы могут стать хуже. P.S. Все репорты на бусти залил еще с утра.

Я думал я один такой: лимиты Sol-6.1 кажутся бесконечными, потому что модель печатает около 20 токенов в секунду. Жалоба не единичная. Пользователь получил 16,7 токена/с в Codex против 95,2 у Opus 5.5 в Claude Code. А в другом тесте по семь запусков одна и та же Sol 6.1 выдавала 22 токена/с по подписке Codex и 73 через API; даже Fast в Codex дошёл только до 46. Причина разрыва между API и подпиской пока не установлена. Sol 6.1 может расходовать меньше токенов и быть выгоднее на задачу, но пользователям от этого не легче, когда агент заметно медленнее отвечает прямо во время работы ❌ Даже Тибо уже впрягся и обещает, что скоро всё заработает как надо (и наши лимиты начнут таять без замедления)🤷‍♂️

Intel выпустила обновление своей бесплатной утилиты для анализа производительности PresentMon 2.6.0. Разработчики пересмотрели логику работы с событиями ETW и фоновыми циклами. По заявлению Intel, под нагрузкой утилита стала потреблять на 78% меньше ресурсов процессора, а в простое её фоновая нагрузка упала практически до нуля. В интерфейсе появился оверлей Game Experience, который отслеживает плавность анимаций и визуальный комфорт в играх. Также утилита научилась выводить телеметрию сразу с нескольких видеокарт и фиксировать задержки при компиляции шейдеров в DirectX 12. Программа остается полностью бесплатной, имеет открытый исходный код и работает с видеокартами Intel, AMD и NVIDIA.

В 2003-ем, кажется, году я купил последний компьютер, чьи гигабайты и гигагерцы меня интересовали. Думал о них, что-то выбирал, переплачивал за цифирки. Дальше 20 лет важны были только "чтобы Windows", вес, зарядка и экран. Ладно, признаюсь, ещё зачем-то SSD диск. В серьезные игры я не играю, компилятор не запускаю. Все мои нужды — браузер да Excel, точно хватит чего угодно. И до сих пор принцип меня ни разу не подводил. Кто бы мог подумать, что AI и это изменит. Две-три сессии Claude запускают параллельно всякие скрипты-аналитику-рендер, ноутбуку прямо плохо становится. И всё полезно, ничего не выключить. Покупайте компьютеры помощнее, пришло время вспоминать этот навык.

Это график точности и стоимости выполнения задач из тестов TypeSafe. Чем точка выше и левее, тем лучше: больше правильных решений за меньшие деньги. Вертикальная ось показывает точность. У Jev около 68%. Горизонтальная ось показывает стоимость одного задания в долларах. Шкала логарифмическая: каждый следующий крупный шаг вправо означает увеличение цены в 10 раз. Ромбы обозначают задачи, разбитые программой на отдельные проверки. Кружки означают, что всю задачу описали модели одним промптом. Цвет обозначает поставщика модели. Розовая точка слева это Jev. Jev здесь самая дешёвая, но не самая точная. У Sol около 74%, у Opus 5 около 73%. Самое показательное сравнение с Sonnet 5: одинаковые 67,8% точности, при этом Jev примерно в 294 раза дешевле и в 195 раз быстрее. С Terra точность тоже практически совпадает, выигрыш составляет примерно 76 раз по стоимости и 25 раз по скорости. Ещё раз: Jev не предназначена для написания текстов или кода, как ChatGPT. Она анализирует информацию и выдаёт оценки: есть ли ошибка, насколько срочный запрос, какое действие выбрать. Поэтому график сравнивает модели именно в таких задачах, а не по качеству текстов или программирования.