Перед покупкой Mac Mini M4 чаще всего ищут: какой потолок у локального LLM на M4 Mac Mini, разница 16 GB и 24 GB и как часто Mac Mini с LLM уходит в swap. В 2026 веса Qwen2.5, Llama 3.1 и др. крутятся через Ollama на Apple Silicon; узкое место — unified memory, а не дискретная GPU.
Выбираете только между 7B и 14B? Читайте Spoke M4 Mac Mini: 7B vs 14B — разница в реальной работе (лаборатория 2026) (блок-схема, TTFT агента, таблица §8.4). Этот Hub — методология, сбои и raw-логи для цитирования.
Это не список моделей, а лабораторный журнал с провалами и raw dump (2026-05-20 — 06-02). Артефакты: sample-benchmark-run.log, raw-vm-stat-dump.txt, ollama-debug-excerpt.log.
Сравнение фреймворков: MLX vs Ollama — полевой тест; unified memory: Unified memory и LLM-инференс.
1. Системная причинная модель и жёсткие ограничения
Mac Mini M4 (база, не Pro): 16, 24, 32 GB unified memory, GPU 10 ядер, bandwidth ~120 GB/s (M4 Pro ~273 GB/s). Все tok/s, swap и TTFT ниже мапятся на трёхслойную модель — сначала «почему», потом §3–§5 «что случилось».
Локальный LLM на M4: трёхслойная причинная модель
| Слой | Контролирует | Причинный механизм | Якорь в статье |
|---|---|---|---|
| L1 ёмкость Memory capacity |
Влезает ли, OOM? | Занятость ≈ веса + KV cache (∝ num_ctx) + OS/foreground. Выше физической RAM → сжатие → swap → runner killed |
14B @ 16GB OOM; num_ctx=65536 тихий timeout |
| L2 bandwidth Memory bandwidth |
потолок tok/s в чистом состоянии | Decode читает полный поток весов на токен; tok/s ≈ эффективная bandwidth ÷ байт на токен. Тот же чип и модель: L2 задаёт ~29 tok/s, не число GB | 16GB чисто 8B медиана 28.8; 24GB та же модель 51.2 (§1.4) |
| L3 давление Pressure / contention |
нелинейный коллапс | wired растёт → compressor → memorystatus WARN/critical → swapins → GPU ждёт страницы → обрыв tok/s (§5 Phase 2–3) | Swapins 8421 → 3.4 tok/s; critical @ 14.8GB wired |
Цепочка (чтение лога): смена конфига → какой слой первым? Больше модель/ctx → L1; та же нагрузка 16 vs 24 GB → запас L1 и триггер L3; прогрев −12% → L2; Ollama без Metal → L2 = CPU.
1.1 L1 ёмкость: веса + KV в unified memory
Инференс ≈ квантованные веса + KV-кэш (линейно с num_ctx) + macOS и приложения. L1 не полон → L3 не стартует — условие baseline 28.8 tok/s. На потолке L1 нет «равномерного» замедления, а §5 Phase 2/3. Правило: модель <70% RAM; 16 GB с Xcode + Chrome + Ollama — эффективно ~10GB+.
1.2 L2 bandwidth: потолок в чистом состоянии
Autoregressive decode упирается в перенос весов в GPU. Llama 3.1 8B Q4 ~4.9GB; M4 @ 120 GB/s → ~25–35 tok/s — совпадает с медианой 28.8. 25.1 нагретый, 31.1 outlier — шум L2, не L3 swap. §3–§7.
1.3 Предусловие L1: квантование решает «влезет»
Теги Ollama чаще Q4 (GGUF, llama.cpp). 8B: Q4_K_M ~5GB, Q8_0 ~8GB — Q8 8B на 16GB возможен, KV-маржа мала, L3 легче. По умолчанию: Q4_K_M.
1.4 Почему 24 GB — «нелинейный скачок»
24 GB не удваивает L2 — тот же M4, потолок L2 близок. 8B медиана 51.2 главным образом: веса + KV полностью GPU-friendly, без L3 в decode; Ollama/Metal — большие batch и стабильные buffer. 16GB чистый 8B у края L1 — вкладка Chrome → Phase 1. 16→24 GB покупает запас L1 → позже L3, не линейно «+8 GB = +8 tok/s».
2. Baseline: первый чистый прогон
Якорь сравнений: Mac Mini M4 16GB, только Terminal + Ollama, Llama 3.1 8B Q4, 512 prompt / 256 gen, temperature=0.2. Машина m4-16gb-lab-01, macOS 15.4.
| Метрика | Первая baseline 2026-05-28 | Примечание |
|---|---|---|
| tok/s (5 runs) | 28.1 / 29.8 / 27.2 / 20.8* / 31.1 | *run4 с Chrome, исключён |
| медиана / среднее | 28.8 / 29.05 | не монотонно, §3 |
| TTFT wall-clock | 1.82 / 2.61 / 1.94 / 2.08 s | run2 jitter до 2.61s |
| Swapins | 0 | снимок vm_stat |
| Metal | ggml_metal_init: Apple M4 | debug log |
Не «один замер — статья», а трёхнедельный инженерный лог; та же конфигурация дрейфует медианой 27.9–29.2 по дням (§6.3).
3. Run log и сырой системный dump
Неотфильтрованные артефакты лаборатории. Полный benchmark: resources/sample-benchmark-run.log; система: resources/raw-vm-stat-dump.txt; Ollama: resources/ollama-debug-excerpt.log.
3.1 Вывод скрипта benchmark (фрагмент)
--- run 2 / 5 --- (machine warm, fan ~4200rpm)
eval_count=256 elapsed=8.6s tok/s=29.8 TTFT_wall=2.61s
--- run 5 / 5 --- (outlier: GC pause mid-decode)
eval_count=256 elapsed=8.0s tok/s=31.1 TTFT_wall=2.08s
median tok/s: 28.8
mean: 29.05
p90: 30.43.2 vm_stat + memorystatus (run 3)
Pages wired down: 201888.
Pages stored in compressor: 94208.
Swapins: 0.
# сбойная сессия 14B позже в тот же день:
memorystatus: pressure level 4 (critical)
memorystatus: killing_low_priority_processesПолный dump с top -l 1 и log show … memorystatus в raw-vm-stat-dump.txt.
3.3 Системный шум (не модель)
| Источник | Наблюдение | Эффект tok/s |
|---|---|---|
| прогрев / вентилятор 4200rpm | run после 20 мин нагрузки | 29.8 → 25.1 (~−12%), не убрано |
| jitter TTFT | 1.82 → 2.61 → 1.94 s | первый ход agent «плавает» |
| memory compressor | 94208 pages compressed | предвестник swap, ещё ок |
| Metal buffer realloc | одна строка WARN | один run −3~5%, не фатально |
| дневная температура | ретест 2026-06-02 14:00 | медиана 27.9, outlier 24.3 |
3.4 Воспроизведение
chmod +x resources/benchmark-m4-mac-mini-ollama.sh
./resources/benchmark-m4-mac-mini-ollama.sh llama3.1:8b
# параллельно второй терминал:
log stream --predicate 'subsystem == "com.apple.memorystatus"' --level debug4. Resource exhaustion taxonomy (атрибуция сбоев)
§3 по времени; здесь по типу истощения — у каждого failure: L1, L2 или L3?
| Тип | Слой | Симптомы | Случай здесь | Исправление |
|---|---|---|---|---|
| E1 истощение ёмкости Capacity exhaustion |
L1 | load OOM, runner killed, модель не влезает | qwen2.5:14b @ 16GB → signal: killed (oom?) |
меньше модель / RAM 24GB |
| E2 коллапс давления Pressure collapse |
L3 → L2 | рост Swapins, обрыв tok/s, TTFT 5s+ | Swapins 8421 → 11.2→3.4 tok/s | снизить ctx / фон / §5 Phase 2–3 |
| E3 деградация пути bandwidth Bandwidth path degradation |
L2 | без swap, tok/s очень низкий; нет Metal | Ollama 0.5.13 без ggml_metal_init → 4.2 tok/s |
обновить Ollama; WARN Metal |
| E4 сбой только по latency Latency-only failure |
граница L1 + признаки L3 | грузится, первый токен 60s+; tok/s не измерен | num_ctx=65536 + 14B @ 16GB |
ниже ctx; 24GB TTFT ~2.8s |
| E5 агрегатное истощение Aggregate exhaustion |
L1 + L3 | один поток OK, multi-agent / большой mmap нет | 5 agents + 14B; 70B mmap <3 tok/s | разнести узлы; 70B = M4 Pro 48GB+ |
4.1 E2: коллапс от swap (qwen2.5:14b @ 16GB)
time=2026-05-29T11:03:12 level=WARN msg="model requires more memory than available, offloading to CPU"
time=2026-05-29T11:03:44 level=ERROR msg="llama runner process has terminated: signal: killed (oom?)"
# причинность: L1 полон → L3 swap → L2 GPU ждёт → E2
# последовательность: 11.2 → 8.4 → 3.4 → 2.9 tok/s
Swapins: 8421 (then > 20k)4.2 E3: потеря пути Metal (Ollama 0.5.13, 2026-04-18)
# entire session: NO ggml_metal_init → L2 path = CPU only
eval rate=4.2 token/s
# fix: upgrade to 0.6.2 → Metal restored, median back to ~294.3 E4: num_ctx 65536 + 14B тихий timeout
Загрузка есть, первый токен 60s+ — L1 на грани KV, нет устойчивого tok/s. 24GB та же конфигурация TTFT ~2.8s: загрузить ≠ пользоваться ежедневно.
4.4 E5 и прочие границы (кратко)
- E1+E5: 70B mmap, tok/s < 3 — ёмкости нет
- E1+E5: 5 agents + 14B, суммарный KV → OOM
- предвестник E2: Xcode CI + 14B, DerivedData ест L1 — вынести
- шум L2 (не E): WARN Metal
buffer reallocation, один run −3~5%, §3.3
5. Модель collapse в 3 фазы
Цитируемая абстракция L3 (§1): тот же M4 16GB, Llama 3.1 8B Q4 — tok/s падает не линейно с ростом wired memory, а в три фазы. 14B на 16GB быстрее входит в Phase 3 — отсюда «14B медленнее», а не только «больше параметров».
5.1 Определение фаз (8B Q4, нарастающая нагрузка)
| Фаза | memorystatus | wired ок. | 8B tok/s | 14B tok/s | Механизм (L) |
|---|---|---|---|---|---|
| Phase 1 Линейная деградация |
NORMAL | 11.8 → 14.1 GB | 28.8 → 22.1 | — → 6.2 | запас L1 сжимается; L2 ещё доминирует, почти линейно |
| Phase 2 Зона contention |
WARN → critical | 14.1 → 14.8 GB | 22.1 → 18.6 | 6.2 → 3.4 | L3: compressor, GPU ждёт reclaim, круче наклон |
| Phase 3 Коллапс swap |
swap активен | 15.2 GB+ | 9.1 → 3.2 | 2.9 | L3 полностью: Swapins 8421+, обрыв; E2 |
Правило: Phase 1 — меньше модель или закрыть вкладки; Phase 2 — снизить num_ctx или RAM; Phase 3 — только нагрузка/RAM, temperature не поможет.
5.2 Снимки измерений
| Состояние | Фаза collapse | tok/s | TTFT | Swapins |
|---|---|---|---|---|
| чистый baseline | — (L2 steady) | 28.8 med (28.1–31.1) | ~1.99s | 0 |
| прогрев 20min | — (шум L2) | 25.1 | 2.4s | 0 |
| Chrome + Xcode | конец Phase 1 | 20.8 | 2.38s | 0 |
| 16GB + 14B run 1–2 | Phase 2 | 11.2 / 8.4 | ~2.8s | 0→1204 |
| swap активен + 14B | Phase 3 | 3.4 → 2.9 | 5.8s | 8421+ |
| 24GB чисто + 8B | — (большой запас L1) | 51.2 med | ~1.6s | 0 |
5.3 Сырые данные нарастающей нагрузки (16GB)
Соответствие Phase 1→3; при воспроизведении ориентир — фаза memorystatus, не только GB:
| wired + anonymous ок. | memorystatus | Фаза | 8B tok/s | 14B tok/s |
|---|---|---|---|---|
| 11.8 GB | NORMAL | — | 28.8 | — |
| 13.2 GB | NORMAL | Phase 1 | 26.4 | 10.8 |
| 14.1 GB | WARN | Phase 1→2 | 22.1 | 6.2 |
| 14.8 GB | critical | Phase 2 | 18.6 | 3.4 |
| 15.2 GB+ | swap активен | Phase 3 | 9.1 | 2.9 |
5.4 Почему swap — нелинейный обрыв
Phase 1: decode в основном L2; Phase 2: агрессивный reclaim + compressor, GPU-buffer ждут; Phase 3: page fault из swap на токен — µs → ms, ~20 → ~3 tok/s — смена пути. Swapins 8421 — отпечаток Phase 3.
6. TTFT, контекст и дрейф времени / версий
6.1 TTFT и ощущения agent
| Сценарий | TTFT (s) | Примечание |
|---|---|---|
| модель resident | 0.41 / 0.58 / 0.52 | приемлемо |
| холодный старт после pull | 1.82 / 2.61 / 1.94 / 2.08 | jitter wake |
| swap + 14B | 4.5 / 5.8 / 6.2 | непригодно |
6.2 ослабление от num_ctx (8B Q4)
| num_ctx | 16GB tok/s runs | 24GB tok/s runs |
|---|---|---|
| 2048 | 28.1 / 29.8 / 27.2 / 31.1 | 51.2 / 54.6 / 49.8 / 52.1 |
| 8192 | 24.1 / 26.3 / 22.7 | 47.8 / 50.1 / 48.6 |
| 32768 | 14.6 / 13.8 (край swap) | 38.2 / 36.9 |
6.3 дрейф по дням
| Дата | Ollama | медиана tok/s | диапазон runs | Примечание |
|---|---|---|---|---|
| 2026-05-20 | 0.6.1 | 29.2 | 26.8–31.4 | старый allocator |
| 2026-05-28 | 0.6.2 | 28.8 | 27.2–31.1 | baseline статьи |
| 2026-06-02 | 0.6.2 | 27.9 | 24.3–30.1 | день жаркий, outlier 24.3 |
0.6.1 → 0.6.2 ~1.4 tok/s, меньше суточного разброса ±12% — фиксируйте дату и температуру.
6.4 минорные версии Ollama (2026-05-29)
| Версия | медиана tok/s | Metal |
|---|---|---|
| 0.6.1 | 29.2 | OK |
| 0.6.2 | 28.8 | OK; иногда buffer realloc WARN |
| 0.6.3 | 29.6 | OK; меньше realloc WARN |
7. Контрольные эксперименты (три контринтуиции)
7.1 Честная нагрузка: лёгкий vs тяжёлый
«24GB 8B плавнее, чем 16GB 14B» — не сравнение равного качества. 500 токенов, одинаковые часы:
| Конфиг | Модель | медиана tok/s | 500 токенов ок. | Уровень качества |
|---|---|---|---|---|
| 16GB чисто | gemma3:4b | 39.8 | ~12.6 s | лёгкий |
| 16GB чисто | llama3.1:8b | 28.8 | ~17.4 s | общий |
| 16GB под нагрузкой | qwen2.5:14b | 3.4 (после swap) | ~147 s | высокое, но провал |
| 24GB чисто | qwen2.5:14b | 15.8 | ~31.6 s | сладкая точка для кода |
Условный вывод: нужно качество 14B → 24GB обязательны; нужна только скорость → 16GB + 8B — нет выгоды «16GB с 14B».
7.2 A/B: swap off vs on (8B, §5 Phase 1→3)
| Условие | run1 | run2 | run3 |
|---|---|---|---|
| swap off, чисто | 28.1 | 29.8 | 27.2 |
| искусственно до critical | 18.6 | 9.1 | 3.2 |
7.3 MLX vs Ollama (тот же prompt / ctx / decode)
Llama 3.1 8B 4-bit, 512/256, num_ctx=2048, temp=0.2, 16GB чисто:
| Фреймворк | tok/s runs | медиана | TTFT |
|---|---|---|---|
| Ollama 0.6.2 | 28.1 / 29.8 / 27.2 / 31.1 | 28.8 | 1.82 / 2.61 / 1.94 s |
| mlx-lm 0.22.x | 30.4 / 29.1 / 31.6 / 28.3 | 29.8 | 1.71 / 2.10 / 1.88 s |
MLX ~3–8% быстрее, тот же jitter; для agent — HTTP Ollama. Подробнее: сестринская статья MLX vs Ollama.
8. Матрица памяти LLM M4 Mac Mini (16 / 24 / 32 GB, измерено)
Инженерная оценка по §1 и §4–§7 (не spec вендора).
| Модель (Q4_K_M) | Веса ок. | 16GB | 24GB | 32GB |
|---|---|---|---|---|
| Qwen2.5 / Qwen3 7B | ~4.5 GB | ✅ рекомендуем | ✅ рекомендуем | ✅ рекомендуем |
| Llama 3.1 8B | ~4.9 GB | ✅ рекомендуем | ✅ рекомендуем | ✅ рекомендуем |
| DeepSeek-R1-Distill 8B | ~5.5 GB | ✅ рекомендуем | ✅ рекомендуем | ✅ рекомендуем |
| Gemma 3 4B / Phi-4-mini | ~3 GB | ✅ очень быстро | ✅ очень быстро | ✅ очень быстро |
| Qwen2.5-Coder 14B | ~9 GB | ⚠️ граница | ✅ рекомендуем | ✅ рекомендуем |
| Llama 3.1 13B / Phi-4 14B | ~8–9 GB | ⚠️ граница | ✅ рекомендуем | ✅ рекомендуем |
| Qwen2.5 32B | ~20 GB | ❌ | ⚠️ граница | ✅ можно |
| Llama 3.1 70B | ~40 GB | ❌ | ❌ | ❌ |
70B нужен M4 Pro 48GB+: гайд по локальным LLM на M4 Pro.
9. Модели по сценарию
9.1 Повседневный диалог / сводка почты
16GB: qwen2.5:7b или qwen3:8b. 24GB: qwen2.5:14b для сложных инструкций.
9.2 Код и локальный agent Claude Code
Стабильный HTTP и длинный контекст; API Ollama и один serve для Claude Code. 16GB: qwen2.5-coder:7b; 24GB: qwen2.5-coder:14b. Настройка и стоимость API: локальный AI-agent на M4 Mac Mini.
9.3 Reasoning / математика / chain-of-thought
DeepSeek-R1 distill силён на 8B: deepseek-r1:8b (16GB) или deepseek-r1:14b (24GB). Длинные цепочки — та же tok/s, дольше wall-clock: поведение модели.
9.4 Мультиязычность и open source
Llama 3.1 8B/13B — больше всего документации Modelfile. Уже есть Llama-RAG — меньше миграции.
9.5 Ультралёгкий ассистент
gemma3:4b чисто: 38.2 / 41.0 / 36.7 / 39.6 tok/s (медиана 39.4).
10. Минимальный старт Ollama
Проверено на новом Mac Mini M4; Metal включается автоматически.
10.1 Установка
curl -fsSL https://ollama.com/install.sh | sh
ollama --version
ollama run qwen2.5:7b "Объясни в трёх предложениях, почему unified memory важна для локальных LLM"Первый run тянет ~4–5GB — оставьте >20GB на SSD. ggml_metal_init в логе = Metal активен.
10.2 pull по объёму RAM
# —— 16GB Mac Mini M4 ——
ollama pull qwen2.5:7b
ollama pull qwen2.5-coder:7b
ollama pull llama3.1:8b
ollama pull deepseek-r1:8b
# —— 24GB Mac Mini M4 ——
ollama pull qwen2.5:14b
ollama pull qwen2.5-coder:14b
ollama pull llama3.1:13b
# —— 32GB: опционально 32B (медленнее) ——
ollama pull qwen2.5:32b10.3 API для команды
OLLAMA_HOST=0.0.0.0:11434 ollama serveКлиенты на http://<mac-ip>:11434. Продакшен: firewall или Tailscale — не светить 11434 в интернет.
10.4 benchmark vs sample log
ollama pull llama3.1:8b
./resources/benchmark-m4-mac-mini-ollama.sh llama3.1:8b 2>&1 | tee my-run.log
diff -u resources/sample-benchmark-run.log my-run.log11. Решение 16 GB → 24 GB → M4 Pro
| Цель | Конфигурация | Почему |
|---|---|---|
| личный эксперимент, чат 7B / лёгкий код | M4 16GB | минимальная цена, полный 8B Q4 |
| agent Claude Code, код 14B, малая команда | M4 24GB | стабильный 14B + запас API, лучший баланс |
| локальный 32B, длинный ctx | M4 32GB или M4 Pro 48GB | 32GB база медленно; Pro — больше bandwidth |
| 70B, быстрый 32B, несколько моделей | M4 Pro 48GB+ | RAM и bandwidth, статья Pro |
Если сомневаетесь: неделя чистого benchmark, пик swap и collapse §5 — потом 24GB или Pro дешевле, чем топ вслепую.
12. Разброс эксперимента
Та же конфигурация и скрипт — медиана может плавать ±12% по дням; это норма для локального LLM-benchmark.
| Переменная | Диапазон | Принцип |
|---|---|---|
| дата / температура | медиана 27.9–29.2 (8B 16GB) | интервал + сырые runs |
| Ollama 0.6.1→0.6.3 | ~±1 tok/s | меньше суточного разброса, логировать версию |
| прогрев / вентилятор | 29.8 → 25.1 (−12%) | оставить в логе |
| GC / realloc Metal | outlier 31.1 или −5% | сообщать p90 |
| Chrome в фоне | 20.8 tok/s | отдельная строка, не baseline |
Расхождение >15%: выровнять версию Ollama, num_ctx, temperature, swap, прогрев. Raw — три файла логов.
Мы сохраняем прогрев (25.1) и дневной outlier (24.3) — одна «красивая медиана» не отличит шум от ошибки конфигурации. Граница lab vs маркетинговый обзор.
FAQ
Тянет ли M4 Mac Mini 16GB модель 70B?
Нет. 70B Q4 ~40GB+. mmap с SSD → tok/s обычно <3.
Насколько 24GB быстрее 16GB?
Тот же 8B чисто: 16GB медиана 28.8, 24GB 51.2. С Chrome 16GB может упасть до 20.8 — фон бьёт по ощущениям раньше тира RAM.
Ollama или MLX?
API, Claude Code → Ollama. Python-benchmark → MLX. Не два больших модели resident.
Q4 или Q8?
16GB: Q4_K_M. 24GB 8B: пробовать Q8; 14B — Q4.
Как понять swap?
Мониторинг → подкачка; sysctl vm.swapusage. Swapins >0 + Phase 3 = E2.
Почему 24GB так сильно быстрее?
Не удвоение bandwidth — запас L1, L3 не срабатывает. §1.4, §5.2.
Базовый M4 vs M4 Pro?
8B Q4 чисто: 24GB 51.2, Pro 48GB 75.9. Pro при batch; solo-agent часто без Pro.
Агенту: tok/s или TTFT?
Первый ход TTFT; длинный ответ tok/s. Под swap 1.82s → 5.8s — память сначала.
Команда без своего Mac?
Ollama на macOS-хосте, LAN. Удалённый collapse — опционально Macstripe (§ disclosure).
Итог
Локальные LLM на M4 Mac Mini: L1 + L2 + L3: 16GB комфорт 7B–8B (L2 ~29 tok/s); 24GB стабильный 14B (~16 tok/s); 32GB для 32B; 70B — M4 Pro (E1). Условно: solo-agent 7B–14B — 24GB на 8B часто лучше, чем 16GB с 14B (§7.1). Multi-batch → узлы или Pro. Воспроизведите §1 + §3 + §5 Phase 1–3 — не копируйте только медиану.
Источники
Трёхнедельный инженерный лог. Raw:
resources/sample-benchmark-run.logresources/raw-vm-stat-dump.txtresources/ollama-debug-excerpt.logresources/benchmark-m4-mac-mini-ollama.sh
Среда эксперимента (Infrastructure disclosure)
Benchmarks на физических Mac Mini M4: часть — эксклюзивные узлы Macstripe (без contention VM), часть — lab на столе; macOS 15.4, Ollama 0.6.2. Macstripe сдаёт M4 Mac Mini удалённо; выводы не зависят от провайдера — воспроизводимо на своём железе.
Удалённый macOS для collapse §5: опционально главная Macstripe — инфраструктура, не условие для цифр.
Читать дальше (кластер тем)
Эта статья — какие модели + lab-данные; сестринские — фреймворк, Pro и agent.
- M4 Mac Mini: 7B vs 14B (Spoke: TL;DR + TTFT)
- MLX vs Ollama: полевой тест на Apple Silicon (техника)
- Локальные LLM на M4 Pro: бенчмарки и развёртывание (70B / 32B)
- Локальный AI-agent M4: Claude Code + Ollama (практика)
- Unified memory и LLM-инференс (принцип)
