llama.cpp в Vulkan показывает BF16 - нет, тензорных блоков - нет Хотя по обещаниям Intel все должно быть. В интернет уверяют, что для B-серии драйвера допилили, а про A-серию "когда нибудь". Intel на мейнстрим в виде llama.cpp и прочего пофиг, на нормальные драйвера пофиг, она черти чем занимается.
Модель Q3_XXS в 16 Gb может влезть целиком. Упихал в Intel Arc A770, но -fit поменял на 300, вместо дефолтного гигабайта.
Если оставить стандартные настройки, то llama.cpp по умолчанию сама вытесняет слои Moe слои на CPU отставляя запас 1Gb на видеокарте. Чем больше слоев на видеокарте - тем быстрее.
Кроме скорости генерации, еще важна скорость разбора входных токенов.
Дело же не в стандартах, а в доступности решений. Когда я этим занимался (лет 10 назад), бесплатных и общедоступных серверов тайм стемпа просто не было. Аналогично то же самое с проверкой подлинности сертификатов.
Изменилось ли что-то за прошедшее время и есть ли бесплатные и общедоступные сервера - вот что хотелось бы знать.
Несколько подписей (отправитель, организация отправитель, шлюзов), это как раз или придумка авторов СМЭВ или правильно заимствованное решение. За счет того, что и шлюзы подписывают/проверяют, на стороне клиента-заказчика-организации не нужно плясок с таймстемпами IMHO Одно из немного, что в СМЭВ можно похвалить Позитивные эмоции от знакомства с подобными системами крайне редки (((, т.ч. надо ценить хоть малое ))).
"Все стандарты давно разработаны" Не все так очевидно ( C ) дочь офицера За некоторые "как-бы" разработанные стандарты, я бы пообщался бы с авторами, где нибудь в темном месте без видеокамер. Например стандарт канализации XML (XML Canonicalization) применительно к электронной подписи. Большей недоделанной и бесполезной дичи на мой взгляд придумать сложно. Если бы кто-то бы занялся и доделал, было бы хорошо. IMHO Банальные отступы/кол-во пробелов/кодирование пробельных символов или перевода строки. От перехода на другую имплиментацию парсера или просто от пересылки через HTTP шюзы, все запросто может разъехаться и подпись станет не валидной. Подпись на уровне байтов, а байт-представление текста вполне может исказится, например разные кодировки конца строки
P.S. С электронной подписью, СМЭВ, ГИС ГМП сталкивался лет 10 назад, с тех пор не приходилось. Ну и в текущем проекте есть интеграция с ГИС ЖКХ, т.ч. за темой стараюсь следить. Может когда опять вспоминать придется.
P.P.S.
ekey.ru
Главная страница 26.01.2023 не работает https://www.ekey.ru/ Parse error: syntax error, unexpected 'src' (T_STRING) in /home/bitrix/www/bitrix/modules/main/include/prolog.php on line 14
Как я понимаю, кроме электронной подписи, сертификата и закрытого ключа еще в документе и time stamp требуется. А вот про это, мне кажется вообще никто и не знает и не помнит. Ну и кроме сервера time stamp'а, для проверки сертификата, нужен и сервер удостоверяющего центра (или онлайн доступ) для проверки отозванных сертификатов - что опять таки вряд ли кто помнит и вряд ли кто имеет. А без этого, получается "как всегда". Сделать полноценное решение дорого (как я понимаю и сервер time stamp'а и свой локальный удостоверяющий центр /что бы отозванные сертификаты иметь/ - удовольствие сильно не бесплатное ), поэтому все городят поделки-велосипеды с колесами более-менее прямоугольной формы. IMHO & AFAIK
p.s. Насколько я знаю, проблема с time stamp'ом достаточно элегантно решена в СМЭВ (система межведомственного взаимодействия). Хотя пользователь и организация подписывают сообщение только своим закрытым ключом, но отсылают через шлюз СМЭВ'а который уже должен сам добавить time stamp. Т.ч. и подписи имеются (аж 3 штуки) и time stamp имеется. Но вот каких либо документов об обеспечении проверки сертификата на отозванность даже в СМЭВ, я что-то не припомню. Хотя, опять таки, если сообщение пришло из СМЭВ и сертификат шлюза корректен, можно надеяться (!!!), что шлюз сертификаты конечных пользователей проверил. Поднимать же у себя локальный удостоверяющий центр или как-то договариваться об online доступе с удостоверяющими центрами - как-то менеджеры проектов об этом не сильно запарываются.
Теоретически можно настроить tools (MCP) будут искать. Но tools для поиска или платный, или на забугорных сайтах которые запрещает РосЗапрет.
У меня Intel A770 16 Gb.
llama.cpp в Vulkan показывает BF16 - нет, тензорных блоков - нет
Хотя по обещаниям Intel все должно быть. В интернет уверяют, что для B-серии драйвера допилили, а про A-серию "когда нибудь". Intel на мейнстрим в виде llama.cpp и прочего пофиг, на нормальные драйвера пофиг, она черти чем занимается.
На Intel Arc A770 16gb через Vulcan (без bf16, без тензорных ядер)На AMD или тем более nVidia должно летатьqwen35moe 35B.A3B IQ3_XXS - 3.0625 bpw | 12.29 GiB | 34.66 B | pp512 | 170.71 ± 2.32qwen35moe 35B.A3B IQ3_XXS - 3.0625 bpw | 12.29 GiB | 34.66 B | tg128 |41.48 ± 0.06Модель Q3_XXS в 16 Gb может влезть целиком. Упихал в Intel Arc A770, но -fit поменял на 300, вместо дефолтного гигабайта.
Если оставить стандартные настройки, то llama.cpp по умолчанию сама вытесняет слои Moe слои на CPU отставляя запас 1Gb на видеокарте. Чем больше слоев на видеокарте - тем быстрее.
Кроме скорости генерации, еще важна скорость разбора входных токенов.
+100500
Дело же не в стандартах, а в доступности решений. Когда я этим занимался (лет 10 назад), бесплатных и общедоступных серверов тайм стемпа просто не было. Аналогично то же самое с проверкой подлинности сертификатов.
Изменилось ли что-то за прошедшее время и есть ли бесплатные и общедоступные сервера - вот что хотелось бы знать.
Несколько подписей (отправитель, организация отправитель, шлюзов), это как раз или придумка авторов СМЭВ или правильно заимствованное решение. За счет того, что и шлюзы подписывают/проверяют, на стороне клиента-заказчика-организации не нужно плясок с таймстемпами
IMHO Одно из немного, что в СМЭВ можно похвалить
Позитивные эмоции от знакомства с подобными системами крайне редки (((, т.ч. надо ценить хоть малое ))).
"Все стандарты давно разработаны"
Не все так очевидно ( C ) дочь офицера
За некоторые "как-бы" разработанные стандарты, я бы пообщался бы с авторами, где нибудь в темном месте без видеокамер.
Например стандарт канализации XML (XML Canonicalization) применительно к электронной подписи. Большей недоделанной и бесполезной дичи на мой взгляд придумать сложно. Если бы кто-то бы занялся и доделал, было бы хорошо. IMHO
Банальные отступы/кол-во пробелов/кодирование пробельных символов или перевода строки. От перехода на другую имплиментацию парсера или просто от пересылки через HTTP шюзы, все запросто может разъехаться и подпись станет не валидной. Подпись на уровне байтов, а байт-представление текста вполне может исказится, например разные кодировки конца строки
P.S.
С электронной подписью, СМЭВ, ГИС ГМП сталкивался лет 10 назад, с тех пор не приходилось. Ну и в текущем проекте есть интеграция с ГИС ЖКХ, т.ч. за темой стараюсь следить. Может когда опять вспоминать придется.
P.P.S.
Главная страница 26.01.2023 не работает
https://www.ekey.ru/
Parse error: syntax error, unexpected 'src' (T_STRING) in /home/bitrix/www/bitrix/modules/main/include/prolog.php on line 14
Как я понимаю, кроме электронной подписи, сертификата и закрытого ключа еще в документе и time stamp требуется. А вот про это, мне кажется вообще никто и не знает и не помнит. Ну и кроме сервера time stamp'а, для проверки сертификата, нужен и сервер удостоверяющего центра (или онлайн доступ) для проверки отозванных сертификатов - что опять таки вряд ли кто помнит и вряд ли кто имеет.
А без этого, получается "как всегда". Сделать полноценное решение дорого (как я понимаю и сервер time stamp'а и свой локальный удостоверяющий центр /что бы отозванные сертификаты иметь/ - удовольствие сильно не бесплатное ), поэтому все городят поделки-велосипеды с колесами более-менее прямоугольной формы.
IMHO & AFAIK
p.s.
Насколько я знаю, проблема с time stamp'ом достаточно элегантно решена в СМЭВ (система межведомственного взаимодействия). Хотя пользователь и организация подписывают сообщение только своим закрытым ключом, но отсылают через шлюз СМЭВ'а который уже должен сам добавить time stamp. Т.ч. и подписи имеются (аж 3 штуки) и time stamp имеется.
Но вот каких либо документов об обеспечении проверки сертификата на отозванность даже в СМЭВ, я что-то не припомню. Хотя, опять таки, если сообщение пришло из СМЭВ и сертификат шлюза корректен, можно надеяться (!!!), что шлюз сертификаты конечных пользователей проверил.
Поднимать же у себя локальный удостоверяющий центр или как-то договариваться об online доступе с удостоверяющими центрами - как-то менеджеры проектов об этом не сильно запарываются.