На техническом ресурсе статьи в том виде, в каком она есть сейчас, вообще не должно было быть. "Он делал, делал и сделал, сообщение зашифровали, передали и расшифровали обратно, но это стало неактуально и проект прикрыли". На каких принципах работало устройство? Как была представлена речь, как шлифовалась? На каких принципах вообще в то время было основано шифрование нетекстовой информации? Как удалось уложиться в размеры, в несколько десятков раз меньшие, чем у аналогов? Ни одной технической подробности в статье нет, ни-од-ной.
Я и в момент анонса особо не разделял всеобщего хейта, а теперь и подавно убеждаюсь, что технология при нормальном тюнинге крайне годная. Правда тем, кто в свое время не успел урвать топовую карточку по адекватной цене (типа меня с 3070Ti) вряд ли в ближайшее время улыбается оценить её в полной мере(
Не не, я немного не про это, я про то, что когда волна извне приходит на границу и мы понимаем, что она уже потрогала ближайший из допустимых входов (например, если к самому ближайшему подошла), то мы по нему и пройдём внутри и в этот момент (когда мы можем с уверенностью сказать, что мы вошли во внутренний подграф по разрезу оптимально) дерево внешнее растить смысла больше нет, так как вход по неоптимальному входу недопустим (условие ПДД на argmin(...)), в таком случае можно внешнее дерево больше не растить, так как любой другой вход сделает решение недопустимым.
Не, там не всё настолько жёстко (вернее, в ПДД любой пункт - огромное пространство для интерпретаций). Например, там не сказано, что понимается под метрикой "ближайший". Если это "ближайший по прямой", то действительно, таковым может оказаться единственный въезд в зону. Однако если это "ближайший по дорогам", то это плавающее понятие: если единственный проезд от некоторого въезда до точки назначения вдруг стал перекрыт, то ближайшим в этот момент становится другой въезд, из которого достижима точка назначения. Мы выбрали вторую интерпретацию, как минимум потому, что непостроение маршрута - это крайний случай, которого нужно избегать всегда, когда его можно избегать.
Ну и в общем все последующие рассуждения по этой теме у вас опираются на предположении "въезд может быть только один", а мы работаем в парадигме "хоть какой-то проезд да нужно найти".
Но в таком случае ведь если запускать Дейкстру от Дейкстр (внутри стартового графа искать оптимальный и потом менее и менее оптимальный выход и с каждого такого менее оптимального выхода поочерёдно запускать A* во внешность, пока он не сломается (тупик) или не найдёт проезд), то граф плоский будет биться на компоненты связности (тупики) и одна из них всё-же дойдёт до второго графа внутреннего и для неё это будет корректный argmin, а значит решение будет допустимым. Если есть решение лучше, то только в выборе выезда из первой компоненты, а мы помним, что условие на argmin и там и там есть, так что оптимальность очевидна.
Да, и это ровно то, что мы делали в первой версии алгоритма, и что в особо плохих кейса работало десятки секунд! Ровно поэтому и понадобилось городить текущее решение со штрафами, и оно оказалось существенно производительнее исходного, причём не только на плохих кейсах, но и в среднем.
Плюс ко всему вышесказанному, множественные запуски A* приведут к кратно большему суммарному количеству перебранных рёбер, поскольку - сейчас пальцем в небо навскидку - порядка 2/3 или 3/4 (а может и больше) рёбер будут перебраны более чем в одном (а то и во всех или почти во всех) из проходов.
Тут вы рассмотрели частный случай - s-p-t. Вы рассматривали, судя по всему, вариант, когда s вне зоны, а t внутри, но, в целом, тот же анализ верен и для обратного случая.
Но эти кейсы как раз и изначально не были особой проблемой (с точностью до одной оговорки, о которой ниже). Самый проблемный кейс - и s, и t внутри разных зон. Потому что здесь может получиться так, что между se - ближайшим к s выездом из стартовой зоны, и te - ближайшим к t въездом в финишную, нет проезда. И начинается, по сути, брутфорс: перебираем пары въездов/выездов и пытаемся между ними построить проезд. При этом надо минимизировать сумму длин проездов внутри зон, поскольку именно в этом их административный смысл. И вот этот перебор - просто смерть для перформанса. Да, ситуация не столь частая, но кога она стреляла, было грустно.
Тут можно сказать: ну так используйте проверку связности, какого чёрта в лоб считать маршрут между каждой парой в переборе, когда можно заранее вычислить компоненты связности и делать проверку за O(1)?! Да, но нет) Тут в игру вступает два фактора:
time-based штуки, т.е. всё, что может по расписанию "рвать" граф; например, перекрытие дороги, которое вступило в силу за 2 минуты (в таймлайне волны, не в реальном времени) до того, как волна к нему подобралась; самый яркий пример - разведение мостов в Питере;
динамические параметры транспортного средства, которые уникальны для каждого запроса: мост, по которому проедет грузовик с фактической массой 3 тонны, обрушит десятитонник; для первого проезд существует, для второго - нет; если это был единственный проезд между некоторым сочетанием въезда и выезда, то для десятитонника надо искать другой вариант, тогда как для трёхтонника подойдёт и этот.
Второй фактор даже важнее первого. При достаточном уровне оптимизации можно было бы динамически пересчитывать компоненты связности (в целом, мы и сейчас уже так делаем). А вот второй фактор - это гигантское множество комбинаций разных значений параметров ТС (в нашем случае оно вообще почти бесконечно, потому что параметры представлены действительными числами, ведь ПДД действительно не налагает на их значения никаких ограничений ни по верхней границе, ни по шагу).
Теперь оговорка, о которой упомянул выше: она тоже связана с time-based. Вариант, когда в финишной зоне считается обратный маршрут N-1 (от всех въездов в неё до единственной финишной точки), мы не можем корректно учитывать time-based (пробки, перекрытия и т.д.), поскольку не знаем, в какой момент доехали до финишной точки, и, как следствие, не знаем ни для одного ребра внутри зоны время попадания волны на него. Если бы мы знали время, в которое оказались на финише, вопрос решался бы тривиально: при распространении обратной волны мы бы просто вычитали время обратного проезда по ребру из времени проезда по предыдущему ребру, вместо того, чтобы суммировать, как в прямой версии алгоритма. Но мы не знаем) В первой (многоволновой) версии алгоритма мы решали это крайне тупо - просто эвристически предполагали, сколько мог бы занять проезд до финиша. Надо ли говорить, насколько это было неточно?)
В общем-то, обо всём этом (правда, куда менее подробно; попробую учесть это для будущих статей и добавлять побольше деталей) я писал в статье, в разделе "Грузовые маршруты: вариант первый".
Теперь несколько ваших тезисов, которые считаю важным прокомментировать.
Во втором алгоритме вы вводите тормозящие штрафы, вот только пока алгоритм ждёт истечения штрафа на следующий вход, во внешности графа растёт огроменное дерево, которое его тормозит.
...
Но при этом проигрываете за счёт того, что огромное тяжеленное дерево всё это время растёт...
...
Да, через границу из-за тормозящих штрафов ничего не пролезет, но при этом в остальной граф то оно всё полезет.
Тут важно вот что: да, действительно, пока маршрут строится внутри зоны после "просачивания" волны через лучший въезд, перебор также идёт и вне её. Однако ключевую роль здесь играет соотношение весов: как только волна протекла внутрь зоны, она начинает стремительно двигаться к финишу (тут ещё играет фактор того, что строиться с этого момента начинает оптимальный не по времени, а по длине (т.е. кратчайший) маршрут, это тоже требование ПДД к проезду внутри зон; таким образом, пробки для этой части волны уже не помеха. Таким образом, с этого момента эвристический штраф, являющийся одной из составляющих веса ребра в очереди на обработку, начинает почти стабильно уменьшаться у рёбер внутри зоны; веса же рёбер вне зоны почти так же стабильно будут лишь расти, поскольку они уже "облепили" (или в какой-то момент сделают это) границу зоны и дальше могут только отдаляться от неё, всё увеличивая свой вес (причём по обеим составляющим - и по фактической стоимости, и по эвристической) и всё снижая вероятность выбора на очередном шаге волны. Конечно, это полностью не исключает того, что волна будет периодически перекидываться за границы зоны уже после того, как оказалась внутри неё, но всё же это не будет иметь такого серьёзного эффекта, как вы представляете, и со временем будет происходить всё реже, поскольку волне всё выгоднее будет продолжать перебор только внутри зоны, где веса растут только по одной составляющие - фактической.
как бы запускаете внутренний поиск наоборот (от разреза в центр). Получается выигрыш на внутреннем графе (ведь вы не весь его считаете, а только кусочек, да и A* есть куда направить target.
Верно, а ещё выигрываем в точности учёта time-based)
и это при том, что если вы уже зашли с ближайшего входа, то внешнее дерево в принципе можно блокировать.
К сожалению, нельзя. Дело в том, что в конкретный момент времени ближайший вход может оказаться недостижим; всё те же чёртовы time-based :D Именно для этого сделана прогрессия штрафов: если такое происходит, будет естественным образом выбран следующий по "ближайшести" вход. В целом, это скорее исключительная ситуация, но задел на её обработку обязан быть, поэтому обрубать распространение вне зоны нельзя.
До сих пор не понимаю, люди, которые потом в комментах серьезно и позитивно обсуждают этот... кхм... материал — они действительно не осознают, чем их только что накормили, или уже смирились и считают, что это окэй? Если первое — неужели надо обладать каким-то особым когнитивными навыками, чтобы за полтора слова распознавать слоп?
Потому что это классический высер ллмки, как, впрочем, и сам текст статьи. Достаточно полистать ленту, и можно с завидной (нет) регулярностью обнаружить заголовки, сформированные по подобному паттерну.
С тех пор как год назад купил дек, на ПК прошел только одну игру — недавний 007 First Light. Всё остальное — дек. Игровые сессии и по несколько часов подряд случались, так что с аргументом про неудобство, тяжесть, температуру не согласен. За этот год игр пройдено больше, чем за предыдущие пять вместе взятых (и это как минимум), благодаря, опять же, деку. Я его существование воспринимаю крайне позитивно.
В остальном в комментариях выше люди расписали мои мысли по поводу сказанного в статье. Наверное, автору просто надо было кого-то обвинить в текущем состоянии индустрии, а ответ же вот, на поверхности — это свитч с деком виноваты! На проверку же, как мне видится, всё куда сложнее, куда глубже и началось гораздо раньше, чем свитч с деком хотя бы в проекте появились, не то что релизнулись.
На мой взгляд, польза от lmgtfy как минимум в том, что скидывающий ссылку сформулировал такой поисковый запрос, выдача на который как раз содержит ссылки на материалы с ответом. То есть предполагалось, что топикстартер был не в состоянии (или же вообще не пытался) достаточно кратко и ёмко сформулировать свой вопрос, потому гугл ему ничего внятного и не выдал. И зачастую это предположение было правдой, поэтому отвечающий всё же проделал некоторую работу за топикстартера.
По моим воспоминаниям на момент релиза Виста действительно была глючной неюзабельной тварью, но со временем её допилили и к релизу семёрки уровень раздражения от висты был не выше, чем от самой семёрки.
У меня однажды получилось, но больше не получается. Правда, с тех пор я особо сильно не старался.
Но у меня и с балериной так - однажды около 7 минут пытался заставить её вертеться в другую сторону, в конце всё-таки заставил, но проще после этого управлять её вращением не стало. На платье 7 минут тратить не хочется)
Сине-чёрное на всех трёх, извините. Сочувствую/желаю приятного возлияния (хотя если катализатором этого действа является только жена beerware, то просто сочувствую).
Я только один раз смог увидеть на оригинальной картинке бело-золотое, ещё когда первый раз этот хайп был, причем я буквально увидел, как оно из сине-черного "выцветает". С вращающейся танцовщицей мне сильно проще заставить её вращаться в противоположную сторону, хотя и там приходится существенные усилия приложить.
Спасибо, но, думаю, что не хочется жертвовать качеством (я же жертвую качеством с меньшим квантом, верно?) ради пары токенов)
Ещё немного поэкспериментировал сегодня с тремя моделями, всем задавал одну и ту же задачку:
gemma-4-26B-A4B-it-UD-Q4_K_XL (контекст 48k, запускал в мультимодальном режиме с обработкой изображений)
cmoe: 24 t/s
ncmoe=23: 18 t/s
ncmoe=24: 31 t/s
ncmoe=25: 30 t/s
ncmoe=26: 25 t/s
gpt-oss-20b-UD-Q4_K_XL (контекст 64k)
cmoe: 21 t/s
ncmoe=10: 36 t/s
ncmoe=11: 36 t/s
ncmoe=12: 38 t/s
ncmoe=20: 24 t/s
ncmoe=24: 21 t/s
Qwen3.6-35B-A3B-UD-Q4_K_XL (контекст 48k)
cmoe: 9 t/s
ncmoe=31: 20 t/s
ncmoe=32: 27 t/s
ncmoe=33: 22 t/s
ncmoe=34: 20 t/s
ncmoe=35: 18 t/s
ncmoe=40: 11 t/s
И самое интересное, везде прослеживается эта тенденция: загружена только VRAM (вплоть до почти 100%) -- скорость ниже, начинаем залезать в оперативку -- скорость подрастает, но если сильно в неё уходим -- скорость снова падает.
Загрузка видеочипа с cmoe почему-то всегда хилая и очень неровная, в среднем 40-50% или ниже. Как начинаем играться с ncmoe -- нагрузка на чип растёт, всегда выше 80% и зачастую выше 90%.
Шикарный материал (как и предыдущие на ту же тему), спасибо! Благодаря ему даже захотелось вкатиться в эту тему, чего раньше у меня не было)
Если собрать в кучу сведения из текущего материала, а также предыдущий и обсуждения под ним, правильно ли я понял: нет смысла гнаться за степенью заполненности VRAM, главное, условно говоря, насколько в процессе обработки запроса моделька грузит саму GPU (процент её использования)?
Например, у меня 3070Ti на 8 Гб VRAM, 16 (дозаказал ещё 16, на днях поставлю) Гб RAM (DDR4, 3200 Mhz). Вот просто из того железа, что имею на руках (RAM всё равно давно хотел докинуть, так что просто повод нашёлся) хочется выжать максимум.
Взял Qwen3.6-35B-A3B-UD-Q4_K_XL, запустил как есть (по-моему, только -cmoe прописал), контекст поставил 32k вроде (пишу сейчас по памяти, всё равно в итоге на других параметрах остановился). Получил почти полностью забитую VRAM, но использование GPU что-то около 30% (всё как вы и писали) и ~7t/s.
Решил поиграться с -ncmoe, но всё равно целился в то, чтобы VRAM утилизировалась достаточно, в итоге экспериментами дошёл до -ncmoe=35 (не знаю, хорошо ли 35 из 40 слоёв выгружать на CPU, всё равно немного ощущал себя обезьянкой, которая бездумно перебирает чиселки), контекст 48k, скорость получилась порядка 20t/s, GPU грузится на 85-100%, но при этом и VRAM забита, да и в "общую память" (в которой, видимо, 8 Гб настоящей VRAM, и 8 Гб виртуальной, которая на самом деле RAM) на полтора гига забрались. Звоночек тревожный, в общую память не хотелось вылезать, но дальнейшие эксперименты всё равно больше 20 t/s не давали.
Стоит ли продолжать дальше играться с параметрами запуска, пытаться добиться большей скорости, если уже сейчас GPU грузится почти на 100%? Или, возможно, стоит увеличивать размер контекста (вместе с увеличением -ncmoe) для достижения большего качества? И при этом следить за тем, чтобы не вылезать за пределы VRAM?
Сейчас всё тот же криво сформулированный заголовок, о котором я и писал, и который вы процитировали. Я написал "не должен был", потому что ровно так и написано в заголовке.
Вы с своём первом комментарии как раз указали вариант, который, вероятно, пытался вложить в заголовок автор.
Но "оказался таким успешным" и "не должен был оказаться таким успешным" имеет разный смысл, разве не так (даже с припиской "но оказался" лучше не становится)? Чтобы привести его к этому виду с минимальными изменениями, можно просто убрать частицу "не", и получится "Почему никто не ожидал, что механизм «предсказать следующее слово» должен был оказаться так успешен (и оказался)". Но это всё равно кривовато звучит, предложенный вами вариант явно лучше.
Ну и я не писал и даже не намекал, что это признак использования ИИ, я как раз и предположил, что это безграмотность (ну или отсутствие вычитки), хоть явно этого писать и не стал.
На техническом ресурсе статьи в том виде, в каком она есть сейчас, вообще не должно было быть. "Он делал, делал и сделал, сообщение зашифровали, передали и расшифровали обратно, но это стало неактуально и проект прикрыли". На каких принципах работало устройство? Как была представлена речь, как шлифовалась? На каких принципах вообще в то время было основано шифрование нетекстовой информации? Как удалось уложиться в размеры, в несколько десятков раз меньшие, чем у аналогов? Ни одной технической подробности в статье нет, ни-од-ной.
Ого, неожиданно, спасибо. До этого даже и мысли не появлялось попробовать самому, сразу крест на своем железе поставил, но теперь явно попробую.
Видимо, изрядная часть секрета в "full hd", я тоже до сих пор на нём сижу.
Я и в момент анонса особо не разделял всеобщего хейта, а теперь и подавно убеждаюсь, что технология при нормальном тюнинге крайне годная. Правда тем, кто в свое время не успел урвать топовую карточку по адекватной цене (типа меня с 3070Ti) вряд ли в ближайшее время улыбается оценить её в полной мере(
Не, там не всё настолько жёстко (вернее, в ПДД любой пункт - огромное пространство для интерпретаций). Например, там не сказано, что понимается под метрикой "ближайший". Если это "ближайший по прямой", то действительно, таковым может оказаться единственный въезд в зону. Однако если это "ближайший по дорогам", то это плавающее понятие: если единственный проезд от некоторого въезда до точки назначения вдруг стал перекрыт, то ближайшим в этот момент становится другой въезд, из которого достижима точка назначения. Мы выбрали вторую интерпретацию, как минимум потому, что непостроение маршрута - это крайний случай, которого нужно избегать всегда, когда его можно избегать.
Ну и в общем все последующие рассуждения по этой теме у вас опираются на предположении "въезд может быть только один", а мы работаем в парадигме "хоть какой-то проезд да нужно найти".
Да, и это ровно то, что мы делали в первой версии алгоритма, и что в особо плохих кейса работало десятки секунд! Ровно поэтому и понадобилось городить текущее решение со штрафами, и оно оказалось существенно производительнее исходного, причём не только на плохих кейсах, но и в среднем.
Плюс ко всему вышесказанному, множественные запуски A* приведут к кратно большему суммарному количеству перебранных рёбер, поскольку - сейчас пальцем в небо навскидку - порядка 2/3 или 3/4 (а может и больше) рёбер будут перебраны более чем в одном (а то и во всех или почти во всех) из проходов.
Одна волна полностью это исключает.
Все же ставлю на ллм. Посмотрите остальные заголовки и статьи этого автора.
Ого, спасибо за развёрнутый анализ!
Тут вы рассмотрели частный случай - s-p-t. Вы рассматривали, судя по всему, вариант, когда s вне зоны, а t внутри, но, в целом, тот же анализ верен и для обратного случая.
Но эти кейсы как раз и изначально не были особой проблемой (с точностью до одной оговорки, о которой ниже). Самый проблемный кейс - и s, и t внутри разных зон. Потому что здесь может получиться так, что между se - ближайшим к s выездом из стартовой зоны, и te - ближайшим к t въездом в финишную, нет проезда. И начинается, по сути, брутфорс: перебираем пары въездов/выездов и пытаемся между ними построить проезд. При этом надо минимизировать сумму длин проездов внутри зон, поскольку именно в этом их административный смысл. И вот этот перебор - просто смерть для перформанса. Да, ситуация не столь частая, но кога она стреляла, было грустно.
Тут можно сказать: ну так используйте проверку связности, какого чёрта в лоб считать маршрут между каждой парой в переборе, когда можно заранее вычислить компоненты связности и делать проверку за O(1)?! Да, но нет) Тут в игру вступает два фактора:
time-based штуки, т.е. всё, что может по расписанию "рвать" граф; например, перекрытие дороги, которое вступило в силу за 2 минуты (в таймлайне волны, не в реальном времени) до того, как волна к нему подобралась; самый яркий пример - разведение мостов в Питере;
динамические параметры транспортного средства, которые уникальны для каждого запроса: мост, по которому проедет грузовик с фактической массой 3 тонны, обрушит десятитонник; для первого проезд существует, для второго - нет; если это был единственный проезд между некоторым сочетанием въезда и выезда, то для десятитонника надо искать другой вариант, тогда как для трёхтонника подойдёт и этот.
Второй фактор даже важнее первого. При достаточном уровне оптимизации можно было бы динамически пересчитывать компоненты связности (в целом, мы и сейчас уже так делаем). А вот второй фактор - это гигантское множество комбинаций разных значений параметров ТС (в нашем случае оно вообще почти бесконечно, потому что параметры представлены действительными числами, ведь ПДД действительно не налагает на их значения никаких ограничений ни по верхней границе, ни по шагу).
Теперь оговорка, о которой упомянул выше: она тоже связана с time-based. Вариант, когда в финишной зоне считается обратный маршрут N-1 (от всех въездов в неё до единственной финишной точки), мы не можем корректно учитывать time-based (пробки, перекрытия и т.д.), поскольку не знаем, в какой момент доехали до финишной точки, и, как следствие, не знаем ни для одного ребра внутри зоны время попадания волны на него.
Если бы мы знали время, в которое оказались на финише, вопрос решался бы тривиально: при распространении обратной волны мы бы просто вычитали время обратного проезда по ребру из времени проезда по предыдущему ребру, вместо того, чтобы суммировать, как в прямой версии алгоритма. Но мы не знаем)
В первой (многоволновой) версии алгоритма мы решали это крайне тупо - просто эвристически предполагали, сколько мог бы занять проезд до финиша. Надо ли говорить, насколько это было неточно?)
В общем-то, обо всём этом (правда, куда менее подробно; попробую учесть это для будущих статей и добавлять побольше деталей) я писал в статье, в разделе "Грузовые маршруты: вариант первый".
Теперь несколько ваших тезисов, которые считаю важным прокомментировать.
Тут важно вот что: да, действительно, пока маршрут строится внутри зоны после "просачивания" волны через лучший въезд, перебор также идёт и вне её. Однако ключевую роль здесь играет соотношение весов: как только волна протекла внутрь зоны, она начинает стремительно двигаться к финишу (тут ещё играет фактор того, что строиться с этого момента начинает оптимальный не по времени, а по длине (т.е. кратчайший) маршрут, это тоже требование ПДД к проезду внутри зон; таким образом, пробки для этой части волны уже не помеха. Таким образом, с этого момента эвристический штраф, являющийся одной из составляющих веса ребра в очереди на обработку, начинает почти стабильно уменьшаться у рёбер внутри зоны; веса же рёбер вне зоны почти так же стабильно будут лишь расти, поскольку они уже "облепили" (или в какой-то момент сделают это) границу зоны и дальше могут только отдаляться от неё, всё увеличивая свой вес (причём по обеим составляющим - и по фактической стоимости, и по эвристической) и всё снижая вероятность выбора на очередном шаге волны. Конечно, это полностью не исключает того, что волна будет периодически перекидываться за границы зоны уже после того, как оказалась внутри неё, но всё же это не будет иметь такого серьёзного эффекта, как вы представляете, и со временем будет происходить всё реже, поскольку волне всё выгоднее будет продолжать перебор только внутри зоны, где веса растут только по одной составляющие - фактической.
Верно, а ещё выигрываем в точности учёта time-based)
К сожалению, нельзя. Дело в том, что в конкретный момент времени ближайший вход может оказаться недостижим; всё те же чёртовы time-based :D Именно для этого сделана прогрессия штрафов: если такое происходит, будет естественным образом выбран следующий по "ближайшести" вход. В целом, это скорее исключительная ситуация, но задел на её обработку обязан быть, поэтому обрубать распространение вне зоны нельзя.
И правильно, там тот же слоп, что и в заголовках.
До сих пор не понимаю, люди, которые потом в комментах серьезно и позитивно обсуждают этот... кхм... материал — они действительно не осознают, чем их только что накормили, или уже смирились и считают, что это окэй? Если первое — неужели надо обладать каким-то особым когнитивными навыками, чтобы за полтора слова распознавать слоп?
Потому что это классический высер ллмки, как, впрочем, и сам текст статьи. Достаточно полистать ленту, и можно с завидной (нет) регулярностью обнаружить заголовки, сформированные по подобному паттерну.
Нейронку уже попросили сгенерировать эту статью от начала до конца...
С тех пор как год назад купил дек, на ПК прошел только одну игру — недавний 007 First Light. Всё остальное — дек. Игровые сессии и по несколько часов подряд случались, так что с аргументом про неудобство, тяжесть, температуру не согласен. За этот год игр пройдено больше, чем за предыдущие пять вместе взятых (и это как минимум), благодаря, опять же, деку. Я его существование воспринимаю крайне позитивно.
В остальном в комментариях выше люди расписали мои мысли по поводу сказанного в статье. Наверное, автору просто надо было кого-то обвинить в текущем состоянии индустрии, а ответ же вот, на поверхности — это свитч с деком виноваты! На проверку же, как мне видится, всё куда сложнее, куда глубже и началось гораздо раньше, чем свитч с деком хотя бы в проекте появились, не то что релизнулись.
На мой взгляд, польза от lmgtfy как минимум в том, что скидывающий ссылку сформулировал такой поисковый запрос, выдача на который как раз содержит ссылки на материалы с ответом. То есть предполагалось, что топикстартер был не в состоянии (или же вообще не пытался) достаточно кратко и ёмко сформулировать свой вопрос, потому гугл ему ничего внятного и не выдал. И зачастую это предположение было правдой, поэтому отвечающий всё же проделал некоторую работу за топикстартера.
По моим воспоминаниям на момент релиза Виста действительно была глючной неюзабельной тварью, но со временем её допилили и к релизу семёрки уровень раздражения от висты был не выше, чем от самой семёрки.
Этот хинт работает, только если работает) у меня, например, не сработал.
У меня однажды получилось, но больше не получается. Правда, с тех пор я особо сильно не старался.
Но у меня и с балериной так - однажды около 7 минут пытался заставить её вертеться в другую сторону, в конце всё-таки заставил, но проще после этого управлять её вращением не стало. На платье 7 минут тратить не хочется)
Сине-чёрное на всех трёх, извините. Сочувствую/желаю приятного возлияния (хотя если катализатором этого действа является только жена beerware, то просто сочувствую).
Я вижу сине-чёрное.
Я только один раз смог увидеть на оригинальной картинке бело-золотое, ещё когда первый раз этот хайп был, причем я буквально увидел, как оно из сине-черного "выцветает". С вращающейся танцовщицей мне сильно проще заставить её вращаться в противоположную сторону, хотя и там приходится существенные усилия приложить.
Спасибо, но, думаю, что не хочется жертвовать качеством (я же жертвую качеством с меньшим квантом, верно?) ради пары токенов)
Ещё немного поэкспериментировал сегодня с тремя моделями, всем задавал одну и ту же задачку:
gemma-4-26B-A4B-it-UD-Q4_K_XL (контекст 48k, запускал в мультимодальном режиме с обработкой изображений)
cmoe: 24 t/s
ncmoe=23: 18 t/s
ncmoe=24: 31 t/s
ncmoe=25: 30 t/s
ncmoe=26: 25 t/s
gpt-oss-20b-UD-Q4_K_XL (контекст 64k)
cmoe: 21 t/s
ncmoe=10: 36 t/s
ncmoe=11: 36 t/s
ncmoe=12: 38 t/s
ncmoe=20: 24 t/s
ncmoe=24: 21 t/s
Qwen3.6-35B-A3B-UD-Q4_K_XL (контекст 48k)
cmoe: 9 t/s
ncmoe=31: 20 t/s
ncmoe=32: 27 t/s
ncmoe=33: 22 t/s
ncmoe=34: 20 t/s
ncmoe=35: 18 t/s
ncmoe=40: 11 t/s
И самое интересное, везде прослеживается эта тенденция: загружена только VRAM (вплоть до почти 100%) -- скорость ниже, начинаем залезать в оперативку -- скорость подрастает, но если сильно в неё уходим -- скорость снова падает.
Загрузка видеочипа с cmoe почему-то всегда хилая и очень неровная, в среднем 40-50% или ниже. Как начинаем играться с ncmoe -- нагрузка на чип растёт, всегда выше 80% и зачастую выше 90%.
Шикарный материал (как и предыдущие на ту же тему), спасибо! Благодаря ему даже захотелось вкатиться в эту тему, чего раньше у меня не было)
Если собрать в кучу сведения из текущего материала, а также предыдущий и обсуждения под ним, правильно ли я понял: нет смысла гнаться за степенью заполненности VRAM, главное, условно говоря, насколько в процессе обработки запроса моделька грузит саму GPU (процент её использования)?
Например, у меня 3070Ti на 8 Гб VRAM, 16 (дозаказал ещё 16, на днях поставлю) Гб RAM (DDR4, 3200 Mhz). Вот просто из того железа, что имею на руках (RAM всё равно давно хотел докинуть, так что просто повод нашёлся) хочется выжать максимум.
Взял Qwen3.6-35B-A3B-UD-Q4_K_XL, запустил как есть (по-моему, только -cmoe прописал), контекст поставил 32k вроде (пишу сейчас по памяти, всё равно в итоге на других параметрах остановился). Получил почти полностью забитую VRAM, но использование GPU что-то около 30% (всё как вы и писали) и ~7t/s.
Решил поиграться с -ncmoe, но всё равно целился в то, чтобы VRAM утилизировалась достаточно, в итоге экспериментами дошёл до -ncmoe=35 (не знаю, хорошо ли 35 из 40 слоёв выгружать на CPU, всё равно немного ощущал себя обезьянкой, которая бездумно перебирает чиселки), контекст 48k, скорость получилась порядка 20t/s, GPU грузится на 85-100%, но при этом и VRAM забита, да и в "общую память" (в которой, видимо, 8 Гб настоящей VRAM, и 8 Гб виртуальной, которая на самом деле RAM) на полтора гига забрались. Звоночек тревожный, в общую память не хотелось вылезать, но дальнейшие эксперименты всё равно больше 20 t/s не давали.
Стоит ли продолжать дальше играться с параметрами запуска, пытаться добиться большей скорости, если уже сейчас GPU грузится почти на 100%? Или, возможно, стоит увеличивать размер контекста (вместе с увеличением -ncmoe) для достижения большего качества? И при этом следить за тем, чтобы не вылезать за пределы VRAM?
*Статья написана при поддержке картеля производителей детских шампуней.
Сейчас всё тот же криво сформулированный заголовок, о котором я и писал, и который вы процитировали. Я написал "не должен был", потому что ровно так и написано в заголовке.
Вы с своём первом комментарии как раз указали вариант, который, вероятно, пытался вложить в заголовок автор.
Но "оказался таким успешным" и "не должен был оказаться таким успешным" имеет разный смысл, разве не так (даже с припиской "но оказался" лучше не становится)? Чтобы привести его к этому виду с минимальными изменениями, можно просто убрать частицу "не", и получится "Почему никто не ожидал, что механизм «предсказать следующее слово» должен был оказаться так успешен (и оказался)". Но это всё равно кривовато звучит, предложенный вами вариант явно лучше.
Ну и я не писал и даже не намекал, что это признак использования ИИ, я как раз и предположил, что это безграмотность (ну или отсутствие вычитки), хоть явно этого писать и не стал.