בניית צינור הנתונים של אינטליגנציה קצה: טקסט אל ישויות מובנות במילישניות. כאשר מתכננים את אחת המגבלות העיקריות שעלינו להתמודד איתה הייתה "מסים ההנפקה" - ההסתמכות החישובית על מודלים גדולים, מונוליטיים (LLMs) כדי לבצע משימות שמעולם לא היו מתוכננות באופן אופטימלי. FogAI בארכיטקטורה נאיבית, מפתחים עשויים להעביר יומני חיישן אקראיים או מסגרת צ'אט למודל פרמטרים 7B או 8B עם הצעה כגון: "Extract all the field units, locations, and timestamps from the following text." יש שתי בעיות ברורות עם גישה זו עבור Edge AI: מס ההנחה: ביצוע תמצית פשוטה עם פרמטרים של 8B שורף סוללה, ממלא VRAM, ומציג עיכוב (300ms+ לשאילתה) רק כדי להחזיר שורת JSON. Hallucinations: LLMs הם גנרטורים.הם לנחש איזה טוקן מגיע הבא, מה שמוביל לחוסר עקביות מבנית וארגונים מעוצבים. כדי לפתור את זה ב 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 ה- Text Encoder: יוצר שקיפות קונקטקטואליות עשירות עבור הטקסט המגיעים. האקודר לתוויות: יוצר השבבים עבור הרשימה של ישויות שברצונך למצוא. מדוע הפרדה אדריכלית זו היא מופת עבור הקצה? Caching. ב- edge node מעקב אחר נתוני אתר העבודה, התוויות הרצויות שלך (למשל, ) לעתים רחוקות לשנות ממילישניות למילישניות.כי הקודרים טקסט ותוויות נפרדים, . ['worker', 'forklift', 'safety_vest', 'pallet'] FogAi caches the Label Embeddings in RAM עבור כל זרם טקסט חדש שמגיע, Gateway צריך רק להפעיל את Text Encoder. , בין אם אתם מחפשים 5 סוגים של ישויות או 500. Constant-Time Inference זרימת נתונים מלאה: Zero Python FogAi מנצל JNI ו-gRPC כדי לבצע MNN inference ישירות.The workflow is entirely free of heavy Python runtime overhead: Raw Text Ingest -> שורת שורש מגיעה ל- Vert.x Gateway. JNI / C++ Hand-off -> החוט מועבר ישירות דרך קופונים של זיכרון מחוץ לקופון. MNN Text Encoder -> הגרף gliner-bi-base-v2.0 ONNX מתבצע באמצעות זמן ההפעלה של MNN (הוא מואץ לחלוטין עבור Edge CPUs ו- NPUs). Vector Dot Product -> המנוע C++ מחשב מטרייה פשוטה של דמיון של מוצר Dot בין השבבים החדשים של טקסט לבין השבבים של תוויות מחושבים מראש. יציאה מובנית -> עומס שימושי JSON נקי המכיל את השטחים המתויגים מועבר בחזרה למסלול בתוך < 50 מילישניות. כל זה קורה מבלי שהנתונים נוגעים בענן. Benchmarking מס ההשפעה ביחס למס ההנחה: שלושה מודלים בטבעת אני לא רק תיאורטיזתי את "מס ההנחה" - אנחנו מדיכנו אותו. הפרופיל של ה repository, I built Python benchmarking scripts to לחלץ מתוך משפט סטנדרטי. pycompare FogAi ['animal', 'location', 'time', 'date'] בואו נסתכל על שלושת המתחרים בטבעת: משקל כבד (General LLM): Qwen2.5-0.5B-מדריך משקל כבד המומחה: numind / NuExtract-1.5 (LLM החילוץ מתואם) ה- Agile Bi-Encoder (מנוע של FogAi): GLiNER-194M הנה נתונים אמפיריים ראש אל ראש: תגית: תגית: LLM ( ) pycompare/test_llm_perf.py דגם: Qwen2.5-0.5B-Instruct ארכיטקטורה: Generative Causal LM כניסה מיידית טוקינים: 53 תוצאת טוקינים שנוצרו: 100 זמן ההשוואה הכולל: 3.524.42 ms (כן, 3.5 שניות) טביעת אצבע RAM: 1.116.77 MB התוצאה: LLM הזיע, יוצא בלוק JSON שחסר לחלוטין את "הזונה השחורה" ו "הכלב הקשוח", ולאחר מכן 50 תוויות של מונולוג פנימי לא מבוקש על איך הוא מתכנן לחלץ את הישות. LLM המומחה (NuExtract 1.5) מודל: numind/NuExtract-1.5 ארכיטקטורה: Generative Causal LM (Fine-tuned for JSON extraction) כניסה מיידית טוקינים: 55 טוקינוסים שנוצרו: 30 זמן ההשוואה הכולל: ~1,200.00 ms טביעת אצבע RAM: ~1,200.00 MB התוצאה: תמצית מדויקת של הישויות בפורמט JSON הנכון, אך היא עדיין סובלת מהיווצרות טוקן אוטרגרסיבית.היא מהירה יותר מ- Qwen משום שהיא מרתיעה פחות, ומייצרת פחות טוקי פלט, אבל זה עדיין לוקח יותר משנייה. תגיות קשורות תגיות קשורות תגיות קשורות תגיות קשורות תגיות קשורות ( ) pycompare/test_gliner_perf.py דגם: knowledgator/gliner-bi-base-v2.0 ארכיטקטורה: Bi-Encoder סה"כ טוקי כניסה: 22 (טקסט + תוויות) זמן ההשוואה הכולל (Python): 50.83 ms Total Inference Time (JNI/C++ Web Gateway): ~750.00 ms (כולל HTTP framing, queuing, and off-heap memcopy) זיכרון RAM: 824.11 MB התוצאה: ניצול טהור ומבנה מושלם של {חיה: "זונה חומה מהירה", מיקום: "ניו יורק", זמן: "5 PM", תאריך: "יום שני"}. ההחלטה: השבבים הם הדם של מסדי נתונים וקטור על-ידי הורדת ייצור הידע ל-GLiNER, FogAi מאיץ את הצינור עד (3500ms לעומת 50ms בביצוע טהור) בהשוואה ל- LLM כללי, והופך את LLM החילוץ המתאים (כמו NuExtract) על ידי מעבר לחלוטין את מחסום הבקבוק האוטורגרסיבי. 6,800% אבל ההוצאה להורג היא רק חצי מהמאבק. How do we deploy it? מבחן השילוב של Gateway: בדיקת כל טופולוגיה (Nodes 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 סטנדרטי באמצעות זמן הפעלת 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, אני אוטומטית להשיג גישה להתמזגויות הקונקצנטואליות העמוקות של ישויות אלה במהלך העברה הקדמית. LLMs גנרטורים לא לייצר באופן מקורי את התמזגויות טוקן עבור אינדקס מסד נתונים ללא מודלים התמזגויות משניים. אני יכול מיד לבנות תרשימי ידע זמניים מתוך זרימת חיישנים טהורה בשדה. חינם בתשלום unfair advantage להסתמך על LLMs עבור חיסול ידע מקומי על צומת קצה הוא התעללות בחומרה. ייצוא GLiNER ל- C++ MNN כדי להשיג את מהירות האינטגרציה של JNI ללא Python, אני חייב להמיר את המודל HuggingFace GLiNER ל- MNN. אני עובר על שגיאות מעקב צורה דינמית ONNX בגירסאות PyTorch החדשות יותר על ידי קבלת שכבת מעקב ONNX מפורשת ישירות מ- HuggingFace, ובאמצעות . .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 על המחשב שלך. , ולבצע את הבדיקות כדי לראות את מס ההנחה בחיים: 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 מכיוון ש-FOGAI מגלה באופן מקורי (למשל ), אתה אפילו לא צריך לכתוב קוד לקוח מותאם אישית כדי לקיים אינטראקציה עם זה. התקנה במאגר שמסובבת את ממשקי הצ'אט הפופולריים המעידים ישירות על 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
