Hacker News Digest

Энтузиаст поставил Arch Linux ARM на ноутбук ASUS ProArt P16 (128 ГБ ОЗУ, 6144 ядра CUDA, SSD на 2 ТБ), чтобы не заводить аккаунт Microsoft. Среди причин — навязчивая реклама в Windows, уступки приватности при установке и годы ожидания возврата панели задач на бок экрана. За основу взял работу NVIDIA для Ubuntu, поправил выделение ACPI override и отображение фреймбуфера для консоли, собрал патч для hid-asus и отдельный драйвер звука. Готовый образ с расширенным Archinstall 4.5 ставит поддержку железа; пакеты подписаны его ключом мейнтейнера Arch, а входные данные хешированы. Система сообщает ОС и CUDA одинаковый пул памяти — 116,0 GiB.

В inference ноутбук выдаёт около 30 токенов/с, что сопоставимо с Windows-конфигурацией (29,4 и

Обсуждение дополняет статью критическим анализом целесообразности покупки дорогого RTX Spark и способами обхода ограничений Windows. Пользователи спорят о ценности устройства за $6000. @chem83 считает более эффективным мини-ПК с AMD Ryzen и удаленным доступом, тогда как @schaefer и @mrheosuper подчеркивают важность локального запуска LLM, квантования и независимости от сети. Сравнивая RTX Spark с Apple Silicon, @LoganDark отмечает давнее существование MacBook с большим объемом памяти, а @giancarlostoro поясняет, что архитектура NVIDIA нацелена на общую память GPU и системы для локального инференса AI. Архитектура ARM64 в Spark энергоэффективнее x86_64 (AMD), но создает сложности с совместимостью ПО (@SimianSci). Производительность вызывает сомнения: @pshc указывает на низкую скорость (30 tok/s на Qwen 3.8 Flash Next) из-за возможных термических лимитов, а @smcleod считает пропускную способность памяти в Spark и новых Ryzen слишком низкой по сравнению с M2 Max. Система авторизации Microsoft подверглась критике за плохой UX, редиректы и невозможность входа даже с паролем (@TIPSIO, @sureglymop, @tuvix). Для создания локального профиля при установке Windows 11 рекомендуют использовать генератор autounattend.xml (@tiernano) или опцию «Join a Domain» в версии Pro (@tom_, @SimianSci).

DwarfStar 4 (ds4) — это узкоспециализированный C-движок для локального запуска frontier-моделей: DeepSeek V4/V4.1 Flash, GLM 5.x и Qwen3.8 Flash Next. Он работает на высокопамятных Mac (Metal), CUDA и ROCm-устройствах, используя асимметричную 2-битную квантилизацию routed экспертов, сохраняя точность критических путей. Это позволяет размещать 284-миллиардные параметровые модели на машинах с 128 ГБ ОЗУ, где KV-кэш сохраняется на SSD по хешу промпта, ускоряя перезапуски без полного префилла.

Движок предоставляет три интерфейса: интерактивный CLI (./ds4), локальный HTTP-сервер с OpenAI/Anthropic-совместимыми API (./ds4-server) и нативный агент для постоянных кодинг-сессий (./ds4-agent), все разделяющие одно состояние модели и кэш. На M5 Max с 128 ГБ при контексте 65K токенов достигается 398.5 токенов/с на префилле и 27.6 на генерации; на DGX Spark аналогичной конфигурации — 823.0 и 13.8 соответственно. Установка: клонировать репо, скачать веса через download_model.sh ds4f-q2, собрать под бекенд (например, make cuda-spark) и запустить. Лицензия MIT.

ds4 эффективно запускает крупные MoE-модели на Apple Silicon с 128 ГБ RAM, обеспечивая высокую скорость генерации и поддержку длинных контекстов (до 1 млн токенов, ~22 токенов/сек на Qwen 3.8 Flash Next на M5 Max). Требует дорогостоящего оборудования, ограничивая доступность. ds4 отличается минимальными зависимостями, ориентацией на frontier-модели и асимметричной 2-битной квантизацией экспертов, позволяя размещать модели до 284 млрд параметров на потребительском железе. Поддерживает Metal (Apple Silicon) и CUDA/ROCm (другие платформы), фокусируясь на реальных сценариях использования на высокопроизводительном оборудовании, а не на универсальности. Разработчики расширяют ds4: добавлена поддержка Qwen3.8 и Vision, реализованы FFI-биндинги для Go (ds4go), улучшена интеграция с Hugging Face через TUI. SSD-стриминг позволяет запускать крупные модели (например, полные GLM 5.x) на системах с менее чем 96 ГБ RAM, расширяя применимость за пределы флагманских Mac. Пользователь @simoiacos разработал собственный инференс-движок для Intel Xe-LP (без XMX) на 32 ГБ ноутбуках, поддерживающий квантизированный Gemma-4, с планами расширения поддержки MoE-моделей. Пользователь @liuliu рекомендует Local Code (TestFlight) как альтернативу для 64 ГБ M5-Pro, поддерживающую DeepSeek 4.1 Flash и Qwen 3.8 27B с SSD-стримингом и кастомными квантами. Некоторые пользователи сомневаются в уникальности ds4 по сравнению с llama.cpp или ollama, которые также поддерживают длинные контексты и квантизацию. Комментатор @doctorpangloss утверждает, что квантизированный чекпоинт DeepSeek V4 низкого качества, что ставит под сомнение точность результатов несмотря на высокую скорость. Использование C вместо Rust обусловлено стремлением к минимальным зависимостям и максимальной портируемости (как в Redis), обеспечивая лёгкую интеграцию через FFI. Пользователь @neomantra создал ds4go — Go-биндинги и TUI-инструменты для загрузки моделей с Hugging Face, упрощая использование ds4 для не-C-разработчиков. Цена MacBook Pro M5 Max с 128 ГБ RAM (~7800 €) делает ds4 доступным лишь для узкого круга пользователей, ограничивая массовое распространение несмотря на технические достижения.

Ollaya — это локальная система для запуска моделей принятия решений, которая возвращает калиброванные ответы на типизированные вопросы за миллисекунды. Она работает на собственном оборудовании, поддерживает TypeSafe-совместимый API и позволяет задавать вопросы о тексте или JSON, получая структурированные ответы с вероятностями и метками риска, разрушительности и т.д. Например, модель decider:2b на RTX 4090 отвечает за 178 мс, а пятивопросный запрос к laya занимает ~10 мс end-to-end через HTTP API.

Модели Ollaya — открытые и включают laya (быстрая, мультиязычная), decider (точность на основе Qwen3.5), von (до 8192 токенов контекста), qwen3guard (безопасность) и другие. Все они работают без генерации токенов — ответ формируется за один проход forward pass. Система совместима с TypeSafe SDK: достаточно указать локальный эндпоинт и ключ, и официальные клиенты работают без изменений. Данные остаются на устройстве — идеально для обработки敏感ной информации вроде писем или тикетов. Ollaya доступна как десктопное приложение, CLI и Docker-образ для macOS, Windows и Linux, с поддержкой NVIDIA GPU через CUDA 13 (драйвер R580+). Установка — одна команда: ollaya run laya. Лицензия Apache-2.0, исходный код на GitHub.

Laya показывает существенно худшую точность по сравнению с Jev (30.25 против 63.29 на jevbench), особенно на сложных запросах, где теряет уверенность и допускает ошибки. Однако она обеспечивает быструю локальную инференцию на слабом железе (например, GTX 970 с 4 ГБ VRAM), что делает её практичной для персонализированного дообучения и использования устаревшего оборудования. Её легко дообучить на собственных данных, что экономически привлекательно для пользователей, готовых потратить время на сбор корпуса. Laya работает приемлемо на простых классификациях (например, 'mans name'), но точность резко падает при усложнении запросов, в то время как Jev сохраняет стабильность. Ollaya — независимый проект, не связанный с Ollama, цель которого — расширять экосистему локальных моделей принятия решений, а не нарушать её. Пользователи отмечают, что примеры Laya слишком узкие (например, 'refund_requested'), и требуется более богатая семантика для реальных сценариев. Jev и Laya оптимизированы для калиброванных вероятностей и RL-обучения, а не являются простыми rerankers. Рекомендуется добавить метрики нулевого выстрела и задержку для объективного сравнения, поддержать CUDA 12, чтобы избежать апгрейда GPU, и рассмотреть использование kime как более быстрого инференс-движка. Некоторые считают, что для многих задач проще дообучить классификатор на собственном eval-наборе, чем использовать Laya/Jev как готовое решение. Также отмечается, что Laya — обёртка вокруг LLM, а не инновация, и что в эпоху LLM большинство «новых» решений — это лишь упаковка существующих подходов. Ollama может добавить поддержку подобных моделей в будущем, что снижает долгосрочную уникальность Laya. Производительность Laya MultiLang vs Laya En остаётся неочевидной — потенциальная область для улучшения.

Kev — это семейство небольших моделей принятия решений, построенных на базе Qwen3.5 и вдохновлённых архитектурой Jev. Доступны версии 0.8B, 4B и 9B параметров, которые можно запускать локально или дообучать под свои задачи. Модели поддерживают три типа запросов: да/нет (noul), множественный выбор (choice) и оценка (score), все они работают с одним входным текстом, но не видят ответов друг друга. API совместим с TypeSafe System One, что позволяет использовать их Python SDK с локальным сервером.

Модели работают на CUDA, ROCm и Apple Silicon (через MLX); 4B и 9B версии помещаются в 32 ГБ памяти Mac. Есть веб-игровая площадка для тестирования ввода и наблюдения за влиянием порядка вариантов на ответы, доступная в Hugging Face Spaces без установки. Для запуска требуется Python 3.12–3.13 и менеджер пакетов uv. В репозитории есть код для обучения, наборы данных для оценки и тесты, включая проверку через TypeSafe SDK. Лицензия — Apache-2.0, как и у базовых моделей Qwen.

Kev и подобные модели применяются в локальных задачах классификации и принятия решений, но их уникальность по сравнению с Jev ставится под сомнение из-за различий в обучении и качестве. Для классификации с малым числом примеров (50–100) рекомендуется использовать Codex/Claude для создания эмбеддингов + логистической регрессии: модель <1MB, обучение на CPU за 5 минут, точность 95%, инференс <100мс, данные остаются локально. Jev-подобные модели на Qwen3.5 не считаются настоящими Jev, так как Jev обучен на RLCD, а Qwen — на RLHF, что влияет на поведение при принятии решений. Jev-подобные модели могут автоматизировать стилистические правила в фронтенде (React, CSS), устраняя дрейф и дублирование, сокращая рутину разработчиков. Модели размером 0.8B–9B подходят для встраивания в игры как «питомцы»: обработка голосовых команд через STT и локальный инференс для выбора действий NPC. Для фильтрации спама такие модели могут заменить 27B-модели, снижая вычислительные затраты при сохранении высокой точности. На Gemma 4 (12B) достигнута задержка 220 мс на шаг в игре Snake на старом ПК, что указывает на потенциал снижения задержки на более мощных машинах. Прокси-слои между Jev и другими API (например, Frontier) сокращают количество вызовов инструментов на 60%, оптимизируя стоимость и производительность. Jev-подобные модели не имеют принципиального отличия от обычных классификаторов, так как их специфичность определяется обучающими данными, а не архитектурой; открытые альтернативы пока уступают по качеству. Для локального использования моделей с ограниченным knowledge cutoff требуется постоянное дообучение или регулярная смена версий, иначе они устаревают. Jev-подобные модели могут использоваться для автоматической разметки данных, но сравнение их качества с Kev в этой задаче пока неясно. Быстрое появление открытых альтернатив Jev в течение недели после релиза свидетельствует о живом интересе сообщества к простым, локальным моделям принятия решений. Создание Jev-подобных моделей на базе Qwen3.5 может упростить внутреннюю логику маршрутизации в системах, но требует проверки надёжности на критических путях.

Ternary Bonsai 2 27B — это улучшенная версия модели на основе Qwen3.8 27B, использующая тернарные веса {−1, 0, +1} с FP16 групповой масштабировкой, достигающая эффективной плотности 1.76 бита на вес и общего объёма модели всего 5.9 ГБ. Это более чем в 9 раз меньше полноценной модели при сохранении 98.2% её агрегатной производительности по бенчмаркам. Модель поддерживает контекстное окно в 262K токенов, multimodal ввод (текст + изображение) и лицензирована под Apache 2.0.

По сравнению с первым релизом Bonsai 27B, новая версия использует более сильную базовую модель (Qwen3.8 27B вместо Qwen3.6), демонстрирует улучшенные результаты в рассуждениях, кодировании, зрении и агентном поведении, особенно в долгосрочных задачах и работе с инструментами. В агрегатном бенчмарке она набирает 83.9 балла против 85.4 у полноценной Qwen3.8 27B, при этом сохраняя сильные стороны в критичных областях: код (81.58), инструменты (77.57), инструкции (82.66) и математика (96.57). Развёртывание поддерживается на NVIDIA GPU через CUDA и на Apple-устройствах через MLX с использованием кастомных низкобитовых ядер. Такой подход позволяет значительно расширить спектр устройств, способных запускать мощные модели локально, снижая энергопотребление и увеличивая плотность полезного интеллекта на единицу памяти.

Тред подтверждает, что Bonsai 2 27B действительно работает на потребительском железе, но с ограниченной скоростью; предоставляет практические инструкции по запуску модели, поднимает вопросы о корректности заявлений «near‐lossless» и о терминологии «9× smaller», а также указывает на ограничения памяти и необходимость поддержки в upstream‐llama.cpp.

• Совет: Для запуска модели требуется форк PrismML‐llama.cpp; инструкция включает загрузку runtime, скачивание GGUF‐файла (~5.95 GB) и запуск сервера с параметрами -ngl 99 -fa on -c 32768.

• На Mac Mini M2 с 16 GB RAM модель генерирует около 7‐8 токенов в секунду (≈60 токенов в предзаполнении) и считается умнее, чем Bonsai 1 27B, хотя размер чуть больше, чем у квантизации Q1_0.

• Тест на MacBook Pro M4 Pro (24 GB) показывает предзаполнение ~100 токенов/сек, затем падение до 15‐10 токенов/сек; локальные агентные задачи всё ещё слишком медленные.

• Запуск на видеокарте с 6 GB памяти даёт лишь 0.67 токенов в секунду, что указывает на необходимость более 6 GB VRAM для комфортной работы.

• Спор: Некоторые комментаторы считают выражение «9× smaller» нелогичным и предлагают вместо него говорить «1/9th the size» или «original is 9× larger», указывая на путаницу в терминологии.

• Спор: Критика качества: пользователь redox99 утверждает, что заявленная «near‐lossless» компрессия не соответствует реальности, а логика вывода модели отличается от оригинального 27 B.

• Совет: Пользователи просят добавить официальную поддержку в upstream‐llama.cpp, чтобы упростить запуск без форков и улучшить совместимость с различными платформами.

• Совет: Модель достаточно мала, чтобы её можно было запустить полностью в браузере через WebGL/WebGPU, как показал пользователь Aurornis.

• Совет: Отсутствие сравнения с другими квантизациями (например, Q2 или Unsloth) отмечено как недочёт; авторы могут добавить бенчмарки для более объективной оценки.

• Совет: По мнению blactuary, модель лучше всего подходит для задач программирования, а не для генерации изображений или общего знания.

I really wish people would stop saying N times smaller than something when making a comparison; that makes no sense - it's 1/9th (11.11%) the size. You don't get a smaller quantity by multiplying by a number greater than 1.0. — @miffy900

NVIDIA представила CUDA Rust — набор инструментов для написания GPU-ядер на Rust, устраняя необходимость использовать другие языки для ядер, даже если остальная часть стека уже на Rust. Поддерживаются две модели программирования: SIMT (как в CUDA C++), где разработчик указывает действия одного потока, и Tile — более абстрактная модель, где описывается обработка блока данных, а компилятор сам определяетMapping на архитектуру. Tile рекомендуется как отправная точка благодаря переносимости, а SIMT оставлен для случаев, требующих низкоуровневого контроля.

Для SIMT доступен проект cuda-oxide — собственный бэкенд rustc, который компилирует функции с атрибутом #[kernel] в PTX через MIR, Pliron и LLVM. Для Tile — cutile-rs, предоставляющий Rust-биндинги к cuTile API. Оба примера демонстрируют поэлементное сложение 1024 float-значений и выводят одинаковый результат. Требуются Linux, GPU с compute capability ≥8.0, CUDA Toolkit 12.x+, clang и зафиксированная ночная цепочка Rust. Инструменты проверяются через cargo oxide doctor. Документация, примеры и ссылки на репозитории доступны в блоге NVIDIA, а также планируется доклад на RustConf 2026. Interoperability с другими языками остаётся приоритетом.

Обсуждение подтверждает, что CUDA Rust может снизить сложность написания GPU-ядер, но вызывает опасения по поводу вендор-локкита, стабильности pre-1.0 инструментов и качества официальных анонсов.

• Спор: Некоторые считают CUDA вредным из-за вендор-локкита и требуют открытых альтернатив вроде Metal/OpenCL, другие утверждают, что CUDA — лучший GPGPU API на данный момент, и критика его только замедляет прогресс в UX.

• Спор: Один участник критикует ручной запуск ядер как ошибко-чувствительный и трудоёмкий, а другой отмечает, что компиляторная проверка и единое выражение для запуска ядра — ключевое преимущество CUDA, а не просто артефакт C++.

• Совет: Пользователи с опытом в CUDA отмечают, что CUDA Rust требует nightly Rust и pre-1.0 инструментов, что делает его нестабильным для продакшена и усложняет отладку из-за множества слоёв (Rust, cuda-oxide, CUDA, Tile).

• Многие согласны, что Rust для GPU-программирования — важный шаг вперёд, особенно для повышения надёжности кода ядер и уменьшения боли от отладки по сравнению с CUDA C++.

• Отмечается, что NVIDIA открыла CUDA Tile IR, что делает проект частично открытым, и это воспринимается как позитивный сигнал, несмотря на критику вендор-локкита.

• Совет: Опытные разработчики предупреждают, что использование CUDA Rust может привязать код к NVIDIA, если не использовать абстракции, и советуют оценивать альтернативы вроде rust-gpu или WebGPU.

• Поддержка Rust в GPU-программировании усиливается трендами: интеграция Rust в Linux-ядро, использование Rust в Amazon/Microsoft для верифицированного ПО и рост популярности Candle от Hugging Face.

• Спор: Некоторые критикуют стиль анонса NVIDIA как 'автоматически сгенерированный Claude', считая это признаком безразличия команды, в то время как другие воспринимают это как норму для корпоративных анонсов.

• Совет: Пользователь с опытом в WGPU и cudarc отмечает, что CUDA-oxide позволяет делить структуры между хостом и устройством, но требует перехода на экспериментальный диалект, что может быть риском.

• Несколько участников отмечают, что CUDA Rust — это шаг в правильном направлении, особенно для Rust-экосистемы, и благодарят NVIDIA за поддержку, несмотря на прошлые проблемы с Linux.

• Спор: Один участник спрашивает, можно ли использовать CUDA Rust для WebGPU/Vulkan, а другой отвечает, что это нецелевое использование — CUDA Rust ориентирован на CUDA-совместимые GPU, а не на веб-стандарты.

• Совет: Пользователь с опытом в GPU-программировании отмечает, что несоответствие порядка элементов в примерах (a,b,c vs z,x,y) указывает на непоследовательность в API, что может ввести в заблуждение новичков.

Nvidia стала центральным банком искусственного интеллекта, контролируя доступ к вычислительным ресурсам, необходимым для обучения и запуска моделей ИИ. Её графические процессоры (GPU) доминируют на рынке, обеспечивая более 90% вычислительной мощности в дата-центрах, используемых для ИИ. Это положение позволяет Nvidia влиять на темпы развития всей отрасли: компании и исследователи зависят от её чипов, как банки от центрального банка — от доступа к ликвидности. Спрос на её продукцию вырос настолько, что сроки поставок достигли года, а цены на некоторые модели выросли втрое за два года.

Контроль Nvidia распространяется не только на hardware, но и на программную экосистему через CUDA — платформу, которая стала отраслевым стандартом. Переход на альтернативные архитектуры крайне сложен и дорог, что создаёт эффект блокировки. Компания активно инвестирует в следующее поколение чипов, таких как Blackwell, и в облачные сервисы, чтобы укрепить своё положение. Критики предупреждают о рисках монополии, но пока ни один конкурент не смог предложить сопоставимую комбинацию производительности, программной поддержки и масштаба производства. В результате Nvidia не просто поставляет чипы — она определяет, кто и как будет развивать ИИ в ближайшие годы.

Nvidia не создаёт деньги, а перенаправляет существующий капитал от инвесторов (BX, Apollo), и её обязательства в $500 млрд — это долговые или долевые обязательства, не эквивалентные эмиссии ФРС. Её власть основана на контроле над капитальными вложениями и зависимости клиентов от GPU, что создаёт системные риски для рынка и инфраструктуры. Падение акций Nvidia может вызвать кредитный кризис: она входит в 12% фондов NASDAQ и 8% S&P 500, и её обвал спровоцирует массовые продажи и панику. Nvidia не контролирует ставки и не может монотонно расширять предложение чипов — она ограничена физическими и производственными ограничениями, поэтому сравнение с ФРС некорректно. Компании вроде OpenAI и Anthropic публично призывают замедлить развитие ИИ, что указывает на отсутствие дальнейшей экономической выгоды и риск непокрытых инвестиций Nvidia при банкротстве клиентов. Финансирование со стороны Nvidia — это привлечение частного капитала под будущие доходы, а не инфляционная эмиссия без обеспечения. Если GPU, работающие 24/7 на инференсе, выходят из строя быстрее 5 лет (срок амортизации), это создаст кризис замены и перерасходы, не учтённые в бухгалтерских моделях. Nvidia ушла от публикации отдельной отчётности по игровому рынку — сигнал подготовки выхода из сегмента, что может подорвать экосистемы разработчиков и издателей. Гиперскалеры (Amazon, Google, Meta, Microsoft) — половина клиентов Nvidia — строят собственные чипы для инференса, чтобы избежать «налога Дженнсена», угрожая долгосрочной модели продаж Nvidia. Nvidia действует как исламский банк: участвует в прибыли и риске, не беря процентов — если ИИ-бабл лопнет, она останется с неиспользуемым оборудованием. Вендор-финансирование в технологиях — классический механизм поддержания пузыря: когда финансирование прекратится, рынок рухнет, а инвестиции окажутся непокрытыми. Если частный кредит, финансирующий ИИ-проекты, начнёт требовать доходности, а прибыль не появится, это вызовет кризис капитального цикла — перепроизводство мощностей без спроса. Nvidia — центральный банк не ИИ, а дата-центров: её бизнес-модель требует создания инфраструктурных проектов для продажи GPU, и она финансирует именно эти проекты, а не технологии.

Главная идея – выявление острова по геометрии трёх земельных объектов на снимке. Сначала определяют координаты трёх точек (остров, правый и левый островки) через GUI‑кликер, затем сравнивают их форму с реальными полигонами земельного покрытия, отфильтровав всё, что не подходит по широте, плотности и кластеру.

Ключевые факты

• В снимке видны три земные массы: P0 – сам остров, P1 – правый островок, P2 – левый передний с горой.
• При поиске использованы глобальные полигоны land‑polygons‑split‑4326 (≈ 882 МБ), отфильтрованы по тропикам (‑30° ≤ широта ≤ 30°), затем отсеяны участки с более чем 10 соседями в 5 км и оставлены только кластеры из минимум трёх точек на расстоянии ≤ 20 км.
• Последний оставшийся полигон совпадает с островом Oan (остров в Палау), координаты ≈ 7° 21′ 48.4″ N, 151° 45′ 20.7″ E (7.363444, 151.755750).
• На снимке камера смотрит на север‑запад (θ ≈ 325°), что подтверждается вычислением азимута между P0 и P1.

Запомните: тропический диапазон, ограничение по количеству близких соседей и поиск кластеров из трёх близких точек – это то, что превращает геометрию фото в реальное место.

Метод геолокации по топографии (TERCOM) — проверенная военная технология с 1960-х годов, независимая от RF-помех, позже использованная NASA JPL для точной посадки Mars 2020. Аналогичные подходы terrain matching применяются в критически важных системах. OpenStreetMap ценен для OSINT-геолокации в населённых зонах благодаря детализации объектов. Геолокация без GPS возможна через анализ визуальных паттернов ландшафта — как в Geoguessing, где эксперты опираются на данные Google Earth. Современные системы, включая Palantir, вероятно, используют не только геометрическое сопоставление, но и модели компьютерного зрения, обученные на миллиардах геолокированных изображений. Для повышения точности требуется доработка фильтра «eyeball halo»: текущие топ-кандидаты не проходят визуальную проверку. Учёт приливов важен — они могут искажать контуры островов, что не учитывалось в статье. Технология — не новинка, а эволюция старых решений, демонстрирующая, как ограничения прошлого порождали надёжные инженерные подходы. Использование CUDA и геометрического анализа позволяет воссоздать ручные методы с помощью современных вычислений. Споры возникли вокруг иронии публикации метода после статьи о предотвращении технологий для полицейского государства — некоторые считают, что любая технология может быть использована в таких целях. Также есть сомнения в аутентичности кода: комментаторы предполагают его генерацию LLM, несмотря на заявление автора, поскольку стиль не соответствует Pangram. Использование визуальных паттернов и карт для геолокации — это не только технический приём, но и форма цифрового любопытства, вдохновляющая на изучение географии и программирования.

Сегодня анонсирован Bonsai 27B — модель на 27 млрд параметров, основанная на Qwen3.6 27B, впервые способная полностью работать на смартфоне. Существует две версии: трёночная (ternary) с весами {−1,0,+1} и 1‑битовая, использующие групповой масштабирование FP16. Трёночная модель занимает 5,9 ГБ, 1‑битовая — 3,9 ГБ и помещается в память iPhone 17 Pro, при этом сохраняет весь набор функций: мультишаговое рассуждение, вызов инструментов, агентные циклы и мультимодальный vision‑токен. Оба варианта поддерживают 262 K‑токенный контекст, спекулятивное декодирование и полностью работают в низкой точности без перехода в более высокие форматы.

По оценкам на 15‑балльном наборе тестов, включая математику, программирование, вызовы инструментов и визуальные задачи, трёночная версия удерживает 95 % точности полной модели, а 1‑битовая — 90 %. Показатель «интеллектуальной плотности» достигает 0,53 единиц на гигабайт, в 10 раз превышая полноразрядный аналог и в 2,7 раза лучше лучших традиционных низко‑битовых схем. 1‑битовый вариант почти не отстаёт от полной версии в задачах рассуждения и кодирования, а его память в 2,5 раза меньше, чем у самых агрессивных обычных низко‑битовых построек. Весь набор весов доступен по лицензии Apache 2.0, поддерживается MLX на Apple‑устройствах и CUDA на NVIDIA‑GPU, а бесплатный API‑превью уже открыт для разработчиков.

• Bonsai 27B с квантованием до 1–1.58 бит показывает впечатляющую производительность на CPU и мобильных устройствах, конкурируя с более крупными моделями.
• Пользователи отмечают значительное падение в задачах вызова инструментов и странности в ответах (например, неверные макронутриенты), что ставит под сомнение практическую надёжность.
• Инфраструктура для инференса на CPU (llama.cpp, bitnet.cpp) пока не оптимизирована для тернарных моделей, что снижает скорость по сравнению с Q4-квантованными аналогами.
• Мнения разделились: одни видят в этом сдвиг парадигмы к локальным ИИ, другие считают результаты переоценёнными или искусственными, особенно из-за сильного квантования.
• Открытые модели доступны на Hugging Face, но многие инструменты (LM Studio, Ollama) пока не поддерживают их, требуя обновлений или кастомных сборок.

Google TPU возник в 2013 году из расчёта: если каждый пользователь Android задействует voice search по 3 минуты в день, компании придётся удвоить мощности дата-центров. Стандартные CPU и GPU не справлялись с матричной математикой глубокого обучения, поэтому Google создал ASIC для TensorFlow. Проект прошёл от концепта до деплоя за 15 месяцев (2013–2014), к 2015 TPU уже ускоряли Maps, Photos и Translate, а в 2016 их анонсировали на I/O.

В отличие от универсальных GPU с «багажом» (кеширование, ветвления, текстуры), TPU — доменно-специфичный чип с systolic array: данные (веса) загружаются раз, проходят через сетку умножителей без возврата в память, минимизируя Von Neumann bottleneck и HBM-доступы. Новый Ironwood усилил SparseCore для эмбеддингов (рекомендации, LLM) и расширил HBM. TPU — ключевое преимущество Google Cloud на 10 лет, с фокусом на inference; обсуждаются производство, сравнения с GPU и влияние Gemini 3.

• Google's TPUs лидируют в эффективности inference и масштабе благодаря systolic array, OCS interconnects и низкой стоимости эксплуатации по сравнению с Nvidia GPUs.
• Скепсис по поводу исполнения Google: слабая экосистема (JAX/TF vs CUDA), история провалов продуктов и зависимость от ad-бизнеса.
• Nvidia доминирует за счёт универсальности, CUDA и оптимизаций (NVLink, NVFP4), несмотря на "architectural baggage".
• Упоминания альтернатив (Groq, Cerebras, Meta покупает TPU) и рисков: новые архитектуры AI могут устареть hardware, фокус на inference vs training.
• Google имеет ресурсы для доминирования через vertical stack и cloud, но короткий "attention span" вызывает сомнения.

AMD заключила сделку с OpenAI о поставках чипов для искусственного интеллекта, предоставив также опцион на приобретение 10% доли в компании. Это стратегическое партнёрство усиливает позиции AMD на рынке AI-чипов, где доминирует NVIDIA, и обеспечивает OpenAI доступ к передовым аппаратным решениям для разработки и масштабирования своих моделей.

Опцион на долю демонстрирует глубокую интеграцию интересов: AMD получает ключевого клиента и потенциального инвестора, а OpenAI — влияние на поставщика и приоритетный доступ к технологиям. Это может ускорить инновации в области аппаратного обеспечения для ИИ и снизить зависимость от единственного поставщика.

• AMD предоставила OpenAI опцион на покупку 10% своих акций по цене $0.01 за акцию при выполнении определенных условий
• Сделка призвана стимулировать OpenAI к закупкам GPU AMD на сумму до $100 млрд и совместной разработке ПО для AI-чипов
• Рыночная капитализация AMD выросла примерно на $100 млрд после анонса, что частично компенсирует стоимость опциона
• Многие участники обсуждения расценивают сделку как признак финансового пузыря и циркулярных денежных потоков в AI-индустрии
• Партнерство рассматривается как стратегический ход для создания альтернативы доминированию NVIDIA и CUDA

Что такое GPU
Современная ML-GPU (H100/B200) — это ~100–150 независимых вычислительных блоков (SM), каждый из которых содержит матричное ядро Tensor Core, векторные ALU (CUDA-ядра) и 256 КБ кэш SMEM. Все SM делят общий L2 и HBM3-память. SM разбит на 4 подблока; каждый подблок выполняет 32 SIMD-операции за такт. GPU-ядро менее мощное, чем TPU TensorCore, но их много, поэтому общая гибкость выше.

Память
H100: 80 ГБ HBM3, 3 ТБ/с. B200: 192 ГБ, 8 ТБ/с. L2 кэш 50 МБ (H100) / 128 МБ (B200). SMEM даёт 256 КБ на SM.

GPU vs TPU на уровне чипа
TPU: 1–2 больших MXU, жёсткая синхронизация, векторная часть слабее. GPU: 100+ мелких ядер, независимые SM, но общий L2 ограничивает масштаб. GPU лучше для разнородных задач, TPU — для чистых матмул.

Сеть внутри узла
Узел = 8 GPU + 2 CPU. GPU соединены NVLink/NVSwitch (900 ГБ/с между любыми двумя). CPU-GPU идут через PCIe 5.0 (64 ГБ/с). NVSwitch-кроссбар внутри узла = полносвязная сеть.

Сеть за пределами узла
InfiniBand HDR/NDR (до 400 Гб/с) или Ethernet RoCE. GPUDirect RDMA позволяет GPU читать/писать память соседнего узла без участия CPU.

Коллективные операции
Intra-node: NCCL использует NVLink; all-reduce 8×H100 за ~3 мкс.
Cross-node: кольцо IB + NVLink; latency ~10 мкс, bandwidth лимит IB.

Roofline-модель для LLM

• Data Parallelism: ограничен IB; эффективен при малых моделях.
• Tensor Parallelism: ограничен NVLink; лучше внутри узла.
• Expert/ Pipeline Parallelism: комбинируем; pipeline глубже → меньше bubble, но больше весов на каждом GPU.
• TLDR: держи параллелизм так, чтобы IB не стал bottleneck; используй NVLink для tensor-parallel, IB для data-parallel.

Итого
GPU — это масса мелких, независимых SM, связанных быстрым NVLink внутри узла и медленным IB между узлами. Для LLM выбирай параллелизм, который минимизирует IB-трафик и максимально использует NVLink.

• Критика точности: документация местами неточна, особенно в определении «CUDA-core».
• Открытость и вендор-лок: ряд участников считают инвестиции в проприетарную экосистему NVIDIA рискованной ставкой.
• Ошибка в расчётах: Quiz 2 преувеличивает пропускную способность; реальные 3,2 ТБ/с ограничены портами NIC.
• Похвала и польза: серия всё же хорошо объясняет принципы параллелизма, применимые и к другим устройствам.
• Сравнение TPU и GPU: TPU проще масштабировать, но закрыт для продажи; GPU NVIDIA гибче, но сложнее в программировании.
• Дефицит официальных данных: NVIDIA не раскрывает полную архитектуру, поэтому полезные модели приходится собирать из сторонних источников.

Framework Desktop — компактный 4,5-литровый ПК, который почти не шумит даже под полной нагрузкой. Внутри — мобильный AMD Ryzen AI Max 395+ (16 ядер Zen5, 5,1 ГГц), и он оказывается быстрее старого Ryzen 9 7950X в большом корпусе.

Корпус разукрашивается 21 сменной плиткой, можно печатать свои. Внешне — свежий минимализм вместо алюминия и RGB.

По производительности:

• Docker-тест HEY: почти вдвое быстрее Beelink SER8 и на 40 % опережает M4 Max.
• Geekbench 6 multi-core: на уровне M4 Max, заметно выше M4 Pro и Core i9-14900K.
• Одноядерка уступает Apple ≈20 %, но для многопоточных задач это лидер.

Цена выше, чем у Beelink, но пока это единственный безвентиляторный 395+ на рынке.

• Framework Desktop с Ryzen AI Max+ 395 даёт 64–128 ГБ единой памяти, позволяя запускать крупные LLM без дискретной видеокарты и дешевле, чем Mac Studio, но дороже Mini.
• Производительность ниже CUDA-карт Nvidia и M4 Max, зато выше, чем у iGPU Intel и старых решений.
• Многие сомневаются в цене и форм-факторе: за те же деньги можно взять Minisforum, Beelink, HP Z2 Mini или собрать полноценный десктоп.
• Пока CUDA-стека нет, AMD-совместимость с популярными AI-фреймворками ограничена.
• Ремонтопригодность и модульность Framework оценили, но в десктоп-сегменте это не уникально.