Для одной научно-исследовательской задачи мне понадобился массив на 160 ГиБ в Go с максимально быстрым случайным доступом на чтение, а также с быстрым захватом и освобождением памяти при создании/уничтожении массива.
Стандартные методы работы из Go не выжимают максимума, поэтому выходом стал выделенный сервер и Huge Pages размером 1 ГиБ. Тесты по сравнению со стандартным подходом Go и любопытные детали — в статье.
Сайзинг RAM и vCPU для локальной языковой модели начинается с конкретных весов и профиля запросов. Исходные требования self-hosted LLM включают длину входа и ответа, конкурентность, рантайм и схему offload. Расчёт по размеру весов и формуле KV-кэша даёт стартовую конфигурацию, а прогретый тест показывает реальное потребление памяти и точку, где CPU перестаёт помогать.
«Просто арендую сервер помощнее». Так я думал, когда пет-проект внезапно оброс людьми.
Мой проект начинался с одной виртуальной машины. Пока пользователей было мало, всё работало. С ростом нагрузки обычные запросы начали ждать завершения тяжёлых вычислений. В логах появились тайм-ауты, очередь росла, а покупка сервера помощнее давала только временный эффект.
Я изучил, как похожие проблемы решают крупные компании, и применил эти принципы на практике.
В статье покажу, какие архитектурные решения я подсмотрел у больших сервисов и как адаптировал их для небольшого проекта. Разберём, почему мощного сервера недостаточно, как разделять короткие запросы и длительные вычисления, и зачем балансировать не абстрактные запросы, а конкретный ресурс, который становится узким местом.
Недавно я обновил свою видеокарту до RTX-5060-TI 16GB. Получив новую карту я решил исследовать, что можно на ней запустить из нейросетей. Традиционно пишут, что нормальные ИИ модели начинаются с rtx3090 и выше, что ниже 24GB VRAM жизни нет. В этой статье я постараюсь развеять этот миф.
Qwen3.8-27B в Q4TP занимает около 14,3 GB весов, но при длинном контексте упирается ещё и в KV-кэш. Для 16 full-attention слоёв этой гибридной модели FP16 KV-state растёт на 65 536 байт с каждым токеном: на 64K это около 4 ГиБ только для K/V.
В экспериментальном режиме O(1) рантайм CMF заменяет растущий KV-кэш этих 16 слоёв фиксированным состоянием: четыре sink-токена, точное окно последних 128 токенов и 32 опорных представлений для дальней части. В использованном профиле GPU-state attention составляет 44,1 МиБ, и не увеличивается с длиной контекста.
Типовую задачу проксирования трафика на базе заголовков и тела HTTP-запроса теперь можно решать напрямую с помощью предикатных локейшенов в NGINX.
До версии 1.31.5 для этого применяли тяжелые скрипты (медленно) и лабиринты из редиректов (неудобно). Теперь можно создать блоки location на базе любой переменной. В этом блоге разбираем методики чтения запроса и показываем примеры паттернов конфигурирования NGINX, которые вы можете применять для любого API или AI-трафика.
Всем привет, меня зовут Миша, и я бэкенд‑разработчик в платформе Яндекс Еды. Я уже рассказывал, как мы анализировали наш PHP‑монолит и вынесли из него процессинг заказов, и с тех пор роль этого легаси заметно уменьшилась. Заодно туда стали писать гораздо меньше нового кода, релизы стали реже, и он спокойненько себе работал, не привлекая лишнего внимания.
Так оно бы и продолжалось, но тут случилась повышенная нагрузка и необходимость зарезервировать побольше мощностей для беспроблемной обработки повышенного спроса. Монолит справился на отлично, но самое интересное случилось потом: возвращая выделение ресурсов к прежним значениям, я случайно обратил внимание, что RPS в пиковые вечерние часы как‑то подозрительно совпадает с количеством ядер CPU, выделенных на весь монолит.
Количество выделенных ядер, конечно, ещё ничего не означает, поэтому я полез смотреть реальное потребление процессорного времени, сложив CPU usage по всем подам. С помощью нехитрой арифметики я обнаружил, что 100% загрузки одного ядра приходятся на 2,5 RPS. Какое‑то время я находился в состоянии глубокого изумления, после чего решил, что это никуда не годится, и отправился в увлекательное приключение на 20 минут.
Немного спойлеров: дело оказалось далеко не только в PHP.
«👋».length === 2 — это знают все. Дальше все пишут честную функцию, которая ходит по строке по символам, а не по кодовым единицам UTF-16. И почти всегда она получается квадратичной: и длина, и обращение по индексу проходят строку с начала, поэтому обычный цикл по ним — это n²/2 шагов без единого вложенного цикла в коде.
В тестах это невидимо. Десять тысяч символов обходятся за 70 миллисекунд, а строки в тестах короткие, потому что их пишут руками. Дефект жил у меня полгода под зелёными тестами и вылез, когда программа впервые прочитала настоящий файл в 300 килобайт: вместо секунды — минуты.
Внутри: замеры роста, починка через один вопрос «есть ли в строке суррогатная пара», и почему тест на время здесь бесполезен, а тест на показатель роста — нет.
Разворачивать новый кластер базы данных каждую неделю — так себе удовольствие, особенно когда обслуживание десятков кластеров съедает время дежурных. Когда кластеров стало много, локальные аномалии стало сложнее замечать на общих дашбордах.
С этой проблемой мы столкнулись в Яндекс Трекере: за год количество активных организаций и кластеров выросло вдвое, а нагрузка на сервис поднялась всего на 13%. Получилось парадоксально: потребление ресурсов и сложность эксплуатации росли вместе с числом организаций, хотя реальная нагрузка увеличивалась значительно медленнее.
Я строю мультитенантную платформу мониторинга на стеке VictoriaMetrics + Grafana + vmalert: у каждого клиента — изолированный tenant в хранилище и собственный набор правил алертинга, которые он редактирует через личный кабинет. Расскажу про два сцепленных инцидента, которые изменили моё понимание изоляции тенантов, — с конкретными числами, конфигами и кодом фиксов. Спойлер: изолировать данные — этого мало.
У меня два физических сервера на списанном железе — Xeon E5 и старый IBM, суммарно 112 потоков и 754 гигабайта памяти. На них 55 виртуальных машин, и на этом живёт онлайн-школа, платформа с курсами, мессенджер, игровой движок и майнкрафт-серверы для учеников. При этом я не девопс и не системный администратор. Разбираю технически: как поделены машины, как устроена репликация баз между площадками, что происходит при падении основной и какие вещи я сделал неправильно.
GitHub прогоняет регистровую свёртку по каждому байту кода, который попадает в индекс Blackbird, поэтому даже базовая текстовая операция быстро превращается в вопрос производительности. Инженеры обнаружили, что ранний выход из цикла мешает LLVM векторизовать обработку: после удаления break скорость на ASCII выросла до 45+ ГиБ/с на одном ядре. Дальше они пошли ещё глубже и научились сворачивать Unicode прямо в байтовом представлении UTF-8, обходясь без полноценного декодирования символов.
Про ИИ-ботов пишут в основном пересказами документации вендоров: этот собирает данные для обучения, тот ходит за содержанием по запросу пользователя. Я решил посмотреть, что происходит на самом деле — прежде всего по журналам доступа сервера. Ниже представляю вам разбор: кого видно в логах, что они запрашивают, чем отличаются два типа ботов у одного вендора и почему файл llms.txt в этой картине почти не встречается.
Полный self-hosted стек observability (Go-приложение + PostgreSQL + ClickHouse) живёт на VPS с 2 ядрами и 2 ГБ RAM. Но сначала стоковый ClickHouse занял 12 ГБ диска при 543 КБ полезных данных, держал 900 МБ памяти и мержил 11 миллионов строк каждые 30 секунд. Разбор с реальными замерами: куда всё ушло, какая гипотеза не подтвердилась, какая ошибка уронила прод и какие настройки в итоге вернули две трети памяти.
В отчете The State of AI 2025 агентство McKinsey заявляет, что 88% компаний уже используют ИИ хотя бы в одном бизнес-процессе. Grand View Research отмечает, что по их прогнозам глобальный рынок вырастет до 3,5 триллионов долларов к 2033. Уже сейчас мы можем отследить эту динамику.
Однако AI-сервисы не бесплатны. Компании, которые начали с токенизированных API, часто обнаруживают, что при реальной нагрузке их счета растут быстрее, чем польза от ИИ. Поэтому возникает вопрос: как развернуть искусственный интеллект на собственной инфраструктуре и не переплатить.
Привет! Привет! Меня зовут Сергей Ковалёв, я менеджер продукта в Selectel. В статье отвечу на этот вопрос, сравню токенизированные API с on-premise и разберу, когда собственное железо будет выгоднее арендованного. Подскажу, как выбрать модель в зависимости от задачи и GPU под разные сценарии: от простого чат-бота на L4 до многоагентных систем на HGX B300. А в конце дам пошаговый план, как перейти с токенов на собственную инфраструктуру и посчитать реальную стоимость запроса.
Повторяющиеся операции в облачной инфраструктуре — по отдельности совсем не сложные. Проверить доступные мощности, сверить параметры нового объекта, собрать данные об инциденте или рассчитать лимит IOPS — все это можно сделать вручную. Но когда количество кластеров, площадок, клиентов и запросов растет, а количество рук — не увеличивается, это становится проблемой.
Меня зовут Дмитрий, я руководитель службы поддержки виртуальной инфраструктуры в OXYGEN. В этой статье я рассказываю про личный опыт автоматизации мониторинга облака. Под катом разберу четыре задачи, которые мы последовательно автоматизировали — заглядывайте, если интересно.
Выкатили мы первый релиз в прод (100 камер), обрадовали клиентов, начали работать. Прошел где-то час, полетели алерты. Залезаю на сервак, смотрю htop – а там свободно 100 метров ОЗУ. Пу-пу-пу-пу. Нужно внести уточнение что боевой сервер имел 32 гига озу. Ожидаемое поведение было то что процессор отдыхает, сетевуха переваривает трафик, озу 250-300 МБ, диски нагружены не сильно. Так что, когда видишь такие цифры в htop, начинаешь винить себя и свои кривые руки, написавшие это "Г". Но все же решили пойти в Гугл, чатгпт и тому подобное. Благо, ответ нашелся быстро, и посыпать голову пеплом перестали.
Код оказался не вообще не причем, память сожрал сам Линукс. Если когда-нибудь вы писали тонны данных на диск, я думаю вы уже поняли в чем дело. Есть такой «невидимый враг» как страничный кэш (Page Cache). Вот именно он и был корнем этой проблемы.
Как работает страничный кеш и что с ним делать?
Когда ваша функция, которая должна писать данные на диск пишет данные, на самом деле она не пишет их на диск. Она пишет их в ОЗУ. Логика ядра Линукса проста и банальна, и она направленна на ускорение «отзывчивости» системы, всю суть можно объяснить так: «О, только что записали сотню гигабайт данных, наверное, скоро понадобится эти данные прочитать. Оставлю-ка я их в кеше, пользователь будет рад что так быстро смог их прочитать.» И так гигабайт за гигабайтом, пока в сервере не кончится физическая память.
Типичное решение проблемы – пишем скрипт, который раз в час делает echo 3 > /proc/sys/vm/drop_caches. Ну а кто-то просто забивает и позволяет системе убивать случайные процессы через OOM Killer. Но мы же пишем отказоустойчивую штуку. Нам такое не подходит. Задача объяснить ядру ОС, что наши fMP4 сегменты видеоархива — это write-only мусор на небольшое количество времени (т.к если клиент не хочет долго хранить записи, то архив чистится, а если хочет – мы отправляем архив после N времени хранения в S3, а локальную копию тоже чистим). Так что все должно работать по принципу – записал и забыл.
Мы знаем, что сегодняшние большие языковые модели основаны на архитектуре transformer, а самое важное понятие в трансформере это механизм attention.
Вычисление attention происходит путем многократного произведения матриц. Но как модели с миллиардами параметров вычисляют эти матрицы? Почему генерация происходит так быстро? Как можно вычислить следующий токен, без многомиллионного перемножения?
Сегодня вы узнаете об одном из самых важных понятий в современном ИИ — о KV cache.
Предисловие
Есть небольшой побочный профиль, которым я занимаюсь – ретрансляция сырых потоков RTSP, в HLS. По сути задача простая, чтобы любой простой юзер мог увидеть картинку со своих камер, не пользуясь проприетарным облачным ПО от производителя камер. Во-первых, это много денег, т.к многие клиенты хотят хранить достаточно долго записи с камер. Во-вторых, почти у всех производителей камер разное ПО, и это тупо не удобно иметь 10 разных приложений и/или порталов, где это все можно посмотреть. Ну и в-третьих мало где есть интеграции с ИИ (что для моих клиентов, критически важно). Даже если эта интеграция есть, она либо узкоспециализирована, либо опять-таки проприетарна, либо стоит много денег, а иногда и все это вместе. Решение - использование сырых RTSP потоков, их поддерживают и отдают 90% всех камер на рынке.
Так вот, схема была достаточно проста: несколько камер, простой бэк, выдаем на едином ресурсе для клиентов картинку по HLS, используя плеер hls.js. Всех все устраивало, всем все нравилось. Быстро, просто, удобно и не дорого. Тесты работали идеально, клиенты довольны. С каждым был чат, куда выдавали ссылку на просмотр, а также был общий чат со всеми клиентами – где обсуждались вопросы подключения, финансовые ну и прочее. И вот настает момент Х, кто-то по ошибке скидывает в общий чат ссылку…и конец. По ссылке кликнул видимо весь чат, 3 минуты, полетели алерты в боте, алярм, ахтунг, тревога. Смотрим железо, сервер в ауте, ООМ, все потоки отвалились. Через 20 минут чат разрывался от гневных сообщений, о неработоспособности у всех. Занавес.
Если вы эксплуатируете VictoriaLogs, повседневная работа сводится к трём вещам: отправке логов, выполнению запросов и настройке срока хранения, чтобы не переполнить диск. Всё остальное незаметно происходит на диске.
В этой статье мы проследим путь одной записи лога — от поступления в VictoriaLogs до окончательного размещения на диске. Это поможет представить, что происходит внутри системы, и понять наблюдаемое поведение: почему запросы выполняются быстро, почему на диске иногда появляется множество файлов и какие флаги и метрики важны при поиске неполадок. Статья рассчитана на широкую аудиторию: не требуется ни опыт программирования, ни знание Go. Тем, кто захочет разобраться глубже, первоисточником послужит исходный код VictoriaLogs.
