Ычан: [d | b / bro / hr / l / m / mu / o / s / tran / tu / tv / vg / x | a / aa / c / fi / jp / rm / tan / to / vn]
[Назад] [Вся нить] [Последние 50 сообщений]
Ответ в нить [Последние 50 сообщений]
Имя
Animapcha image [@] [?]
Тема   ( ответ в 28139)
Сообщение
flower
Файл 
Пароль  (для удаления файлов и сообщений)
Параметры   
  • Прежде чем постить, ознакомьтесь с правилами.
  • Поддерживаются файлы типов GIF, JPG, MP4, PNG, WEBM, WEBP размером до 5120 кБ.
  • Ныне 3800 unique user posts. Посмотреть каталог
  • Предельное количество бампов нити: 500
junior_vibecoder_a_ko.png - (242.50KB, 720×720)
28139
No. 28139  
Здесь можно получить помощь и консультацию по любому языку программирования, в любой сфере разработки. Не важно, программируете ли вы собственного робота, пишете серверную приблуду, интегрируете чужие API, ковыряете игру, или пытаетесь сделать сайт на Wordpress - если аноним что-то об этом знает, он обязательно поможет.

Пополняемая база знаний: http://pastebin.com/AGhLZppH

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

Другие тематические нити (бывает, обновляется): https://pastebin.com/psy43ibG

Примеры кода лучше выкладывать в виде ссылок на http://pastebin.com или http://ideone.com
Фронтендные вещи лучше выкладывать на http://jsfiddle.net

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

Чтобы не сбивать новичков с толку, а также не разбавлять полезную информацию мусором, беспредметные споры типа "какой язык / парадигма / библиотека / етц лучше" здесь запрещены. Для подобных вещей теперь есть отдельная диспутов нить >>/dev/21353

Если здесь поселится достаточное количество программистов на одном языке / одной сферы, можно будет их выделить в отдельную нить, а в этой оставить на неё ссылку.
По мере поступления вопросов можно составлять FAQ и базу знаний.

Архив нитей:
http://410chan.org/dev/arch/res/14160.html
http://410chan.org/dev/arch/res/15681.html
http://410chan.org/dev/arch/res/17424.html
http://410chan.org/dev/arch/res/19666.html
http://410chan.org/dev/arch/res/21641.html
http://410chan.org/dev/arch/res/23830.html
http://410chan.org/dev/arch/res/25965.html

Прошлая нить пока тонет тут: >>/dev/25965
17 сообщений пропущено. Показаны 50 последних сообщений
No. 28176  
>>28175
Спасибо за ответ, друг! Я вот сегодня решил поставить оракл, посмотреть как у них всё устроено например. Планирую дальше изучать OLAP и более крупные СУБД
No. 28177  
>>28176
Рад помочь! Заходи если что, рассказывай о прогрессе, задавай вопросы. OLAP прикольная вещь, но часто недопонятая. Обычно с ним пытаются взаимодействовать как с обычной СУБД, думая что это такая магическая коробка, которая просто делает все запросы быстрее, в то время как по задумке требуется грамотная реорганизация данных, и что самое важное, предварительная подготовка срезов часто запрашиваемых данных в статический вид.
No. 28178  
>>28177
А сам ты чем занимаешься? Работаешь или учишься? Что интересное находишь в разработке?
No. 28179  
>>28178
Работаю, занимаюсь всем подряд, даже пару раз пришлось для рабочих нужд язык (DSL) написать, но в основном backend, в основном API, обработка потоков данных. Пожалуй, самое интересное в разработке - это общение с другими программистами, обмен идеями, и jolly cooperation, ну и конечно же когда удается сделать вот этими вот своими руками что-нибудь лучше, чем оно было. А что ты нашел для себя?
No. 28180  
>>28179
Круто, не слышал раньше про DSL... Потоки данных это типа стриминг? Под общением с другими программистами ты имеешь в виду на работе или на борде? Я вот хотел поискать борды для программистов, но везде сидят или токсики-вахтеры, или как здесь пару человек пишет...

