H100 стоит $30 000 и потребляет 700 Вт. RTX 5090 — $2 000 (де-факто больше) и 575 Вт. Прирост производительности между поколениями сжался с 80% до 15–20%. Разбираемся, почему это структурная проблема и что индустрия делает, чтобы с ней жить.
Некоторое время назад мы столкнулись с типовой проблемой очередей при исполнении пайплайнов. Задачи упирались друг в друга, мешая выполнять операции последовательно.
Особенно остро это ощущалось на пайплайнах для сборки статики. Задачи требовали много ресурсов, выполнялись довольно долго, но основная нагрузка приходилась не столько процессор, сколько на дисковую подсистему (IOPS). В результате у нас возникали постоянные заторы при выполнении нескольких таких задач подряд.
Таким образом, вырисовывалась такая картина маслом: несколько разработчиков одновременно пушат свои сборки — кто-то новую версию плагина, кто-то страницу сайта — и все эти задачи, каждая минут на десять, устремляются в горстку общих runner-ов. Первый в очереди, конечно, чувствует себя прекрасно. Остальные же с тоской смотрят на статус pending ....
Что внутри:
Метапромптинг: как заставить ИИ самому написать промпт для анализа конкурентов
Метод Франкенштейна: прогон через три нейросети (Claude, ChatGPT, Gemini) и синтез лучшего
Финальная сборка: все данные в одном месте → готовая презентация для клиента
Реальный кейс: анализ конкурентов для сайта по аутсорсингу бухгалтерии. С промптами, скриншотами и ссылками на итоговые материалы.
Кто умнее — человек или машина?
На протяжении 30 лет, которые я проработала в сфере искусственного интеллекта, именно этот вопрос был в центре дискуссий.
Нам также внушали следующую историю об ИИ: он будет заниматься утомительной рутинной работой — исследованиями, составлением первых черновиков, обработкой цифр — в то время как мы сосредоточимся на интересных аспектах: творчестве, суждениях, человеческом факторе.
Мои исследования показывают, что мы задавали неверный вопрос и делали неверные выводы.
Несколько месяцев назад я набрала группу взрослых из района залива Сан-Франциско для проведения эксперимента. Я дала каждой группе час на то, чтобы сделать прогнозы о реальных событиях, используя сценарии, взятые с платформы прогнозного рынка Polymarket. Это дало нам строгий, объективный способ проверить результаты на фоне коллективной мудрости тысяч прогнозистов, мотивированных финансовой выгодой. Помимо ИИ, делающего прогнозы самостоятельно, некоторые команды людей работали отдельно, а другие — в гибридном составе «человек + ИИ».
Посмотрел демку, где AI-агент ревьюит PR за 40 секунд — и решил внедрить у себя. LangGraph, GitHub API, неделя на прототип. Прототип заработал красиво. А потом начался продакшен: галлюцинации, 60% мусорных комментариев, разработчики игнорируют бота. Рассказываю, как чинил это три месяца и к каким цифрам пришёл.
Привет! Я Владимир Потехин, разработчик в Т-Банке в ИТ-хабе Нижнего Новгорода. Моя статья — первая в спецпроекте «20 в 20» к 20-летию Т-Банка. Двадцать специалистов из двадцати городов расскажут свои истории в серии статей, чтобы показать, как выглядит наша распределенная ИТ-карта. За эти годы Т-Банк сильно вырос, вместе с ним выросла и инженерная среда: команды работают в разных городах, но остаются частью одного большого процесса.
Я много времени уделяю работе с опенсорсом и искренне за него радею. Люблю опенсорс за ощущение общего дела: когда код не просто пишешь, а вместе с другими улучшаешь, обсуждаешь, докручиваешь и делаешь полезнее.
В крупной компании есть объективное ограничение: не каждый проект можно вынести за периметр. Даже хорошо изолированный от бизнес-логики код часто несет на себе груз внутренней инфраструктуры, договоренностей, данных и открыть его невозможно даже при большом желании.
И вот здесь появляется иннерсорс: подход, который берет лучшее из опенсорса — открытость, совместную работу, общий вклад — и переносит это внутрь компании. В итоге закрытые продукты тоже можно делать быстро, прозрачно и по-хорошему командно.
Карьерный консультант сказал «сфокусируйся».
Я сфокусировался: через 22 методики стратегического анализа, 31 экспертное интервью, финмодель, 64 сценария и год работы в Executive Master in Management ВШЭ.
Получил:
— Прогнозную NPV +8,7 млн ₽ на горизонте 24 месяцев
— Стратегию из трёх измерений (где играем, чем играем, через какой канал)
— Защиту выпускной работы на 10/10
Работы пока нет.
Метод — да. Гарантий — нет. Уверенность — да.
Это статья о том, как корпоративный стратегический инструментарий (PESTEL, Porter, VRIN, финансовое моделирование) работает применительно к карьере. И почему уверенность в методе и неуверенность в результате прекрасно живут вместе.
Внутри: 22 методики, 5 промоделированных сценариев, разбор «проблемы периметра» для интровертов‑управленцев, и одна неудобная мысль про то, что в 2026 году поиск работы перестал быть операционной задачей.
Хотите увидеть, как живое Spring Boot‑приложение проходит путь от репозитория до кластера Kubernetes? В статье пройдем путь от создания простого HealthController до автоматического деплоя через CI/CD. Разберём Dockerfile без магии, манифесты Deployment с пробами, настройку ресурсов и изящный Graceful Shutdown. В финале вы получите живую связку «код — контейнер — кластер», готовую к продакшену.
Если бы у этого дела был спортивный аналог — это титульный бой, выигранный в поздних раундах при отставании по очкам. Соперник: матёрый профи с большим портфелем доменов и опытом в «сотнях разбирательств». Мы: одно небольшое издание. Победили терпением — и тем, что позволили ему нокаутировать самого себя. Вот как это было — и чему нас научило.
HikariCP давно стал де-факто стандартом JDBC connection pooling в JVM-проектах. Но подключить его мало: важно правильно выбрать размер пула, таймауты, maxLifetime, keepaliveTime, leak detection и метрики.
Разбираем, как настроить HikariCP для Java, Kotlin, Scala и Spring Boot, какие ошибки чаще всего встречаются в проде и почему maximumPoolSize нельзя просто копировать из соседнего сервиса.
После статьи про Cursor и сжатие контекста я получил много комментариев. В коментах спорят: виноват компактинг? Или attention dilution? Или модель просто ослушалась? Или проблема вообще не в контексте, а в alignment?
Спор хороший, но он показывает фундаментальную проблему: у инженеров нет общей картины того, как LLM работают с контекстом. Мы видим симптомы (агент удалил базу, модель галлюцинирует, точность падает на длинной сессии), но не понимаем механизмы.
Попробуем собрать эту картинку
Запустил pinock.io — бесплатную ленту AI-генерации животных в стиле советских спичечных коробков. Под капотом FLUX.2-klein + кастомная LoRA + двухпроходный «sandwich»-пайплайн.
Получил детальный технический комментарий на r/StableDiffusion с тремя претензиями. Сел и прогнал ablation: 5 вариантов пайплайна × 5 категорий × 3 сида = 75 картинок.
Нашёл дыры в собственном пайплайне — в том числе кириллицу прямо в выходе LoRA (training-set leakage) и полный коллапс LoRA при scale=2.0. Текущий sandwich оказался патчем поверх плохо обученной LoRA, а не правильным решением.
В статье — все картинки, цифры, и почему оба «правильных» совета критика на текущей модели не сработали. Плюс план переобучения на 1500-датасете.
Вы наверняка видели такой код - for (String s : data) { result += s; } сотни раз.
Что с ним не так?
Ведь он выглядит безобидно, почти идиоматично. Но в продакшене под нагрузкой этот цикл способен генерировать сотни мегабайт мусора в секунду - даже если сам результат никому не нужен.
И казалось бы, проблема конкатенации строк в Java давно решена. Джунам говорят: используй StringBuilder и будет тебе щастье. А статьи десятилетней давности сравнивают + и append() в бенчмарках и ставят точку.
В сегодняшней статье я копнул немного глубже и оказалось, что реальность сложнее.
Вред не исчез - он принял новые, менее очевидные формы.
Сегодня мы расскажем об игре на основе AI‑модели, которая наделала много шуму в 90-х и начале нулевых. А все потому что ее персонажи были пугающе умными.
Иногда перед разработчиком встает задача воссоздания некоторого окружения локально. В него часто входят различные компоненты инфраструктуры, такие как:
– PostgreSQL
– Kafka
– RabbitMQ
– Redis
И так далее. Менеджить целый зоопарк таких сервисов локально бывает не очень удобно. К счастью, у команды Spring Boot для вас есть небольшой помошник - Spring Boot Docker Compose.
Комментарий от Михаила Поливахи:
Друзья, хоть на дворе уже Spring Boot 4, мы знаем, что большинство из вас сидит на Spring Boot 3. И мы посчитали очень нужным рассказать о таком Spring Boot инструменте, который, на наш взгляд, делает локальную разработку со Spring Boot намного более приятной.
У дисковой подсистемы слишком хорошая репутация в тарифных таблицах и не самая однозначная в инженерных обсуждениях. В первом случае нам продают гигабайты в секунду, во втором часто говорят, что для веба диск почти не важен.
Я работаю контент-маркетологом в Scalehost и по работе регулярно разбираю темы, связанные с производительностью веб-проектов. Вопрос “нужен ли сайту NVMe или это просто маркетинговая галочка” возникает так часто, что мне захотелось собрать его в один технически внятный разбор.
1. Введение. Trino: ключевые задачи и главные преимущества
В современной архитектуре управления данными ETL‑процессы рассматриваются не как вспомогательный инструмент, а как базовый механизм интеграции, трансформации и подготовки данных, поступающих из множества гетерогенных источников. Ключевая цель этих процессов — избавиться от хаоса и разрозненности данных, которые почти всегда появляются в больших распределенных компаниях [1].
В рамках ETL‑конвейера выполняется автоматизированное извлечение данных из различных источников, их очистка, нормализация и приведение к единой модели, после чего подготовленные данные загружаются в централизованное аналитическое хранилище. Это даёт три главных преимущества: обеспечивает высокое качество и согласованность данных, структурирует информацию под нужды бизнес‑отчетности, а также отделяет аналитическую нагрузку от операционных систем, повышая таким образом производительность системы в целом.
ETL возник как вынужденная мера, так как во время его появления (1970–1990-е) не было ни высокоскоростных сетей, ни мощных распределенных движков аналитики, ни концепции Data Lake. Единственным надёжным способом построить аналитическую отчетность было физически извлекать данные из операционных систем и копировать их в отдельную специализированную базу. Именно поэтому ETL закрепился как основной архитектурный паттерн аналитических систем на долгие десятилетия.
Увы, такой подход породил и массу проблем: это дублирование данных, долгие пайплайны, сложные зависимости, задержки обновления и огромные затраты на поддержку. Традиционным ETL‑процессам становится всё труднее справляться с постоянно растущим объемом поступающих данных. Более того, большие сложности возникают при работе с уже накопленной информацией, ведь её требуется хранить на протяжении многих лет, а значит — сохранять возможность глубокого анализа по всей доступной истории.
Ryzen AI 9 HX 370 - это чип с NPU на 50 TOPS и Ollama его не видит - из-за своей архитектуры. Собственно, сама Ollama работает поверх llama.cpp, llama.cpp поддерживает GPU через CUDA, Metal, Vulkan и ROCm. А вот AMD GPU Ollama запускает - через ROCm и Vulkan. Но AMD NPU на базе архитектуры XDNA туда, к сожалению, не входит. Ryzen AI 300, Ryzen 8040, Ryzen 7040 - у всех этих чипов есть нейронный процессор, который при запуске Ollama простаивает.
И вот Lemonade Server появился именно для этого сегмента.
Всем привет!
Мы команда интеграции в Московской Бирже (MOEX).
В наши задачи входит развитие интеграционной шины (ESB).
Без надёжной интеграционной шины невозможно представить ни один межсистемный процесс.
В этом году мы реализовали проект по модернизации существующего решения ESB.
В результате улучшили процессы управления интеграциями и сократили время на создание типовых интеграций в несколько раз.
О том, какую ценность это несет и как это работает, данная статья.
Иллюзия участия в AI-инструментах: как мы теряем пользователя внутри собственного продукта
Мы в Кэмпе уже более 6 лет работаем над AI-инструментами для образования и фиксируем устойчивый эффект: пользователь воспринимает результат генерации как «свой», даже если его реальное участие в процессе было минимальным.
При этом проблема не в том, что AI делает слишком много, а в том, что пользователь перестает понимать, что именно он сделал внутри процесса генерации самостоятельно. Это не поведенческая особенность аудитории, а продуктовая проблема, которая напрямую влияет на то, чему пользователь реально учится и как он закрепляет знания.
В этой статье мы разберем этот эффект как продуктовую проблему: откуда берется ощущение «я сделал сам», как оно связано с архитектурой AI-интерфейсов и как вернуть пользователя в процесс, а не просто ускорять результат.