Hacker News Digest

Тег: #inference

Постов: 5

ChunkLLM: A Lightweight Pluggable Framework for Accelerating LLMs Inference (arxiv.org)

Представлен ChunkLLM - легковесный подключаемый фреймворк для ускорения инференса больших языковых моделей. Основная проблема - квадратичная сложность механизма self-attention в Transformer, что приводит к вычислительным неэффективностям. Авторы предлагают двухкомпонентную систему: QK Adapter (для сжатия признаков и получения чанк-внимания) и Chunk Adapter (для обнаружения границ чанков с использованием семантической информации). Во время обучения основная модель остается замороженной, тренируются только адаптеры.

Эксперименты показали, что ChunkLLM сохраняет 98.64% производительности на бенчмарках с длинным контекстом, при этом достигая ускорения до 4.48x при обработке текстов длиной 120K токенов по сравнению с базовым Transformer. Ключевое преимущество - выбор чанков происходит только при обнаружении границы, что значительно ускоряет инференс. Фреймворк демонстрирует сопоставимые результаты на коротких текстах и сохраняет 48.58% ключевого кэша.

by PaulHoule • 24 октября 2025 г. в 11:41 • 84 points

ОригиналHN

#transformer#self-attention#llm#inference#attention-mechanism#machine-learning#natural-language-processing#arxiv

Комментарии (6)

  • Контекст 30k+ токенов становится нормой, но при этом требуется 4× ускорение без значимой потери качества.
  • Модульная, «железо-ориентированная» архитектура становится трендом: LLM-фреймворки стремятся к эффективности и низким вычислительным затратам.
  • Стоит ли жертвовать 2% качества ради 4× ускорения? Да, если речь идет о длинном контексте.
  • Развитие идет в сторону мелких, легковесных решений, которые можно встроить в реальные приложения.

Intel Announces Inference-Optimized Xe3P Graphics Card with 160GB VRAM (phoronix.com)

Intel анонсировала новый графический процессор "Crescent Island", оптимизированный для задач искусственного интеллекта. Эта модель, основанная на архитектуре Xe3P, оснащена 160 ГБ памяти LPDDR5X. Она специализирована на эффективное выполнение задач логического вывода (inference) с акцентом на производительность на ватт, что делает её привлекательной для центров обработки данных.

Ключевой особенностью является оптимизация под большие языковые модели (LLM): объёмная память позволяет хранить и обрабатывать модели непосредственно на устройстве, снижая задержки. Система использует воздушное охлаждение, что снижает общую стоимость владения.

Производство начнётся не раньше второй половины 2026 года, что оставляет время для доработки программного обеспечения. В частности, Intel уже работает над улучшением своей открытой программной экосистемы для этого оборудования, включая поддержку в ядре Linux и в пользовательских библиотеках, что может дать преимущество в долгосрочной перспективе по сравнению с конкурентами.

Таким образом, "Crescent Island" представляется как ответ Intel на растущий спрос на энергоэффективные и экономичные решения для ИИ, с акцентом на открытое программное обеспечение и стандартизацию.

by wrigby • 14 октября 2025 г. в 18:30 • 140 points

ОригиналHN

#intel#xe3p#graphics#llm#inference#linux#openvino#oneapi#twitter

Комментарии (99)

  • Intel анонсировал 160 ГБ видеопамяти и 2,3 Пфлопс fp16, но цена и сроки появления в продаже остаются неизвестными.
  • Пока неясно, будет ли карта доступна для покупки в 2026 году, а цена может оказаться на уровне RTX 5090.
  • Вопрос остаётся открытым: будет ли поддержка CUDA/ROCm и какие фреймворки будут работать.
  • Поддержка ПО остаётся под вопросом, но Intel утверждает, что у них есть OpenVINO и oneAPI.
  • Пока неясно, будет ли карта доступна для покупки в 2026 году, а цена может оказаться на уровне RTX 5090.

Launch HN: Cactus (YC S25) – AI inference on smartphones (github.com)

cactus-compute/cactus

Запуск ИИ локально на телефонах и AI-устройствах.

Навигационное меню

Платформа:

  • GitHub Copilot
  • GitHub Spark
  • GitHub Models
  • GitHub Advanced Security
  • Actions
  • Codespaces
  • Issues
  • Code Review
  • Discussions
  • Code Search

Решения:

  • Для предприятий
  • Малые и средние команды
  • Стартапы
  • Некоммерческие организации

Ресурсы:

  • Темы (ИИ, DevOps, безопасность)
  • Обучающие материалы
  • Мероприятия
  • Истории клиентов

Open Source:

  • GitHub Sponsors
  • The ReadME Project
  • Репозитории

Enterprise:

  • Платформа для предприятий
  • Дополнительные модули
  • Поддержка

Цены

by HenryNdubuaku • 18 сентября 2025 г. в 15:40 • 105 points

ОригиналHN

#llm#mobile#inference#apache-2.0#open-source#github#y-combinator

Комментарии (50)

  • Пользователи обсуждают смену лицензии Cactus с Apache 2.0 на некоммерческую, выражая озабоченность по поводу доверия и её влияния на коммерческие приложения.
  • Поднимаются вопросы о технических возможностях фреймворка: производительность на разных устройствах (Pixel 9 Pro, rk3588), использование NPU/GPU, размер приложений и влияние на батарею.
  • Разработчики спрашивают о бизнес-модели проекта, коммерческом лицензировании и его стоимости, а также уточняют кажущиеся противоречия в формулировках о поддержке платформ.
  • Обсуждаются функциональные возможности: работа с инструментами (веб-поиск), оффлайн-режим, добавление моделей и поддержка агентских workflow.
  • Создатель проекта отвечает на вопросы, упоминая улучшения производительности, бесплатность для личного использования и возможность интеграции различных инструментов.