> А что ты нашел для себя?
Мне нравится SQL... Писать запросы, оптимизировать... С одной стороны это не совсем настоящее программирование, но с другой мне нравится работать с данными...
No. 28181  
>>28180
>Потоки данных это типа стриминг?
Да, но у нас когда говоришь "стриминг" часто понимают "видео-стриминг", а тут просто данные гуляют

>Под общением с другими программистами ты имеешь в виду на работе или на борде?
Везде, где удается пообщаться, лишь бы со смыслом

>Я вот хотел поискать борды для программистов, но везде сидят или токсики-вахтеры, или как здесь пару человек пишет...
Оставайся с нами, чо. Чтобы не открывать по 20 раз в день медленный раздел, подписывайся на RSS: https://410chan.org/dev/rss.xml
Мне низкая скорость в чем-то и лучше, очень мало свободного времени

>С одной стороны это не совсем настоящее программирование, но с другой мне нравится работать с данными...
Лучше делать именно то, что нравится, тем более индустрия твой интерес к работе с данными поддерживает. Но пробовать самые разные языки и формы программирования тоже весело, там тебя могут ждать новые открытия и увлечения, пробуй!
No. 28182  
>>28181
Спс, но на счёт RSS я плохо разбираюсь... Нужно какое-то расширение в браузер?
No. 28183  
>>28182
Можно и расширение в браузер, но можно и воспользоваться ботом, чтобы тот тебе обновления по RSS пересылал в Дискорд или Телегу например:
https://github.com/Rongronggg9/RSS-to-Telegram-Bot
No. 28184  
tears_in_the_rain.jpg - (432.22KB, 1137×1000)
28184
>>28140
>В процессе систематизация прошлой нити для пополнения базы знаний

Наконец-то перечитал всю нить и систематизировал информацию. По ощущениям насобиралось всякого больше, чем раньше:

>Материалы для вкатывания в C#, собранные пассажиром
>>/dev/26723

>С чего начинать бэкенд разработку на Node.js?
>>/dev/26508

>Посоветуйте хорошую бумажную книгу по Python
>>/dev/26091
>И бумажных книг по юнит-тестированию на Python
>>/dev/26099

>Подскажите курсы / тренинги по сетям и многопоточке на C++
>>/dev/26138
>Чем отличается мьютекс от семафора?
>>/dev/26791
>Есть ли разница между sem_open("test") и sem_open("/test")?
>>/dev/27704
>Посветуйте книг по юнит-тестированию на C++
>>/dev/26108
>>/dev/26110

>Обязательно ли знать C++ чтобы заниматься разработкой компиляторов?
>>/dev/26174
>Список литературы для создателей компиляторов
>>/dev/26177

>Посоветуйте курсы по программированию микроконтроллеров
>>/dev/27924

>Посоветуйте материалы новичку по Qt
>>/dev/27100

>Как написать Linux-demon?
>>/dev/27010

>Хочу создать VN на Java с libGDX, помогите
>>/dev/27683
>Конвертируем SHIFT-JIS в UTF-8 в контексте скриптов японских визуальных новелл
>>/dev/26079
>Подскажите инструмент для построения графа диалогов VN на RenPy
>>/dev/27062

>Подскажите C++ библиотеку для работы со старыми .doc-файлами
>>/dev/26081

>Подскажите самый простой способ с минимумом зависимостей сделать свой index.html доступным по ссылке?
>Docker
>>/dev/27719
>девелоперские сервера в среде исполнения
>>/dev/27713

>Рекламируем форматировалку для OpenSCAD
>>/dev/27992

>Рекламируем базированную книгу по оптимизации
>>/dev/28035

