Всё началось с простой, на первый взгляд, задачи. Я хотел использовать локально Qwen3.8-27B именно в BF16. Причём не исходный PyTorch-чекпойнт через случайный слой совместимости, а mlx-community/Qwen3.8-27B-bf16 — специально подготовленную ...
Всё началось с простой, на первый взгляд, задачи.
Я хотел использовать локально 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?
Я начал искать узкое место.