Облачные вычисления *

На протяжении более десяти лет графические процессоры Nvidia лежали в основе практически всех значимых прорывов в современной сфере искусственного интеллекта. Но теперь эта позиция впервые оказалась под серьезным давлением.

Передовые модели, такие как Gemini 3 от Google и Claude 4.5 Opus от Anthropic, были обучены не на оборудовании Nvidia, а на новейших Tensor Processing Units компании Google — TPUv7 на базе архитектуры Ironwood. Это показывает: жизнеспособная альтернатива GPU-центричному стеку ИИ уже существует — и она способна заметно изменить экономику и архитектуру обучения моделей предельного масштаба.

Эта статья — для владельцев малого и среднего бизнеса, а также для IT-директоров, которые впервые сталкиваются с задачей переноса инфраструктуры. Мы не будем углубляться в настройки Kubernetes или тонкости сетевой маршрутизации. Наша цель — дать понятную «дорожную карту» переезда с точки зрения бизнеса: зачем это нужно, сколько это стоит и как не остановить работу компании в процессе.

Несмотря на то что в России последние годы идет явный тренд на импортозамещение, многие компании продолжают пользоваться не только отечественными, но и зарубежными облаками. У кого‑то остались подразделения за границей, кто‑то завязан на legacy‑решения, которые дешевле оставить как есть, чем переезжать, а кому‑то просто лень. Причины у всех разные, но объединяет их одно: необходимость свести этот облачный зоопарк в понятную модель затрат, с которой будет удобно работать всем. 

Есть несколько очевидных проблем с LLM: утечка конфиденциальных данных и кода, компрометация токенов, зависимость от внешних провайдеров. О них знают все, но это никого не останавливает. Даже если руководитель решит перестраховаться и не выделит деньги на LLM, сотрудники купят подписку сами и продолжат ими пользоваться, потому что это удобно. Есть и менее очевидные сложности: например, одна команда может потратить все токены, и их придется докупать.

Привет, я Павел Мохляков. Вообще я Data Science-инженер в Cloud.ru, но сегодня решил, почему бы не рассказать как с помощью LLM-шлюза можно использовать несколько LLM через один API и при этом снизить риск утечки данных, контролировать расходы и соблюдать требования №152-ФЗ. Кроме того, покажу пример тестового подключения и объясню, что делать на каждом этапе.

Сразу оговорюсь, что статья будет полезна, скорее всего, инженерам, архитекторам, да и просто человекам-оркестрам из средних и малых компаний, которым нужно относительно быстро и безопасно внедрить у себя LLM. А вот для крупного бизнеса или, например, КИИ явно нужно что-то другое — посерьезнее и понадежнее.

Еще лет 10 назад iPhone в корпоративной среде воспринимали примерно как электрокары Тесла. Да, красиво, да, статусно, но как с этим жить – решительно непонятно. Особенно людям, которые дальше Windows и Outlook вообще никогда не выглядывали. Но мир поменялся, айтишники забыли, как патчить KDE2 под FreeBSD, а iPhone научились нормально работать с MDM. Однако остался вопрос: насколько все это применимо к реальной жизни, особенно в наших широтах, где к эппловским девайсам отношение стало, мягко говоря, настороженным?

Представьте ситуацию: ваше приложение в Kubernetes работает стабильно, но внезапно начинается пиковая нагрузка. Поды пытаются масштабироваться, HPA увеличивает их количество, но... они висят в статусе Pending. Почему? Потому что в кластере недостаточно ресурсов на нодах. Cluster Autoscaler должен добавить новые ноды, но процесс занимает много времени, иногда нода не создается из-за проблем с облаком. За это время пользователи уже получают ошибки 503, а вы теряете деньги. Знакомо?

А теперь обратная ситуация: нагрузка спала, поды удалились, но ноды продолжают работать вхолостую. Вы платите за простаивающие ресурсы, потому что Cluster Autoscaler слишком консервативен в удалении нод или не может оптимально «упаковать» workloads.

Есть ли способ сделать это быстрее, умнее и экономичнее? Меня зовут Даниил Кондрашов, я разработчик Managed Kubernetes в Selectel. В этой статье познакомлю вас с Karpenter — современным решением для автоматического управления нодами в Kubernetes, которое решает эти проблемы принципиально иначе. Подробности под катом!