>Набор интересных ссылочек, начинающийся с >>/dev/28043
No. 28185  
framed.jpg - (1.02MB, 849×1200)
28185
>>28140
>>28184
И отдельно бы хотелось выделить специфику по C и C++, за которую отдельное спасибо разбирающимся пассажирам

>Немного специфики по C
>Что за тип const char ★ const ★ в C?
>>/dev/26938
>Переводчик с C-шных типов на человеческий
>>/dev/26940
>Проясните особенности работы C-шного fgets
>>/dev/26167

>Много специфики по C++
>Расскажите об исключениях в конструкторе и деструкторе в C++
>>/dev/26903
>>/dev/26905
>Расскажите про препроцессорные макросы в C++
>>/dev/26916
>Зачем вкладывать анонимный неймспейс в именной неймспейс в C++?
>>/dev/26920
>>/dev/26924
>Зачем нужно override в C++?
>>/dev/26351
>Что лучше: string_view или константная ссылка на string (C++)?
>>/dev/26951
>>/dev/26952
>Поясните разницу между static_cast, dynamic_cast и reinterpret_cast (С++)
>>/dev/27071
>Глобальный массив vs статический массив (C++)
>>/dev/27112
>Поясните поведение sizeof (С++)
>>/dev/27155
>>/dev/27162
>В чем принципиальная разница между std::thread и std::async?
>>/dev/27438
>>/dev/27440
No. 28195  
410localhost.png - (122.19KB, 997×599)
28195
Как думаете, если скормить локальное зеркало Автобуса ЛЛМке, что будет?
No. 28199  
>>28195
Думаю, если речь именно про обучение LLM, и о том чтобы производить его только зеркалом Автобуса, то скорее всего LLM даже связную фразу выдать не сможет, слишком мало данных для обучения.

Если речь о том, чтобы подгрузить зеркало Автобуса в LLM как RAG - может выйти так, что это уже слишком много данных, для такого контекста.

О каком из двух вариантов речь?
No. 28201  
>>28199
Скорее о третьем варианте — шаг за шагом суммаризировать автобус, потом суммаризировать ранее суммаризированные куски вместе и т.д., пока не останется несколько страниц текста (a.k.a. файл SCP), полностью отражающие его суть
No. 28202  
>>28201
Очень интересное исследование, хотелось бы узнать!
No. 28203  
>>28195
> Как думаете, если скормить локальное зеркало Автобуса ЛЛМке, что будет?
Если бездумно кормить ЛЛМке html, не перегнав в Markdown хоть как-то, то будет долго и дорого - этот (едва начавшийся) тред у меня занял 10к токенов. Седьмой тред занял 125k 125349 токенов. Использовал локальную Qwen3.5-122B-A35B в MXFP4, llama.cpp + rocm7.2 - железка сожрала 97Gb после обработки контекста во время генерации ответа.
Держите в уме, что эта модель большая и не про RAG. Для RAG я бы использовал сильно меньшие модели и, соответственно, более быстрые - примерно в четыре раза быстрее PP, что критично.

8 тред:
10392 tokens на вход, 1230 на выход.
303 pp t/s
19.92 tg t/s

7 тред:
125349 tokens на вход, 8232 на выход.
161 pp t/s
13.5 tg t/s

В остальном вот вывод невросетошки по первому и второму треду:
txt (вывод в md): https://cloud.containercat.com/s/76e6izZwSJ7ZCrC
pdf: https://cloud.containercat.com/s/o79JJHoNKgQHCaa
No. 28204  
>>28203
Ого, ты даже перешёл к практике.
По моим наблюдениям 122B избыточна даже для чрезвычайно сложных технических задач. Я фактически 3.5-27B поручаю нечто уровня научной работы. Для суммаризации же можно использовать гораздо более простые модели. Даже gpt-oss-20b показывала себя отлично. Жаль, что она не мультимодальна, ведь на мой взгляд тамбнейлы задают тон всему Автобусу.
No. 28225  
Как вам глубина анализа?
No. 28226  
>>28225
Майор Судзумия?
No. 28227  
>>28225
Из-за того что Qwen не видит картинок - не может уловить смысл основанный на сочетании картинки с текстом. Это сильно мешает улавливать юмор или иронию, увы.
No. 28229  
>>28227
Видит пересжатые в webp миниатюры. Чаще он понимает всё, это просто забавный момент.
No. 28234  
Я просто оставлю это тут.>

