#apple_silicon — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #apple_silicon, aggregated by home.social.
-
Упаковщик наносит ответный удар: ZA как машина транспонирования
В этой части мы вернёмся к работе, которую предыдущие главы принимали как готовую: упаковке. Сначала найдём скалярную ловушку в упаковке B, затем используем ZA как машину транспонирования, после этого разберём 128-битный случай для комплексных чисел и правило корректности для общего PACKM_KER . В финале соберём весь цикл одной дугой: от FMOPA до работающей субконфигурации BLIS для Apple SME.
https://habr.com/ru/articles/1080094/
#SME2 #Apple_Silicon #BLIS #GEMM #ZA #транспонирование #упаковка_панелей #SVE2 #микроядро #высокопроизводительные_вычисления
-
Дело о лишних размышлениях: почему вредно много думать
…Еще играясь с Qwen3.6 я дал ей стандартную handoff задачу от своей AI команды по проекту SwiftUI и QWEN cli ее так и не решил. Просто ушел в постоянные размышления. В итоге я его просто закрыл и сделал вывод, что Qwen3.6 не может решать такие задачи. И как оказалось я поспешил… В предыдущем расследовании https://habr.com/ru/articles/1075706 мы искали скорость локальной Qwen3.8-27B на Mac Studio. Вывод был довольно жёстким: для интерактивной работы радикально ускорить 27-миллиардную модель можно прежде всего уменьшив объём её весов, то есть квантизацией. В связке с DFlash2 версия 8-bit дошла до 38 токенов в секунду. Но это был только первый вопрос. Быстро отвечать и хорошо работать — не одно и то же. Особенно когда модель должна не пересказать текст, а разобрать инцидент, соблюдать строгий формат, написать и отладить код. Я хотел найти не самую быструю версию Qwen3.8-27B, а модель, которую можно реально использовать каждый день: чтобы не ждать ответ по минуте и не получать взамен очень убедительную чепуху. Казалось, что план очевиден. BF16 берём как эталон качества. 8-bit и 4-bit сравниваем с ним. А чтобы квантизованные версии точно не потеряли в сложных задачах, включаем им максимальный уровень рассуждений — reasoning_effort=xhigh . Это была вполне логичная гипотеза. И она оказалась неверной.
https://habr.com/ru/articles/1079274/
#qwen3827b #omlx #mlx #apple_silicon #mac_studio_m3_ultra #локальные_llm #инференс_llm
-
Дело о 38 токенах в секунду: почему M3 Ultra начинал с двенадцати
Всё началось с простой, на первый взгляд, задачи. Я хотел использовать локально Qwen3.8-27B именно в BF16. Причём не исходный PyTorch-чекпойнт через случайный слой совместимости, а mlx-community/Qwen3.8-27B-bf16 — специально подготовленную в формате MLX версию для Apple Silicon. Вся линейка Qwen3.8 от mlx-community конвертирована именно для запуска на процессорах Apple. То есть модель уже была адаптирована под архитектуру Mac. Без 8-битной или 4-битной квантизации, потому что исходный приоритет был не в том, чтобы любой ценой получить красивую цифру в бенчмарке. Мне нужна была максимальная точность модели для сложного анализа, работы с кодом и длинных рассуждений. Казалось, что с железом проблем точно не будет. Моя конфигурация — Mac Studio 2025 года ( Mac15,14 , заказной номер Z1CE001BMZP/A ) с Apple M3 Ultra: 32 ядра CPU, из них 24 производительных, 80 ядер GPU, 512 ГБ объединённой памяти и SSD на 2 ТБ. Заявленная Apple пропускная способность памяти — 819 ГБ/с . То есть перед нами не ноутбук, который случайно заставили считать большую языковую модель. Это максимальная конфигурация M3 Ultra по CPU, GPU и объёму памяти. И на ней оптимизированная для Apple Silicon версия Qwen3.8-27B в BF16 выдавала всего 12 токенов в секунду . Сначала результат выглядел подозрительно. В машине десятки CPU- и GPU-ядер, модель целиком помещается в память, используется нативный для Apple Silicon фреймворк MLX. Почему тогда скорость совсем не похожа на то, чего ждёшь от топового GPU? Я начал искать узкое место.
https://habr.com/ru/articles/1075706/
#Qwen3827B #DFlash2 #oMLX #MLX #Apple_Silicon #Mac_Studio_M3_Ultra #локальные_LLM #инференс_LLM #speculative_decoding #BF16
-
Микроядро SME2 sgemm: 1024 умножения-сложения за проход
В этой части мы возьмём первый из пропусков BLIS — микроядро sgemm ; сначала зафиксируем форму аккумулятора 32×32 в четырёх тайлах ZA, затем разберём горячий цикл по K, потом эпилог с alpha , beta и ловушкой NaN, а в конце посмотрим, какие числа производительности даёт именно это ядро. Следующая часть оставит структуру почти той же, но заменит геометрию тайла и условия существования ядра.
https://habr.com/ru/articles/1071462/
#BLIS #GEMM #SME2 #Apple_Silicon #микроядро #кэшблокинг #упаковка_данных #высокопроизводительные_вычисления #линейная_алгебра #BLAS
-
BLIS: недостающую среднюю ступеньку построили тридцать лет назад
В этой части мы начнём с тупика, в который приводит голый цикл FMOPA ; затем покажем, какую часть GEMM BLIS уже построил за нас; после этого разберём пять циклов BLIS и место микроядра внутри них. Финал главы должен сделать дальнейший план конкретным: что именно нужно добавить для Apple SME, а что уже относится к готовой «мебели» фреймворка.
https://habr.com/ru/articles/1069058/
#BLIS #GEMM #SME2 #Apple_Silicon #микроядро #кэшблокинг #упаковка_данных #высокопроизводительные_вычисления #линейная_алгебра #BLAS
-
56 минут созвона → текст за 5 минут на M4 без OBS и облака
У меня от трёх до пяти созвонов в день, почти все в браузере: Meet, Яндекс Телемост, ktalk, реже всего Zoom. Детали встреч мне нужны в тексте, иначе договорённости расползаются. Писал я звонки через OBS с захватом экрана, и на самих звонках началось веселье: звук временами жёстко квакал, всё чуть-чуть подвисало. Причину до конца не выяснял, моё предположение - процессор зажирался захватом и перебивал сам разговор; ktalk и браузер тут ни при чём. А экран, как потом дошло, мне вообще был не нужен. Дальше вторая серия. Расшифровку я гонял своими Python-скриптами: конвертация → транскрибация → диаризация (разметка, кто когда говорил). На встрече с пятью участниками диаризация расставляла голоса крайне плохо, половину фраз всё равно восстанавливал по памяти. Пошёл искать вариант, чтобы запись не мешала звонку, результат был приличный и всё крутилось локально: не хотелось ни отдавать записи в облако, ни платить подписку за минуты. Нашёл платный Audio Hijack , он подкупил лёгкостью и простотой настройки. Потом узнал, что на M-чипе быстрее всего у меня отрабатывает mlx-whisper на MLX : веса large-v3-turbo с Hugging Face, инференс на GPU Mac. Это архитектура Whisper, но рантайм — пакет mlx-whisper и бинарь mlx_whisper , не pip install openai-whisper и не репозиторий openai/whisper . Так собрался стек: Hijack пишет один mp3, mlx_whisper делает VTT, pyannote раскладывает по SPEAKER_XX. На 56-минутном звонке транскрипция заняла около пяти минут. Платный только Hijack — разовая лицензия, без подписки (цену смотрите на сайте Rogue Amoeba). Скрипты выложил в mac-call-transcribe под MIT. Ниже сборка, замеры с двух реальных звонков и грабли; повторяется на любом Mac с M-чипом.
https://habr.com/ru/articles/1062068/
#whisper #mlx #pyannote #speaker_diarization #расшифровка_звонков #python #apple_silicon #транскрибация_звонков
-
Запретный 3ds Max на Mac mini M4: 1 час 21 минута на интерьер
Autodesk не рекомендует 3ds Max на Apple Silicon. Я всё равно завёл 3ds Max 2022 + Chaos Corona 15 на Mac mini M4 через Parallels и отрендерил интерьер на CPU за 1 час 21 минуту. Внутри: полный порядок установки, фикс лагов вьюпорта, обход ошибки AVX2 и честные замеры.
https://habr.com/ru/articles/1050156/
#3ds_Max #Chaos_Corona #Parallels_Desktop #Mac_mini_M4 #Apple_Silicon #Windows_11_ARM #CPUрендеринг #эмуляция_x64 #AVX2