Осенью 2025-го многие, как и я, открыли любимый магазин железа, чтобы «по-быстрому взять ещё 32–64 ГБ DDR5 под игры, IDE и пару Docker-контейнеров» — и закрыли вкладку с лёгким культурным шоком. Память, которая летом стоила «адекватных» денег, внезапно стала стоить почти как видеокарта среднего уровня.

Если коротко, это не «жадность магазинов», а последствия довольно сложной перестройки всего рынка DRAM под ИИ-серверы и HBM-память. В статье разберёмся, что происходит на фабриках памяти, почему страдают именно ПК-модули, чего ждать в 2026-м и как принимать решения об апгрейде, если вы геймер, разработчик или просто любитель собирать железо.

Привет, Хабр!

Ноябрь — месяц, когда природа засыпала, а наши строительные площадки в Марфино и Мытищах, напротив, демонстрировали активность. Если вы только присоединяетесь к нашей истории, все предыдущие серии ждут вас здесь: раз, два, три, четыре, пять, шесть, семь, восемь, девять.

Привет, Хабр! Меня зовут Иван Дюков. Последние несколько лет я занимался разработкой и оптимизацией сетевых компонентов для облачной инфраструктуры. Среди моих проектов — участие в разработке сетевого процессора для компании Google в составе российского подразделения Intel, а также оптимизация программных сетевых функций для облака Samsung в команде Samsung R&D Institute Russia. В настоящее время работаю над сетевыми сервисами для платформы Cloud.ru Evolution в R&D-команде Cloud.ru.

Основное направление моей работы — это исследования программных сетей, сетевых сервисов и их производительности. В этой статье хочу рассказать, как я искал точку отказа прокси-балансировщика. Расскажу и про метрики, и про инструменты, и как я автоматизировал измерения. Путь оказался весьма извилист, наполнен граблями и шишками, зато результат был познавательными. Статья будет интересна разработчикам сетевых сервисов, DevOps-инженерам и тестировщикам, исследующим проблемы производительности сети и сетевых сервисов.

Мы медленно вступаем в 4-ю промышленную революцию, где интернет-пространство существует не отдельно, а влияет на реальность, и наоборот. Вследствие объединения технологий и принципов телефонной связи и компьютерных систем появился тот интернет, какой мы знаем сейчас.

И наш основной способ взаимодействия с глобальной паутиной — смартфоны. Они пришли взамен обычным кнопочным телефонам, чтобы на экране было проще потреблять медиаконтент. А после и создавать. Именно в таком ключе смартфоны развивались и развиваются сейчас, из последнего нововведения можно назвать тесную интеграцию нейросетей для упрощения генерации контента в соц сети или управления ресурсами устройства. Но принципиально способ взаимодействия не менялся.

Технологии улучшались, адаптировался интернет, развивались облачные сервисы, но сам концепт использования интернета в повседневной жизни посредством смартфона не менялся. Планшеты и ноутбуки стали более портативными и удобными, но всё же это не то. Неужели нам и не нужно замены смартфону? Или всё-таки можно проследить тенденцию и увидеть, куда нас в будущем может привести желание комфорта и большей интеграции в интернет-пространство? Интеграция в 4-ю промышленную революцию?

Я вижу двух кандидатов: очки AR и складные смартфоны. И если о «раскладушках» можно дискутировать и спорить, что это не нечто новое, а улучшение смартфона (но про это мы поговорим в другой раз), то очки — принципиально новое устройство для взаимодействия с интернетом и реальностью.

В этой статье разберём, во сколько обходится LLM-сервис при нагрузке в 100 000 диалогов в день и где проходит граница окупаемости разных вариантов. Посмотрим на стоимость облачных API, аренды GPU и собственного железа, а заодно прикинем, какая инфраструктура нужна, чтобы всё это выдержало боевой трафик.

Казалось бы, облака давно разобрали по косточкам. Уже даже финдирам понятно, что и как там устроено. Но стоит только кому-то запустить новую платформу или свернуть проект, как начинается: а почему не в паблике? А почему не в приватке? А оно нам вообще надо? И пошло-поехало. Хотя на деле-то выбор часто донельзя очевиден, если знать пару нюансов.