Defeating Nondeterminism in LLM Inference (thinkingmachines.ai) 🔥 Горячее

Почему LLM неповторяемы и как это исправить

Проблема
Даже при temperature=0 и одном железе выводы моделей различаются от запуска к запуску. Популярное объяснение: «параллельные GPU-ядра + погрешности float = недетерминизм». Это не вся правда.

Что на самом деле происходит

  1. Все «математические» ядра (matmul, softmax и т.д.) внутри одного forward-прохода детерминированы — бит-в-бит.
  2. Недетерминизм появляется между forward-проходами:
    • динамическое разбиение работы на потоки (different thread blocks);
    • неупорядоченные редукции при вычислении softmax/layernorm;
    • разные стратегии cudnn/cublas в зависимости от загрузки GPU;
    • кэш-промахи и atomicAdd в attention.

Как убедиться

A = torch.randn(2048, 2048, device='cuda', dtype=torch.bfloat16)
B = torch.randn(2048, 2048, device='cuda', dtype=torch.bfloat16)
ref = A @ B
for _ in range(1000):
    assert (A @ B == ref).all()   # всегда True

Матричное умножение повторяется, а вот softmax(A @ B) — уже нет.

Побеждаем за 3 шага

  1. Фиксируем редукции

    • torch.use_deterministic_algorithms(True)
    • CUBLAS_WORKSPACE_CONFIG=:4096:8 (для CUDA ≥10.2)
    • export CUDA_LAUNCH_BLOCKING=1 (медленно, но зато стабильно).
  2. Отключаем динамические алгоритмы

    • torch.backends.cudnn.deterministic = True
    • torch.backends.cudnn.benchmark = False
    • в vLLM: --disable-custom-all-reduce, --enforce-eager.
  3. Контролируем параллелизм

    • фиксированный батч и длина последовательности;
    • один GPU-поток (tensor_parallel_size=1);
    • один и тот же порядок запросов (queuing seed).

Результат
На Llama-3-8B с vLLM + указанными флагами 1000 прогонов дают идентичные токены вплоть до последнего бита. Стоимость: ≈8 % к throughput.

TL;DR
Недетерминизм — не «float плавает», а race-conditions вне математического ядра. Убери их, и LLM станет строго воспроизводимым.

by jxmorris12 • 10 сентября 2025 г. в 17:26 • 280 points

ОригиналHN

#cuda#pytorch#gpu#deterministic-algorithms#llm#machine-learning#nondeterminism#inference#cublas#cudnn

Комментарии (117)

  • Корень проблемы: «один и тот же» запуск LLM выдаёт разные токены из-за race-конкуренции ядер, неассоциативности float и недетерминированных GPU-ядёр; авторы показали, как зафиксировать порядок операций и получить бит-в-бит повтор.
  • Практика: temperature=0 ≠ гарантия: во-первых, библиотеки всё равно подкладывают ε>0, во-вторых, MoE-модели выбирают экспертов в зависимости от состава батча, поэтому даже «одинаковый» запуск в API почти никогда не повторяется.
  • Зачем нужна детерминированность: CI-тесты, отладка багов, шеринг промптов между разработчиками, валидация через LLM, агентские цепочки и RL-обучение требуют, чтобы «один и тот же вход = один и тот же выход».
  • Ограничения: статья решает только замкнутую задачу inference-ядер; контекст, семантически эквивалентные формулировки и много-нодовые коллективы остаются источником разброса; при temperature>0 нужен фиксированный PRNG-сид.

Token growth indicates future AI spend per dev (blog.kilocode.ai)

  • Kilo превысил 1 трлн токенов/мес в OpenRouter; Cline, Roo, Kilo растут из-за дросселирования Cursor и Claude.
  • Стартапы рассчитывали: себестоимость токенов упадёт на 90 % за год, маржа станет +80 %.
  • Вместо этого цена токенов фронтир-моделей не упала, а расход токенов на задачу вырос.
  • Причины: модели стали крупнее, появились «длинные мысли» и агенты, которые запускают цепочки вызовов.
  • Итог: расход на разработчика уже $20–40 к/мес и стремится к $100 к/год.

by twapi • 11 августа 2025 г. в 17:59 • 167 points

ОригиналHN

#openrouter#llm#cloud#cost#development#agents#inference#opensource

Комментарии (132)

  • Почти все участники считают цифру в $100 000/год на разработчика безосновательной и преувеличенной.
  • Основной аргумент: стоимость инференса либо быстро упадёт, либо станет дешевле запускать opensource-модели локально.
  • Многие отмечают, что уже сейчас $100–200/мес хватает большинству, а при росте нагрузки выгоднее купить железо, чем платить за облако.
  • Поднимается тема «токеномики»: расходы растут из-за параллельных агентов и увеличения контекста, но это пока не дотягивает до $100 000.
  • Часть комментаторов указывает, что крупные компании вряд ли вернутся к on-prem, а будут торговаться за долгосрочные контракты у дешёвых провайдеров.