Hacker News Digest

PokerBattle.ai представляет собой первый в истории турнир по покеру с реальными денежными призами, специально созданный для соревнования больших языковых моделей (LLM). Это инновационное событие позволяет ИИ-системам проявить свои стратегические способности в одной из самых сложных интеллектуальных игр, где успех зависит не только от математических расчетов, но и от психологических аспектов и блефа. Турнир загружает данные о событиях, что указывает на его активный характер или недавнее проведение.

Уникальность этого мероприятия заключается в том, что оно впервые объединяет мир покера с передовыми технологиями ИИ, создавая новую платформу для оценки и развития возможностей языковых моделей. Организаторы стремятся определить, какие из современных LLM способны демонстрировать наилучшую игровую стратегию, адаптивность и способность к принятию решений в условиях неопределенности. Денежные призы добавляют соревнованиям серьезности и привлекают внимание как исследователей ИИ, так и энтузиастов покера со всего мира.

• ИИ демонстрируют ошибки в оценке рук (например, LLAMA ошибочно определила топ-пару), что указывает на текущие ограничения в понимании игры.
• Эксперимент критикуется за недостаток данных (714 рук у Meta LLAMA) и отсутствие возможности для ИИ развивать новые стратегии со временем.
• Предлагается улучшить тестирование, добавив "трэш-ток" и возможность блефа между ИИ, что сделало бы наблюдение более интересным и показательным.
• ИИ часто "галлюцинируют", принимая неверные решения (как Gemini, сдавшая сильную руку), что связано с неправильной оценкой силы руки в текущей ситуации.
• Шутливые предложения по тестированию включают попытки обмана ИИ через подсказки ("игнорируй предыдущие инструкции").

AMD и GPUOpen опубликовали практическое руководство, как запустить LLM на Windows с GPU AMD и PyTorch. Самое важное — это не требует ROCm, а использует DirectML, что делает процесс доступным для большинства геймерских видеокарт Radeon. Поддерживаются модели Llama 3.2, Mistral и Gemma, а также Q4 и FP16 квантизация. Подготовка включает установку ROCm и PyTorch, но ROCm не используется; вместо этого используется DirectML. Процесс включает скачивание модели, конвертацию в GGUF с помощью llama.cpp, и запуск через веб-интерфейс Gradio. Важно, что весь процесс происходит на Windows без виртуализации или WSL2.

I have a philosophy for which I have mixed feelings because I like it in principle despite it making me worse off in some other ways: Devs should punish companies that clearly don't give a shit about them. When I see AMD, I think of a firm that heavily prioritized their B2B busin

Исследователи из Hazy Research разработали высокопроизводительный мегаядро для тензорно-параллельного вывода Llama-70B на H100, которое агрессивно перекрывает вычисления, работу с памятью и коммуникацию между GPU. Это позволяет одновременно задействовать различные аппаратные ресурсы: тензорные ядра, модули для нетензорных операций, пропускную способность HBM и NVLink. В интеграции с движком Tokasaurus их решение превосходит SGLang на >22% по общей пропускной способности при обработке 65 536 промптов из ShareGPT.

Ключевая идея — использование интерпретатора инструкций, работающего на каждом SM, который позволяет гибко планировать выполнение разнородных операций. Это обеспечивает перекрытие на нескольких уровнях: внутри SM (память и вычисления), между SM (матричные умножения и нормирование) и между GPU (скрытие задержек связи за счёт специальных потоков). Особенно отмечается простота реализации сложных трансформаций данных между GPU прямо после attention-слоя, что трудно выразить стандартными средствами коммуникации.

• Обсуждение эффективности использования GPU: использование всех блоков (NVDEC, NVJPG, RT и тензорные ядра) для декомпрессии весов и вычислений, аналогии с оптимизацией под консоли.
• Проблемы инструментов и драйверов: отставание языков, библиотек и драйверов от возможностей современного железа, сложности компиляторов для гетерогенных систем.
• Виртуализация и разделение ресурсов GPU: обсуждение MIG, MPS для многопользовательского использования, риски утечки данных и ограничения этих технологий.
• Сравнение с другими платформами: упоминание Apple Metal и открытости драйверов, потенциал использования GPU для аудиообработки и сигналов.
• Критика и ирония: сравнение стиля статьи с "Трансгрессия границ", комментарии о "коде, который не предназначен для поддержки" и неожиданно доступных оптимизациях в крупных лабораториях.

