Комментарии 25
Уверен, что Claude Opus 5.5 справился бы с задачей в разы быстрее, но приходится пользоваться тем, что есть.
Тоесть вы хотите сказать что Claude генерирует 70-100т.с ?
Может быть прежде всего в этом одна из причин почему ваши задачи решаются медленнее ?
Попробуйте Qwen пихнуть на 2-3 ваши DGX Spark и потом уже сравнить скорость решения задачи.
Думаю, что с low effort около 90 TPS как раз таки и выдаёт, а на medium и high - порядка 80. Т.е. по скорости декода вполне сопоставимо с Deep Seek на двух Spark.
Почему надо больше времени на задачу? При работе с Opus в последнее время не приходилось много времени тратить на написание плана и тщательно вычитывать его. Достаточно было пройти grilling сессию, утвердить спеку и вперёд.
А вот Qwen'у и Deep seek пока у меня доверия нет - часто приходится по нескольку раз вычитывать план, т.к. они могут что-то вписать лишнее или даже вредное, неправильно меня поняв. Плюс время на кросс проверку другой нейронкой. Также у меня много замечаний по коду.
Но я верю, что с выходом новых версий локальных LLM ситуация будет улучшаться. До выхода Qwen 3.8 27B я даже не рассматривал в серьёз возмость использовать в рабочих задачах локальные модели. А 3 месяца спустя делаю первые шаги в этом направлении.
Обязательно попробую Qwen на паре спарков. Спасибо за идею
Да по доверию с вами соглашусь, за ними нужно проводить аудит, в тоже время на счет Kimi попробуйте не 3.1 а 3.0 он жрет много токинов, но он умнее значительно, часто подмечает то что не видит 3.1 и GLM 5.3
Я сперва прошу у Qwen повторить, как профессионала, что я от нее требую. Читаю ее формулировку (обычно совпадают) потом план с ожидаемым результатом и основная работа по написанию кода, тестирования и т.д. По моим ощущениям, если составить хороший промпт, то Qwen 3.8 Flash Next, справляешься без проблем с задачами.
deepseek у вас сильно покоцаный, это же практически Q2_K модель, поэтому он и не намного лучше Qwen. Полный DeepSeek уровень GPT-Sol6 High, поэтому говорить что Codex это плохо, как минимум смишно.
Ну, формально, 2.9 ближе к трем, чем к двум битам. Когда в моем распоряжении будет 4-й Spark и коммутатор, то первым делом опробую 4-й квант DeepSeek.
Но я и не говорю, что Codex хуже, чем Deep seek в EXL3, а лишь транслирую мнение моих коллег, что Codex сильно отстает от Opus 5.5 по их мнению. Плюс сейчас участились случаи блокировок и со стороны OpenAI.
Q2_K это НЕ 2бита, это 2.96 bpw, доки llama.cpp почитайте.
2бита, точнее 2.06bpw - это IQ2_XXS
Спасибо за уточнение, действительно погорячился с 2 битами. Но сути моего ответа на прошлый комментарий это не меняет. Я не сравниваю квантованный DeepSeek с Codex напрямую — я лишь говорил, что, по ощущениям моих коллег, Codex заметно слабее Opus 5.5. А вот конкретный квант DeepSeek с Codex сравнивать пока не берусь.
Для четырех спарков не нужен коммутатор, вопреки официальной документации. Поищите на гитхабе "dgx-spark-4-ring-no-switch"
Претензии к Codex у людей строятся на блокировках учетных записей. Какой толк от качества модели, если доступ к ней могут перекрыть в любой понедельник
А чем именно не устроил gpt и kimi? Мне кажется они не должны быть хуже квантованного дипсика
Чем Kimi не устроил моих коллег:
1) Очень долго думает. После grilling сессии больше часа писал спеку.
2) Быстро расходуются лимиты. Около 10% месячного лимита только на план одной задачи.
3) Хуже понимает пользователя - нужно гораздо более подробно все расписывать.
4) Часто теряет контекст - приходится заново объяснять то, что было сказано пару промптов назад.
Проблемы с Codex:
1) Теряет детали при работе
2) Также нужно более подробно расписывать промпты, чтобы добиться приемлемого результата
3) Часто забывает какие-то договоренности и факты, которые ранее обсуждались в этой сессии
Но хочу подчеркнуть, что это мнение людей, привыкших работать с Opus 5.5. У квантованного deep seek тоже немало проблем и до уровня Opus 5.5 ему еще далеко. И добровольно я бы на него не перешёл.
У Kimi при работе с кодом есть неприятное свойство раздувать контекст рассуждений до десятков тысяч токенов на ровном месте. Лимиты тают буквально на глазах за два-три сложных запроса. При этом скорость ответов на больших промптах проседает в разы сильнее, чем у локального стенда
Примерно тот же стек по моделям, но на одной 5090, на других движках, железе и квантах. Глубину размышлений как регулируете?
Qwen на одном Spark выдаёт ~70–80 ток/с, DeepSeek на двух — ~99–109 ток/с. Если нормировать на железо, картина меняется: Qwen — 70–80 ток/с на Spark, DeepSeek — 49–55 ток/с на Spark.
На сколько корректно нормировать? Инференс хорошо параллелится, но только в рамках 1 машины. При работе на нескольких - они работают последовательно, а не параллельно (+ накладные расходы на передачу данных).
Зато DeepSeek субъективно умнее — об этом ниже.
DeepSeek объективно имеет больше параметров (что общее количество, что активных), при этом вышли почти одновременно (Qwen “старше” на 2 недели) - так что он заметно умнее.
На следующей неделе планирую испытать GLM 5.3 Flash в задачах на кластере из двух Spark.
Как раз хотел написать про GLM 5.3 Flash - лично мне GLM нравится больше. Заметно меньше текста генерирует, чем DeepSeek (с DeepSeek у меня любая задача очень быстро до 100к токенов разрастается), при этом не сказать что глупее (хотя учитывая квантование - может и умнее даже будет - модель мельче, чем DeepSeek). Но, скорее всего, будет медленнее - все-таки DeepSeek сильно на скорость затачивали (и оптимизировали размер контекста в памяти). Так что буду ждать тестов GLM 5.3 Flash )
На сколько корректно нормировать?
Возможно, не совсем корректно выразился. Имел в виду, что хоть DeepSeek и выдает в полтора раза больше токенов в секунду, но с точки зрения экономики ему нужно в 2 раза больше железа.
Тогда лучше добавить TPS при параллельном инференсе (в 1-2-4-8-16-32 потока), а для Qwen “размножить” на независимые инстансы - будет показательнее для “сколько TPS можно выжать с пары Spark-ов в офисе”.
Потому как личная пара Spark-ов - это хорошо, но несколько избыточно )
P.S. а не пробовали AMD Ryzen AI Max+ 395? По идее для инференса будет не сильно хуже, но может быть заметно дешевле (PP сильно упадет, но кеш в помощь).
Тогда лучше добавить TPS при параллельном инференсе (в 1-2-4-8-16-32 потока)
Собственно, так я изначально и пытался замерять. И когда Qwen был запущен на старом рецепте с vLLM, то был ощутим батчинг и суммарный TPS увеличивался с каждым потоком. Наиболее значимый прирост происходил до 8, потом уже прирост был несущественный, а скорость на поток падала до некомфортных значений...
Но на новом рецепте с TensorFold батчинг работает только с контекстом до 2К (или я не разобрался, как сделать больше). Несмотря на --parallel 4 , запросы выше 2К токенов обрабатываются последовательно.
По большому счету, можно на несколько человек в таком режиме отдавать Spark - скорость генерации не страдает, но вот TTFT может непредсказуемым образом меняться.
Для фоновых задач такой подход имеет место быть. Ну, и обязательно нужно настраивать звуковые сигналы об окончании хода или когда требуется действие пользователя (вопрос, разрешение)
AMD Ryzen AI Max+
Руководство периодически на него посматривает, но не понятно, будет ли на него спрос. Если Spark будет и дальше дорожать, возможно появятся у нас и AMD Ryzen.
Аренда двух серверов DGX Spark для рядового разработчика выйдет дороже годовой подписки на все облачные сервисы вместе взятые. Такой сетап имеет смысл только в закрытом контуре крупного энтерпрайза
Да, согласен, аренда или покупка для индивидуального разработчика экономически нецелесообразна. Но мне, вот, очень хотелось бы иметь Spark или пару в личное пользование, хоть это и неразумно.
Такой сетап имеет смысл только в закрытом контуре крупного энтерпрайза
Арендует, в основном, мелкий и средний бизнес, которым нельзя пользоваться облачным ИИ из-за ФЗ 153. А также для файнтюнинга моделей. Так что речь об экономии на подписках точно не идёт.
за первую неделю цикл разработки стал занимать в 3–4 раза больше времени, чем с Claude Code.
Как я вас понимаю. Нас пересадили на gpt и я просто вешаюсь от его тормознутости. Там, где за опусом читать не успеваю, gtp просто стоит и тупит. Бесит.
После прочтения статьи стало понятно, что сама специфика работы этого человека уже является красным флагом для Anthropic. Понимаю, что комментарий может показаться неприятным, но исходя из наблюдаемых паттернов, разработчики из РФ с похожим профилем использования с высокой вероятностью окажутся среди первых заблокированных. В его активности в Claude Code, судя по всему, уже присутствовал набор характерных red flags. Подход в духе «нагружу чем-нибудь, чтобы не оставлять неиспользованные лимиты» сам по себе является довольно чётким сигналом для систем антиабьюза. Логика здесь простая: Anthropic в первую очередь будет ограничивать тех, кто систематически выжигает лимиты по подписке, которая для компании экономически не самая выгодная. При прочих равных быстрее заблокируют пользователя, который регулярно выжигает весь лимит, чем того, кто использует лишь ~30% от доступного.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Есть ли жизнь после блокировки Claude Code? Первая неделя на локальных Qwen и DeepSeek