Het bouwen van de edge intelligence data pipeline: tekst naar gestructureerde entiteiten in milliseconden. Bij het ontwerpen van de Een van de primaire beperkingen waarmee ik geconfronteerd werd, was de "Inference Tax" - de computationele overhead van het vertrouwen op massale, monolithische Large Language Models (LLM's) om taken uit te voeren waarvoor ze nooit optimaal zijn ontworpen. FogAI In een naïeve architectuur kan een ontwikkelaar ruilen ruwe sensor logs of chat context naar een 7B of 8B parameter model met een prompt als "Extract all the field units, locations, and timestamps from the following text." Er zijn twee opvallende problemen met deze aanpak voor Edge AI: De Inference Tax: Het uitvoeren van eenvoudige extractie met 8B-parameters verbrandt de batterij, vult VRAM en introduceert latency (300ms+ per query) alleen om een JSON-string te retourneren. Hallucinaties: LLM's zijn generatief. ze raden aan welke token de volgende is, wat leidt tot structurele inconsistenties en gefabriceerde entiteiten. Om dit in FogAi op te lossen, heb ik een toegewijde Het gebruik van de model (194M parameters). loopt puur op , deze laag brengt de kloof tussen ruwe tekststromen en gestructureerde actiegebruikbare gegevens - allemaal zonder een enkele Python-wrapper. Knowledge Extraction Layer knowledgator/gliner-bi-base-v2.0 MNN Hier is de architecturale afbraak van hoe ik de "magische" snelheid haal. De bi-encoder doorbraak Klassieke NER-modellen vereisen dat u de entiteiten vooraf definieert (bijv. - het - het ) tijdens de training. Het moment dat u een aangepaste entiteit nodig hebt zoals of Het model breekt. PERSON ORG LOC WELDING DEFECT RADIO FREQUENCY GLiNER (Generalist and Lightweight Named Entity Recognition) lost dit op met een Het verdeelt het coderingsproces fysiek in het midden: Bi-Encoder Architecture Text Encoder: Creëert rijke contextuele embeddings voor de rauwe inkomende tekst. De Label Encoder: Creëert embeddings voor de lijst met entiteiten die u wilt vinden. Waarom is deze architecturale splitsing een meesterwerk voor de Edge? Caching. In een edge node die gegevens van de werkplek volgt, worden de gewenste labels (bijv. zelden veranderen van milliseconde naar milliseconde. omdat de tekst- en labelkoders zijn losgekoppeld, . ['worker', 'forklift', 'safety_vest', 'pallet'] FogAi caches the Label Embeddings in RAM Voor elke nieuwe tekststroom die aankomt, hoeft de Gateway alleen de Text Encoder uit te voeren. , ongeacht of u op zoek bent naar 5 entiteitstypen of 500. Constant-Time Inference Volledige gegevensstroom: Zero Python FogAi maakt gebruik van JNI en gRPC om MNN inferentie rechtstreeks uit te voeren. Raw Text Ingest -> Een raw string komt naar de Vert.x Gateway. JNI / C++ Hand-off -> De string wordt rechtstreeks doorgegeven via off-heap geheugenbuffers. MNN Text Encoder -> De gliner-bi-base-v2.0 ONNX grafiek wordt uitgevoerd via de MNN runtime (die volledig wordt versneld voor Edge CPU's en NPU's). Vector Dot Product -> De C++-engine berekent een eenvoudige Dot Product-gelijkheid matrix tussen de nieuwe Text Embeddings en de vooraf berekende Label Embeddings. Structured Output -> Een schone JSON-gewicht die de gemarkeerde bereiken bevat, wordt teruggestuurd naar de router in < 50 milliseconden. Dit alles gebeurt zonder dat de gegevens ooit de cloud raken. Benchmarking van de inferentiebelasting Benchmarking van de inferentiebelasting: drie modellen in de ring Ik heb niet alleen de “Inferentiebelasting” theoretiseerd – we hebben het gemeten. Folder van de ik heb Python benchmarking scripts gebouwd om te extraheren van een standaardwoord. pycompare FogAi ['animal', 'location', 'time', 'date'] Laten we eens kijken naar de drie concurrenten in de ring: De Heavyweight (Algemene LLM): Qwen2.5-0.5B-Instruct De gespecialiseerde Heavyweight: numind/NuExtract-1.5 (een fijn aangepaste extractie LLM) De Agile Bi-Encoder (FogAi's Engine): GLiNER-194M Hier de hoofd-tot-hoofd empirische gegevens: De algemene LLM ( ) pycompare/test_llm_perf.py Model: Qwen2.5-0.5B Instructie Architectuur: Generative Causal LM Input Prompt Tokens: 53 Uitvoer gegenereerde tokens: 100 Totaal Inferentietijd: 3,524.42 ms (Ja, 3,5 seconden) RAM Voetafdruk: 1,116.77 MB Het resultaat: De LLM hallucineerde en produceerde een JSON-blok dat de "bruine vos" en "laze hond" volledig miste, gevolgd door 50 tokens van een ongevraagde interne monoloog over hoe het van plan is om de entiteiten te extraheren. De gespecialiseerde LLM (NuExtract 1.5) Model: numind/NuExtract 1.5 Architectuur: Generative Causal LM (Fine-tuned voor JSON extractie) Input Prompt Tokens: 55 Uitvoer gegenereerde tokens: 30 Totaal Inferentie Tijd: ~1,200.00 ms RAM Voetafdruk: ~1,200.00 MB Het resultaat: Precieze extractie van de entiteiten in het juiste JSON-formaat, maar het lijdt nog steeds aan autoregressieve tokengeneratie overhead. De oplossingen van de FogAi Bi-Encoder Solution ( ) pycompare/test_gliner_perf.py Voorbeeld: knowledgator/gliner-bi-base-v2.0 Architectuur: Bi-Encoder Approximate Input Tokens: 22 (Text + Labels) Totaal Inferentie Tijd (Python): 50,83 ms Total Inference Time (JNI/C++ Web Gateway): ~750.00 ms (inclusief HTTP framing, wachtrij en off-heap memcopy) RAM Voetafdruk: 824.11 MB Het resultaat: Schone, perfect gestructureerde extractie van {dieren: "snelle bruine vos", locatie: "New York", tijd: "5 PM", datum: "Maandag"}. The Verdict: Embeddings zijn het bloed van vectordatabases Door Knowledge Extraction naar GLiNER af te laden, versnelt FogAi de pijpleiding met maximaal (3500ms versus 50ms in ruwe uitvoering) in vergelijking met een algemene LLM, en overtreft fijn aangepaste extractie LLMs (zoals NuExtract) door de autoregressieve bottleneck volledig te omzeilen. 6,800% Maar ruwe executie is slechts de helft van de strijd. How do we deploy it? De Gateway Integration Test: het testen van elke topologie (nodes A, B en C) In de FogAi-architectuur bouwde ik drie verschillende implementatietopologieën om de integratie van GLiNER te testen. Type A (In-Process JNI): Voert GLiNER expliciet uit in C++ via directe geheugentoegang (off-heap geheugenbuffers) in dezelfde JVM als de Vert.x API Gateway. Type B (Out-of-Process C++ gRPC): Voert GLiNER uit in een standalone C++ microservice (met behulp van MNN of ONNX runtime) en communiceert met de Gateway via HTTP/2. Type C (Out-of-Process Python gRPC): Voert GLiNER uit in een standaard Python-gebaseerde gRPC microservice met behulp van de ONNX runtime. Toen ik alle drie de knooppunten via de Vert.x API Gateway laad-testte, waren de resultaten definitief: 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. Door GLiNER natief te verwerken op een edge Type A-knooppunt in MNN, krijgen toegang tot de dichte contextuele embeddings van deze entiteiten tijdens de forward pass. Generatieve LLM's produceren niet natief token-embeddings voor database-indexering zonder secundaire embeddingsmodellen. : Ik kan onmiddellijk Temporal Knowledge Graphs bouwen uit ruwe sensorfeeds in het veld. Vrij van rekening unfair advantage Het vertrouwen op LLM's voor gelokaliseerde Knowledge Extraction op een edge node is hardware misbruik. GLiNER exporteren naar C++ MNN Om deze JNI-integratiesnelheden zonder Python te bereiken, moet ik het HuggingFace GLiNER-model converteren naar MNN's Ik omzeil ONNX dynamische vorm tracking bugs in nieuwere PyTorch versies door het ophalen van de expliciete ONNX trace laag rechtstreeks van HuggingFace, en met behulp van . .mnn MNNConvert Ik heb dit exacte conversie script in In het repository: 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/" Controleer de magie zelf Je kunt de Python benchmarks op je eigen machine uitvoeren. klonen de FogAi repository, navigeren naar , en voer de tests uit om de Inference Tax live te zien: 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 Bonus: FogAi pluggen in Open WebUI Sinds FogAi natively onthult een ( van ), je hoeft niet eens een aangepaste clientcode te schrijven om ermee te communiceren. ik heb een vooraf geconfigureerde instellen in het repository dat populaire chat-interfaces opspint die rechtstreeks op de Gateway wijzen. OpenAI-compatible API /v1/chat/completions docker-compose Zorg ervoor dat u Docker op uw machine hebt geïnstalleerd. Navigeren naar de UI-directory en de services starten: 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 De interfaces bereiken automatisch de , ontdek de lopende MNN- en ONNX-modellen en laat je ze roepen alsof ze in de cloud lopen. http://host.docker.internal:8080/v1
