Журналіст і розробник Анураг Сингх поставив собі за мету перевірити, чи здатна компактна локальна модель заступити хмарний Claude у щоденній роботі. Про це пише XDA-Developers.

Слабке залізо проти хмарного сервісу

Тест відбувався на MacBook Air із чипом M5 та лише 16 ГБ оперативної пам'яті — не найпотужнішій конфігурації для запуску великих мовних моделей на локальній машині. До цього автор працював із доопрацьованою версією Qwen 2.5 Coder для викликів інструментів, але та часто давала збої. Тому він вирішив на сім днів повністю відмовитися від Claude, яким зазвичай користувався для більшості задач, і подивитися, наскільки відчутною буде відмінність після переходу на Qwen 3.5-9B.

Що модель виконала без жодних проблем

Завдання для Qwen не обмежувалися дрібними тестовими вправами. Модель самостійно усунула ваду в системі логіну власного SaaS-продукту автора, через яку не доходили одноразові коди підтвердження (OTP), а також додала можливість вивантажувати результати у форматі звіту — обидва завдання стосувалися вже наявного застосунку, і Claude тут не знадобився.

Крім того, модель написала сценарії автоматизації для Home Assistant, які ефективніше задіюють пристрої й датчики в будинку автора: достатньо було словесного опису потрібної поведінки — і Qwen самостійно втілював відповідну логіку.

Окремо модель отримала доступ до серверних логів і почала регулярно виокремлювати проблеми, що вимагають реакції, — на відміну від типових повідомлень про збій, які просто фіксують факт помилки, залишаючи розробнику пошук її причини.

За тиждень Qwen 3.5-9B самостійно закрив приблизно 95% типових щоденних задач — агентне програмування, підтримку SaaS-продукту, автоматизацію розумного дому та аналіз логів.

Дві задачі, що виявилися занадто складними

Попри загалом вдалий результат, модель наштовхнулася на дві ситуації, які показали, де Claude все ще залишається сильнішим.

Перша складність — рефакторинг коду, що генерує звіти. Спочатку вся логіка перебувала всередині API-маршруту, і автор хотів винести її у спільний сервіс, щоб і сайт, і фонові процеси могли користуватися одним кодом. Qwen створив новий сервіс і оновив основний API-маршрут, але не відстежив усі місця, де застосовувалася попередня реалізація: фонове завдання й далі викликало стару функцію, деякі тести очікували старих параметрів, а типи на фронтенді розійшлися зі структурою відповіді. Модель лагодила кожну помилку окремо, але щоразу породжувала нову в іншому місці.

Друга проблема стосувалася звіту, який зависав у статусі «Обробка», хоча фонове завдання вже давно завершилося. Qwen спершу вирішив, що причина на боці фронтенда, і змінив механізм опитування сервера, щоб сторінка запитувала статус повторно. Насправді ж проблема крилася в тому, що ендпойнт статусу віддавав кешовану відповідь. Навіть коли автор показав моделі логи з підтвердженням, що звіт уже сформовано, Qwen продовжував правити компонент фронтенда, а не простежував шлях запиту через API та кеш.

На думку автора, саме ці дві ситуації демонструють сильну сторону Claude: він частіше сумнівається у власному первинному діагнозі, перевіряє інші ділянки стека і рухається від доказів у зворотному напрямку, тоді як Qwen схильний повторювати незначні варіації одного й того самого виправлення.

Підсумок експерименту

Незважаючи на невдачі зі складним наскрізним рефакторингом і налагодженням «впертого» бага, автор дійшов висновку, що Qwen 3.5-9B — цілком робоча локальна альтернатива хмарним моделям для повсякденних задач. Модель знайшла вдалий баланс між функціями універсального асистента й інструменту для агентного програмування, і для більшості типових завдань Claude автору просто не знадобився.

Нагадаємо, за останніми даними Qwen3.8-Max став новим лідером серед відкритих LLM: на тестах ця модель 16 днів автономно писала код.

Джерело: Highload.tech