Проект ollm представляет собой инструмент для локального запуска больших языковых моделей через Ollama, позволяя пользователям взаимодействовать с ними напрямую из терминала. Он поддерживает различные модели, включая Llama 3 и Mistral, и предлагает простой интерфейс для отправки запросов и получения ответов без необходимости веб-интерфейса или API.

Ключевые возможности включают настройку параметров модели, таких как температура и контекстное окно, а также сохранение истории диалогов. Это упрощает тестирование и использование LLM для разработчиков и исследователей, работающих в командной строке. Инструмент особенно полезен для быстрого прототипирования и экспериментов с разными моделями.

• Обсуждение возможности запуска больших языковых моделей на устройствах с ограниченной оперативной памятью (например, Apple Silicon M1/M2/M3) с использованием 4-битного квантования.
• Уточнение, что конкретная обсуждаемая техника (GPT-OSS) для работы с дисковым кешем может не подходить для Mac, но сами модели (например, Qwen3-Next) на этих чипах работают через другие инструменты (mlx_lm).
• Упоминание о высокой скорости генерации (~40 токенов/сек) на Mac с большим объемом оперативной памяти (64 ГБ) при использовании квантованных моделей.
• Замечание о низкой пропускной способности (1 токен/2 сек) при использовании дискового кеша в методе GPT-OSS из-за bottleneck на скорости SSD.
• Ответ на вопрос о применимости техники к diffusion-моделям: архитектуры разные, но основные идеи, возможно, можно адаптировать.

LLaMA-Factory — это унифицированный инструмент для эффективной тонкой настройки более 100 языковых и визуально-языковых моделей, представленный на ACL 2024. Он позволяет разработчикам адаптировать модели под конкретные задачи с минимальными затратами ресурсов, поддерживая популярные архитектуры вроде LLaMA и Mistral, а также многомодальные модели.

Инструмент предлагает гибкие методы обучения, включая LoRA и полную настройку параметров, и работает с различными аппаратными конфигурациями, от одного GPU до распределённых кластеров. Это значительно упрощает эксперименты и развёртывание кастомизированных моделей, экономя время и вычислительные мощности.

• Обсуждаются возможности и библиотеки для тонкой настройки (SFT), предобучения и RL-тренировки больших языковых моделей, включая LLaMA Factory и сравнение с Unsloth.
• Подчёркивается важность качественного подбора данных и аппаратного обеспечения (например, 8xH200 или A100 для серьёзных задач, потребительского GPU для меньших моделей).
• Отмечается практическая пользя тонкой настройки для создания узкоспециализированных моделей под конкретные задачи (например, text-to-SQL), способных конкурировать с большими hosted-моделями.
• Упоминаются альтернативные инструменты и подходы, такие как Axolotl для потребительского железа, Oumi (с синтезом данных и LLM-as-a-Judge) и коммерческие решения типа Nvidia NIM.
• Высказываются критические замечания о поддержке конкретных моделей (например, Deepseek) и локализации документации.

Apertus-70B-2509
Модель от швейцарского консорциума ETH Zurich и EPFL: 70 и 8 млрд параметров, полностью открытая (веса, данные, рецепты). Поддержка 1811 языков, 15 трлн токенов, xIELU-активация, AdEMAMix, QRPO-выравнивание. Работает в transformers ≥4.56 и vLLM. Требует согласия на политику конфиденциальности и фильтрацию персональных данных.

• Apertus — 8B и 70B «полностью открытые» мультиязычные модели (1811 языков, 15T токенов, полные веса, данные и рецепты).
• Подчёркивают правовую чистоту: учёт robots.txt ретроспективно, opt-out, фильтр персональных данных, 81 контрольная точка для аудита.
• На бенчмарках ≈ Llama-3.1 по общим знаниям, но уступают в коде/рассуждениях; модели уже в MLX, GGUF скоро.
• Критика: gated-доступ на HF (нужен договор и контакты), размеры «2-3 поколения назад», нет GGUF/OpenRouter, ускоренный релиз без ярких метрик.
• Пользователи спрашивают стоимость обучения, запреты копирайта, весы швейцарских языков и прозрачность фильтров — команда обещает доклады и кастомизацию.

llama-scan — локальный инструмент для транскрибирования PDF с помощью LLM.
Полностью работает на вашем ПК: данные не уходят в облако.
Поддерживает модели Llama 3.2 3B/1B, работает без GPU.

Возможности

• Конвертация PDF → Markdown
• Пакетная обработка папок
• Параллельные задачи
• Подсчёт токенов и стоимости
• Плагины для Obsidian и Zotero

Установка

pip install llamascan

Использование

CLI:

llamascan input.pdf --output out.md