https://youtube.com/watch?v=BsfXZjKLT9A
No. 28238  
our.webp - (14.99KB, 660×432)
28238
Продолжаю сворачивать в компактный текстовой отчёт наше общее ризоматическое шевеление. Две недели расчётов заставили задуматься, но не решиться на покупку второй видеокарты. Даже не спрашивайте, сколько сотен миллионов токенов input, сколько миллионов — output: сам уже сбился со счёта. И это еще только первая фаза обработки.

Это слепок сайта 20.03.2015 года с "общими" разделами /b/, /dev/ и /cu/. Раздел /int/ исключён как гостевой.
Визуальный контент представлен только миниатюрами. Это, пожалуй, ошибка — возможно, получится включить полноразмерные картинки для последних еще не обработанных тредов.

В качестве моделей использовались Qwen3.6-27B, Qwen3.6-35B-A3B, Qwen3.5-27B. Остановился на последней. MoE ведёт себя нестабильно на длинной дистанции, а линейка 3.6 будто бы слишком серьёзная для русско-японских каламбуров. Любая модель, конечно, ошибается, ничего не зная о Лурке и глубоком лоре дна рунета. Часть ошибок исправляю сам — другие, надеюсь, самоскомпенсируются при составлении финальных документов. Квант — Unsloth UD-Q5_K_XL, KV-кэш — q8_0, длина контекста — 128к, настройки инференса — thinking mode for precise coding tasks.

Переезд с ollama на llama.cpp тонкой настройки дал ускорение на 25%. Так что треды из /b/ разбираются и анализируются со скоростью 5 тредов в час. Да, не быстро, но терпимо. Когда же всё это закончится.
No. 28239  
>>28238
Жду с нетерпением. Предварительные результаты уже позабавили немало.
No. 28241  
Продолжаю сжимать, и вот некоторые наблюдения.
Оказалось, что даже на такой старой карточке, как у меня (V100 32GB), можно делать MTP (multi-token prediction).
Использование MTP-моделей, вместе с включенным спекулятивным выполнением (опции --spec-type draft-mtp и --spec-draft-n-max N в llama.cpp), дают ускорение до двух раз (число N подбирается экспериментально от 1 до 6, и используется то, которое даёт самый высокий draft acceptance). MTP требует где-то на гигабайт больше VRAM.

Ускорение инференса позволило перейти к анализу действительно больших тредов с полноразмерными картинками. Рутинные операции удалось автоматизировать скриптами (скачивание и преобразование картинок, извлечение имён файлов картинок, создание промптов для субагентов, вставка описаний картинок из jsonl-файлов обратно в тред).

Вот три модели — короли на потребительском железе:

1. Qwen 3.5 27B. Из минусов: типично ЛЛМный стиль письма ("не то, а это"), часто приукрашает реальность, склонен к поиску глубинного смысла и галюнам на ровном месте. Он многое находит, но после него часто нужно исправлять места, где он катастрофически лажает.

2. Qwen 3.6 27B. Напоминает помесь Терминатора, пробивающего кирпичную кладку головой, с Шелдоном Купером из Big Bang Theory. Чуть лучше пишет, не забывая при этом изредка коверкать грамматику (не сказал бы, что он в этом значительно хуже 3.5). Так же трудолюбив, что может приводить к высасыванию фактов из пальца.

