Провести честный тест на 30 000 ВРМ, сжечь 400 тысяч процессорных ядер-часов и доказать, что отечественная связка из RED OS, 1С и Postgres Pro Enterprise способна стабильно держать промышленную нагрузку в 1 Тб — выполнено. Рассказываем историю одного большого нагрузочного тестирования длиною в три месяца
Это вторая часть цикла про mTLS. В первой разобрали теорию: как работает рукопожатие, от каких атак защищает и где принципиально бессилен. Здесь — практика. Разберём реальный сценарий: homelab на одном сервере с Traefik и Dokploy. Пройдём путь от модели угроз до конкретных попыток атаковать собственный сервер — с командами и объяснениями, что происходит.
Если первую часть не читали — не страшно. Ниже есть краткий раздел с основными понятиями, достаточный, чтобы двигаться дальше.
На майском HPC User Forum в Остине AMD рассказали о MI430X — ускорителе серии MI400, который позиционируется как инструмент для научных вычислений. Пока индустрия увлечена инференсом и считает токены в секунду на FP4, AMD напомнила, что CFD-код (Computational Fluid Dynamics) не интересует, насколько быстро чип умножает восьмибитные числа.
Привет, Хабр! Меня зовут Сергей Ковалёв, я менеджер выделенных серверов в Selectel. В этой статье мы мысленно «разберем» MI430X и обсудим, насколько новинка подходит для «ядерных расчетов» и машинного обучения. Подробности под катом!
Каждый раз, когда пользователь открывает страницу каталога или дашборд со статистикой, база данных заново считает одно и то же. Запрос к 800 тысячам строк ради одного числа — снова и снова. Расширение pgpro_result_cache в Postgres Pro Enterprise решает эту проблему на уровне СУБД: результат тяжёлого запроса сохраняется в разделяемой памяти и при повторном обращении возвращается за миллисекунду — без сканирования, без нагрузки на процессор, прозрачно для приложения. В этой статье разберём, как это работает, когда кэш действительно полезен и на что нужно обратить внимание при настройке.
Этот дайджест получился объемным! В апреле команда Selectel презентовала Foundation Models Catalog, запустила VDS и Enterprise-grade ЦОД. И это лишь малая часть обновлений. Все подробности — ниже.
Случалось мне работать с CV: запускаешь сорокаминутное видео, YOLO честно находит людей, машины, собак. На двадцатой минуте падает сеть или, что хуже, камера наблюдения выходит из строя. Перезапускаешь. Модель снова смотрит те же кадры, снова инференс, трекинг ID, пошла пахота GPU…
Так продолжаться не может — подключаю кеширование.
Сегодня разбираемся, как совместить YOLO и кэширование Redis с трекингом объектов так, чтобы каждый кадр считался ровно один раз и чтобы информация не терялась. В конце будут готовые сниппеты, которые можно сразу скопировать и запустить.
Актуальное на сегодняшний день поколение серверных ускорителей AMD — это MI350X и MI355X на архитектуре CDNA 4. Это уже серьезные машины для обучения и инференса больших моделей — с соответствующей ценой и требованиями к электроснабжению и охлаждению.
Несколько дней назад AMD анонсировали GPU Instinct MI350P — первую с 2022 года PCIe-карту серии Instinct, которая устанавливается в любой сервер с поддержкой двухслотовых GPU с воздушным охлаждением. Удобно и универсально, новинку точно стоит рассмотреть подробнее.
У дисковой подсистемы слишком хорошая репутация в тарифных таблицах и не самая однозначная в инженерных обсуждениях. В первом случае нам продают гигабайты в секунду, во втором часто говорят, что для веба диск почти не важен.
Я работаю контент-маркетологом в Scalehost и по работе регулярно разбираю темы, связанные с производительностью веб-проектов. Вопрос “нужен ли сайту NVMe или это просто маркетинговая галочка” возникает так часто, что мне захотелось собрать его в один технически внятный разбор.
Я много думал о том, как проектируются промежуточные представления (IR) для компилятора. В этом посте я поделюсь с вами некоторыми идеями, к которым я пришёл, и поясню, почему считаю их важными.
Главенствующая идея заключается в способности принимать решения, располагая лишь локальной информацией.
Она существует примерно в паре трактовок. Исходим из того, что в каждый момент времени компилируем один какой-то метод, а не занимаемся чем-то сближающимся с трассировкой (трассировка, трейслеты, версионирование базовых блоков, т.д.).
Для ясности: я бывший инженер и учёный НАСА с докторской степенью в области космической электроники. Я также проработал в Google 10 лет в различных подразделениях компании, включая YouTube и тот отдел облачных технологий, который отвечал за развёртывание ИИ-ресурсов, поэтому я вполне компетентен высказать своё мнение по этому вопросу.
Краткая версия статьи: это абсолютно ужасная идея, которая действительно не имеет никакого смысла. Для этого есть множество причин, но все они сводятся к тому, что электроника, необходимая для работы центра обработки данных, особенно развёртывающего ИИ-ресурсы на основе графических процессоров (GPU) и тензорных процессоров (TPU), является полной противоположностью тому, что работает в космосе. Если вы раньше не работали конкретно в этой области, я бы предостёрег вас от поспешных выводов, потому что реальность обеспечения функционирования космического оборудования в космосе не всегда интуитивно очевидна.
Привет, Хабр! На связи команда Рег.облака. Мы запустили программу Free Tier полнофункционального облака с бесшовным переходом в основную инфраструктуру. Теперь любой желающий может заказать абсолютно бесплатно облачный сервер с минимальной конфигурацией с одним виртуальным ядром, 1 ГБ оперативной памяти и 10 ГБ пространства на NVMe-накопителе на срок до 6 месяцев и с возможностью ее расширения по запросу.
Но статья не об этом. Один-два гигабайта — ресурс ограниченный. И сегодня мы попытаемся разобраться, что в него помещается, какой стек выбрать, на чем можно сэкономить, а на чем не стоит. Будет полезно всем, кто работает с недорогими VPS или оптимизирует расходы на ИТ-инфраструктуру.
Теги: Инфраструктура, LLM, Python, Прокси-серверы, Оптимизация
Когда GPU-кластер с vLLM задыхается от пиковых нагрузок, классический Rate Limiting и блокировка пользователей — это худший UX из возможных. А что если не отбрасывать запросы, а заставить саму языковую модель «сжать» свои промпты и стать предельно лаконичной, выдавая только самую суть? В этой статье мы разбираем архитектуру LazyGate — open-source шлюза, который в фоновом режиме читает метрики видеокарты и с помощью системных промптов динамически регулирует «болтливость» нейросети, кардинально спасая метрику Time-to-First-Token.
В серверной разработке кэш влияет не только на скорость ответа. От него напрямую зависят стоимость обработки запроса, нагрузка на базу, поведение системы под пиком и предсказуемость масштабирования. Именно поэтому практика кэширования имеет сегодня столько нюансов и разновидностей, если вы хотите реализовать что-то особенное или применить сложную схему кэширования, от ваших специалистов потребуются специальные навыки и умения. Под катом — рассказ о том, как мы ушли от кастомного кода к использованию гибридного кэша из .Net Framework, с какими сложностями столкнулись на этапе масштабирования системы, и как решали вопросы инвалидации кэша в процессе развития нашего проекта API Hub.
Привет, Хабр.
Хотим поделиться с вами новостью о том, что завершаем более чем годичный фундаментальный проект - готовимся к выпуску русского издания знаменитой книги Дениса Бахвалова "Performance Analysis and Tuning on Modern CPUs: Learn to write fast software like a pro". Денис теснейшим образом взаимодействовал с нашими редакторами, мы составили глоссарий к русскому изданию и уверены, что книга на долгие годы станет де-факто главным пособием по оптимизации производительности CPU. Книга выросла из многочисленных практических исследований, которыми Денис занимается в компании "Intel", и в качестве анонса мы хотим предложить вам перевод статьи автора, которая вышла ещё в 2019 году и может считаться рассказом о том, как зародилась идея будущей книги. В тексте под катом содержатся многочисленные ссылки на статьи Дениса из блога https://easyperf.net/notes/, который также рекомендуем пристально изучить. Русскую книгу ждите в мае. Далее - от автора.
Доброго времени суток, уважаемые хаброжители! Сегодня поговорим о данных — о той самой основе, без которой в классическом машинном обучении да и в deeplearning, по большому счёту, не происходит вообще ничего, от слова совсем: ни обучения моделей, ни проверки гипотез, ни сколько-нибудь осмысленных выводов, ни построение пайплайнов. И в квантовом машинном обучении история, в сущности, та же самая. Только вот сами данные здесь устроены несколько иначе — и вот здесь как раз начинается самое интересное ;) Когда впервые слышишь словосочетание квантовые данные, реакция, как правило, одна из двух: либо это звучит как что-то из научной фантастики, где сейчас из-за угла выйдет кот Шрёдингера и испортит вам датасет, либо как "ну хорошо, ещё один датасет, просто теперь с модной квантовой приставкой" и всякими наворотами. Сразу скажу: на практике всё интереснее и более вариативно. Именно, последнее и приобретает особо важную роль в современном мире ИИ.
В этой статье мы разберём следующие важные положения:
Я ставил перед собой задачу собрать домашний сервер еще несколько лет назад, но тогда я это делал скорее из интереса и в учебных целях. Сейчас это мой основной ресурс и инструмент, без которого я не представляю собственную работу.
Я инженер, и у меня есть эдакий фетиш - все, что важно, должно находиться под моим контролем. Локально, в железе, которое можно измерить осциллографом, нагрузить до упора и при необходимости перепаять. Когда ты привык работать со схемами, сигналами и источниками питания, становится странно отдавать вычисления куда-то наружу и надеяться, что там “все нормально работает”.
В этой статье собираем локальный вычислительный кластер для дома, тихий чтобы стоять дома, максимально эффективный по соотношению цена-вычислительная мощность.
С 1947 года, когда появилась первая память с произвольным доступом — трубка Уильямса, — базовый принцип хранения данных в оперативной памяти фундаментально почти не изменился. За это время процессоры стали на порядки быстрее, но по-прежнему значительную часть времени они тратят на ожидание данных. Этот разрыв известен как «стена памяти» (Memory Wall), и именно он всё сильнее влияет на экономику современной инфраструктуры. Достаточно посмотреть, какую долю в стоимости сервера сегодня занимает RAM.
Мы покупаем терабайты памяти, но существенная её часть нередко остаётся «холодной»: ресурсы зарезервированы, потребляют энергию и стоят дорого, но используются далеко не полностью. В эпоху дефицита памяти, in-memory-приложений, искусственного интеллекта и других высоконагруженных систем такая неэффективность обходится слишком дорого.
А что, если эффективный объём доступной памяти можно заметно увеличить за считаные минуты — без замены оборудования?
В этой статье я коротко пройду по истории RAM, объясню, почему проблема Memory Wall стала особенно острой именно сейчас, и покажу, к какой новой вехе может привести подход, который условно можно назвать Software-Defined Memory. Разберем, как технологии MEXT используют AI для оптимизации инфраструктуры под AI- и data-intensive-нагрузки.
Спойлер: иногда, чтобы «увеличить» память, не нужно покупать новую — достаточно радикально лучше использовать ту, что уже установлена.
Асинхронное логирование давно считается “очевидной оптимизацией”: вынесли запись в отдельный поток — и всё стало быстрее.
Но если копнуть глубже, оказывается, что это не совсем так.
В предыдущей статье я разбирал производительность популярных C++ логгеров и показывал реальные цифры:
👉 https://habr.com/ru/articles/1012874/
Там уже было видно, что хорошо оптимизированное синхронное логирование может быть очень быстрым.
В этой статье разберёмся, почему async logging не делает логирование быстрее само по себе, и что на самом деле происходит внутри:
Многие слышали, что разные модели видеокарт имеют разную экономическую эффективность, например, в майнинге, где часто используется понятие «хэш/Ватт». Однако, даже одна и та же видеокарта может работать с сильно разной экономической эффективностью в зависимости от настроек Power Limit и частоты. И это касается любых длительных вычислительных задач.
Давайте же посмотрим, как помощью простой школьной формулы Энергия = Время × Мощность оптимально настроить видеокарту и получить за каждый потраченный киловатт максимум полезной работы.