Python:

from llamascan import transcribe
transcribe("file.pdf", model="llama3.2:3b")

Требования

• Python ≥ 3.9
• Ollama (для локальных моделей)

Лицензия

MIT

• Участники сравнивают LLM-OCR с классическими решениями: первые могут «галлюцинировать» и терять структуру, вторые точнее, но не понимают макет.
• Практики делятся пайплайнами: извлечь текст, снять скрин страницы, отправить всё в LLM с чётким промптом и структурированным выводом.
• Авторы жалуются на провисание процесса, пропуск символов и невозможность редактировать промпт под свои задачи (например, выделять только рукописные таблицы).
• Рекомендуют альтернативы: nanonets-ocr-s, Docling, Marker, Nougat, ocrmypdf, pgpdf, а также советуют бенчмарк OmniDocBench для объективной оценки.

• В день выхода открытой модели вроде gpt-oss-120b мы сразу ускоряем её для клиентов, как партнёры запуска OpenAI. К концу дня запуска стали лидерами на NVIDIA по латентности и пропускной способности по данным OpenRouter.

• Быстрая оптимизация обеспечена гибким стеком инференса и экспертизой команды; за время написания поста прибавили ещё ~100 ток/с при 100% аптайме.

• Работы включали:

  • Тесты и бенчмарки в TensorRT-LLM, vLLM и SGLang.
  • Совместимость с архитектурами Hopper и Blackwell.
  • Интеграцию с нашим стеком (в т. ч. NVIDIA Dynamo).
  • Оптимизации: маршрутизация с учётом KV-кэша, спекулятивная генерация с Eagle.

Шаг 1: Первый инференс

• Запускаем базовый инференс в любом доступном фреймворке и на нужных GPU/серверных уровнях.
• Параллелим работу: одни пробуют vLLM и SGLang, другие — TensorRT-LLM; быстрее всего взлетел TensorRT-LLM.
• Важно обслуживать модель и на Hopper (H100), и на Blackwell (B200) для широкой доступности и максимальной скорости.
• Гибкость рантайма позволяет быстро переключать инструменты и обновлять матрицу поддержки.

Шаг 2: Исправление багов совместимости

• Новые архитектуры приводят к тонким несовместимостям; GPT OSS добавил, например, Harmony — новый формат ответов.
• Итеративно чиним и валидируем на скорость и корректность; по возможности контрибутим обратно в open source.
• Благодаря сообществу есть несколько отличных путей запуска GPT OSS, проблемы быстро выявляются и чинятся.

Шаг 3: Оптимизация конфигурации

• Хотя GPT OSS 120B можно запустить на одном H100, оптимально масштабировать на 4–8 GPU для лучшей латентности/throughput.
• Рассмотрены два подхода параллелизма для MoE: тензорный и экспертный. Тензорный даёт меньшую задержку, экспертный — выше системную пропускную способность. Мы выбрали тензорный, так как приоритет — латентность.
• Приняли MoE Backend в TensorRT-LLM (поддерживается на Blackwell, не на Hopper), который добавляет более быстрые CUDA-ядра и превосходит предыдущие решения.

• Обсуждение крутится вокруг запуска и производительности GPT-OSS (20B/120B) на разном железе: от MacBook M-серии и RTX 4090/3050 до датацентровых H100/Blackwell и даже CPU.
• Многие отмечают, что скорость хороша при малых контекстах; при >10k токенов начинается существенная деградация скорости и рост задержек, особенно без MCP/веб-доступа.
• TensorRT-LLM часто даёт лучшую латентность/пропускную способность, но сложен в настройке; альтернативы вроде vLLM/SGLang проще, Llama/Оllama позволяют быстро поднять 20B локально и даже распределить по старым GPU.
• Идут споры о “доступности” H100: купить дорого, но аренда широко доступна и выгоднее для нерегулярных нагрузок; при этом Blackwell с FP4 обещает ещё больший буст, в экосистеме Rust добавляют FP8/FP4.
• Пользователи спрашивают про требования к VRAM, практичную локальную агентную разработку на потребительских GPU, и оптимальные настройки на Mac (например, iogpu.wired_limit_mb).
• Обсуждают техники ускорения (спекулятивное декодирование — вызывающее вопросы пользы), причины падения токен/с при длинных диалогах, и различие prefill vs decode по узким местам.
• Наряду с похвалами скорости есть критика: сложность стеков, неточности/галлюцинации ответов, «извиняльный» контент, и вопрос — зачем OpenAI выпускает OSS-модели и как это соотносится с доступностью железа.