Акции Nvidia просели в цене, а регуляторы ограничивают её продажи чипов, но американский гигант ИИ смотрит в будущее и ведёт долгую игру в Китае. Авторы издания The Wall Street Journal объясняют, почему релиз DeepSeek не сможет пошатнуть доминацию Nvidia на рынке чипов для искусственного интеллекта.
Китайская индустрия создания CPU уникальна, причем, не только за счет национального калорита, но огромного многообразия производителей, каждый из которых предлагает уникальные технологические решения. Мы насчитали целых 8 производителей и выделили их уникальные архитектуры, такие как LoongArch LA464 от Loongson, FTC от Feiteng, CN86 от Zhaoxin, а также ряд других других интересных платформ и технологий, о которых вам определенно хотелось бы узнать. В этом путеводителе по китайской полупроводниковой индустрии мы рассказали о всех наиболее интересных и перспективных китайских чипмейкерах, а также об их передовых центральных процессорах.
В условиях ограничения доступа к самым современным технологиям компании всё чаще стремятся переложить заботу о поддержании работоспособности ИТ-инфраструктуры на профессионалов. И вариантов тут два: либо консолидировать вычислительные ресурсы на собственной технологической площадке, развитием которой будут заниматься своя ИТ-служба, либо отдавать вычислительные ресурсы на аутсорсинг, то есть пользоваться услугами облачных провайдеров. Проще, конечно же, доверить управление ИТ-инфраструктурой сторонним профессионалам, однако надежнее и безопаснее развивать собственные компетенции за счет внедрения современных средств автоматизации управления Центрами обработки данных (ЦОД).
В статье разбирается модель claims и её ценность для управления ресурсами в Kubernetes. Узнайте, как она помогает разделять желаемое и наблюдаемое состояния ресурсов.
Моя основная деятельность — конфиденциальная обработка данных. Это такая развивающаяся область науки и техники, в которой часто возникает что-то новое, поэтому терминология ещё не устоялась. То, чем я занимаюсь, по-английски называется Secure Multi-Party Computation, а на русский переводят как совместные или многосторонние вычисления. Однажды я видел перевод: «многопартийные вычисления», – но, надеюсь, это единичный случай. Лично мне нравится вариант: «конфиденциальные вычисления», который использует википедия. Его буду использовать и я.
Представьте, вы собрали какие-то ценные данные, зашифровали их и сохранили на диске. Таким образом, вы защищаете данные во время хранения (data-at-rest). Далее, предположим, вам нужно передать данные по сети с одного сервера на другой. Серверы устанавливают защищённое соединение и обмениваются данными – снова зашифрованными. Так серверы защищают данные во время передачи (data-in-transit). Пока всё знакомо и понятно. Далее вы собираетесь делать то, ради чего вы эти данные собирали, хранили и передавали: использовать их. Что-нибудь посчитать, агрегат какой-нибудь, статистику или даже модельку обучить. Анализировать зашифрованные данные —, затруднительно, поэтому вы их расшифровываете и… делате беззащитными.
Во-первых, это странно: вы старательно защищали данные, когда хранили и передавали, и вдруг почему-то перестали. Во-вторых, это опасно: атаки, утечки, несанкционированный доступ, всё, что угодно может случиться, когда данные уязвимы. Ну, и в-третьих, расшифровывать не обязательно: существуют методы, защищающие данные, когда они используются (data-in-use). Совместные конфиденциальные вычисления – один из них.
Привет, Хабр!
Зима пришла стремительно, и принесла с собой много новых идей, ключевых решений, а самое главное, пересмотр уже устоявшихся концепций и парадигм. Одной из таких идей на первый план вышла FinOps (Financial Operations), практика по управлению расходами, применительно к облачным технологиям. Этот подход ставит целью проведение глубокого анализа облачных расходов и работу с реализацией продуктовых задач компаний. Он помогает видеть комплексно процессы компании и объединять усилия команд, для оптимизации операционных процессов. Зачем это нужно? Цифры подскажут:
Привет! Меня зовут Михаил Шпак, я занимаюсь комплексной архитектурой технологических решений в сетевой части ИТ-холдинга Fplus, который выпускает широкий спектр высокотехнологичных электронных устройств. В данной статье я хочу показать, как за последние 5 лет требования современного бизнеса и развитие ресурсоемких приложений (искусственного интеллекта, поисковых систем, мобильной связи стандарта 5G и т.д.) изменили требования к архитектуре, скорости и отзывчивости сетей, используемых в центрах обработки данных. Давайте разберемся, какие комплексные технологические решения заставляют нас ускоряться, а где можно использовать старые наработки и отточенные десятилетиями практики.
Всем привет. Данная статья не более чем эксперимент. Тем более, что сейчас есть тренд на запуск баз данных в контейнерах т.к. это действительно производительнее и нет лишнего оверхеда в сравнении использования технологий, которые используют виртуализацию. Во многих статьях есть поле манипуляций — это выводы на основе одного бенчмарка или когда надо доказать и обосновать, что принятое решение самое лучшее. В рамках статьи будет проверка работы clickhouse запускаемый в qemu‑kvm, firecracker, containerd.
Привет, Хабр! В этой статье расскажем о гиперконвергенции и как ее можно реализовать разными путями в облаке. А также просто разберемся, чем она отличается от виртуализации с контейнерами. Для начала дадим определение гиперконвергенции, далее поговорим про OpenStack и VMware и затем перейдем к деталям реализации.
Привет, Хабр! Меня зовут Данила Дюгуров, я CTO MWS. Сегодня расскажу, как наша команда создаёт облако MWS, и на его примере разберу ключевые концепции, которые лежат в основе построения облаков в целом: от аппаратного обеспечения и выбора сетевой архитектуры до организации работы в инфраструктурной команде. А ещё порассуждаю о том, что лучше для облачного провайдера — вендорский софт или OpenStack — и что в итоге выбрали мы. Спойлер: ни то ни другое.
Раньше я считал, что публичные облака дорогие, и как я заблуждался! Да что говорить, многие мои знакомые так и считают. Но я попробую объяснить, почему это совсем не так, и я изменил свое мнение!
Serverless функции - отличная возможность не думать о масштабировании, легко деплоить, а также использовать free tier для своих телеграм-ботов. В своей практике я часто использую этот подход и хочу поделиться опытом, когда это действительно удобно, а когда лучше посмотреть в сторону других решений.
Если у нас простая задача, например отправлять уведомления по вызову и событиям, то в целом проблем нет (только нюансы реализации). Но если мы хотим один или несколько микросервисов, или целое приложение разделить на serverless функции - тут начинаются интересные вещи. Нужно так спланировать свое приложение, чтобы оно было разделено по функциям, при этом его легко можно было масштабировать и расширять.
В этой статье хочу разобрать, каким образом проектировать и делить приложение, когда этот подход имеет смысл, а когда нет. За последние годы я реализовал несколько проектов на serverless архитектуре, и постараюсь поделиться основными принципами и подводными камнями, с которыми столкнулся.
Каждый, кто имеет дело с более-менее крупной IT-инфраструктурой, знает, что в мире сетей есть две прямо противоположных реальности. В одной — виртуализация с эффективным дроблением ресурсов, но потерей скоростей, в другой — Bare Metal с высокой скоростью и мощностью, но слабой гибкостью в вопросах выделения ресурсов. И если вы уже задались вопросом: «А можно без крайностей?», я инженер R&D-команды Cloud.ru Вадим Михеев, расскажу, как нам удалось достичь скоростей передачи пакетов в SDN на уровне Bare Metal на примере облака OpenStack. А еще посмотрим, какой прирост к скорости передачи пакетов дает технология ASAP².
Статья будет полезна всем обладателям железок NVIDIA Mellanox ConnectX-5/6/7, использующим виртуализацию, ну а остальные смогут посмотреть, какие способы ускорить сеть для своих клиентов мы тестируем и, возможно, вдохновиться.
В последние годы наблюдается тренд на использование облачных вычислений, все чаще компании отдают предпочтение именно им при развитии своей информационной инфраструктуры.
Стремительное увеличение сферы облачных услуг приводит и к росту числа атак на облачные ресурсы. По данным из открытых источников прогнозируется рост числа кибератак на облачные ресурсы до конца 2024 года на 30% относительно 2023 года. В связи с этим, вопросы информационной безопасности облачных вычислений остаются одними из самых острых при принятии бизнесом решений о переносе части инфраструктуры или хранении данных в облаках.
Привет! Мы планируем закупить партию новых RTX 4090 48 ГБ, чтобы предлагать их для ML-задач вместо доступных сейчас GPU карт. Поэтому хотим спросить: была бы вам интересна услуга аренды облачных серверов с этой GPU?
Что это за видеокарта и чем она хороша — рассказали далее.
Привет, Хабр! Я Алексей Колосков, DevOps‑инженер Hilbert Team. Сегодня я расскажу вам историю о компании, которая из маленькой облачной инфраструктуры выросла до сложного решения с использованием Infrastructure as Code (IaC) и Terraform. И, как это часто бывает, в процессе роста учли не всё. Все персонажи вымышлены и любые совпадения случайны (ну, почти).
В этой статье покажу грабли, на которые можно наступить при росте облачной инфраструктуры, и расскажу, как их обойти.
В статье на примере приложения Podinfo показывается, как Kubernetes с помощью iptables управляет трафиком, предназначенным для этого приложения. Вместе с автором вы развернёте Podinfo, включите трейсинг iptables и проанализируете его вывод. Это поможет разобраться в сетевой инфраструктуре кластера и понять, как работают Kubernetes Services.
Привет! Сегодня рассмотрим управление IT-инфраструктурой с точки зрения руководителя IT-отдела, для которого бюджетирование и расчёт времени простоя — неотъемлемая часть работы.
Говорить будем о том, как выстраивать отказоустойчивую и катастрофоустойчивую IT-систему, чтобы избежать убытков при сбоях. Сразу заметим, что эти изыскания актуальны на определённом уровне развития компании. То есть ларьку с шаурмой они явно не нужны, а вот для сети шаурмичных из 200 объектов уже актуальны.
По работе я привык, что если какая-то нейронка не влезает на GPU-сервер, то первое моё действие — проверить, нет ли модели с квантизацией побольше, либо запросить ещё больше VRAM. Однако не все работают на облачных провайдерах, кто-то у нас ещё и заказывает услуги. А тарифы на GPU-серверы порой заставляют серьёзно задуматься о том, так ли они нужны, особенно когда нет потребности в нейронках на сотни миллиардов параметров. Что, если попробовать делать всё на обычном VPS-тарифе с бюджетом в 5000 рублей в месяц? Да и зачем ограничиваться одними лишь нейронками?
