Работа на корпоратов в антиутопии:

- Корпоративное жильё - сотрудники и их семьи жили в защищённых корпоративных анклавах, изолированных от опасностей улиц
- Медицинское обслуживание - доступ к высококачественной медицине, включая кибернетические улучшения за счёт корпорации
- Безопасность - личная охрана и защита от уличной преступности
- Юридическая защита - корпоративные адвокаты и иммунитет от многих городских законов

Работа на корпоратов в реальности:

- Возможность взять однушку в ипотеку в СберСити
- Возможность посмотреть ютуб через корпоративный ВПН (наверное)

v0.2.0 - More headless

Добавил headless creator'a для телемоста + пофиксил ВК, чтобы в случае разрыва звонка сервером оно автоматически переподключалось по созданной ссылке.

Так же перелопатил архитектуру, чтобы окончательно перенести webrtc стэк из WebView в Go. Теперь работа в бэкграунде должна быть стабильнее, так как андроид будет менее агрессивно урезать ресурсы. В идеальных условиях (хорошая связь, близкое расположение к серверам/creator'у) получилось достичь довольно неплохой скорости.

Плюс добавлен режим proxy-only с настройками логина/пароля.

Правда, капчу для присоединения к звонкам ВК все так же нужно проходить. Может потом что-нибудь придумаю.

Все билды [тут]

Могу только дропнуть в виде исходников с режимами headless-only и proxy-only. Не знаю, насколько долго система позволит этому решению жить - оно находится в бэкграунде благодаря хаку с односекундным WAV-файлом, состоящим из нулей. Ну и еще система не дает стабильно биндить проксю на определенный порт, поэтому он из раза в раз может слегка отличаться. Но вроде оно работает (по крайней мере на ios 16) + нет необходимости в NetworkExtension

v0.2.1 [билды]

В общем, зарелизил исходники proxy-only для iOS [тык]. Может кто-нибудь захочет накидать свой пет-проект с полноценным VPN через NetworkExtension.

Так как телемост закрыл DC туннель - оптимизировал VP8 подход: на тесте скорость выросла с 1.5mbps до 6mbps. В теории можно выжать еще больше, но оно становится менее стабильным из-за congestion control. Плюс исправлен ряд минорных багов вроде 401 при попытке создать headless звонок в creator-app'е на винде.

В ближайшее время новых релизов не планируется - хочу передохнуть и позаниматься чем-нибудь другим. Если в новом релизе что-то поломалось/отвалилось - пишите в [конфу канала]. Попробуем отдебажить и я обновлю имеющийся релиз

Поддержать автора/проекты можно через

0xd986b7576340d8d7b04f806dfd38a182b19edf50 - USDC (ERC20)

и

TTEo4XXTB6CqhEiKpyoncfk3skEvoq3bCP - USDT (TRC20)

И еще обновил сетап гайд

https://github.com/kulikov0/whitelist-bypass/blob/main/docs/SETUP.md

Сначала мужчины говорят что у них нет депрессии, а потом строят вот это на заднем дворе

https://www.youtube.com/watch?v=HfSO-LCKmrA

Dude, I wish there was an easier way for local inference on macOS

Я скорее поверю в то, что через пару месяцев эта команда индусов релизнет Copilot Task Manager

Продолжение red eyes is all you need

В общем, глобально было два пути оптимизации этого исчадия: через увеличение тактовой частоты железки и через уменьшение tokens per cycle. Первое в самом начале решалось простым раскидыванием регистров в нужных местах, но со временем я уперся в тот факт, что один большой BRAM модуль с весами слишком медленно доставляет данные из-за физического положения (веса/активации нужны многим модулям, и сам путь до нужного модуля занимает слишком много времени). Поэтому пришлось дробить на кучу блоков + конфигурировать все модули в свои pblocks.

Идея в том, что place&route по умолчанию раскидывает логику по кристаллу как ему удобнее, а удобнее ему обычно не там, где надо, и clock tree synthesis потом героически пытается развести тактовый сигнал через всю эту кашу. Если matvec u_qkv оказался в одном углу, а его weight_store в другом, то на трассы между ними уходят те самые наносекунды, из-за которых слайсится тайминг. Поэтому каждому matvec'у выделяется своя территория с примерно нужным количеством SLICE/DSP/BRAM, и его weight_store селится туда же.

Нижняя половина кристалла (X0..X145, Y0..Y149) поделена на четыре вертикальные полосы под четыре w32-matvec'а внутри transformer_layer: u_qkv в X0..X41, u_proj в X42..X69, u_ff_up в X70..X109, u_ff_down в X110..X145. Каждый pblock включает и сам matvec, и парный к нему weight_store, чтобы трассы от выхода weight_store (256 бит на u_qkv/u_proj/u_ff_up/u_ff_down, 128 на u_head_proj) не тянулись через полкристалла. Размеры полос пропорциональны размеру весов: pb_ff_up жирнее pb_proj по BRAM, потому что ff_up хранит 512x128 против 128x128 у proj, и так далее.

Head projection ушел на правый край (X146..X163) во всю высоту кристалла, потому что он живет в transformer_top, и его удобно держать на отшибе - он шарит tok_emb с embedding lookup, и весь этот weight-tied кусок логически отдельный. В верхней половине (Y150+) поселились остальные. Слева ln_f (X0..X100), правее в полосе X100..X145 живут u_sm_a и u_sm_b в одном pblock'е (чтобы оба softmax'а были рядом со своими ping-pong буферами), а сэмплер сидит в той же X-полосе сверху и снизу от softmax'а - в Y150..Y169 и Y211..Y249, обтекая его.

