Это не очень очевидно, потому что много маленьких серверов может стоить дешевле, чем 2 больших (как минимум из-за меньшего резерва в %). И вообще все сводится к тому, что надо просто считать, а общие рекомендации остаются прежними - считаем какие нужны ядра -> считаем сколько нужно ядер -> считаем сколько нужно серверов.
В статье имелось ввиду, что лучше не заниматься оверселлингом нагруженных процессов/виртуалок, на нескольких высокочастотных ядрах, а лучше взять много дешёвых низкочастотных ядер.
Я как раз сильно против такого общего утверждения. По многим причинам:
1.) как я писал, переподписка уровня 2-4 к одному - нормальная, стандартная и широко распространённая практика. Особенно если мы говорим про Enterprise, где на это значение можно влиять.
2.) Сама по себе переподписка ни о чем не говорит. Если взять в пример тот же VDI, то там рекомендации СТРОГО обратные - высокочастотные и малоядерные CPU c большой переподпиской. Просто из-за того, что VDI нагрузки имеют малопоточный характер, сильно зависят от частоты одного ядра, но при этом редкие и spike-like, т.е. переподписка не сказывается на работе. Серверных нагрузок со схожим профилем тоже более, чем достаточно.
3.) Дело в том, что добавить ядер можно и потом при необходимости путем добавления сервера, а вот добавить частоту существующим ядрам невозможно.
то вообще не универсальный показатель, он относится только к некоторым гипервизорам.
Да, так и есть. Поэтому на высоконагруженных системах на этот авторазгон можно и не рассчитывать.
Если у вас загружены все ядра, то C-state в них не будет. А значит и толку от отключения C-States нету.
Меня смущает тот факт, что производитель CPU явно пишет, что он настоятельно не рекомендует отключать эту штуку во всех случаях, за исключением latency-sensitive workloads (тут все понятно). Вы же советуете строго обратное без (на мой взгляд) достаточного обоснования этому. Более того, если посмотреть Best Practices производителей серверов (вот, например Lenovo), виртуализации (вот, например VMware), то там тоже рекомендация не отключать C-States по умолчанию.
А если используется практически для любых вычислений, то память будет неизбежно узким местом.
Вы пишите, что это очевидно, но это не очевидно. Давайте я приведу вам аргументы:
1.) Если производительность General Propose (еще раз, да я понимаю, что существуют задачи чувствительные к полосе RAM. Но многим наплевать, и они реагируют на latency обращения к RAM, а не полосе), в ОБЩЕМ случае зависит от полосы пропускания, то должна быть прямая корреляция между полосой RAM на CPU и общей производительностью системы. Теперь мы берем последние несколько поколений CPU и видим - AMD 7001/7002/7003 (8 x DDR4-3200) = 204.8 GB/s, AMD 9005 (12x DDR5 4800) = 460GB/s, Intel Xeon Cascade (6 x DDR4-2933) = 140 GB/s, Intel Xeon Ice Lake (8 x DDR4-3200) = 204 GB/s, Intel Xeon Sapphire (8 x DDR5-4800) = 307 GB/s, Intel Xeon Emerald (8 x DDR5-5600) = 358 GB/s. Таким образом, мы видим, что 9005 больше, чем в два раза быстрее, чем 7003 или Ice Lake. Теперь мы смотрим на известный тест производительности системы виртуализации VMMark как раз с разнообразной, но относительно реалистичной нагрузкой. Находим там две максимально близкие системы, обе на 4 сервера с 1 CPU по 64pCore, etc. Только одна на 7763 (2.45GHz, 16x64GB 3200=205 GB/s), а вторая на 9554P (3.1GHz, 12x 128GB DDR5-4800=460GB/s). Так вот разница между ними порядка 15%, что вполне вписывается исключительно в разницу по IPC и росте базовой частоты. И несмотря на то, что RAM быстрее в x2.25 раза, такого же роста производительности не видно даже близко. Более того, в реальной жизни так же не наблюдал какого-то кардинального роста производительности при смене поколения (которое увеличивает полосу RAM) при том же числе ядер на той же частоте.
2.) Полоса на CPU обычно одинаковая в рамках одного семейства. Но в одном семействе очень разное число ядер. Нас, очевидно, волнует полоса per Core. Тогда если все определяется полосой RAM, то нам нужно брать максимально мало ядерные CPU (скажем 16 ядер) и тогда они будет сильно быстрее, чем 96pCore.
Я как бы не спорю с тем, что при конфигурации сервера стоит использовать все каналы. Это очевидно. Но я сомневаюсь с утверждениями о том, что полоса памяти — это ключевое, что определяет производительность, как вы говорите.
Я исследовал вопрос и нашёл, что Эпик 2300 МГц с кешем 768МБ даёт производительность примерно как Эпик на 2800-3000 МГц с кешем 128МБ.
Ну вроде очевидно, что это сильно зависит от профиля нагрузки и приложения. Если приложение зависит от скорости обработки данных из RAM, то cache может (еще вопрос насколько хорошо кэшируются данные) помочь. Если оно Compute-bound, то cache не поможет никак. https://chipsandcheese.com/p/deep-diving-zen-3-v-cache
Более того, очевидно, что Cache просто так не дается и его наличие сказывается и на частоте (при том же TDP она ниже), и на цене. Например, AMD EPYC™ 9384X (32@3.1GHz+768MB L3 320W) vs AMD EPYC™ 9374F (32@3.85GHz+256MB L3 320W). Что будет быстрее в реальный задачах (и каких) - ИМХО очень нетривиальный вопрос. Ставлю на то, что в СРЕДНЕМ 9374F будет быстрее.
В общем, моя мысль в том, что фраза про Cache дающий что-то там к частоте ядра выглядит супер странно. Cache может что-то дать к общей производительности - да (поэтому кэши и ставят). При этом еще в определенных задачах. Является ли Cache панацеей и дефолтным решением для всего - нет. AMD, вероятно, считает так же - это видно если просто посмотреть на линейку EPYC. Есть только несколько моделей с доп. кэшом.
5. Для рейда в Линукс (а сверху возможны виртуалки с Windows) можно использовать lvm, btrfs, zfs. Можно использовать аппаратные контроллеры на базе LSI.
Да, но... SW RAID и 3-mode RAID контроллеры - относительно медленные. Особенно в R5. Речь обычно идет про несколько миллионов IOPS на чтение и несколько сотен IOPS на запись. И озвученная вами планка в 1M IOPS на диск достигается супер быстро (буквально на нескольких дисках). При этом SW RAID жрут CPU еще как не в себя.
И поэтому с одной стороны индустрия пытается что-то придумать - GRAID (RAID с offload на CUDA GPU), Xinnor (ex-raidix), а с другой облака типа AWS/Azure для локальных дисков не собирают RAID из локальных NVMe, а отдают или диск целиком или его часть через namespace.
3. Некоторые бизнесмены в России использовали консьюмерские ССД в серверах. Знаю по личному опыту.
Ну вы же пишите, как надо. А не как не надо. Использовать consumer SSD в Datacenter это плохая идея не только (и даже не столько) с точки зрения производительности, но и надежности.
Samsung обожает использовать в Product Brief и маркетинге использовать "Up to". Причём технические документы с реальными цифрами найти крайне сложно.
С-States это про уменьшение частоты или отключение ядер. Авторазгона отдельных ядер это не касается.
Ну как это не касается. Boost ядра является функцией от потребления и температуры всего CPU. "Core Performance Boost <> allows the processor to opportunistically increase a set of CPU cores to higher than the CPU’s rated base clock speeds based on the number of active cores, power, and thermal headroom in a system." Т.е. больше у вас активных ядер (которые не ушли в C-state, потому что вы им запретили), тем меньше остается запаса на разгон отдельного ядра.
Да, есть особенность в том, что выход "из спячки" занимает время и поэтому для low-latency/jitter-sensitive (но НЕ high-throughput) это может быть больно. Но в документах от AMD (AMD EPYC™ 9005 BIOS & WORKLOAD TUNING GUIDE) прямо и четко написано:
"If you have a low latency or extremely low jitter use case, then consider disabling DF C-states as described in this Tuning Guide. AMD strongly recommends not disabling Global C-states except for debugging."
потом оказывается, что процессоров с 64-ядрами с такой частотой не бывает и берут
Нужно число серверов с нужным числом CPU. В чем проблема?
На нормальную работающую "переподписку" (или "overselling") лучше вообще не рассчитывать.
Это странно и идет в разрез со всем практическим опытом виртуализации, который я наблюдал. Для БОЛЬШИНСТВА (но, разумеется, не всех) задач в Enterprise переподписка используется. Это обычно 1:2-1:3 для стандартных серверных нагрузок, 1:3-1:5 для Test/Dev ландшафтов и 1:5+ для условного VDI. Более того, если посмотреть, скажем, на AWS (и прочих), то там переподписка vCPU на pCore для большинства инстансов 1:2, потому что у AWS 1vCPU=1Thread, коих два на pCore. Поэтому переподписка — это нормально и не страшно, до тех пор, пока вы понимаете, что делаете и следите за показателем CPU Ready.
А есть пруф, что под стандартными задачами типа General Propose виртуализации узким местом является полоса RAM? Не, я понимаю, что есть RAM-чувствительные бенчмарки, но все же это несколько не то.
И еще вот это напоминаю. Я просто часто встречаю такое утверждение, но пока не видел пруфов.
Как правило, наиболее узкое место сервера — это не частота, а память и система ввода-вывода.
А есть пруф, что под стандартными задачами типа General Propose виртуализации узким местом является полоса RAM? Не, я понимаю, что есть RAM-чувствительные бенчмарки, но все же это несколько не то.
По сравнению с десктопными процессорами у них огромные кэши всех уровней, которые дают прирост примерно как +300-500 MHz.
А каким образом кэш влияет на частоту? Кэш в моей картине мира приводит у к уменьшению задержек обращения к RAM, потому что часть как раз в кэше, т.е. ослабляет требования к полосе RAM и снижает latency (для некоторых запросов, которым повезло быть в кэше), но при чем тут частота?
Однако потом при запуске большого числа виртуалок, большего чем число ядер, всё начнёт тормозить, так как частое переключение контекста хуже, чем работа без переключений на более низкой частоте, но когда ядер хватает.
Это ложная дихотомия. Производительность одного потока, с точки зрения чистой вычислительной мощности, определяется зависит от IPC и частоты. Хотя, разумеется, зависит от того, можете ли вы достаточно быстро подавать данные в ядро. Переключение контекста зависит от степени переподписки на хосте (vCPU/pCPU) и профиля нагрузки самих приложений. Если у вас частота 2GHz, то за выделенный квант времени, система не сможет обработать больше X операций независимо от поведения других ВМ на хосте. Поэтому для Single Threaded-heavy операций (например, некоторые операции в OLTP СУБД) вам нужна высокая частота и числом ядер вы никак ситуацию не улучшите. При этом, разумеется, при очень большой переподписки у вас будет расти CPU Ready, что так же будет сказываться на производительности, поэтому вы должны отслеживать эти значения. Поэтому сначала определяется требуемая частота одного ядра, а потом сколько этих самых ядер на надо, но не на оборот.
А вообще (сейчас будет не честный прием) расскажите, что "2.0GHz - достаточно" ярым адептам 1С и услышите много веселого (хотя и не всегда правильного). :)
Поэтому отключаем Global C-State
А как вы про комментируете влияние отключения C-states на Boost Clocks?
Поэтому более экономически выгодно поставить несколько накопителей NVME (в рейд или на разные виртуалки), пусть даже версии PCI-E 3.0, которые в сумме дадут больше IOPS, чем накопитель с более высокой версией NVME.
1.) Что такое версия NVMe? Речь про 2.1 (последняя на текущий момент) vs например 1.4? Как это влияет на производительность?
2.) А каким образом вы советуете собирать много NVMe SSD в RAID?
«Up to» — это пиковая производительность. Реальная может быть в разы ниже.
Если открыть datasheet на любой Enterprise SSD, то там обычно указан профиль, при котором получены данные цифры и это производительность в Steady State.
даже пользовательские NVME иногда анонсируют достаточное количество IOPS
Как по мне, то все несколько проще - не используйте Consumer SSD для задач Data Center. Всё.
Окей, я готов признать, что я погорячился и, вероятно, из-за проф. деформации сделал излишний перенос с промышленных систем на домашние.
При этом я по-прежнему считаю, что мнение, что инференс не требователен к полосе GPU2GPU в общем случае, ошибочным и/или неполным и считаю важным это подсветить:
1.) Чем больше у вас параметров в модели (пусть и при меньшем числе разрядов на параметр), тем больше требования. 7-8B - нынче это очень маленькие модели и сейчас очевиден тренд на рост моделей при одновременном снижении разрядности параметров (а значит при +- тех же требованиях по VRAM). 40-70B INT4 влезает в ~30-35GB VRAM.
2.) Чем больше у вас TP (т.е. чем больше у вас "объединяется" карт), тем больше данных ходит через GPU2GPU создавая нагрузку. 8 GPU на сервер, в общем-то нормальная история нынче, 4 так вообще везде ставится.
3.) GPU2GPU влияет в основном на prefill, а не Decode. И это критично, если:
а.) У вас есть требования по TTFT. Для пром. систем они практически всегда есть и задаются в качестве исходного требования. Ожидания в минуты часто является просто не допустимым. Например, в MLPerf Inference это 6 секунд для LLama 3.1 405B и 0.5 секунды для Llama 2 70B, в среднем же обычно, для чат-ботов берут что-то порядка до 2-5 секунд. Чтобы обеспечить низкое время TTFT нужен очень быстрый prefill, а это, в свою очередь, резко задирает требования по GPU2GPU. С другой стороны, супербыстрый Decode нужен реже, потому что мы (человека) читаем со скоростью 200-1000 слов в минуту максимум. Если Decode идет с такой скоростью, то обычно быстрее не нужно. Исключение - очень большой и длинный Reasoning.
б.) Большой размер входящего окна. Размер окна нынче очень быстро и сильно растет. Та же Llama 405B имеет 128к токенов против 4k у Llama 70B.
в.) Задача подразумевает обработку большего числа входящих данных. Особенно если это новые данные. Например Coding, Text Summarization, Translate, Deep Research, RAG, etc.
4.) По мере роста вычислительных способностей карт и объема их памяти, bottleneck начинает смещаться. 5090 имеет 104TFLOP FP32/16 и 1.8TB/s VRAM, что в 5 раз быстрее в FP32, на 30% быстрее в FP16, на уровне по скорости VRAM по сравнению с A100 с NVLINK. RTX Pro 6000 BSE еще быстрее и имеет больше RAM при этом PCIe и не имеет NVLINK.
5.) Все проблемы с полосой GPU2GPU вылезают супер явно на multi-node inference. Понятно, что там и задержки начинают играть большую роль, но и требования по полосе заметны.
Короче, выше написанное не является оспариванием ваших аргументов (во многом справедливых), а скорее дополнением и комментарием против заявлений общего типа вроде "скорость PCIe не критична для инференса". Она может не являться проблемой (особенно если мы говорим про домашние условия и требования на уровне "ну да медленно и мало, но хоть как-то"), а может и очень даже являться (особенно если мы про современные и промышленные системы, где "как-то" не варант). Как обычно "it depends" от задачи и условий.
ИМХО это очень сильно зависит от размера моделей и ее параметров. Для маленьких моделей оно одна, для моделей с большим число параметров пусть и с меньшим квантованием - будет другое. В MoE и reasoning models там совсем все драматично.
На картинке, которые вы привели (от сюда) 2x Llama 3 8B in Q8 (1 модель на двух картах), пусть и пишется про "схожие паттерны" 34/70B), а вторая - Mixtral-8x7B-Instruct-0.1-GPTQ. Я соглашусь, что на 8B там будет не так много нагрузки. Но возьмите DeepSeek R1/V3 и там все будет намного хуже.
Насчет processing/generation — это как раз очень наглядно. Processing (prefill) - compute-bound обычно и делается параллельно. Generation (Decode) делается последовательно и там нету большого объема передаваемых данных. Prefill напрямую влияет на time-to-first-token, т.е. вбили промпт и сидим ждем пока оно начнет писать. Особенно больно это при большом input типа text summarization, кодинге и т.д, а также по мере роста длительности беседы (потому что обрабатываются все прошлые сообщения в рамках окна, которое резко растет последнее время). Я уже молчу про Deep Research, т.е. супер много prefill.
Короче, я соглашусь, что для маленьких, простых моделей, с низким контекстным окном, полоса не так критична. Для больших моделей с большим контекстом и требованиями по низкому time-to-first-token — это становится проблемой. И так же полоса становится все более и более критичной по мере увеличения мощности compute и скорости RAM - оно просто съедает выигрыш. Именно поэтому инференс сейчас активно двигается в сторону больших систем типа GB200NVL72 или B200 NVL8, которые ранее использовались в основном для тренинга.
Да нет. У вас скорость обмена между картами ограничена самым медленным компонентом. И это будет PCIe 5.0 x8 в 5060 Ti. То, что у вас в 5070 Ti есть еще 30GB/s сверху совершенно ни на что не повлияет. Да и вообще, ставить разные карты под одну модель - такое себе, ибо распределять сложно.
Наиболее "эффективно" - брать карту, куда модель влезет целиком и вообще не ходит в PCIe, а не заниматься multi-gpu инсталляциями. Насколько это возможно, подъемно и на самом деле нужно, как обычно, зависит от задачи/бюджета/ограничений и прочего
Это называется Parallelism. Прекрасные объяснения есть тут и тут. Вкратце, есть множество техник/способов такого разделения со своими особенностями. Например, Data Parallelism (по сути, загрузка множества копий модели каждая в свой GPU) и оно не требует быстрого интерконнекта между GPU, ибо там данные почти не ходят, но и "объединения карт" там нет. Есть Tensor parallelism - там разрезается модель на N-слоев (каждый слой делится на N частей и отправляется в свою GPU). И вот тут оно намного более требовательное к полосе, ибо при запросе данные ходят очень активно между картами. Есть еще Pipeline parallelism и т.д.
А дальше есть 3 варианта, как GPU могут общаться между собой - PCIe, NVLINK (SLI нет уже), Ethernet/IB. NVLINK - самый быстрый. Потом Ethernet/IB или PCIe (в зависимости от системы и конфигурации).
И как раз вот тут автор и стрельнул себе в ногу, выбрав 5060 Ti, у которой шина PCIe 5.0 x8. Т.е. всего 30GB/s при скорости VRAM у 5060 Ti в 450GB/s. Взял бы хотя бы 5070 Ti было бы в два раза быстрее, потому что там PCIe 5.0 x16 (хотя справедливости ради там и VRAM 900GB/s), но тогда бы математика по стоимости не сошлась.
И вот ровно по той причине, что PCIe СИЛЬНО (больше, чем в 10 раз) медленнее даже GDDR7 (я молчу тут про HBM), делать тензорный или pipeline parallelism на картах без NVLINK - такая себе затея. Дешевле (с точки зрения $/token/s) взять более мощную и дорогую карту, куда модель влезет целиком. Нынче это, например, 5090 c 32GB VRAM за ~3k$ или RTX Pro 6000 c 96GB VRAM за ~10k$. Понятно, что есть и H100/H200 и B200, но это уже другая лига.
На существующих видеокартах многие блоки для машинного обучения в принципе не нужны, например растеризатор, буфер кадра и весь геометрический конвейер.
Их нету(практически) в Compute-only GPU из серии H100/H200 и B200/B300. Поэтому на этих картах не возможно нормально делать рендеринг. В H100 - 24 rops, что на уровне дёшевой старой интегрированной карты. https://www.tomshardware.com/news/nvidia-h100-benchmarkedin-games И, вероятно, оставлено исключительно для каких-то целей обратной совместимости.
А есть они в универсальных GPU - L40, RTX Pro 6000, но на то они и универсальные - могут и картинку рендерить, а могут и AI посчитать, но далеко не так быстро, как Compute-only.
а для обучения нейросетей с Deep Learning — 16 ГБ и более
Хм.. Какую более-менее актуальную модель вы собрались обучать c 16GB VRAM?
Современные модели NVIDIA с тензорными ядрами (серии RTX, Tesla, A100)
Хм... Tesla и A100, по-вашему, являются актуальными? Последняя Tesla была - T4. Release Date - Sep 13th, 2018. Да и A100 уже безнадежно устарела - May 14th, 2020. 5 лет — это безумно много для мира AI и сейчас уже многие с Hopper на Blackwell переходят.
задача была выяснить чем cxl уступает или нет другим протоколам например infiniband или RDMA
Это очень странная формулировка, потому что это теплое, мягкое и апельсины. CXL — это в первую протокол поверх PCIe (Peripheral Component Interconnect Express) для подключения локальных/периферийных устройств. Который или блочный (CXL.IO), или кэш-когерентный (CXL.Cache), или для памяти (CXL.Mem). Infiniband - сетевой протокол для коммуникации множества удаленных, равноправных устройств (в первую очередь вычислительных узлов). RDMA — это вообще технология доступа к памяти удаленного хоста, которая может работать поверх чего угодно (и Infiniband, и Ethernet, etc).
Да, я в курсе, что существуют крайне редкие внешние PCIe свитчи, но они тут не тестировались, да и задача по-прежнему не понятна. Подключать полку с RAM к хосту? Зачем?
Ну я перечитал еще раз статью и не нашел ничего насчет сравнения с ними ("в чем уступает"), что в общем-то логично, ибо это сравнение не сравнимого.
Конечно же целевое использование это HPC, ML, может быть реал тайм базы данных.
Тут еще более непонятно. Зачем для задач HPC и ML нужен CXL и "дезагрегированная память", если задачи HPC/ML по определению распределяются по узлам для обработки? При этом скорость интерконнекта там уже заведомо выше (800Gbs у IB против 500Gbs у PCIe 5.0 x16), поддерживается всеми шедулерами (типа swarm).
С т.з. зрения ML я бы еще мог понять отсылку к NVLINK, но тогда вообще не понятно, к чему ваш тест тут, да и результат тоже заранее очевиден при учете, что скорость HBM3e в картах типа B200 - 7TB/s.
Про базы я уже писал выше. Какие базы?
Задача была "прощупать" технологию и понять ее нюансы.
Дело конечно ваше и кто я такой, чтобы вам указывать, но ИМХО перед "щупанием" крайне полезно прочитать теорию, а во-вторых, определить что/зачем/каким-образом мы можем это использовать. Иначе получается тест ради теста, ценность которого стремится к нулю, ибо никаких практических выводов сделать не получится.
Я вот лично так и не понял, зачем мне хотеть присоединиться к вашему эксперименту. Чтобы что? Что я могу получить от использования CXL? Какие задачи оно поможет мне решить? В каких случаях мне надо на это смотреть? И т.д.
Не очень понятно и другое. Зачем вообще этим заниматься и RAM втыкать в PCIe? DRAM слотов мало? Стандартный двухсокетный 2U сервер (типа dell r760) имеет 32 слота DRAM, что даёт до 8TB RAM на Хост. Стандартный/средний Хост под туже виртуализацию крайне редко использует большее 2ТБ (Ибо слишком большой домен отказа выходит). Классические bare-metal хосты под те же базы данных тоже редко когда используют более 8ТБ. Да, я понимаю, что есть специфические кейсы типа immemory database например та же HANA, но тогда надо рассматривать per-case, где быстро выяснится, что это просто не поддерживается и плохо работает. А даже если и работает, то эти 768gb принципиально ничего не меняют и надо все равно смотреть на другие системы с большим числом сокетов и слотов.
Какую проблему и задачу вы лично пытаетесь этим решить?
Не совсем. Просто не надо хранить TOTP от Bitwarden в самом Bitwarden. Используйте для этого внешний/независимый TOTP. Ровно так же, с master паролем от Bitwarden. В таком случае утечка пароля от сайта не позволит зайти на него, ибо потребуется TOTP. Утечка пароля от Bitwarden не позволит утащить Bitwarden без второго фактора. И да, разблокировка (не регистрация) в Bitwarden должен осуществляться по биометрии. В таком случае, чтобы взломать что-то, где второй фактор в самом Bitwarden нужно ИЛИ:
1.) Устройство, где зарегистрирован Bitwarden + пароль от устройства + биометрия (ну или master пароль) для разблокировки Bitwarden.
2.) ИЛИ Master пароль от Bitwarden + TOTP от Bitwarden.
P.S. Понятно, что самые главные учетки (банки, почта, etc) все равно надежнее держать отдельно, но в 90% случаев — это обеспечивает ИМХО отличный баланс между безопасностью и удобством.
1.) Если вы используете MIG с A100, то вы можете разделить карту максимум на 7 частей, что на bare-metal, что в vSphere. Потому что это определяется картой.
2.) C vGPU карта может делиться на большее число, но не любое. Максимум 20 для A100 80GB. Работает только с виртуализацией.
3.) Дальше есть просто time-slicing без vGPU. Я его руками не ставил на bare-metal, но оно должно работать и с bare-metal при помощи NVIDIA device plugin for Kubernetes
У VMware есть vSGA режим, где ВМ действительно может быть много, но это ни разу не шаринг карты. Это скорее оффлоад на неё некоторых инструкций.
Я сам этим не занимался, но подсказали, что под k8s приходится вручную изобретать, как пилить партиции с каждой A100 между контейнерами. Под VMWare такой проблемы нет, так как поддерживается vCS.
Это не очень очевидно, потому что много маленьких серверов может стоить дешевле, чем 2 больших (как минимум из-за меньшего резерва в %). И вообще все сводится к тому, что надо просто считать, а общие рекомендации остаются прежними - считаем какие нужны ядра -> считаем сколько нужно ядер -> считаем сколько нужно серверов.
Я как раз сильно против такого общего утверждения. По многим причинам:
1.) как я писал, переподписка уровня 2-4 к одному - нормальная, стандартная и широко распространённая практика. Особенно если мы говорим про Enterprise, где на это значение можно влиять.
2.) Сама по себе переподписка ни о чем не говорит. Если взять в пример тот же VDI, то там рекомендации СТРОГО обратные - высокочастотные и малоядерные CPU c большой переподпиской. Просто из-за того, что VDI нагрузки имеют малопоточный характер, сильно зависят от частоты одного ядра, но при этом редкие и spike-like, т.е. переподписка не сказывается на работе. Серверных нагрузок со схожим профилем тоже более, чем достаточно.
3.) Дело в том, что добавить ядер можно и потом при необходимости путем добавления сервера, а вот добавить частоту существующим ядрам невозможно.
Это не суть важно. CPU Ready - у VMware, Steal Time у KVM, CPU Wait Timer Per Dispatch у Hyper-V. Смысл одинаковый в данном контексте.
Если у вас загружены все ядра, то C-state в них не будет. А значит и толку от отключения C-States нету.
Меня смущает тот факт, что производитель CPU явно пишет, что он настоятельно не рекомендует отключать эту штуку во всех случаях, за исключением latency-sensitive workloads (тут все понятно). Вы же советуете строго обратное без (на мой взгляд) достаточного обоснования этому. Более того, если посмотреть Best Practices производителей серверов (вот, например Lenovo), виртуализации (вот, например VMware), то там тоже рекомендация не отключать C-States по умолчанию.
Вы пишите, что это очевидно, но это не очевидно. Давайте я приведу вам аргументы:
1.) Если производительность General Propose (еще раз, да я понимаю, что существуют задачи чувствительные к полосе RAM. Но многим наплевать, и они реагируют на latency обращения к RAM, а не полосе), в ОБЩЕМ случае зависит от полосы пропускания, то должна быть прямая корреляция между полосой RAM на CPU и общей производительностью системы. Теперь мы берем последние несколько поколений CPU и видим - AMD 7001/7002/7003 (8 x DDR4-3200) = 204.8 GB/s, AMD 9005 (12x DDR5 4800) = 460GB/s, Intel Xeon Cascade (6 x DDR4-2933) = 140 GB/s, Intel Xeon Ice Lake (8 x DDR4-3200) = 204 GB/s, Intel Xeon Sapphire (8 x DDR5-4800) = 307 GB/s, Intel Xeon Emerald (8 x DDR5-5600) = 358 GB/s. Таким образом, мы видим, что 9005 больше, чем в два раза быстрее, чем 7003 или Ice Lake. Теперь мы смотрим на известный тест производительности системы виртуализации VMMark как раз с разнообразной, но относительно реалистичной нагрузкой. Находим там две максимально близкие системы, обе на 4 сервера с 1 CPU по 64pCore, etc. Только одна на 7763 (2.45GHz, 16x64GB 3200=205 GB/s), а вторая на 9554P (3.1GHz, 12x 128GB DDR5-4800=460GB/s). Так вот разница между ними порядка 15%, что вполне вписывается исключительно в разницу по IPC и росте базовой частоты. И несмотря на то, что RAM быстрее в x2.25 раза, такого же роста производительности не видно даже близко. Более того, в реальной жизни так же не наблюдал какого-то кардинального роста производительности при смене поколения (которое увеличивает полосу RAM) при том же числе ядер на той же частоте.
2.) Полоса на CPU обычно одинаковая в рамках одного семейства. Но в одном семействе очень разное число ядер. Нас, очевидно, волнует полоса per Core. Тогда если все определяется полосой RAM, то нам нужно брать максимально мало ядерные CPU (скажем 16 ядер) и тогда они будет сильно быстрее, чем 96pCore.
Я как бы не спорю с тем, что при конфигурации сервера стоит использовать все каналы. Это очевидно. Но я сомневаюсь с утверждениями о том, что полоса памяти — это ключевое, что определяет производительность, как вы говорите.
Ну вроде очевидно, что это сильно зависит от профиля нагрузки и приложения. Если приложение зависит от скорости обработки данных из RAM, то cache может (еще вопрос насколько хорошо кэшируются данные) помочь. Если оно Compute-bound, то cache не поможет никак. https://chipsandcheese.com/p/deep-diving-zen-3-v-cache
Более того, очевидно, что Cache просто так не дается и его наличие сказывается и на частоте (при том же TDP она ниже), и на цене. Например, AMD EPYC™ 9384X (32@3.1GHz+768MB L3 320W) vs AMD EPYC™ 9374F (32@3.85GHz+256MB L3 320W). Что будет быстрее в реальный задачах (и каких) - ИМХО очень нетривиальный вопрос. Ставлю на то, что в СРЕДНЕМ 9374F будет быстрее.
В общем, моя мысль в том, что фраза про Cache дающий что-то там к частоте ядра выглядит супер странно. Cache может что-то дать к общей производительности - да (поэтому кэши и ставят). При этом еще в определенных задачах. Является ли Cache панацеей и дефолтным решением для всего - нет. AMD, вероятно, считает так же - это видно если просто посмотреть на линейку EPYC. Есть только несколько моделей с доп. кэшом.
Да, но... SW RAID и 3-mode RAID контроллеры - относительно медленные. Особенно в R5. Речь обычно идет про несколько миллионов IOPS на чтение и несколько сотен IOPS на запись. И озвученная вами планка в 1M IOPS на диск достигается супер быстро (буквально на нескольких дисках). При этом SW RAID жрут CPU еще как не в себя.
И поэтому с одной стороны индустрия пытается что-то придумать - GRAID (RAID с offload на CUDA GPU), Xinnor (ex-raidix), а с другой облака типа AWS/Azure для локальных дисков не собирают RAID из локальных NVMe, а отдают или диск целиком или его часть через namespace.
Вот просто несколько пруфов - https://www.storagereview.com/review/graid-supremeraid-sr-1010-review, https://www.storagereview.com/review/broadcom-megaraid-9670w-16i-raid-card-review, https://habr.com/ru/companies/raidix/articles/586384/, https://www.storagereview.com/review/graid-supremeraid-gen5-support-lets-ssds-fly, https://forum.level1techs.com/t/extremely-poor-write-performance-in-software-raid-5/200677/15 и далее по списку.
Ну вы же пишите, как надо. А не как не надо. Использовать consumer SSD в Datacenter это плохая идея не только (и даже не столько) с точки зрения производительности, но и надежности.
Ну не знаю. Открываете сайт Samsung, там есть спецификации дисков, загуглил PM1743 specs первой ссылкой вышло https://download.semiconductor.samsung.com/resources/white-paper/PM1743_White_Paper_240510.pdf Потом загуглил тесты, а там очень схожая картинка https://www.storagereview.com/review/western-digital-sn861-gen5-ssd-versatile-solutions-for-modern-hyperscale-and-enterprise-needs (14500 vs 14000 Seq Read, 6000 vs 6000 Seq Write, 1.9M vs 2.5M Rand Read, 320K vs 300K Rand Write).
Ну как это не касается. Boost ядра является функцией от потребления и температуры всего CPU. "Core Performance Boost <> allows the processor to opportunistically increase a set of CPU cores to higher than the CPU’s rated base clock speeds based on the number of active cores, power, and thermal headroom in a system." Т.е. больше у вас активных ядер (которые не ушли в C-state, потому что вы им запретили), тем меньше остается запаса на разгон отдельного ядра.
Да, есть особенность в том, что выход "из спячки" занимает время и поэтому для low-latency/jitter-sensitive (но НЕ high-throughput) это может быть больно. Но в документах от AMD (AMD EPYC™ 9005 BIOS & WORKLOAD TUNING GUIDE) прямо и четко написано:
"If you have a low latency or extremely low jitter use case, then consider disabling DF C-states as described in this Tuning Guide. AMD strongly recommends not disabling Global C-states except for debugging."
Нужно число серверов с нужным числом CPU. В чем проблема?
Это странно и идет в разрез со всем практическим опытом виртуализации, который я наблюдал. Для БОЛЬШИНСТВА (но, разумеется, не всех) задач в Enterprise переподписка используется. Это обычно 1:2-1:3 для стандартных серверных нагрузок, 1:3-1:5 для Test/Dev ландшафтов и 1:5+ для условного VDI. Более того, если посмотреть, скажем, на AWS (и прочих), то там переподписка vCPU на pCore для большинства инстансов 1:2, потому что у AWS 1vCPU=1Thread, коих два на pCore. Поэтому переподписка — это нормально и не страшно, до тех пор, пока вы понимаете, что делаете и следите за показателем CPU Ready.
И еще вот это напоминаю. Я просто часто встречаю такое утверждение, но пока не видел пруфов.
А есть пруф, что под стандартными задачами типа General Propose виртуализации узким местом является полоса RAM? Не, я понимаю, что есть RAM-чувствительные бенчмарки, но все же это несколько не то.
А каким образом кэш влияет на частоту? Кэш в моей картине мира приводит у к уменьшению задержек обращения к RAM, потому что часть как раз в кэше, т.е. ослабляет требования к полосе RAM и снижает latency (для некоторых запросов, которым повезло быть в кэше), но при чем тут частота?
Это ложная дихотомия. Производительность одного потока, с точки зрения чистой вычислительной мощности, определяется зависит от IPC и частоты. Хотя, разумеется, зависит от того, можете ли вы достаточно быстро подавать данные в ядро. Переключение контекста зависит от степени переподписки на хосте (vCPU/pCPU) и профиля нагрузки самих приложений. Если у вас частота 2GHz, то за выделенный квант времени, система не сможет обработать больше X операций независимо от поведения других ВМ на хосте. Поэтому для Single Threaded-heavy операций (например, некоторые операции в OLTP СУБД) вам нужна высокая частота и числом ядер вы никак ситуацию не улучшите. При этом, разумеется, при очень большой переподписки у вас будет расти CPU Ready, что так же будет сказываться на производительности, поэтому вы должны отслеживать эти значения. Поэтому сначала определяется требуемая частота одного ядра, а потом сколько этих самых ядер на надо, но не на оборот.
А вообще (сейчас будет не честный прием) расскажите, что "2.0GHz - достаточно" ярым адептам 1С и услышите много веселого (хотя и не всегда правильного). :)
А как вы про комментируете влияние отключения C-states на Boost Clocks?
1.) Что такое версия NVMe? Речь про 2.1 (последняя на текущий момент) vs например 1.4? Как это влияет на производительность?
2.) А каким образом вы советуете собирать много NVMe SSD в RAID?
Если открыть datasheet на любой Enterprise SSD, то там обычно указан профиль, при котором получены данные цифры и это производительность в Steady State.
Как по мне, то все несколько проще - не используйте Consumer SSD для задач Data Center. Всё.
Хм... А как же https://techdocs.broadcom.com/us/en/vmware-cis/vsan/vsan/8-0/vsan-administration/expanding-and-managing-a-vsan-cluster/using-the-vsan-iscsi-target-service.html и https://techdocs.broadcom.com/us/en/vmware-cis/vsan/vsan/8-0/vsan-administration/expanding-and-managing-a-vsan-cluster/vsan-file-service.html и https://techdocs.broadcom.com/us/en/vmware-cis/vsan/vsan/8-0/vsan-administration/expanding-and-managing-a-vsan-cluster/sharing-remote-vsan-datastores-with-hci-mesh.html
Лучшее от всех миров это https://www.servethehome.com/the-nvidia-dgx-spark-is-a-tiny-128gb-ai-mini-pc-made-for-scale-out-clustering-arm/ или https://www.servethehome.com/this-is-the-asus-ascent-gx10-a-nvidia-gb10-mini-pc-with-128gb-of-memory-and-200gbe/ :)
Тут и 128GB Unified RAM, и CUDA, и Blackwell, и возможность две штуки собирать в стек. И стоит 3-4k$, что дешевле MacBook Pro c 128GB RAM.
Окей, я готов признать, что я погорячился и, вероятно, из-за проф. деформации сделал излишний перенос с промышленных систем на домашние.
При этом я по-прежнему считаю, что мнение, что инференс не требователен к полосе GPU2GPU в общем случае, ошибочным и/или неполным и считаю важным это подсветить:
1.) Чем больше у вас параметров в модели (пусть и при меньшем числе разрядов на параметр), тем больше требования. 7-8B - нынче это очень маленькие модели и сейчас очевиден тренд на рост моделей при одновременном снижении разрядности параметров (а значит при +- тех же требованиях по VRAM). 40-70B INT4 влезает в ~30-35GB VRAM.
2.) Чем больше у вас TP (т.е. чем больше у вас "объединяется" карт), тем больше данных ходит через GPU2GPU создавая нагрузку. 8 GPU на сервер, в общем-то нормальная история нынче, 4 так вообще везде ставится.
3.) GPU2GPU влияет в основном на prefill, а не Decode. И это критично, если:
а.) У вас есть требования по TTFT. Для пром. систем они практически всегда есть и задаются в качестве исходного требования. Ожидания в минуты часто является просто не допустимым. Например, в MLPerf Inference это 6 секунд для LLama 3.1 405B и 0.5 секунды для Llama 2 70B, в среднем же обычно, для чат-ботов берут что-то порядка до 2-5 секунд. Чтобы обеспечить низкое время TTFT нужен очень быстрый prefill, а это, в свою очередь, резко задирает требования по GPU2GPU. С другой стороны, супербыстрый Decode нужен реже, потому что мы (человека) читаем со скоростью 200-1000 слов в минуту максимум. Если Decode идет с такой скоростью, то обычно быстрее не нужно. Исключение - очень большой и длинный Reasoning.
б.) Большой размер входящего окна. Размер окна нынче очень быстро и сильно растет. Та же Llama 405B имеет 128к токенов против 4k у Llama 70B.
в.) Задача подразумевает обработку большего числа входящих данных. Особенно если это новые данные. Например Coding, Text Summarization, Translate, Deep Research, RAG, etc.
4.) По мере роста вычислительных способностей карт и объема их памяти, bottleneck начинает смещаться. 5090 имеет 104TFLOP FP32/16 и 1.8TB/s VRAM, что в 5 раз быстрее в FP32, на 30% быстрее в FP16, на уровне по скорости VRAM по сравнению с A100 с NVLINK. RTX Pro 6000 BSE еще быстрее и имеет больше RAM при этом PCIe и не имеет NVLINK.
5.) Все проблемы с полосой GPU2GPU вылезают супер явно на multi-node inference. Понятно, что там и задержки начинают играть большую роль, но и требования по полосе заметны.
Короче, выше написанное не является оспариванием ваших аргументов (во многом справедливых), а скорее дополнением и комментарием против заявлений общего типа вроде "скорость PCIe не критична для инференса". Она может не являться проблемой (особенно если мы говорим про домашние условия и требования на уровне "ну да медленно и мало, но хоть как-то"), а может и очень даже являться (особенно если мы про современные и промышленные системы, где "как-то" не варант). Как обычно "it depends" от задачи и условий.
Спасибо за прекрасную и содержательную беседу!
ИМХО это очень сильно зависит от размера моделей и ее параметров. Для маленьких моделей оно одна, для моделей с большим число параметров пусть и с меньшим квантованием - будет другое. В MoE и reasoning models там совсем все драматично.
На картинке, которые вы привели (от сюда) 2x Llama 3 8B in Q8 (1 модель на двух картах), пусть и пишется про "схожие паттерны" 34/70B), а вторая - Mixtral-8x7B-Instruct-0.1-GPTQ. Я соглашусь, что на 8B там будет не так много нагрузки. Но возьмите DeepSeek R1/V3 и там все будет намного хуже.
Насчет processing/generation — это как раз очень наглядно. Processing (prefill) - compute-bound обычно и делается параллельно. Generation (Decode) делается последовательно и там нету большого объема передаваемых данных. Prefill напрямую влияет на time-to-first-token, т.е. вбили промпт и сидим ждем пока оно начнет писать. Особенно больно это при большом input типа text summarization, кодинге и т.д, а также по мере роста длительности беседы (потому что обрабатываются все прошлые сообщения в рамках окна, которое резко растет последнее время). Я уже молчу про Deep Research, т.е. супер много prefill.
Короче, я соглашусь, что для маленьких, простых моделей, с низким контекстным окном, полоса не так критична. Для больших моделей с большим контекстом и требованиями по низкому time-to-first-token — это становится проблемой. И так же полоса становится все более и более критичной по мере увеличения мощности compute и скорости RAM - оно просто съедает выигрыш. Именно поэтому инференс сейчас активно двигается в сторону больших систем типа GB200NVL72 или B200 NVL8, которые ранее использовались в основном для тренинга.
Да нет. У вас скорость обмена между картами ограничена самым медленным компонентом. И это будет PCIe 5.0 x8 в 5060 Ti. То, что у вас в 5070 Ti есть еще 30GB/s сверху совершенно ни на что не повлияет. Да и вообще, ставить разные карты под одну модель - такое себе, ибо распределять сложно.
Наиболее "эффективно" - брать карту, куда модель влезет целиком и вообще не ходит в PCIe, а не заниматься multi-gpu инсталляциями. Насколько это возможно, подъемно и на самом деле нужно, как обычно, зависит от задачи/бюджета/ограничений и прочего
Это называется Parallelism. Прекрасные объяснения есть тут и тут. Вкратце, есть множество техник/способов такого разделения со своими особенностями. Например, Data Parallelism (по сути, загрузка множества копий модели каждая в свой GPU) и оно не требует быстрого интерконнекта между GPU, ибо там данные почти не ходят, но и "объединения карт" там нет. Есть Tensor parallelism - там разрезается модель на N-слоев (каждый слой делится на N частей и отправляется в свою GPU). И вот тут оно намного более требовательное к полосе, ибо при запросе данные ходят очень активно между картами. Есть еще Pipeline parallelism и т.д.
А дальше есть 3 варианта, как GPU могут общаться между собой - PCIe, NVLINK (SLI нет уже), Ethernet/IB. NVLINK - самый быстрый. Потом Ethernet/IB или PCIe (в зависимости от системы и конфигурации).
И как раз вот тут автор и стрельнул себе в ногу, выбрав 5060 Ti, у которой шина PCIe 5.0 x8. Т.е. всего 30GB/s при скорости VRAM у 5060 Ti в 450GB/s. Взял бы хотя бы 5070 Ti было бы в два раза быстрее, потому что там PCIe 5.0 x16 (хотя справедливости ради там и VRAM 900GB/s), но тогда бы математика по стоимости не сошлась.
И вот ровно по той причине, что PCIe СИЛЬНО (больше, чем в 10 раз) медленнее даже GDDR7 (я молчу тут про HBM), делать тензорный или pipeline parallelism на картах без NVLINK - такая себе затея. Дешевле (с точки зрения $/token/s) взять более мощную и дорогую карту, куда модель влезет целиком. Нынче это, например, 5090 c 32GB VRAM за ~3k$ или RTX Pro 6000 c 96GB VRAM за ~10k$. Понятно, что есть и H100/H200 и B200, но это уже другая лига.
Их нету(практически) в Compute-only GPU из серии H100/H200 и B200/B300. Поэтому на этих картах не возможно нормально делать рендеринг. В H100 - 24 rops, что на уровне дёшевой старой интегрированной карты. https://www.tomshardware.com/news/nvidia-h100-benchmarkedin-games И, вероятно, оставлено исключительно для каких-то целей обратной совместимости.
А есть они в универсальных GPU - L40, RTX Pro 6000, но на то они и универсальные - могут и картинку рендерить, а могут и AI посчитать, но далеко не так быстро, как Compute-only.
Хм.. Какую более-менее актуальную модель вы собрались обучать c 16GB VRAM?
Хм... Tesla и A100, по-вашему, являются актуальными? Последняя Tesla была - T4. Release Date - Sep 13th, 2018. Да и A100 уже безнадежно устарела - May 14th, 2020. 5 лет — это безумно много для мира AI и сейчас уже многие с Hopper на Blackwell переходят.
Почему не H100? Не H200? Почему GPU для китайского рынка? https://www.reuters.com/technology/nvidia-tweaks-flagship-h100-chip-export-china-h800-2023-03-21/
P.S. У вас там еще ссылки поломались
Каким образом TPU от Гугла решают проблемы высокой (относительно чего, кстати) стоимости и
?
Я бы сказал, что по мимо UALink, которого еще нет в железе, у AMD есть Infinity Fabric - https://rocm.docs.amd.com/en/docs-6.0.2/conceptual/gpu-arch/mi300.html
Ответы на часть ваших вопросов есть вот тут:
https://semianalysis.com/2025/05/23/amd-vs-nvidia-inference-benchmark-who-wins-performance-cost-per-million-tokens/
https://semianalysis.com/2024/12/22/mi300x-vs-h100-vs-h200-benchmark-part-1-training/
Это очень странная формулировка, потому что это теплое, мягкое и апельсины. CXL — это в первую протокол поверх PCIe (Peripheral Component Interconnect Express) для подключения локальных/периферийных устройств. Который или блочный (CXL.IO), или кэш-когерентный (CXL.Cache), или для памяти (CXL.Mem). Infiniband - сетевой протокол для коммуникации множества удаленных, равноправных устройств (в первую очередь вычислительных узлов). RDMA — это вообще технология доступа к памяти удаленного хоста, которая может работать поверх чего угодно (и Infiniband, и Ethernet, etc).
Да, я в курсе, что существуют крайне редкие внешние PCIe свитчи, но они тут не тестировались, да и задача по-прежнему не понятна. Подключать полку с RAM к хосту? Зачем?
Ну я перечитал еще раз статью и не нашел ничего насчет сравнения с ними ("в чем уступает"), что в общем-то логично, ибо это сравнение не сравнимого.
Тут еще более непонятно. Зачем для задач HPC и ML нужен CXL и "дезагрегированная память", если задачи HPC/ML по определению распределяются по узлам для обработки? При этом скорость интерконнекта там уже заведомо выше (800Gbs у IB против 500Gbs у PCIe 5.0 x16), поддерживается всеми шедулерами (типа swarm).
С т.з. зрения ML я бы еще мог понять отсылку к NVLINK, но тогда вообще не понятно, к чему ваш тест тут, да и результат тоже заранее очевиден при учете, что скорость HBM3e в картах типа B200 - 7TB/s.
Про базы я уже писал выше. Какие базы?
Дело конечно ваше и кто я такой, чтобы вам указывать, но ИМХО перед "щупанием" крайне полезно прочитать теорию, а во-вторых, определить что/зачем/каким-образом мы можем это использовать. Иначе получается тест ради теста, ценность которого стремится к нулю, ибо никаких практических выводов сделать не получится.
Я вот лично так и не понял, зачем мне хотеть присоединиться к вашему эксперименту. Чтобы что? Что я могу получить от использования CXL? Какие задачи оно поможет мне решить? В каких случаях мне надо на это смотреть? И т.д.
Не очень понятно и другое. Зачем вообще этим заниматься и RAM втыкать в PCIe? DRAM слотов мало? Стандартный двухсокетный 2U сервер (типа dell r760) имеет 32 слота DRAM, что даёт до 8TB RAM на Хост. Стандартный/средний Хост под туже виртуализацию крайне редко использует большее 2ТБ (Ибо слишком большой домен отказа выходит). Классические bare-metal хосты под те же базы данных тоже редко когда используют более 8ТБ. Да, я понимаю, что есть специфические кейсы типа immemory database например та же HANA, но тогда надо рассматривать per-case, где быстро выяснится, что это просто не поддерживается и плохо работает. А даже если и работает, то эти 768gb принципиально ничего не меняют и надо все равно смотреть на другие системы с большим числом сокетов и слотов.
Какую проблему и задачу вы лично пытаетесь этим решить?
В DGXB200 NVL72 есть: NVLINK5 - 1,800GB/s per GPU (18 линков по 50GB/s). Для сравнения: HBM3e в B200 - 7TB/s. PCIe 5.0 x16 - 64GB/s. NVLINK5 Switch Chip - 72 NVLINK порта, т.е. 7.2TB/s. В NVLINK switch tray - 2 чипа, т.е 14.4TB/s. В DGXB200 NVL72 - 9 switch trays, т.е. ~130TB/s. Так что все DGX уже все давно есть. И заметно быстрее. P.S. Да, я в курсе, что там медь, а не оптика, но исключительно из соображений тепловыделения. Но фотонику для IB и Ethernet на 115Tb/s (144 порта по 800Gb) уже представили. Ссылки: https://www.nvidia.com/en-gb/networking/products/silicon-photonics/ + https://naddod.medium.com/nvidia-gb200-interconnect-architecture-analysis-nvlink-infiniband-and-future-trends-91dc6ba49bf3
Очень это все напоминает ChatGPT. Причем, и примерами без ссылок и названий, и большой любовью к нумерованным спискам.
Не совсем. Просто не надо хранить TOTP от Bitwarden в самом Bitwarden. Используйте для этого внешний/независимый TOTP. Ровно так же, с master паролем от Bitwarden. В таком случае утечка пароля от сайта не позволит зайти на него, ибо потребуется TOTP. Утечка пароля от Bitwarden не позволит утащить Bitwarden без второго фактора. И да, разблокировка (не регистрация) в Bitwarden должен осуществляться по биометрии. В таком случае, чтобы взломать что-то, где второй фактор в самом Bitwarden нужно ИЛИ:
1.) Устройство, где зарегистрирован Bitwarden + пароль от устройства + биометрия (ну или master пароль) для разблокировки Bitwarden.
2.) ИЛИ Master пароль от Bitwarden + TOTP от Bitwarden.
P.S. Понятно, что самые главные учетки (банки, почта, etc) все равно надежнее держать отдельно, но в 90% случаев — это обеспечивает ИМХО отличный баланс между безопасностью и удобством.
Я сказал не совсем это, а то что:
1.) Если вы используете MIG с A100, то вы можете разделить карту максимум на 7 частей, что на bare-metal, что в vSphere. Потому что это определяется картой.
2.) C vGPU карта может делиться на большее число, но не любое. Максимум 20 для A100 80GB. Работает только с виртуализацией.
3.) Дальше есть просто time-slicing без vGPU. Я его руками не ставил на bare-metal, но оно должно работать и с bare-metal при помощи NVIDIA device plugin for Kubernetes
4.) Есть еще CUDA MPS, который тоже должен работать с bare-metal k8s, но я его не копал, так что нюансов не подскажу. https://docs.google.com/document/d/1H-ddA11laPQf_1olwXRjEDbzNihxprjPr74pZ4Vdf2M/edit?tab=t.0 + https://docs.nvidia.com/deploy/mps/index.html + https://ronanquigley.com/blog/understanding-gpu-sharing-strategies-in-kubernetes/
Ну а MIG, потому что это единственный способ сделать максимально честную изоляцию между ВМ на картах. ИМХО не плохой пост для начала изучения: https://developer.nvidia.com/blog/improving-gpu-utilization-in-kubernetes/
P.S. Я согласен, что терминология на этот счет у NVIDIA так себе и постоянно меняется, так что бывает сложно.
Не, это не так работает. Число (и тип) vGPU профилей определяется картой, а не платформой. Поэтому если вы хотите разделить A100, то максимум у вас может быть 7 частей при использовании MIG или 20 Time-sliced. https://docs.nvidia.com/ai-enterprise/release-5/latest/appendix/appendix-misc.html + https://blogs.vmware.com/performance/2021/09/mig-or-vgpu-part1.html + https://www.vmware.com/docs/vgpu-vs-mig-perf
У VMware есть vSGA режим, где ВМ действительно может быть много, но это ни разу не шаринг карты. Это скорее оффлоад на неё некоторых инструкций.
Не очень понятно, потому что vCS поддерживается на bare-metal https://docs.nvidia.com/ai-enterprise/deployment/bare-metal/latest/advanced-gpu.html
Ну а нарезать профили можно через nvidia-smi -i 0 -mig 1 + nvidia-smi mig -cgi 19/nvidia-smi mig -cci 1 9