Обновить

Во Vue 3 есть важная и нередко используемая конструкция, у которой нет имени. Это то, что обычно называют "композабл с глобальными рефами".

Но:

  1. Это не композабл по определению

  2. Там не обязательно рефы

  3. Они не "глобальны"

В общем случае структура данного объекта - экспортируемые из ES модуля реактивные данные и функции для работы с ними.

Функционально они заменяют "сторы" Pinia. Называть их тоже stores - двусмысленно и нелогично. Вообще, молиться на "глобальный стейт" после появления идеи JavaScript signals и их всевозможных реализаций, включая Vue Reactivity API, архаично.

Мне кажется, самое подходящее название для данной конструкции - [реактивный] бизнес объект (РБО) или Vue Business Object (VBO). В них инкапсулируется логика предметной области и приложения, они не привязаны к конкретным компонентам, и по аналогии с другими языками и фреймворками, этот паттерн - Business Object, - выглядит вполне подходящим.

Техническая реализация может быть через ES классы, ES модули, closures, Pinia stores, с использованием singleton или DI.

Кроме того, позиционирование именно как "бизнес объект" будет требовать явного отделения от него презентационного и инфраструктурного слоев - работы с Backend API, например. То есть, стимулировать использование лучших практик и наработок из других сфер разработки ПО, еще более переводя Vue.js из фреймворка для небольших проектов в разряд enterprise level решений.

--------------

Telegram-канал о Vue и фронтенд-разработке: @vuefaq и вебсайт: Vue‑FAQ.org.

Теги:
Всего голосов 2: ↑1 и ↓1+2
Комментарии0

Как мы запустили Qwen3.8–27B целиком на RTX 5060 8 GB и получили ~30 токенов/с

Наш проект называется ExVRAM Lab. Это открытая исследовательская лаборатория, в которой мы проверяем, насколько большие локальные LLM можно запускать на обычных видеокартах с ограниченным объёмом VRAM, если использовать ultra‑low‑bit quantization, полное размещение весов на GPU и существующие open‑source inference‑технологии.

ExVRAM расшифровывается как Exchange Compute for VRAM. Основная идея проекта — в ряде сценариев выгоднее потратить часть свободной вычислительной мощности GPU на работу с более компактным представлением весов, чем хранить часть модели в оперативной памяти и постоянно передавать данные через PCIe.

Когда мы начинали проект, исходный вопрос был достаточно простой: можно ли запустить dense‑модель примерно на 27 миллиардов параметров на видеокарте всего с 8 ГБ VRAM так, чтобы она не просто «запустилась», а работала полностью на GPU, поддерживала длинный контекст и обеспечивала нормальную интерактивную скорость генерации.

В качестве основной тестовой системы мы используем NVIDIA GeForce RTX 5060 8 GB на архитектуре Blackwell. Основная модель в текущих экспериментах — Qwen3.8–27B.

Сначала результат выглядел не слишком впечатляюще. Модель запускалась, но значительная часть весов оставалась в системной памяти. Около 5,7 GiB весов находилось на GPU, ещё примерно 2,5 GiB — на CPU. Скорость генерации составляла порядка 3,8–5,5 токена в секунду.

При этом сама видеокарта была загружена далеко не полностью.

Это стало одним из первых важных наблюдений проекта. Проблема заключалась не столько в нехватке вычислительной мощности RTX 5060, сколько в том, что часть decoder weights находилась в RAM. Во время autoregressive generation данные приходилось постоянно передавать между CPU и GPU через PCIe.

Как мы запустили Qwen3.8–27B целиком на RTX 5060 8 GB и получили ~30 токенов/с

Публикации