Благодаря этому удалось достичь Fmax ~98.8 MHz и зафиксировать рабочую частоту на 95 MHz

Дальше пошла оптимизация cycles/token

Тут вся работа свелась к тому, чтобы attention перестал быть последовательным куском логики, потому что именно он съедал большую часть циклов.

Первое что переехало это сами matvec'и. Раньше matvec_fp16 ел по одному int8-весу за такт через 8-битный weight bus, и QKV с proj шарили этот bus через мультиплексор. Сейчас стоит matvec_fp16_w32 (и w16 для head_proj), который читает по 32 веса за такт из своего weight_store, а qkv и proj получили свои отдельные банки и могут работать параллельно, не толкаясь за один порт.

Дальше пошел score внутри attn head (Q*K). K cache отдает 4 fp16-позиции за одно чтение, над ним стоят четыре fp16_mul, которые делят один q_head[dim], и за такт получаем 4 произведения Q*K вместо одного. Дальше эти произведения нужно складывать по dim, и тут возникает обычная для fp16-арифметики проблема: fp16_add имеет 4-тактную обратную связь, и если складывать в один аккумулятор, то получается одно сложение раз в 4 такта. Поэтому вместо одного аккумулятора стоят 16 fp16_reduce_k8 в 4-way ping-pong (4 позиционных lane'а на 4 фазы pair_idx). A берет каждый четвертый quad (0, 4, 8...), B следующий (1, 5, 9...), C (2, 6, 10...), D (3, 7, 11...). Пока A досчитывает свой quad, B уже принимает следующий, потом C, потом D, и к моменту когда снова доходит очередь до A, его 4-тактная задержка уже прошла. Так держится throughput одно сложение за такт на lane.

AV устроен похоже, четыре fp16_mul читают 4 V-вектора из одного 64-битного чтения, дальше balanced add tree и один аккумулятор av_acc[d].

Самое жирное это параллелизм между attn heads. Инстансов softmax два (u_sm_a для четных, u_sm_b для нечетных), и за ними два ping-pong attn_buf'а. Score sub-FSM и AV sub-FSM крутятся независимо: пока AV ест выходы attn head N из attn_buf_a, score уже стреляет dot-product'ами для attn head N+1 в u_sm_b, который пишет в attn_buf_b. K и V в кэше имеют раздельные адреса чтения ровно для этого, чтобы score (читает K) и AV (читает V) не дрались за порт. Pipeline depth ограничен через scored_count - av_done_count <= 2, чтобы score attn head N+2 не начал перезаписывать буфер, который AV еще читает для attn head N.

Из мелкого еще дописал нормальный сэмплер вместо argmax'а: логиты умножаются на inv_temp с repetition penalty, уходят в softmax, top-k выбирается через compare tree, дальше multinomial draw через CDF-walk. Источник энтропии 16-битный Fibonacci LFSR (потому что Mersenne Twister и Philox на один сэмпл в такт это перебор для такой модели мне было лень).

Тащем-то, ответ на главный вопрос: “сколько токенов”? Эта чилслодробилка выдает примерно 1100 токенов в секунду на 854k W8A16, но потенциально может и больше, если добавить еще параллельных вычислений и обработки весов за раз

Хз, какие выводы можно из этого сделать. Если хотите запихнуть модель в железо:

1) Используйте быструю память (медленную не используйте)
2) Делайте параллельные вычисления (последовательные не делайте)

С одной стороны мне не нравятся тонны нейрослопа, цены на оперативку/гпу и прочее, но с другой - вместо AI bubble у нас было бы вот это с теми же условиями

My honest reaction, когда любители сырков по средам фиксят vp8 туннель вместо многолетних багов в своей супераппе

whitelist-bypass v0.3.0 - ночное, бессонное

Добавлена поддержка wbstream: DC + VP8 (авторизация/куки не нужны).

Добавлена обфускация пакетов (в принципе давно пора, но до определенного времени всем, думаю, было плевать на подобные проекты, поэтому особого значения не придавал) - надеюсь, что поможет с низкими скоростями при включенных бс. Плюсом добавлен контроль для VP8 bandwidth - в настройках появился пункт VP8 pacing: там выбирается количество кадров в секунду + количество пакетов, которые летят между кадрами. По умолчанию 24 фпс/30 батчей - у меня на тестах это самый стабильный вариант с точки зрения потери пакетов.

Из-за этого, правда, оно теперь работает только в режиме headless <-> headless (раньше была поддержка headless <-> webview).

По вашим просьбам было добавлено подключение к уже существующему звонку для headless + сделан headless VK bot (возможно на определенных системах он будет криво спавнить фоновые процессы со звонками, но проверить возможности нет).

А, еще были добавлены headless joiner'ы для линуксовых систем (wb, tm) - теперь в теории можно развернуть все это на слабых железках и попробовать пропускать весь траффик system-wide через redsocks/tun2socks.

Чуть более подробно расписал в [SETUP.md];
И сам релиз как всегда [здесь];
В случае, если что-то внезапно работает только на моей машине - по классике, пинайте меня в [чате канала]. Поправлю в нынешнем релизе, пока окончательно не переключился на другое