3. Gemma 4 31B. Парадокс этой модели в том, что она не зарывается слишком глубоко, и поэтому меньше лажает, требует меньше контроля. Её ответы короче, более лаконичные и часто содержат неудобную правду, на которую Qwen с радостью бы закрыл глаза. Более того, она чрезвычайно устойчиво следует инструкциям, если они простые, когда всё уже автоматизировано.

Для Геммы я использую тоже пятибитные кванты от Unsloth. Но из-за того, что Gemma требует больше памяти, приходится запускать только один слот (--parallel 1).
Сейчас вот с такими опциями гоняю:

llama-server \

    --host 0.0.0.0 \
    --port 8080 \
    --model unsloth-Gemma-4-31B-it/gemma-4-31B-it-UD-Q5_K_XL.gguf \
    --mmproj unsloth-Gemma-4-31B-it/mmproj-F16.gguf \
    --model-draft unsloth-Gemma-4-31B-it/gemma-4-31B-it-Q8_0-MTP.gguf \
    --alias 'gemma4' \
    --jinja \
    --gpu-layers all \
    --temp 1.0 \
    --top-p 0.95 \
    --top-k 64 \
    --ctx-size 98304 \
    -ctk q8_0 -ctv q8_0 \
    -b 1024 -ub 1024 \
    --spec-type draft-mtp \
    --spec-draft-n-max 4 \
    --parallel 1 \
    --ctx-checkpoints 12 \
    --checkpoint-min-step 16384 \
    --cache-ram 0 \
    --no-cache-idle-slots

No. 28242  
Должен отметить пару моментов.
В llama.cpp (в недавних версиях b9848 и b9986, во всяком случае) инвалидация чекпоинтов довольно агрессивная. Если единственный слот переключается на новый промпт (промпт субагента), происходит инвалидация чекпоинтов основного агента. Поэтому, вне зависимости от значения --ctx-checkpoints, после завершения субагента происходит полный репроцессинг контекста. Это всё видно, если повысить уровень логгирования до trace (--verbosity 4).

Во-вторых, при повышении --spec-draft-n-max иногда draft acceptance падает медленнее, чем растёт скорость токенов в секунду, и при меньшей доли принятия токенов, суммарно скорость всё равно получается немного выше. Поэтому не следует слепо ориентироваться только на draft acceptance. При выставленном значении 4 у меня, например, иногда draft acceptance падает даже до 0.6, но в среднем колеблется вокруг цифры 0.8, а при значении 2 — почти всегда выше 0.9. Однако итоговая скорость у значения 2 оказывается ниже, чем у значений 3 или 4.

В общем, для выполнения на одном слоте модели Gemma 4 31B на сборке b9986 на ПК с 16 гигами ОЗУ я экспериментально нашёл самыми производительными настройки:

<       --ctx-checkpoints 12 \

<       --checkpoint-min-step 16384 \
<       --cache-ram 0 \
<       --no-cache-idle-slots
---
>       --ctx-checkpoints 2 \
>       --checkpoint-min-step 32768 \
>       --verbosity 4 \
>       --cache-ram 8192 \
>       --cache-idle-slots


Восьми гигов кэша хватает для того, чтобы мгновенно восстанавливать работу основного агента после завершения одного субагента. Параллельный запуск нескольких субагентов я запретил на уровне AGENTS.md, так что эту ситуацию даже не тестировал.
No. 28243  
3d23c9c0821.webp - (69.87KB, 500×461)
28243
Все треды были проанализированы (по отдельности) несколько часов назад.
Большие треды анализировались сразу Геммой, используя полноразмерные картинки.
Анализ треда сразу учитывался как чистовик.

