27 января вышла LM Studio версии 0.4.0 и это обновление принесло долгожданную функцию параллельной обработки запросов через continuous batching. Это критически важное обновление для production-использования локальных LLM, которое обещает значительное увеличение пропускной способности. Теперь можно не просто "крутить модельку для себя", а разворачивать реальные multi-user сервисы.

Но как это работает на практике? Я провел комплексное исследование на своем домашнем ПК, сравнив производительность ROCm и Vulkan, а также влияние количества потоков на пропускную способность (TPS).

Спойлер: Разница между ROCm и Vulkan оказалась шокирующей — до 2 раз в пользу ROCm, а правильная настройка потоков дает +50% бесплатной производительности.

В своей прошлой статье я рассказывал о компактной модели, которая по бенчмаркам смогла превзойти модели в 10 раз больше ее самой. О том, что это стало возможным благодаря особому подходу к обучения самой модели и что такую модель вполне реально запустить у себя локально.

Однако, когда дело касается локального запуска, думаю, далеко немногие из нас запускают модели в BF16 через vLLM на Nvidia H100. А значит, все эти красивые результаты по бенчмаркам на практике, вероятнее всего, очень далеки от того, что мы получим на практике.

И я решил это проверить.

В ноябре вышла модель Nanbeige4-3B-25-11 (а 6 декабря они выложили статью об обучении на arxiv). Её размер всего лишь 3 миллиарда параметров. Это почти в 100 раз меньше, чем GPT-4, и даже меньше, чем большинство открытых моделей.

Но вот парадокс: на тестах она достигает показателей выше, чем модели в 10 раз больше, а на бенчмарке WritingBench и вовсе держится на уровне проприетарных моделей занимая место между Gemini-2.5-Pro и Deepseek-R1-0528.

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

Сейчас, наверное, только ленивый не ругает наши российские LLM: редкие и слабые релизы, спорная практическая эффективность, особенно в кодинге и математике, ограниченный контекст и забывчивость, плохое следование инструкциям и поверхностные ответы.

Да и в целом, несмотря на заявления об использовании современных архитектур и решений складывается впечатление, что «наши» модели словно отстают на 1, а то и 2 поколения от зарубежных аналогов.

Но так ли все плохо и есть ли белый свет в конце тоннеля для российских LLM?

Это третья часть моей мини‑саги про вайбкодинг, LLM и здравый смысл в разработке. В первой статье я уже рассказывал, как по совету ИИ едва не снёс себе БД, а во второй — разбирался, страшен ли этот самый вайбкодинг или это просто инерция мышления перед лицом прогресса.

Сегодня я хочу поговорить о «священном граале» текущего AI-хайпа — полной автономности кодинг-агентов. О том, почему вера в то, что нейросеть «сама всё напишет, пока я пью кофе», — это опасное заблуждение, которое лишь усиливает скепсис профильного сообщества.

В своей прошлой статье я рассказывал, как продвинутая LLM для написания кода может упустить очевидные вещи и привести к потере данных. Та история была скорее о техническом курьезе, который может случиться при бездумной вере в возможности нейросети.

Сегодня я хочу поговорить о самом вайбкодинге как о явлении, вызывающем бурю эмоций в IT-сообществе. Этот термин, придуманный и популяризированный Андреем Карпатым в начале 2025 года, быстро стал нарицательным. Для одних это будущее, для других — синоним «говнокода». Но так ли страшен вайбкодинг, как его малюют?

Вайбкодинг обещает нам будущее, где мы лишь «менеджеры кода», а всю работу делают нейросети. Я всегда скептически относился к этому, и суровая реальность деплоя лишь подтвердила мои опасения. Мой проект лег, процессор забился под 100%, а «самая умная» кодинг-модель Claude Opus 4.5 настойчиво предлагала единственное решение — снести мою БД. Рассказываю, как инженерное чутьё спасло проект от советов ИИ, и почему даже в 2025 году вайбкодинг не заменяет мозги.