Попробовал добавить старую Radeon VII с 16Гб на борту и потерпел неудачу. Технически карточку вставить можно, но мешают подключенные USB 3.0 на корпус и остальные провода типа кнопок питания. Задумался о том что бы собрать следующий рабочий комп на Threadripper там материнки как-то побольше размером.
Все это достаточно интересно, но для меня вполне хватает DeepSeek в браузере.
Мне кажется что в этом году должны выйти интересные железки для инференса.
Могу подсказать. У меня несколько компов, сервер на Ryzen 7 2700x, 96Гб оперативной памяти, но 2666MHz. Рабочий Ryzen 9 5950x, 64Гб 3400MHz. Проверил на Qwen3 32B. Не скажу что у меня супер оптимальные настройки были, скорее стоковые из коробки, возможно тюнингом можно еще подразогнать.
Ryzen 2700x - 1.67 t/s
Ryzen 5950x - 2.32 t/s
NVidia 4090 - 15.76 t/s
Так же у меня есть материнская плата с двумя E5-2697V4, именно сейчас он разобран и проверить на нем не смогу, но скорости были то же порядка 1.5-2 t/s. Так же что бы не делал, у меня всегда был загружен только один процессор из двух, возможно это плохой планировщик в Windows был и нужно было ставить серверную версию ОС или линукс.
Так же попробовал MoE модель Qwen 30B(MoE). Результаты у меня вызвали удивление:
Ryzen 5950x - 18.85 t/s
NVidia 4090 - 32.93 t/s.
Теперь хочется попробовать Qwen3 235B(MoE), но у меня не хватит оперативной памяти... раза в 2.5 не хватит. 3-битная модель 111Gb, 8-битная 250Gb, а пределы моего железа 128Gb.
Проверил еще раз на модели R1 70B - 0.63 t/s. На простом запросе, более сложного не дождался. Вы оказались правы. Наверно когда грузил модели больше VRAM я не слишком сильно превышал пределы, может быть это было 40B и поэтому в памяти отпечаталось что скорость падала примерно до 1-3 t/s. В любом случае такие модели уже быстрее просто на хорошем многоядерном процессоре исполнять.
Всё автоматически заработает, если вместо CUDA выбрать Vulkan - то заработает даже для AMD + Nvidia + Intel.
Это очень интересно. Технически достаточно дома железа что бы проверить две видеокарты в действие. У меня стоит 4090, могу временно одолжить из компьютера супруги 5070Ti (16Gb). Но это сделать сложно, использую обычную материнскую плату на AMD x470 чипсете. Там какие-то сложность с вторым PCI-E16x, если установлен второй SSD(возможно это на B450/550 чипсете).
Скажите, что важнее для второй видеокарты, скорость самого чипа или размер памяти? Или на ней то же будет производиться исполнение и важно и то и другое?
Qwen3-235B-A22B - размер 235B, скорость 4.5-6.5 t/s.
DeepSeek V3/R1 - размер 671B, скорость 2-3 t/s.
Я о этом говорю, где граница комфорта тут каждый сам решает. Как по мне меньше 20 t/s так себе.
Не, не будет. Это будет на порядок медленнее чем на любом CPU, на практике "видео-своп" дичайшие тормозит и все рекомендуют его отключать,
Может мы говорим про разные вещи, пробовал грузить 70B модели в lmstudio в 4090, вроде они не должны помещаться в память и работало быстрее чем 0.01 t/s, не помню точно с какой скоростью, но не так медленно.
Так энтузиасту с 4090 достаточно добавить одну 5060 ti 16гб
А можно с этого момента подробнее? У меня не то что бы залежи видеокарт поэтому никогда не смотрел как использовать две. Может поделитесь ссылкой как это дело настраивать?
Llama 4 Scout - размер 109B, скорость 20 t/s, большой запас по скорости. Хватит 8гб gpu.
Llama 4 Maverick - размер 402B, скорость 19 t/s. Хватит 12гб gpu.
Они недавно совсем вышли, никогда их не пробовал. Для моих задач дипсика и грока хватает, мне так простой код сгенерить, еще за развернутой справкой и примерами обращаюсь. Так то код умею писать, просто тяжело всю документацию в голове держать.
У меня сервер работает под TrueNas Scale там это все разворачивается тремя кликами, OpenWebUI можно поставить сразу с встроенным ollama, можно сделать пять кликов и поставить ollama отдельно.
Но все это действительно не имеет смысла. 1.5B это ооооочень маленькая модель, зачем она нужно вообще не сильно понятно, какой-то сервис сделать с донастройкой(дообучением) под внутренние или внешние задачи проекта(компании).
Основной вопрос зачем вам своя маленькая модель, если бесплатно доступна большая, и даже если вы хотите сделать свой сервис на основе дипсика, то проще их апи купить, там цены достаточно низкие.
Можно локально развернуть и 670B - но тут как говорится два стула: первый развернуть на CPU и это относительно дешевый вариант, т.к. найти сервер с 1,5Tb памяти не так сложно как кажется и не так дорого, стартовый ценник от $1k, если использовать старые Xeon, до $5k, если брать что-то поновее типа EPYC. Только в любом случае получите производительно 1.5-3 токена в секунду и ответы у вас будут минут за 20 появляться, а то и больше, когда контекст разговора вырастет. Следующий шаг это исполнение на GPU и тут стартовый ценник увеличивается на порядок или два порядка(~$100k, нужно просто 8 Nvidia A100). И снова не сильно понятно зачем это нужно, первый вариант работает слишком медленно что бы им пользоваться, а второй вариант непонятно зачем нужен если вы можете купить доступ к апи за гораздо меньшие деньги. За те же $10k вам доступа к апи хватит надолго, даже на продовый продукт, очень сомневаюсь что в ваш стартап сразу прибегут миллионы пользователей, а привлечь какую-то аудиторию и сделать софт-ланч точно хватит и $10k.
Сейчас предел для энтузиаста это модели 30B. Это влезет на хороший домашний компьютер с 4090 или 5090. Может быть можно замахнуться на 70B, но по видеопамяти вы уже выйдете за пределы 5090 и будет использовать видео-своп(не знаю как правильно называется, подкачку из оперативы), работать будет все равно быстрее чем на любом CPU.
На computex ожидаются релизы видеокарт от интел с 48Гб видеопамяти и может амд чет представит, но ценник все равно будет не маленький это будут тысячи долларов(думаю 5-7). Если счет идет на тысячи долларов то можно думать о NVIDIA RTX PRO 6000(96Gb) - это 70B модели будет тягать очень бодро, ценник около $12k.
Вот и все реалии. А 1,5B даже и не знаю кому и зачем может пригодиться, так поиграться разве что.
Когда политика начинает управлять экономикой, экономика очень быстро заканчивается.
Мне то же очень много непонятно и не только по спг, многие поступки правительств разных стран кажутся нелогичными, возможно так и есть, но скорее всего у нас просто недостаток информации. Или недостаток ТОЙ информации которая для конкретных людей принимающих решения сформировала такую реальность. Ну и действительно не стоит забывать что политики могут быть просто тупыми,
Газопровод так не работает, строительство газопровода достаточно долгое и дорогое развлечение, которое требует еще постоянного технического обслуживания, его нельзя включать и выключать пять раз в день.
Плюс непонятно чем плохи стабильные и непрерывные поставки с прогнозируемой низкой ценой?
Вот вы как работать предпочитаете по годовому контракту или сдельно? А вашему работодателю как больше нравится что вы устроитесь к нему на несколько лет или каждый день он будет гадать придете вы сегодня на работу или нет?
Как жалко что все гениальные экономические и политические аналитики способные определить беглым взглядом, сидя дома и не погружаясь глубоко в тему, истинное положение дел уже работают айтишниками...
Тем что это противоречит документации Google. Пользователи должны работать через авторизацию для пользователей, а сервисный аккаунт это условно аналог рута в ОС, почему пользователи в ОС работают в пользовательском пространстве? Ведь это их компьютер могут и от рута все запускать и вообще заходить в систему из под рута, верно? (ну могли бы в старых версия линукса, сейчас вроде нельзя зайти из под рута, отключили), по этой же причине отключили su, теперь только sudo. Потому что это нарушение правил безопасности, дает слишком много полномочий и плохо поддается контролю и вообще система не рассчитана на работу пользователей из под сервисного аккаунта, само название как бы намекает о его предназначение.
Пользователь не должен заходить в консоль, ему там делать нечего. И уж тем более он не должен брать оттуда ключи и отдавать их куда-то.
Это не совсем правильный путь. Клиентам не нужно создавать сервисный аккаунт. С точки зрения пользователя авторизация выглядит вот так.
1) пользователю ваша программа дает URL - это специальная ссылка которая формируется по определенным правилам. Пользователь должен ее скопировать и вставить в браузер. После чего ему будет показано окно где будет видно какое приложение, какой компании запрашивает доступ к его аккаунту. Как альтернатива это окно можно открывать из вашей программе, а потом доставать ключ автоматически.
2) После авторизации пользователя ему выдает ключ, этот ключ он должен отдать вашей программе.
3) Ваша программа используя ключ от пользователя (не сервисный аккаунт). Может получать доступ через Гугл АПИ к данным в аккаунте пользователя.
При таком подходе пользователь может в любой момент смотреть каким приложениям он дал доступ и отозвать его, а так же при авторизации выбирать аккаунт.
Вы уверены что это то что должно работать у клиентов? Через сервисный аккаунт? Я делал иначе, создается приложение в гугл консоли, после чего для авторизации пользователю дается ссылка открыв которую в браузере он должен получить ключ(по-моему это называется рефреш токен). Этот токен он отдает вашему приложению и вы его должны сохранить. Но по нему нельзя работать с АПИ, его нужно поменять на другой токен и вот с ним обращаться к АПИ. Могу более подробно кодом показать как это делается.
Что бы конкретный пользователь мог работать с конкретной таблицей должны совпасть две вещи 1) идентификация пользователя (что бы проверить что у него есть доступ к таблице), 2) идентификация приложения (гугл заставляет ваш код представляться каждый раз когда вы хотите вызвать его АПИ)
Это безусловно полезно и скорее всего мне пригодиться вот прям скоро. Обычно нет необходимости так делать, в своих рабочих проектах такого избегал, потому что зачем добавлять сложность в проект, если можно без этого, лучший код которого нет, но вот прям сейчас в рамках домашнего проекта задумал сделать библиотеку которая выключает стандартные рамки окна(не знаю как правильно называется) и использует свой декоратор, свои кнопки закрытия, сворачивание и прочее. Это достаточно изолированная часть и надоело таскать из проекта в проект код, проще действительно сделать либу(плагин) и вот это все, что вы описали и положить в отдельный репозиторий. Последний раз плагины делал на Qt 3.7 ))) лет 20 назад, с тех пор конечно много поменялось.
Мне доводилось видеть проект где вместо обычных статических либ было разбиение проекта именно на qt плагины, причем обоснования не было, просто вот так захотелось кому-то в команде на ранних стадиях разработки, сложность сразу выросла, как по сборке, так и по разработке. Не драматично, но постоянно что-то из-за этого мешалось, конкретных деталей уже не вспомню, давно было, помню общие ощущения от работы.
Qt дает много фичей, некоторые из них надо применять очень редко и очень в особых случаях, они могут быть хороши для самой библиотеки, но для приложения вредить, вот в чем моя мысль.
Не понимаю что вы имеете ввиду? Вы берете и наследуетесь от QQuickItem, это будет обычный С++ класс(с поправкой на мок, QObject и прочее), но в итоге это соберется в обычный объектный файл. Останется только регистрацию в самом приложение сделать(qmlRegisterType).
stream=False #если True - делит ответ на куски для постепенного отображения
Это как раз самое сложное, особенно, если использовать R1 апи, оно просто в поток шлет все подряд, может обрывать json в теле на половине, вообще рвет как угодно, поэтому нужно накапливать выхлоп из потока, разбивать на отдельные пакеты, и брать те которые уже сформировались, выкусывать из буффера и обрабатывать. Апи там в целом похожее на ChatGPT, апи у всех сеток в общем похожее, есть маленькие различия, которые не всегда описаны в документации и как использовать АПИ иногда проще узнать у самого бота, или посмотреть внимательно на то что приходит в body ответа. По ценам примерно в 10 или 100 раз дешевле Grok. Но контекст всего 32 тысячи токенов, у Грока 128к, но еще две недели назад через апи была доступна только вторая версия, а третья - "каминг сун".
У автора в статье график - самое быстрое это манипулировать QSGNode. Так что не гарантия, кривые руки могут испортить все, но это способ получить самую быструю отрисовку.
если существует возможность
Ну примерно о этом и сказал, если нужен виджет который показывает примерно одинаковые списки, просто делайте свою qml'ку на основе listview и не парьтесь. Свой виджет нужен когда надо рисовать что-то очень замороченное, например флеймграф колстека(это то для чего мне приходилось делать) или карту игры. В любой программе на QML которая сложнее лабораторки студента так или иначе появляется своя библиотека виджетов, обычно это обвязка над стандартными каких-то специфичных для программы функций.
Не знаю как в шестом, но в 5-ом был один очень неприятный для меня момент, который если честно непонятно зачем был сделан. Если вы делаете свой виджет на основе QQuickItem то вам дорога делать кастомные QSGNode или использовать стандартные и вот в стандартных нет нода для отрисовки текста(!!!), он в приватном АПИ qt. У меня от этого факта реально конкретно подгорело в свое время. Типа в смысле? Выводить текст это прям то что нужно буквально сразу как делаешь кастомный виджет, почти всегда. Какого хрена? До сих пор не могу понять зачем они его сделали внутри приватного апи, откуда его не так просто достать, и делать этого явно не стоит.
Поэтому если вы планируете рисовать текст вам дорога в QQuickPaintedItem или делайте свою отрисовку текста, что вообще не тривиальная задача. Как вариант рендерить в текстуру и рисовать текстурки, но то же такое. А если хочется текст правильно рисовать... короче обычный программист это не сделает с первого раза, когда строится текстурный атлас шрифта, и потом начинается долго и упорно побеждать хинтинг шрифтов и uft8.
Как по мне так единственное что стоит использовать - это наследование от QQuickPaintedItem и QQuickItem. В таком случае можно обойтись обычной статической библиотекой и непонятно зачем городить огород с плагином(модулем).
Новые виджеты хочешь - не хочешь, а создаешь всегда, в этом концепция QML. Любой qml файл это уже новый виджет. Я бы назвал статью - разные способы рисования в QML.
Если нужно что-то сложное рисовать, то вероятно вам захочется делать это быстро или очень быстро, и тут добро пожаловать в С++.
Неплохо, спасибо за объяснение.
Попробовал добавить старую Radeon VII с 16Гб на борту и потерпел неудачу. Технически карточку вставить можно, но мешают подключенные USB 3.0 на корпус и остальные провода типа кнопок питания. Задумался о том что бы собрать следующий рабочий комп на Threadripper там материнки как-то побольше размером.
Все это достаточно интересно, но для меня вполне хватает DeepSeek в браузере.
Мне кажется что в этом году должны выйти интересные железки для инференса.
Могу подсказать. У меня несколько компов, сервер на Ryzen 7 2700x, 96Гб оперативной памяти, но 2666MHz. Рабочий Ryzen 9 5950x, 64Гб 3400MHz. Проверил на Qwen3 32B. Не скажу что у меня супер оптимальные настройки были, скорее стоковые из коробки, возможно тюнингом можно еще подразогнать.
Ryzen 2700x - 1.67 t/s
Ryzen 5950x - 2.32 t/s
NVidia 4090 - 15.76 t/s
Так же у меня есть материнская плата с двумя E5-2697V4, именно сейчас он разобран и проверить на нем не смогу, но скорости были то же порядка 1.5-2 t/s. Так же что бы не делал, у меня всегда был загружен только один процессор из двух, возможно это плохой планировщик в Windows был и нужно было ставить серверную версию ОС или линукс.
Так же попробовал MoE модель Qwen 30B(MoE). Результаты у меня вызвали удивление:
Ryzen 5950x - 18.85 t/s
NVidia 4090 - 32.93 t/s.
Теперь хочется попробовать Qwen3 235B(MoE), но у меня не хватит оперативной памяти... раза в 2.5 не хватит. 3-битная модель 111Gb, 8-битная 250Gb, а пределы моего железа 128Gb.
Проверил еще раз на модели R1 70B - 0.63 t/s. На простом запросе, более сложного не дождался. Вы оказались правы. Наверно когда грузил модели больше VRAM я не слишком сильно превышал пределы, может быть это было 40B и поэтому в памяти отпечаталось что скорость падала примерно до 1-3 t/s. В любом случае такие модели уже быстрее просто на хорошем многоядерном процессоре исполнять.
Это очень интересно. Технически достаточно дома железа что бы проверить две видеокарты в действие. У меня стоит 4090, могу временно одолжить из компьютера супруги 5070Ti (16Gb). Но это сделать сложно, использую обычную материнскую плату на AMD x470 чипсете. Там какие-то сложность с вторым PCI-E16x, если установлен второй SSD(возможно это на B450/550 чипсете).
Скажите, что важнее для второй видеокарты, скорость самого чипа или размер памяти? Или на ней то же будет производиться исполнение и важно и то и другое?
Спасибо за ответ, достаточно познавательно.
Qwen3-235B-A22B - размер 235B, скорость 4.5-6.5 t/s.DeepSeek V3/R1 - размер 671B, скорость 2-3 t/s.Я о этом говорю, где граница комфорта тут каждый сам решает. Как по мне меньше 20 t/s так себе.
Может мы говорим про разные вещи, пробовал грузить 70B модели в lmstudio в 4090, вроде они не должны помещаться в память и работало быстрее чем 0.01 t/s, не помню точно с какой скоростью, но не так медленно.
А можно с этого момента подробнее? У меня не то что бы залежи видеокарт поэтому никогда не смотрел как использовать две. Может поделитесь ссылкой как это дело настраивать?
Llama 4 Scout - размер 109B, скорость 20 t/s, большой запас по скорости. Хватит 8гб gpu.Llama 4 Maverick - размер 402B, скорость 19 t/s. Хватит 12гб gpu.Они недавно совсем вышли, никогда их не пробовал. Для моих задач дипсика и грока хватает, мне так простой код сгенерить, еще за развернутой справкой и примерами обращаюсь. Так то код умею писать, просто тяжело всю документацию в голове держать.
А вы внимательно прочитали мое сообщение? прочитайте еще раз текст написанный до "QwQ-32B".
gemini 27b не самая лучшая модель. Если хотите хорошие локальные модели то это: gemma3:27B, qwen3(чем больше тем лучше), QwQ-32B
У меня сервер работает под TrueNas Scale там это все разворачивается тремя кликами, OpenWebUI можно поставить сразу с встроенным ollama, можно сделать пять кликов и поставить ollama отдельно.
Но все это действительно не имеет смысла. 1.5B это ооооочень маленькая модель, зачем она нужно вообще не сильно понятно, какой-то сервис сделать с донастройкой(дообучением) под внутренние или внешние задачи проекта(компании).
Основной вопрос зачем вам своя маленькая модель, если бесплатно доступна большая, и даже если вы хотите сделать свой сервис на основе дипсика, то проще их апи купить, там цены достаточно низкие.
Можно локально развернуть и 670B - но тут как говорится два стула: первый развернуть на CPU и это относительно дешевый вариант, т.к. найти сервер с 1,5Tb памяти не так сложно как кажется и не так дорого, стартовый ценник от $1k, если использовать старые Xeon, до $5k, если брать что-то поновее типа EPYC. Только в любом случае получите производительно 1.5-3 токена в секунду и ответы у вас будут минут за 20 появляться, а то и больше, когда контекст разговора вырастет. Следующий шаг это исполнение на GPU и тут стартовый ценник увеличивается на порядок или два порядка(~$100k, нужно просто 8 Nvidia A100). И снова не сильно понятно зачем это нужно, первый вариант работает слишком медленно что бы им пользоваться, а второй вариант непонятно зачем нужен если вы можете купить доступ к апи за гораздо меньшие деньги. За те же $10k вам доступа к апи хватит надолго, даже на продовый продукт, очень сомневаюсь что в ваш стартап сразу прибегут миллионы пользователей, а привлечь какую-то аудиторию и сделать софт-ланч точно хватит и $10k.
Сейчас предел для энтузиаста это модели 30B. Это влезет на хороший домашний компьютер с 4090 или 5090. Может быть можно замахнуться на 70B, но по видеопамяти вы уже выйдете за пределы 5090 и будет использовать видео-своп(не знаю как правильно называется, подкачку из оперативы), работать будет все равно быстрее чем на любом CPU.
На computex ожидаются релизы видеокарт от интел с 48Гб видеопамяти и может амд чет представит, но ценник все равно будет не маленький это будут тысячи долларов(думаю 5-7). Если счет идет на тысячи долларов то можно думать о NVIDIA RTX PRO 6000(96Gb) - это 70B модели будет тягать очень бодро, ценник около $12k.
Вот и все реалии. А 1,5B даже и не знаю кому и зачем может пригодиться, так поиграться разве что.
Когда политика начинает управлять экономикой, экономика очень быстро заканчивается.
Мне то же очень много непонятно и не только по спг, многие поступки правительств разных стран кажутся нелогичными, возможно так и есть, но скорее всего у нас просто недостаток информации. Или недостаток ТОЙ информации которая для конкретных людей принимающих решения сформировала такую реальность. Ну и действительно не стоит забывать что политики могут быть просто тупыми,
Газопровод так не работает, строительство газопровода достаточно долгое и дорогое развлечение, которое требует еще постоянного технического обслуживания, его нельзя включать и выключать пять раз в день.
Плюс непонятно чем плохи стабильные и непрерывные поставки с прогнозируемой низкой ценой?
Вот вы как работать предпочитаете по годовому контракту или сдельно? А вашему работодателю как больше нравится что вы устроитесь к нему на несколько лет или каждый день он будет гадать придете вы сегодня на работу или нет?
Как жалко что все гениальные экономические и политические аналитики способные определить беглым взглядом, сидя дома и не погружаясь глубоко в тему, истинное положение дел уже работают айтишниками...
Вся статья и комментарии - пример того как не заметить в комнате слона. Какого политического строя по заявлению самого Китая он придерживается?
В этом случае - да. Возможно я агенду не прочитал внимательно. Я думал что вы сделали приложение для пользователей.
Тем что это противоречит документации Google. Пользователи должны работать через авторизацию для пользователей, а сервисный аккаунт это условно аналог рута в ОС, почему пользователи в ОС работают в пользовательском пространстве? Ведь это их компьютер могут и от рута все запускать и вообще заходить в систему из под рута, верно? (ну могли бы в старых версия линукса, сейчас вроде нельзя зайти из под рута, отключили), по этой же причине отключили su, теперь только sudo. Потому что это нарушение правил безопасности, дает слишком много полномочий и плохо поддается контролю и вообще система не рассчитана на работу пользователей из под сервисного аккаунта, само название как бы намекает о его предназначение.
Пользователь не должен заходить в консоль, ему там делать нечего. И уж тем более он не должен брать оттуда ключи и отдавать их куда-то.
Это не совсем правильный путь. Клиентам не нужно создавать сервисный аккаунт. С точки зрения пользователя авторизация выглядит вот так.
1) пользователю ваша программа дает URL - это специальная ссылка которая формируется по определенным правилам. Пользователь должен ее скопировать и вставить в браузер. После чего ему будет показано окно где будет видно какое приложение, какой компании запрашивает доступ к его аккаунту. Как альтернатива это окно можно открывать из вашей программе, а потом доставать ключ автоматически.
2) После авторизации пользователя ему выдает ключ, этот ключ он должен отдать вашей программе.
3) Ваша программа используя ключ от пользователя (не сервисный аккаунт). Может получать доступ через Гугл АПИ к данным в аккаунте пользователя.
При таком подходе пользователь может в любой момент смотреть каким приложениям он дал доступ и отозвать его, а так же при авторизации выбирать аккаунт.
Вы уверены что это то что должно работать у клиентов? Через сервисный аккаунт? Я делал иначе, создается приложение в гугл консоли, после чего для авторизации пользователю дается ссылка открыв которую в браузере он должен получить ключ(по-моему это называется рефреш токен). Этот токен он отдает вашему приложению и вы его должны сохранить. Но по нему нельзя работать с АПИ, его нужно поменять на другой токен и вот с ним обращаться к АПИ. Могу более подробно кодом показать как это делается.
Что бы конкретный пользователь мог работать с конкретной таблицей должны совпасть две вещи 1) идентификация пользователя (что бы проверить что у него есть доступ к таблице), 2) идентификация приложения (гугл заставляет ваш код представляться каждый раз когда вы хотите вызвать его АПИ)
Это безусловно полезно и скорее всего мне пригодиться вот прям скоро. Обычно нет необходимости так делать, в своих рабочих проектах такого избегал, потому что зачем добавлять сложность в проект, если можно без этого, лучший код которого нет, но вот прям сейчас в рамках домашнего проекта задумал сделать библиотеку которая выключает стандартные рамки окна(не знаю как правильно называется) и использует свой декоратор, свои кнопки закрытия, сворачивание и прочее. Это достаточно изолированная часть и надоело таскать из проекта в проект код, проще действительно сделать либу(плагин) и вот это все, что вы описали и положить в отдельный репозиторий. Последний раз плагины делал на Qt 3.7 ))) лет 20 назад, с тех пор конечно много поменялось.
Мне доводилось видеть проект где вместо обычных статических либ было разбиение проекта именно на qt плагины, причем обоснования не было, просто вот так захотелось кому-то в команде на ранних стадиях разработки, сложность сразу выросла, как по сборке, так и по разработке. Не драматично, но постоянно что-то из-за этого мешалось, конкретных деталей уже не вспомню, давно было, помню общие ощущения от работы.
Qt дает много фичей, некоторые из них надо применять очень редко и очень в особых случаях, они могут быть хороши для самой библиотеки, но для приложения вредить, вот в чем моя мысль.
Не понимаю что вы имеете ввиду? Вы берете и наследуетесь от QQuickItem, это будет обычный С++ класс(с поправкой на мок, QObject и прочее), но в итоге это соберется в обычный объектный файл. Останется только регистрацию в самом приложение сделать(qmlRegisterType).
Это как раз самое сложное, особенно, если использовать R1 апи, оно просто в поток шлет все подряд, может обрывать json в теле на половине, вообще рвет как угодно, поэтому нужно накапливать выхлоп из потока, разбивать на отдельные пакеты, и брать те которые уже сформировались, выкусывать из буффера и обрабатывать. Апи там в целом похожее на ChatGPT, апи у всех сеток в общем похожее, есть маленькие различия, которые не всегда описаны в документации и как использовать АПИ иногда проще узнать у самого бота, или посмотреть внимательно на то что приходит в body ответа. По ценам примерно в 10 или 100 раз дешевле Grok. Но контекст всего 32 тысячи токенов, у Грока 128к, но еще две недели назад через апи была доступна только вторая версия, а третья - "каминг сун".
У автора в статье график - самое быстрое это манипулировать QSGNode. Так что не гарантия, кривые руки могут испортить все, но это способ получить самую быструю отрисовку.
Ну примерно о этом и сказал, если нужен виджет который показывает примерно одинаковые списки, просто делайте свою qml'ку на основе listview и не парьтесь. Свой виджет нужен когда надо рисовать что-то очень замороченное, например флеймграф колстека(это то для чего мне приходилось делать) или карту игры. В любой программе на QML которая сложнее лабораторки студента так или иначе появляется своя библиотека виджетов, обычно это обвязка над стандартными каких-то специфичных для программы функций.
Не знаю как в шестом, но в 5-ом был один очень неприятный для меня момент, который если честно непонятно зачем был сделан. Если вы делаете свой виджет на основе QQuickItem то вам дорога делать кастомные QSGNode или использовать стандартные и вот в стандартных нет нода для отрисовки текста(!!!), он в приватном АПИ qt. У меня от этого факта реально конкретно подгорело в свое время. Типа в смысле? Выводить текст это прям то что нужно буквально сразу как делаешь кастомный виджет, почти всегда. Какого хрена? До сих пор не могу понять зачем они его сделали внутри приватного апи, откуда его не так просто достать, и делать этого явно не стоит.
Поэтому если вы планируете рисовать текст вам дорога в QQuickPaintedItem или делайте свою отрисовку текста, что вообще не тривиальная задача. Как вариант рендерить в текстуру и рисовать текстурки, но то же такое. А если хочется текст правильно рисовать... короче обычный программист это не сделает с первого раза, когда строится текстурный атлас шрифта, и потом начинается долго и упорно побеждать хинтинг шрифтов и uft8.
Как по мне так единственное что стоит использовать - это наследование от QQuickPaintedItem и QQuickItem. В таком случае можно обойтись обычной статической библиотекой и непонятно зачем городить огород с плагином(модулем).
Новые виджеты хочешь - не хочешь, а создаешь всегда, в этом концепция QML. Любой qml файл это уже новый виджет. Я бы назвал статью - разные способы рисования в QML.
Если нужно что-то сложное рисовать, то вероятно вам захочется делать это быстро или очень быстро, и тут добро пожаловать в С++.