А для тредов, которые анализировались еще в июне, когда процесс был не отлажен, я запустил еще одну итерацию самморизации/рецензирования. Я называю это второй фазой ("Фаза два? Что еще за фаза два?"). Так что около тысячи тредов пережёвываются к краткую форму со скоростью 30 шт/сек. Через полтора суток у меня будет несколько мегабайт несколькокилобайтных файлов, которые еще не до конца понятно, как превращать в рефераты b.md, cu.md и dev.md. Но я что-нибудь придумаю.
No. 28244  
30 штук в час, конечно же, лол
No. 28245  
Buckaroo.webp - (304.80KB, 1344×1148)
28245
Ya ustal, ничего еще не сделав.
Оказывается, скрипты пропустили неархивные треды, находящиеся дальше первой страницы: примерно 90 тредов в /b/, 80 — в /cu/ и еще 260 — в /dev/.
No. 28246  
тащемта.webp - (144.55KB, 957×928)
28246
А вот что меня знатно удивило — многие треды на этих страницах отсутствуют и на текущем автобусе, в том числе в архиве. А я верил, все треды попадают в рай.
No. 28247  
>>28246
Насколько я понимаю, перемещение в архив это хоть и не ручной процесс, но инициируется вручную. Получается архив - избранная коллекция нитей, Золотой Фонд!
No. 28248  
12Monkeys.webm - (2.58MB, 535×360)
28248
Ну и в чём он не прав?!11 Финальный отчёт: https://pastebin.com/bwi2ttjD

Отчёты по разделам:

b: https://pastebin.com/pQ3KH0Tk (черновик: https://pastebin.com/sGCwMSe3 - 71 KB)

dev: https://pastebin.com/fv71UFjs (черновик https://n0paste.eu/PJ7KV5Q/ - 165 KB)

cu: https://pastebin.com/AAQHfaSQ (черновик https://pastebin.com/F5WuphBS - 76 KB)
No. 28249  
>>28248
Как минимум, слишком много первой пятилетки и слишком мало всего остатльного.
No. 28250  
>>28249
Справедливое замечание. Я нашёл 649 новых тредов и запустил анализ десятилетия.
No. 28266  
1782934.webp - (110.44KB, 506×767)
28266
MoE-моделька 26B A4B позволяла запускать 4 слота с контекстом 128к у каждого, суммарной скоростью (n_decoded) около 120-160 t/s. За ней нужен глаз да глаз. Меня хватило на два дня. Думаю, её способность так экономно использовать VRAM для контекста связана с в два раза меньшим количеством слоёв. Мне она показалась чуть более стабильной, чем Qwen 35B, но у всех этих маленьких MoE-моделей у всех одни и те же проблемы — они много путаются и отклоняются от инструкций.

Сейчас я перешёл на другой интересный вариант — 31B QAT.
Google делает варианты квантованных моделей, которые дообучены так, чтобы в квантованном виде быть почти такими же производительными, как оригиналы. Я по привычке взял GGUF-файлы у Unsloth (не уверен, что в этом есть смысл).
https://huggingface.co/unsloth/gemma-4-31B-it-qat-GGUF

Т.е. это 4-битный квант, но по интеллекту выше, чем классический 4-битный квант. И поскольку это 4-битный квант, он занимает меньше видеопамяти, чем 5-битный, позволяя выделить больше памяти под контекст. В данный момент я запустил 2 слота по 96к контекста у каждого с суммарной скоростью, доходящей до 50-55 токенов в секунду. И prompt processing тоже раза в 2.5 медленнее, чем у 26B. Но это быстрее, чем классический 5-битный квант где-то на 25-30%. И, если не смотреть просто на токены в секунду, а примерно прикидывать по скорости реальной работы, 31 QAT в 2 раза медленнее 26B, когда 26B не сбоит. Это неплохая золотая середина. Это бесконечно более стабильная модель — её можно оставлять на многие часы без присмотра.

Текущие настройки (V100 32GB и 32GB ОЗУ): https://pastebin.com/FVfnC5tw
No. 28268  
>>28266
А почему ты не используешь dense модели? В VRAM влезть должно.

Gemma4 31б в твоём случае, может быть, и сойдёт, но tool calling у неё очень плох.

мимо использую Strix Halo и Qwen3.6-35B Q8
No. 28269  
Перечитал >>28266.

