Будівництво протоколу обробки даних Edge Intelligence: Text to Structured Entities in Milliseconds. Під час проектування Одним з основних обмежень, з якими я стикався в архітектурі, був "Податок на інференцію" - обчислювальна перевага покладатися на масивні, монолітні моделі великої мови (LLM) для виконання завдань, для яких вони ніколи не були оптимально розроблені. FogAI У наївній архітектурі розробник може перенаправляти грубі журнали датчиків або контекст чату до моделі параметрів 7B або 8B з проханням: "Extract all the field units, locations, and timestamps from the following text." Існують дві очевидні проблеми з цим підходом для Edge AI: Податок на висновок: Проведення простого вилучення з параметрами 8B спалює батарею, заповнює VRAM і вводить затримку (300 мс + на запит), щоб повернути ряд JSON. Галюцинації: LLM є генеративними. Вони здогадуються, який токен приходить далі, що призводить до структурних невідповідності та виготовлених суб'єктів. Щоб вирішити цю проблему в FogAi, я впровадив присвячений Використовуючи моделі (194M параметри). працює виключно на , цей шар перетинає розрив між сировими потоками тексту та структурованими діючими даними - все без єдиного обертача Python. Knowledge Extraction Layer knowledgator/gliner-bi-base-v2.0 MNN Ось архітектурний збій того, як я витягую «магічну» швидкість. Прорив Bi-Encoder Класичні моделі NER вимагають попереднього визначення суб'єктів (наприклад, , , ) під час навчання. момент, коли вам потрібна налаштована суб'єкт, як або Ця модель руйнується. PERSON ORG LOC WELDING DEFECT RADIO FREQUENCY GLiNER (Generalist and Lightweight Named Entity Recognition) вирішує це за допомогою Вона фізично розділяє процес кодування вниз по середині: Bi-Encoder Architecture Текстовий кодер: створює багаті контекстні вбудовування для сирого вхідного тексту. Label Encoder: створює вбудовані елементи для списку суб'єктів, які ви хочете знайти. Чому цей архітектурний поділ є майстерним ударом для Edge? Caching. У кінцевому вузлі, що відстежує дані робочого місця, потрібні етикетки (наприклад, ) рідко змінюється від мілісекунди до мілісекунди. тому що текстові та етикетні кодери роз'єднані, . ['worker', 'forklift', 'safety_vest', 'pallet'] FogAi caches the Label Embeddings in RAM Для кожного нового потоку тексту, який надходить, брандмауер повинен тільки виконувати текстовий кодувальник. , незалежно від того, чи шукаєте ви 5 типів суб'єктів або 500. Constant-Time Inference Повний потік даних: Zero Python FogAi використовує JNI і gRPC для безпосереднього виконання висновків MNN. Робочий процес повністю позбавлений важкого часу виконання Python: Raw Text Ingest -> Raw string прибуває в Vert.x Gateway. JNI / C++ Hand-off -> Структура передається безпосередньо через буфери пам'яті. MNN Text Encoder -> Gliner-bi-base-v2.0 ONNX графік виконується за допомогою MNN runtime (який повністю прискорюється для Edge CPU і NPU). Vector Dot Product -> C++ engine обчислює простий матрицю подібності Dot Product між новими Text Embeddings і попередньо обчисленими Label Embeddings. Структурований вихід -> Чисте навантаження JSON, що містить позначені діапазони, спрямовується назад до маршрутизатора за < 50 мілісекунд. Все це відбувається без того, щоб дані ніколи не торкалися хмари. Бенчмарк податку на інференцію Бенчмаркінг інференційного податку: три моделі в кольорі Я не просто теоретизував "податок на інференцію" - ми його вимірювали. Файл про Репозиторій, я побудував скрипти бенчмаркування Python для вилучення Згідно зі стандартним реченням pycompare FogAi ['animal', 'location', 'time', 'date'] Давайте подивимося на трьох конкурсантів у рингу: Важка вага (Загальна LLM): Qwen2.5-0.5B-Інструкція Спеціалізована важка вага: numind / NuExtract-1.5 (фінна екстракція LLM) Двигун Agile Bi-Encoder (FogAi's Engine): GLiNER-194M Ось основні емпіричні дані: 1 ст. 1 Закону України ( ) pycompare/test_llm_perf.py Модель: Qwen2.5-0.5B-Інструкція Архітектура: Generative Causal LM Вхідні токени: 53 Вихід генеруються токени: 100 Загальний час інференції: 3,524.42 мс (Так, 3,5 секунди) Відбиток оперативної пам'яті: 1,116.77 MB Результат: LLM галюцинував, випускаючи блок JSON, який повністю пропустив "коричневу лисицю" і "лізну собаку", за яким слідували 50 токенів небажаного внутрішнього монолога про те, як він планує вилучити суб'єкти. Спеціалізований LLM (NuExtract 1.5) Модель: numind/NuExtract-1.5 Архітектура: генеративний причинний LM (Fine-tuned for JSON extraction) Вхідні швидкі токени: 55 Вихід генеруються токени: 30 Загальний час інференції: ~1,200.00 мс Відбиток оперативної пам'яті: ~1,200.00 MB Результат: Точне вилучення суб'єктів у правильному форматі JSON, але він все ще страждає від авторегресивного генерації токенів. Це швидше, ніж Qwen, тому що він галюцинує менше, генеруючи менше вихідних токенів, але це все одно займає більше секунди. Використання біохімічних методів ( ) pycompare/test_gliner_perf.py Модель: knowledgator/gliner-bi-base-v2.0 Архітектура: Bi-Encoder Приблизна кількість вхідних токенів: 22 (текст + етикетки) Загальний час інференції (Python): 50,83 мс Total Inference Time (JNI/C++ Web Gateway): ~750.00 мс (Включаючи HTTP-фрамінг, чергування та мемкопію поза скупченням) Опис пам'яті: 824.11 MB Результат: Чистий, ідеально структурований видобуток {животно: «швидка коричнева лисиця», місцезнаходження: «Нью-Йорк», час: «5 вечора», дата: «Понеділок»}. Вердикт: вбудовані матеріали є кров'ю векторних баз даних Відвантажуючи видобуток знань до GLiNER, FogAi прискорює трубопровід до (3500ms проти 50ms в сирому виконанні) порівняно з загальним LLM, і перевершує тонко налаштовані видобувні LLM (як NuExtract), повністю обійшовши авторегресивний бар'єр. 6,800% Але жорстка екзекуція – це лише половина битви. How do we deploy it? Тест на інтеграцію шлюзів: тестування кожної топології (вузли A, B і C) В архітектурі FogAi я побудував три різні топології розгортання для тестування інтеграції GLiNER. Тип A (In-Process JNI): Виконує GLiNER прямо в C++ за допомогою прямого доступу до пам'яті (помилки пам'яті) всередині того ж JVM, що і Vert.x API Gateway. Тип B (Out-of-Process C++ gRPC): Виконує GLiNER в автономному C++ мікросервісі (використовуючи або MNN, або ONNX runtime) і спілкується з Gateway через HTTP/2. Тип C (Out-of-Process Python gRPC): Виконує GLiNER в стандартній мікрослужбі gRPC на базі Python, використовуючи runtime ONNX. Коли я перевірив завантаження всіх трьох вузлів через Vert.x API Gateway, результати були остаточними: Averaged per request under load. The combined overhead of Protobuf serialization, inter-process HTTP/2 networking, and the crushing weight of the Python Global Interpreter Lock (GIL) created a massive bottleneck. Type C (Out-of-Process Python gRPC): 3,200 ms - 4,500 ms Averaged per request under load. Even with a hyper-optimized C++ backend, the overhead of Protobuf serialization/deserialization and inter-process HTTP/2 networking created a massive bottleneck. Under stress tests ( ), the network stack overhead resulted in queue pileups for a model that normally takes 50ms to run natively. Type B (Out-of-Process C++ gRPC): 1,250 ms - 2,100 ms test_integration.sh Sustained end-to-end latency the HTTP Web Gateway routing, EDF queueing, Type A (In-Process JNI): ~750.00 ms including the "Vanilla" safety checks, and memory mapping. The direct off-heap C++ memory handoff bypassed the networking and serialization layer entirely. Обробляючи GLiNER натурально на вузлі краю типу A всередині MNN, я автоматично і отримання доступу до щільних контекстних вбудованих даних цих суб'єктів під час переходу вперед. Генеративні LLM не народжують вбудованих токенів для індексування баз даних без вторинних моделей вбудування. Робити це безпосередньо через JNI, перш ніж дані навіть надходять в хмарний кластер, дає мені можливість : Я можу миттєво побудувати тимчасові графіки знань з сирових джерел датчиків у полі. Безкоштовна оплата unfair advantage Покладаючись на LLM для локалізованого видобутку знань на крайньому вузлі, це зловживання апаратним обладнанням. Експорт GLiNER в C++ MNN Щоб досягти цих швидкостей інтеграції JNI без Python, я повинен перетворити модель HuggingFace GLiNER на модель MNN I обходити ONNX динамічної форми відстеження помилок в новітніх версіях PyTorch шляхом вилучення прямо з HuggingFace чіткий ONNX слідовий шар, і використовуючи . .mnn MNNConvert Я надав цей точний сценарій конверсії в В репозиторії : scripts/convert_gliner_to_mnn.sh #!/bin/bash ONNX_MODEL="models_onnx/gliner-bi-v2/onnx/model.onnx" MNN_DIR="models_mnn/gliner-bi-v2" mnnconvert -f ONNX --modelFile "$ONNX_MODEL" --MNNModel "$MNN_DIR/model.mnn" --bizCode MNN copy models_onnx/gliner-bi-v2/*.json "$MNN_DIR/" Перевірте магію самі Ви можете запустити бенчмарки Python на власному комп'ютері. Клонуйте репозиторій FogAi, перейдіть до , і виконайте тести, щоб подивитися податковий інвентар наживо: pycompare git clone https://github.com/NickZt/FogAi.git cd FogAi python3 -m venv venv && source venv/bin/activate pip install psutil gliner transformers accelerate python3 pycompare/test_gliner_perf.py python3 pycompare/test_llm_perf.py Бонус: підключення FogAi до Open WebUI З огляду на те, що нацизм виявляє (від ), вам навіть не потрібно писати власний клієнтський код, щоб взаємодіяти з ним. налаштування в репозиторії, що обертається на популярні інтерфейси чату, вказуючи безпосередньо на Gateway. OpenAI-compatible API /v1/chat/completions docker-compose Переконайтеся, що на вашому комп'ютері встановлено Docker. Перейти до каталогу UI і запустити сервіси: cd UI docker-compose up -d Open your browser and start chatting: : Open WebUI http://localhost:3000 : (Password is simply ) Lobe Chat http://localhost:3210 fogai Інтерфейси автоматично виходять на , відкрийте працюючі моделі MNN і ONNX, і дозвольте вам викликати їх, як якщо б вони працювали в хмарі. http://host.docker.internal:8080/v1