Облако  это гибкая и экономичная модель, которая подстраивается под нагрузку и помогает бизнесу расти без лишних затрат. На простом, но реалистичном примере разбираемся, как всё устроено внутри и почему облачные подходы в некоторых случаях  выигрывают у традиционного хостинга.

Еще 3-5 лет назад у многих было полное ощущение, что облака победили. Казалось, что теперь только тарифы, all-in cloud и все такое. Но нет. В какой-то момент некоторые компании вновь начали думать о том, чтобы не выгружать все в облако, а держать у себя под боком и даже возвращать их облака на землю. В результате сложилось два противоположных лагеря, где одни вкладывают миллиарды в строительство ЦОД, а другие продолжают арендовать ресурсы и не парятся. Разница в подходах, понятное дело, не случайна.

Есть три вида писем, которые могут испортить блаженную субботу: уведомление безопасности, предупреждение об отключении электричества и, очевидно, повторное напоминание о том, что вы задолжали облачному провайдеру один цент — да, именно $0,01. Услугами DigitalOcean я пользуюсь с 2013 года, хотя для личных задач я этот сервис использую редко, просто авторизуюсь несколько раз в неделю для обеспечения поддержки моих клиентов на этой платформе.

Привет, Хабр! В статье поговорим о том, почему традиционные методы оценки производительности серверов для 1С не работают в облачной инфраструктуре и как мы нашли решение этой проблемы.

А еще приглашаем вас на бесплатный вебинар 18 ноября в 11:00 мск, где разберем реальные провалы и фатальные ошибки при работе 1С в облаке. Поговорим о том, почему CPU не покажет реальных проблем, расскажем про кейс с дедлоками при нормальных показателях железа и объясним, почему 40% нагрузки должны стать вашим новым максимумом. 

Всем зарегистрировавшимся пришлем чек-лист по критическим настройкам 1С из практики обслуживания 7000 пользователей. 

Регистрация здесь

За последние несколько лет ИИ прошел колоссальный путь. Сначала над ним смеялись. Затем вдруг испугались, решив, что он отнимет у всех работу. А теперь — причем не исключено даже, что все это были одни и те же люди — внедряют его в своих компаниях. Что же поменялось?

Последние две пятницы без какого-либо уведомления в Google Cloud блокировали аккаунт моей компании SSLMate. Впервые подобное произошло в 2024 году, тоже без какого-либо предупреждения. Но сегодня я хочу не столько предупредить вас о рисках использования платформы Google Cloud, сколько поведать о вынужденных компромиссах между снижением безопасности и удобством работы, вызванных своенравной политикой Google.

Привет, Хабр! Меня зовут Саша, я ведущий специалист технической поддержки по услугам информационной безопасности в Selectel. В последние годы многие начинают задумываться о повышении безопасности своих информационных ресурсов. И это неудивительно, ведь кибератаки и связанные с ними риски касаются как крупных компаний, так и небольших проектов, использующих в работе пару серверов.

Конечно, тяжело написать универсальный гайд, который полностью закроет все вопросы по ИБ для каждого случая. Все кейсы — разные и требуют отдельного рассмотрения и анализа, а также регулярного обновления средств защиты и мониторинга для поддержания системы в актуальном состоянии.

В этой статье я буду использовать стенд, на котором можно наглядно смоделировать типовые проблемы при проектировании безопасной системы. Мы ориентировались на базовые потребности, которые могут возникнуть, когда речь заходит об информационной системе для организации. И, надеюсь, наш небольшой разбор познакомит вас с базовыми принципами проектирования безопасной инфраструктуры, а также поможет разобраться в основных услугах. Подробности под катом!

NAS обычно рассматривают как домашнее облако. Им он, в общем, и является. Только лучше: все данные лежат у тебя под боком, скорость выше, да и платить каждый месяц не надо. Купил один раз железо, настроил и пользуешься. Вот только вместе с NAS приходит и ответственность. Сегодня разбираем типичные косяки, которые пользователи допускают при эксплуатации NAS, а лучше бы не.

В основу этой статьи легли комментарии наших читателей к статье “Облако vs. NAS”. Вы накидали столько кейсов, что нам хватило на целый материал, и еще осталось. Спасибо, друзья!