>4 слота с контекстом 128к у каждого, суммарной скоростью (n_decoded) около 120-160 t/s.
Это на "народной" V100 и заполненном до 120k контексте MoE выдаёт столько на tg? Неплохо, конечно, да уж. А какой pp в начале и в конце контекста?
No. 28270  
>>28269
Когда один слот активен, pp начинается с 1800 t/s и при заполненном контексте становится около 800 t/s. Когда все слоты активны, там поменьше, я уже не помню.
У Gemma 4 31B гораздо хуже: начинается с 850 t/s, заканчивается на 350 t/s.

>>28268
>А почему ты не используешь dense модели?
Так Gemma 4 31B — это и есть dense-модель.
А Qwen3.6-35B Q8 — это как раз не dense-модель.
> У Gemma4 31б tool calling очень плох
По сравнению с 26B A4B это tool calling уровня бог.
No. 28271  
Pastebin нонче вообще ничего не хранит.
Вот опции обеих моделек, если интересно:
https://pastelink.net/hkw6u90d
No. 28272  
Было бы идеально, если бы Гемма смогла сварганить
что-то вроде https://scpfoundation.net/scp-2602
No. 28273  
>>28270
Читал по-диагонали, но вообще всё сходится - dense медленнее и "умнее", moe - быстрее, но "поверхностнее".
Только pp оч сильно падает, почему так?

Под слотом ты имеешь в виду один запрос в llama-cpp (не знаю, что у тебя в качестве фронта; подозреваю, что Open WebUI).

>По сравнению с 26B A4B это tool calling уровня бог.
А расскажи, как ты агентов используешь, ну и тулы в целом. Откуда-то берёшь? Сам пишешь?
No. 28275  
В качестве фронта — qwen-code (форк Gemini CLI) в отдельном tty под отдельным пользователем в chroot-окружении с минимумом самого необходимого, в режиме YOLO (действует самостоятельно бесконечно долго, если не прервать или если что-то не сломается или пока не решит, что работа завершена).

Qwen-code — обычная приложуха на ноде. Ставится свежий Node через nvm (в /home, без рута). Дальше в эту свежую ноду ставится qwen-code.

Минус qwen-code — огромный системный промпт. Подумываю попробовать другие агенты (например, pi), но пока руки не дошли.

Скрипты по большей части писал Qwen, потом Gemma. Некоторые я вручную исправлял. В целом pipeline спланировал сам.
No. 28279  
>>28273
Слот в llama.cpp — это поток с отдельным контекстом. Инференс в слотах происходит параллельно. При этом немного растёт суммарная скорость, но не так сильно, как если бы это были отдельные видеокарты. Грубо говоря, 4 слота будет суммарно выдавать процентов на 20 больше токенов, чем один слот.
Т.е. например, "--ctx-size 524288 --parallel 4" означает, что 512к контекста будет разделено на 4 параллельных слота с контекстами по 128к. Веса модели при этом хранятся в видеопамяти только один раз. KV-кэш у слотов в видеопамяти раздельный, если не использовать unified KV cache (не очень понимаю смысл).
Для агентов слоты очень удобны, т.к. иногда полезно запустить субагента, чтобы он что-то быстро обработал в отдельном контексте и отчитался основному агенту. Агент может запустить сразу пачку субагентов, чтобы они что-то проанализировали. В моём случае субагенты используются для анализа изображений. И они работают в отдельных слотах. Они занимают все слоты, а когда заканчивают работать, промпт основного агента достаётся из кэша промптов (см. 22 гига в опциях), и агент мгновенно продолжает работу.
No. 28281  
>>28279
Огонь, спасибо - не знал.

У меня llama-cpp на железке чисто ради задачек по обработке документов (помогаю подруге друга с учёбой в универе). Там простецкий сетап - Open WebUI + Qwen3.6-35B в Q8 + Qwen3.6-27b в Q4. С MTP терпимо выходит по PP и TG, на большом контексте (200к+ токенов) прям 35B хороша - 25-30 токенов/с TG очень радует.

