Aufbau der Edge Intelligence-Datenleitung: Text zu strukturierten Entitäten in Millisekunden. Bei der Gestaltung der Eine der primären Einschränkungen, mit denen ich konfrontiert war, war die "Inferenzsteuer" - die computergestützte Oberfläche des Vertrauens auf massive, monolithische Large Language Models (LLMs), um Aufgaben auszuführen, für die sie nie optimal konzipiert wurden. FogAI In einer naiven Architektur könnte ein Entwickler Rohsensor-Logs oder Chat-Kontexte zu einem 7B- oder 8B-Parameter-Modell mit einem Anruf wie "Extract all the field units, locations, and timestamps from the following text." Es gibt zwei auffällige Probleme mit diesem Ansatz für Edge AI: Die Inferenzsteuer: Einfache Extraktion mit 8B-Parametern verbrennt Batterie, füllt VRAM und führt eine Latenz (300ms+ pro Abfrage) ein, um nur eine JSON-String zurückzugeben. Halluzinationen: LLMs sind generativ. Sie erraten, welches Token als nächstes kommt, was zu strukturellen Inkonsistenzen und gefertigten Entitäten führt. Um dies in FogAi zu lösen, habe ich eine dedizierte Verwendung der Modell (194M Parameter). läuft rein auf Diese Schicht überbrückt die Lücke zwischen Rohtextströmen und strukturierten handlungsfähigen Daten – alles ohne einen einzigen Python-Wrapper. Knowledge Extraction Layer knowledgator/gliner-bi-base-v2.0 MNN Hier ist der architektonische Zusammenbruch, wie ich die "magische" Geschwindigkeit extrahiere. Der Bi-Encoder Durchbruch Klassische NER-Modelle verlangen, dass Sie die Entitäten vordefinieren (z.B. , der , der ) während des Trainings. Der Moment, in dem Sie eine benutzerdefinierte Einheit wie oder Das Modell bricht. PERSON ORG LOC WELDING DEFECT RADIO FREQUENCY GLiNER (Generalist and Lightweight Named Entity Recognition) löst dies mit einer Es teilt den Codierungsprozess physikalisch in die Mitte: Bi-Encoder Architecture Text Encoder: Erstellt reiche kontextuelle Einbettungen für den Rohtext. Label Encoder: Erstellt Embeddings für die Liste der Entitäten, die Sie finden möchten. Warum ist diese architektonische Spaltung ein Meisterwerk für den Edge? Caching. In einem Randknoten, in dem Daten der Arbeitsstelle verfolgt werden, werden Ihre gewünschten Etiketten (z. B. ) ändert sich selten von Millisekunden zu Millisekunden. Weil die Text- und Label-Codierer abgeschnitten sind, . ['worker', 'forklift', 'safety_vest', 'pallet'] FogAi caches the Label Embeddings in RAM Für jeden neuen Textstrom, der kommt, muss das Gateway nur den Text Encoder ausführen. , unabhängig davon, ob Sie 5 Entity-Typen oder 500 suchen. Constant-Time Inference Vollständiger Datenfluss: Zero Python FogAi nutzt JNI und gRPC, um MNN-Inferenz direkt auszuführen.Der Workflow ist völlig frei von schwerer Python-Laufzeit: Raw Text Ingest -> Eine Rohzeile kommt zum Vert.x Gateway. JNI / C++ Hand-off -> Die Zeichenfolge wird direkt über Off-Heap-Speicherpuffer übertragen. MNN Text Encoder -> Der Gliner-bi-base-v2.0 ONNX-Diagramm wird über die MNN-Laufzeit ausgeführt (die für Edge-CPUs und NPUs vollständig beschleunigt ist). Vector Dot Product -> Die C++-Engine berechnet eine einfache Dot Product-Ähnlichkeitsmatrix zwischen den neuen Text-Embeddings und den vorbereiteten Label-Embeddings. Strukturierte Ausgabe -> Eine saubere JSON-Nutzlast, die die markierten Spannen enthält, wird in < 50 Millisekunden zum Router zurückverwiesen. All dies geschieht, ohne dass die Daten jemals die Cloud berühren. Benchmarking der Inferenzsteuer Benchmarking der Inferenzsteuer: Drei Modelle im Ring Ich habe nicht nur die „Inferenzsteuer“ theoretisiert – wir haben sie gemessen. Folder des Repository, Ich baute Python Benchmarking-Skripte, um zu extrahieren Aus einem normalen Satz. pycompare FogAi ['animal', 'location', 'time', 'date'] Schauen wir uns die drei Konkurrenten im Ring an: Das Schwergewicht (Allgemeine LLM): Qwen2.5-0.5B-Anweisung Das spezialisierte Schwergewicht: numind/NuExtract-1.5 (ein fein abgestimmter Extraktions-LLM) Der Agile Bi-Encoder (FogAis Motor): GLiNER-194M Hier die empirischen Daten von Kopf zu Kopf: 1. Die allgemeine LLM ( ) pycompare/test_llm_perf.py Modell: Qwen2.5-0.5B-Anweisung Architektur: Generative Causal LM Input Prompt Tokens: 53 Ausgabe Generierte Token: 100 Gesamte Inferenzzeit: 3,524.42 ms (Ja, 3,5 Sekunden) RAM Fußabdruck: 1.116.77 MB Das Ergebnis: Das LLM halluzinierte und brachte einen JSON-Block hervor, der den "braunen Fuchs" und den "lästigen Hund" völlig verpasst hatte, gefolgt von 50 Token eines unerwünschten internen Monologs darüber, wie es beabsichtigt, die Entitäten zu extrahieren. Der spezialisierte LLM (NuExtract 1.5) Modell: numind/NuExtract-1.5 Architektur: Generative Causal LM (Fine-Tuned für JSON-Extraktion) Input Prompt Tokens: 55 Ausgabe Generierte Token: 30 Gesamt Inferenzzeit: ~1,200.00 ms RAM Fußabdruck: ~1,200.00 MB Das Ergebnis: Genaue Extraktion der Entitäten im richtigen JSON-Format, aber es leidet immer noch unter der autoregressiven Token-Generation.Es ist schneller als Qwen, weil es weniger Halluziniert, generiert weniger Ausgabe-Token, aber es dauert immer noch über eine Sekunde. 3. Die FogAi Bi-Encoder-Lösung ( ) pycompare/test_gliner_perf.py Modell: knowledgator/gliner-bi-base-v2.0 Architektur: Bi-Encoder Ungefähre Input-Token: 22 (Text + Labels) Gesamte Inferenzzeit (Python): 50,83 ms Total Inference Time (JNI/C++ Web Gateway): ~750.00 ms (einschließlich HTTP-Framing, Reihenfolge und Memcopy) RAM Fußabdruck: 824,11 MB Das Ergebnis: saubere, perfekt strukturierte Extraktion von {animal: "quick brown fox", Ort: "New York", Zeit: "5 PM", Datum: "Monday"} Das Urteil: Embeddings sind das Blut von Vektordatenbanken Durch Entladen von Knowledge Extraction auf GLiNER beschleunigt FogAi die Pipeline um bis zu (3500ms vs. 50ms in roher Ausführung) im Vergleich zu einem allgemeinen LLM und übertrifft fein abgestimmte Extraktions-LLMs (wie NuExtract) durch die vollständige Umgehung der autoregressiven bottleneck. 6,800% Aber die rohe Hinrichtung ist nur die Hälfte des Kampfes. How do we deploy it? Der Gateway-Integrationstest: Testen jeder Topologie (Nodes A, B und C) In der FogAi-Architektur habe ich drei verschiedene Bereitstellungstopologien gebaut, um die Integration von GLiNER zu testen. Typ A (In-Process JNI): Führt GLiNER explizit in C++ über direkten Speicherzugriff (off-heap-Speicherpuffer) innerhalb des gleichen JVM wie das Vert.x API Gateway aus. Typ B (Out-of-Process C++ gRPC): Führt GLiNER in einem eigenständigen C++-Mikroservice (mit MNN oder ONNX-Laufzeit) aus und kommuniziert mit dem Gateway über HTTP/2. Typ C (Out-of-Process Python gRPC): Führt GLiNER in einem Standard-Python-basierten gRPC-Microservice mithilfe der ONNX-Laufzeit aus. Als ich alle drei Knoten über das Vert.x API Gateway geladen habe, waren die Ergebnisse endgültig: 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. Durch die Verarbeitung von GLiNER nativ auf einem Kantenknoten Typ A innerhalb von MNN werde ich automatisch und Erhalten Sie Zugang zu den dichten kontextuellen Embeddings dieser Entitäten während des forward-pass. Generative LLMs liefern nicht nativ Token-Embeddings für die Datenbank-Indexierung ohne sekundäre Embeddings-Modelle. : Ich kann sofort Temporal Knowledge Graphs aus rohen Sensor-Feeds auf dem Feld erstellen. Kostenfrei aufgeladen unfair advantage Die Abhängigkeit von LLMs für die lokalisierte Wissensextraktion auf einem Randknoten ist Hardwaremissbrauch. Exportieren von GLiNER zu C++ MNN Um diese JNI-Integrationsgeschwindigkeiten ohne Python zu erreichen, muss ich das HuggingFace GLiNER-Modell in das von MNN umwandeln Ich umgehe ONNX Dynamic Shape Tracking Bugs in neueren PyTorch-Versionen, indem ich die explizite ONNX-Trace-Schicht direkt von HuggingFace abhebe und . .mnn MNNConvert Ich habe dieses exakte Konvertierungsscript in In dem 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/" Überprüfen Sie die Magie selbst Du kannst die Python-Benchmarks auf deiner eigenen Maschine ausführen.Klone den FogAi-Repository, navigieren zu , und führen Sie die Tests aus, um die Inference Tax live zu sehen: 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 in Open WebUI einfügen Da FogAi nativ eine (in der ), Sie müssen nicht einmal benutzerdefinierten Client-Code schreiben, um mit ihm zu interagieren. Setup im Repository, das beliebte Chat-Schnittstellen dreht, die direkt auf den Gateway hinweisen. OpenAI-compatible API /v1/chat/completions docker-compose Stellen Sie sicher, dass Docker auf Ihrem Computer installiert ist. Navigieren Sie zum UI-Verzeichnis und starten Sie die Dienste: 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 Die Schnittstellen erreichen automatisch die Entdecken Sie die laufenden MNN- und ONNX-Modelle und lassen Sie sie so anrufen, als würden sie in der Cloud ausgeführt. http://host.docker.internal:8080/v1
