Когда китайский гигант встречает C++ оптимизацию
Tencent выпустил WeDLM-8B — модель, которая в шесть раз быстрее Qwen на математических задачах. Звучит как мечта для локального запуска. Но мечта сталкивается с реальностью в виде chatllm.cpp — форка llama.cpp, который обещает эффективное декодирование больших контекстов. Что получится на выходе? Иногда — разочарование. Иногда — неожиданный триумф процессора над видеокартой.
Три параметра, которые решают всё (и ломают)
Забудьте про стандартные --temp и --top-p. В chatllm.cpp для WeDLM игра идёт на другом поле. Здесь правят балом block_size, accept_algo и threshold. Ошибешься в одном — получишь либо молчащую модель, либо бессвязный поток сознания.
1 Block_size: размер имеет значение
Этот параметр определяет, сколько токенов модель обрабатывает за один проход. По умолчанию — 512. Для WeDLM-8B это часто слишком мало. Увеличиваете до 1024 или 2048 — модель начинает «думать» более связно, но требует больше памяти. Упираетесь в лимиты оперативки или VRAM. Классическая дилемма.
2 Accept_algo: алгоритм принятия решений
Здесь chatllm.cpp предлагает несколько вариантов: greedy, sample, top_k. Для WeDLM, которая заточена под точные вычисления, greedy часто работает лучше всего. Но попробуйте sample с низким temperature — и получите более креативные (иногда слишком креативные) ответы на математические задачи. Рискованно.
3 Threshold: порог принятия
Самый капризный параметр. Определяет, насколько «уверенной» должна быть модель в следующем токене. Слишком высокий threshold — модель застревает, повторяет одни и те же фразы. Слишком низкий — генерирует бессмыслицу. Для WeDLM-8B золотая середина где-то между 0.7 и 0.85, но это зависит от конкретной задачи.
Не копируйте настройки слепо из других моделей. WeDLM-8B имеет другую архитектуру и тренировалась на другом датасете. То, что работало для Qwen или GLM, здесь может дать сбой.
CPU против GPU: неожиданный поворот
Вот где начинается самое интересное. Логика подсказывает: GPU с его тысячами ядер должен рвать CPU на части. С моделями вроде Qwen3-30B так и происходит. Но WeDLM-8B в chatllm.cpp — другой зверь.
| Конфигурация | Скорость (токенов/с) | Потребление памяти | Стабильность |
|---|---|---|---|
| CPU (Ryzen 9 7950X, 32 потока) | 18-22 | ~12 ГБ ОЗУ | Высокая |
| GPU (RTX 4090, полная загрузка) | 45-55 | ~8 ГБ VRAM | Средняя |
| GPU (RTX 3090, mixed precision) | 32-38 | ~10 ГБ VRAM | Низкая |
Видите проблему? RTX 3090 показывает худшую стабильность. Модель периодически «заикается», особенно при длинных контекстах. Пока вы решаете математическую задачу на 500 токенов, всё хорошо. Попробуйте анализировать код или длинный документ — начинаются артефакты генерации.
А теперь главное: на CPU таких проблем нет. Медленнее? Да. Но стабильнее и предсказуемее. Для production-задач, где важна воспроизводимость результатов, это может быть решающим фактором.
Блочное декодирование: ускоритель или тормоз?
Chatllm.cpp гордится своей реализацией блочного декодирования. В теории это должно ускорять обработку длинных последовательностей. В практике с WeDLM-8B получается неоднозначно.
Включите блочное декодирование с block_size=1024 — и модель действительно быстрее обрабатывает длинные промпты. Но качество генерации иногда страдает. Модель как будто «теряет нить» рассуждения между блоками. Для математических задач, где важна последовательность шагов, это фатально.
Отключите блочное декодирование — качество восстанавливается, но скорость падает на 30-40%. Выбирайте: быстрые, но менее точные ответы или медленные, но качественные. Третьего не дано.
Квантованная модель: спасение для слабого железа
Оригинальная WeDLM-8B в формате FP16 весит около 16 ГБ. Для запуска на GPU с 12-16 ГБ VRAM это предельно. Решение — квантование до Q4_K_M или Q5_K_M. Как в случае с Gemma 3 1B, но с другими нюансами.
Q4_K_M сокращает размер модели до ~4.5 ГБ с минимальной потерей качества на математических задачах. Q5_K_M даёт ~5.5 ГБ и практически идентичную оригиналу точность. Разница в скорости между ними — около 15% в пользу более агрессивного квантования.
Но вот что интересно: квантованная WeDLM-8B на CPU часто работает стабильнее, чем полная версия на GPU. Меньше артефактов генерации, более предсказуемые ответы. Ирония в том, что для серьёзной работы с моделью иногда лучше взять мощный процессор и квантованную версию, чем средний GPU с полной моделью.
Кому подойдёт этот стек?
Запуск WeDLM-8B в chatllm.cpp — не для всех. Это инструмент для тех, кто готов копаться в настройках и принимать неочевидные решения.
- Исследователи в области NLP, которым нужна стабильная, воспроизводимая работа модели больше, чем максимальная скорость.
- Разработчики математических ассистентов, где точность вычислений критична, а задержки в 2-3 секунды допустимы.
- Владельцы мощных CPU-серверов, которые хотят использовать существующее железо без покупки дополнительных GPU.
- Энтузиасты локального AI, уже знакомые с нюансами llama.cpp и готовые к новым вызовам.
Если же вам нужен простой API «из коробки» для production, посмотрите в сторону vLLM или других готовых решений. Chatllm.cpp с WeDLM-8B — это ручное управление на грани слома. Иногда оно даёт лучшие результаты. Часто — требует больше времени и нервов.
Что будет дальше?
Tencent не остановится на WeDLM-8B. Уже ходят слухи о 20B и 70B версиях. Chatllm.cpp тоже развивается — добавляют поддержку новых алгоритмов декодирования, оптимизируют работу с большими контекстами.
Но главный тренд, который я вижу: разделение на «скоростные» и «точные» конфигурации. МыDLM-8B в chatllm.cpp уже сегодня показывает, что иногда можно пожертвовать скоростью ради качества. В будущем этот разрыв будет только увеличиваться.
Совет напоследок: не гонитесь за максимальными токенами в секунду. Для WeDLM-8B важнее стабильность генерации и точность ответов. Настройте block_size=1024, accept_algo=greedy, threshold=0.8 и запустите на CPU с достаточным количеством потоков. Да, это будет медленнее, чем на GPU. Зато вы получите работающий инструмент, а не источник случайных чисел с претензией на интеллект.