И вайбкотинг хорош, хотя я только начинаю с этим возиться (агенты, MCP и т.д.).
No. 28282  
nobudy.webp - (44.02KB, 1612×808)
28282
Штош, вот итоги 2015-2026.
На всякий случай, заливаю всё в несколько зеркал.
2026_dev: https://termbin.com/ezgu https://n0paste.eu/5LVS4G6/ https://pastebin.com/NY9TWY6p
2026_b: https://termbin.com/sfdbd https://n0paste.eu/DYrb4O6/
2026_cu: https://termbin.com/713c https://n0paste.eu/8BmaPin/ https://pastebin.com/YkuKCEyW
Психопрофиль: https://termbin.com/2vlq https://n0paste.eu/swkO0H6/ https://pastebin.com/trwVVv9V
No. 28283  
>>28282

「バーナム効果でググれ」
No. 28285  
>>28283
Справедливости ради, должен заметить:
1. Описание в психопрофиле не общее, а очень даже весьма конкретное.
2. Оно совершенно не лестное, и я сам готов спорить с некоторыми пунктами. Например, я убеждён, что иногда чрезмерный интеллектуализм ("Power-User подход") также идёт в ироничном ключе для создания комического эффекта, и Gemma просто не понимает такие шутки. Я также не уверен, корректно ли она оценивает доброжелательность. Мне кажется, она что-то немного не понимает в местном стиле общения. "Травматическая солидарность" — достаточно общий вывод на основе довольно небольшого числа тредов, которые у меня не задерживаются в памяти, однако они там есть.
Блин, я вот в последние полтора месяца много раз читал краткие описания тредов и думал: "Не, ну это точно 100% галлюцинации нейросетки". Потом открываю тред, а там именно то, что описано.
Кстати, в качестве побочного продукта разбора у меня есть краткие описания (~5 КБ) почти каждого треда (кроме тредов без единого ответа) с 2015 года. И еще то же самое до марта 2015 года, но чуть менее качественно сделанное. Суммарно это 13,6 МБ данных. Я могу это куда-то выложить в форме архива, если кому-то надо.
No. 28286  
Screenshot_2026-08-05_17-39-46.webp - (161.16KB, 1920×1080)
28286
Я уже и забыл, насколько чертовски быстрые Си и C++. А вы помните?
У меня тут куча вложенных циклов в коде, и тесты выполняются за 4 мс.
По меркам любых managed языков это раз в 10-20 раз быстрее, чем можно было бы надеяться.
Но я не могу сопротивяться желанию оптимизировать всё, думать о строках кэша и т.п.
No. 28287  
>>28286
> По меркам любых managed языков это раз в 10-20 раз быстрее, чем можно было бы надеяться.
Помню, наблюлал случай, где JIT-уемый C#-код работал чуть-чуть быстрее, чем gcc -O3 -march=native. Но я в .cs тогда напрямую указатели использовал, что не очень-то managed.
No. 28288  
>>28287
Да, JIT и правда может быть очень быстрым, но скорость старта при этом гарантировано низкая, т.к. JIT сам по себе не бесплатный, и включается только для горячего кода (после того, как много раз будет проинтерпретирован байткод). Кроме того, JIT не спасает от не-cache-friendly-структур в памяти. Правда, если писать на C++ везде при помощи STL и экстремально жирных классов, код будет работать со скоростью Джавы примерно.
Кстати, патологическая оптимизация у меня была и при попытках программировать на Go. Считаю байтики там. Очень медленно это всё происходит.
No. 28289  
Ничего необычного, это просто 💥 blazing fast 🚀 исполнение кода.
Просто 🦀 "blazingly fast and memory-efficient"...
Удалить сообщение []
Пароль  
[Mod]