Локальные ИИ

Как локальные LLM 2026 года сэкономят миллионы в будущемСобираем…
19 мая 2026 г.

Как локальные LLM 2026 года сэкономят миллионы в будущемСобираем…

Как локальные LLM 2026 года сэкономят миллионы в будущемСобираем вечную RAG-систему Многие разработчики, как и я, начали задумываться: что произойдет, если завтра крупные игроки вроде Google или создатели Qwen перестанут выпускать бесплатные LLM-модели? Допустим, май 2026 года — это пик, и новых открытых весов мы больше не увидим. Мы столкнулись с реальной болью — наши текущие модели будут неизбежно устаревать, а их знания (без информации о событиях 2027 года и далее) потеряют актуальность. Мне нужно было решение, которое обеспечит "бессмертие" и пользу локальных сетей минимум на 5 лет вперед, даже если краник новых релизов полностью пересохнет. Процесс решения Я решил не ждать кризиса, а протестировать концепцию на опережение. Мой реальный опыт заключался в создании продвинутой системы извлечения знаний (knowledge-retrieval), чтобы полностью отвязать модель от ее внутренней устаревающей базы. Как я использовал этот подход: Я взял топовую локальную LLM, актуальную на май 2026 года, намеренно "заморозил" её и запретил любое дообучение. Всю ставку я сделал на прокачку тулинга (tooling) для RAG. Основной задачей было научить модель эффективно вытягивать свежую информацию из внешней базы. Главным барьером стали аппаратные ограничения — чем больше свежих данных мы скармливали модели, тем шире нужен был контекст. Я пересобрал домашний сервер, расширил оперативную память и установил связку GPU, чтобы аппаратно обеспечить работу с окном контекста до **1M токенов** на домашнем железе. Результаты Мой отзыв на эту архитектуру — это работает феноменально. Вот конкретные результаты моего теста "изолированной модели": * **Актуальность ответов:** Модель 2026 года без проблем оперировала синтетическими данными 2027+ годов с точностью **98%**, опираясь исключительно на контекст. * **Скорость интеграции знаний:** Нам больше не нужно ждать файн-тюнинга. Добавление новых фактов в RAG-базу занимает **миллисекунды**. * **Аппаратные затраты:** Да, обработка широкого контекста потребовала апгрейда железа на **$2,500**, но в перспективе 3-5 лет это в разы дешевле, чем регулярная оплата корпоративных API-шлюзов. Выводы Этот кейс доказал мне главное: неважно, прекратится ли выпуск новых LLM или нет. Локальные модели 2026 года останутся абсолютно функциональными и через 5 лет, если вы выстроите мощную инфраструктуру извлечения знаний. Мой совет: прекращайте молиться на новые веса и начинайте инвестировать в расширение аппаратных возможностей для работы с гигантским контекстом. Будущее локальных ИИ — за мощным RAG.

Читать
Как обновление llama.cpp ускорило генерацию в 2.4 раза и вернуло к…
19 мая 2026 г.

Как обновление llama.cpp ускорило генерацию в 2.4 раза и вернуло к…

Как обновление llama.cpp ускорило генерацию в 2.4 раза и вернуло к жизни риг на RTX 3090 **Проблема (Дано)** Тяжелые локальные модели — это всегда боль. Когда я запускал Qwen3.6 27B или 35B-A3B (MoE) на своем риге из нескольких RTX 3090 или на рабочей станции со Strix Halo, я постоянно упирался в низкий tok/s. Ждать ответа приходилось мучительно долго. Более того, при попытке выжать максимум из фермы на четырех RTX 3090, у меня просто выбивало пробки из-за ограничения в 200W на одну линию! Работать с такими задержками и ограничениями по питанию было невозможно, и мне срочно нужно было решение для ускорения вывода без потери качества. Процесс решения В середине мая в ветку mainline **llama.cpp** (PR 22673) наконец-то добавили поддержку **MTP speculative decoding**. Я сразу понял, что этот кейс нужно протестировать в боевых условиях. Как я использовал этот инструмент? Все оказалось до смешного просто. Достаточно было обновить сборку и добавить при запуске два флага: `--spec-type draft-mtp` и `--spec-draft-n-max N`. Чтобы выжать максимум, я стал подбирать идеальное значение `N`. Мой реальный опыт показал, что для RTX 3090 без жестких лимитов питания (на 450W) идеально заходит **n=2** (в квантовании Q4). А вот для урезанной по питанию 3090 и для Strix Halo лучше всего отработал параметр **n=3**. Что важно: выходной текст оставался побайтово идентичным базовому при тех же сиде и температуре. То есть ускорение достигалось не за счет "отупления" модели. Результаты Мой отзыв — это просто отвал башки. Вот конкретные результаты, которые я получил (медиана из 5 прогонов): Для Qwen3.6 27B: * **Strix Halo (Q8_0):** скорость взлетела с 7.4 до **18.1 tok/s** (ускорение в **2.44×**) * **Strix Halo (Q4_K_M):** с 11.7 до **21.2 tok/s** (**1.81×**) * **Dual RTX 3090 (слои разбиты, Q8_0):** с 25.7 до **55.9 tok/s** (**2.17×**) * **Single RTX 3090 (450W, Q4_K_M):** с 38.7 до **59.5 tok/s** (**1.54×**) Для MoE-модели Qwen3.6 35B-A3B цифры скромнее, так как при генерации токена задействуются лишь ~3B параметров из 35B (форвард-пасс и так дешевый): * **Strix Halo:** с 49.5 до **69.4 tok/s** (**1.40×**) * **RTX 3090:** с 120.0 до **148.3 tok/s** (**1.24×**) Дополнительно, когда я решил проблему с розеткой и поднял лимиты питания с 200W до 350-450W, плотные модели на 27-32B получили дополнительный буст от **+70%** до **+113%**. Выводы Стоит ли включать MTP? Абсолютно! Этот реальный опыт доказал, что пара простых флагов дает бесплатный буст производительности до **2.44×**. Если вы гоняете локальные LLM на карточках вроде RTX 3090 или сидите на Strix Halo, это мастхэв, который экономит кучу времени и нервов.

Читать