Hacker News Digest

Unsloth теперь поддерживает обучение с подкреплением для OpenAI gpt-oss и всех типов моделей, что значительно ускоряет процесс тонкой настройки. Это позволяет эффективно применять методы RL, такие как DPO, ORPO и KTO, для улучшения качества генерации текста и рассуждений модели.

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

• Благодарность Unsloth за реализацию режима сна в vLLM, упрощающего RL-обучение и делающего его более доступным.
• Споры о качестве модели GPT-OSS: одни пользователи считают её устаревшей, другие приводят примеры её эффективности в конкретных задачах.
• Обсуждение практической пользы дообучения моделей для бизнеса и локального использования, включая работу с редкими языками.
• Акцент на демонстрации в релизе Unsloth методов борьбы с читерством (reward hacking) в reinforcement learning.
• Упоминание инструмента DeepFabric для генерации данных в формате OpenAI.

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, ускоренный релиз без ярких метрик.
• Пользователи спрашивают стоимость обучения, запреты копирайта, весы швейцарских языков и прозрачность фильтров — команда обещает доклады и кастомизацию.

• Участники обсуждают, что описанный метод напоминает beam-search, но без прямого упоминания.
• Подчёркивается: высокая производительность (DeepConf-low) достигается за счёт 512 сэмплов, что требует ресурсов уровня enterprise и не подходит для локальных моделей.
• Автор блога подтверждает: текст сгенерирован LLM, затем вручную проверен; метод можно запустить и на слабом GPU через vLLM.
• Пользователи требуют явной маркировки «LLM output» и сравнивают подход с понижением температуры.

• В день выхода открытой модели вроде 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-модели и как это соотносится с доступностью железа.