בינה מלאכותית ניידת עם זמן ריצה של ONNX: כיצד לבנות דיכוי רעשים בזמן אמת שעובד

הטלפון שלכם חזק יותר ממחשב שולחני מלפני חמש שנים. מכשירי הדגל החדשים ביותר של אנדרואיד מצוידים ביחידות עיבוד עצביות, מעבדים מרובי ליבות שהיו מעוררים קנאה במחשבים ניידים של 2019, ותצורות זיכרון RAM שנראו בלתי אפשריות רק לפני כמה שנים. אז למה זה מרגיש שאנחנו בקושי מגרדים את פני השטח של מה שאפשרי עם בינה מלאכותית בנייד? ברור, עכשיו אפשר אפילו להריץ גרסאות כמותיות של מודלים של Llama ו-DeepSeek באופן מקומי במכשיר שלכם. אבל בואו נהיה כנים - השיחות האלה עדיין מרגישות מגושמות, איטיות ולא מתקרבות לחוויה החלקה שמשתמשים מצפים מהאפליקציות שלהם. ההייפ סביב בינה מלאכותית שיחתית במכשיר אמיתי, אבל המציאות המעשית? אנחנו עדיין לא שם. הנה המקום שבו רוב המפתחים מפספסים את ההזדמנות: בינה מלאכותית שיחתית אינה המשחק היחיד בעיר. בעוד שכולם רודפים אחר שיבוט ChatGPT הבא, יש פוטנציאל עצום שלא נוצל ביישומי בינה מלאכותית ייעודיים שעובדים בצורה מבריקה על חומרה ניידת . כרגע קחו לדוגמה את נושא דיכוי הרעשים. המשתמשים שלכם נאבקים כל הזמן ברעשי רקע במהלך שיחות, הקלטות והודעות קוליות. רוח, תנועה, תינוקות בוכים, כלבים נובחים - זוהי מלחמה אינסופית נגד כאוס שמע. אבל מה אם האפליקציה שלכם הייתה יכולה לחסל את הרעש הזה בזמן אמת, באופן מקומי, מבלי לשלוח אפילו בייט אחד לענן? זה לא מדע בדיוני. זה קורה היום, וכל מפתח אנדרואיד יכול ליישם את זה. הכלים בוגרים, הביצועים שם, והמשתמשים שלכם יבחינו בהבדל מיד. זמן ריצה של ONNX: השער שלך לבינה מלאכותית ניידת נוף הבינה המלאכותית הניידת מקוטע. PyTorch שולט במחקר, ביצירת חוקי TensorFlow, ואינספור מסגרות ייעודיות צצות עבור מקרי שימוש ספציפיים. עבור מפתחי אנדרואיד, זה יוצר בחירה כואבת: להתחייב למערכת אקולוגית אחת או לתחזק צינורות נפרדים עבור מודלים שונים. לאחר הערכת מסגרות בינה מלאכותית למובייל, בחרנו ב-ONNX Runtime מכמה סיבות משכנעות המשפיעות ישירות על פיתוח אנדרואיד. תאימות רחבה יותר בין גרסאות אנדרואיד בניגוד ל- LiteRT של גוגל (לשעבר TensorFlow Lite), אשר מחייב רמת SDK מינימלית של 31 (אנדרואיד 12), ONNX Runtime תומך בנוחות ברמות API של אנדרואיד עד 24 (או אפילו 21, אם אתם קוסמים). הגרסה המינימלית הנתמכת של הפרויקט שלנו הייתה API 28, מה שהופך את ONNX Runtime לבחירה הברורה להגיע לקהל רחב יותר מבלי להוציא מיליוני משתמשים פעילים במכשירי אנדרואיד 10 ומכשירים מוקדמים יותר. אינטגרציה חלקה בין מסגרות החוזק הגדול ביותר של ONNX Runtime טמון באופיו האגנוסטי למסגרת העבודה. בין אם מודלי הבינה המלאכותית שלכם מגיעים מ-PyTorch, TensorFlow, או אפילו מספריות למידה חינוכית מסורתיות כמו scikit-learn, ייצוא מודלים ל-ONNX מאפשר פריסה אחידה על פני אנדרואיד, iOS, מחשבים שולחניים וסביבות ענן. גמישות זו מפשטת משמעותית את התחזוקה, ומאפשרת ניהול צינור מאוחד במקום להתעסק עם מספר כלים ספציפיים למסגרת העבודה. פריסה קלת משקל ומודולרית האינטגרציה עם ONNX Runtime היא פשוטה. עם גרסה קומפקטית של Maven AAR (כ-5-7 מגה-בייט עבור גרסאות CPU), הספרייה משתלבת בצורה חלקה באפליקציית האנדרואיד הקיימת שלך מבלי להכניס תלויות מיותרות כמו שירותי Google Play או לבקש הרשאות משתמש נוספות. פריסה יעילה זו שומרת על האפליקציה שלך רזה, יעילה ומאובטחת. ביצועים מוכחים בזמן אמת זמן הריצה של ONNX נבדק היטב בתרחישים תובעניים בזמן אמת. מודלים של עיבוד אודיו, כגון דיכוי רעשים או שיפור דיבור, מספקים באופן עקבי מהירויות הסקה של פחות מ-4 אלפיות שנייה לכל מסגרת שמע בחומרה ניידת סטנדרטית - בנוחות במסגרת דרישות הביצועים בזמן אמת. הצוות שלנו מינף את היכולת הזו בדיוק לדיכוי רעשים אמין ובעל השהייה נמוכה. בסופו של דבר, ONNX Runtime סיפק לצוות שלנו לא רק נוחות, אלא גם יתרון אסטרטגי - ואפשר לנו לשמור על תאימות, ביצועים ופשטות ללא פשרות. אם הפרויקט שלכם דורש בינה מלאכותית ניידת נגישה, יעילה וניתנת להרחבה, ONNX Runtime בהחלט יכולה להיות הבחירה האופטימלית שלכם. תוכנית אינטגרציה: הגדרת זמן ריצה של ONNX חבילת ברירת המחדל של ONNX Runtime שוקלת 27 מגה-בייט. עבור אפליקציה סלולרית, זה לא רק ניפוח - זה גורם להרג משתמשים. מחקרים מראים שעל כל עלייה של 6 מגה-בייט בגודל ה-APK, שיעורי ההמרה של ההתקנות יורדים ב-1% (יש לציין שהמחקר אינו החדש ביותר, והוא נוגע בעיקר לא למדינות המפותחות ביותר, אך עדיין, שווה לשקול אותו). הפתרון? בנייה מינימלית מותאמת אישית שמצמצמת את הפריסה שלך בדיוק למה שאתה צריך. יישום דיכוי הרעשים של DTLN שלנו מסתכם ב-7.1MB בלבד - צמצום גודל של 70% ששומר על האפליקציה שלך רזה ועל המשתמשים שלך מרוצים. הארכיטקטורה של ONNX Runtime היא מודולרית מבחינה עיצובית. החבילה המלאה כוללת ספקי ביצוע להאצת GPU (NNAPI, Vulkan), עשרות אופרטורים שלעולם לא תשתמשו בהם, ושכבות תאימות למקרי קצה שאינם חלים על המודל הספציפי שלכם. על ידי בניית רק מה שאתם צריכים, אתם מבטלים את התקורה הזו לחלוטין. שלב 1: המר את המודלים שלך לפורמט ORT לפני הבנייה, המירו את מודלי ה-ONNX שלכם לפורמט ORT. פורמט אופטימלי זה מסיר צמתי גרף והגדרות אופרטורים שאינם בשימוש, ומקטין עוד יותר את גודל הבינארי הסופי. שלב 2: יצירת תצורת מפעיל python -m onnxruntime.tools.convert_onnx_models_to_ort --target_platform {arm,amd64} לאחר המרת כל המודלים הדרושים, ייווצרו גם קבצי תצורה עם האופרטורים הדרושים שיידרשו לבנייה מינימלית של ONNX. בעת שימוש במספר מודלים, יש לאחד את כל קבצי התצורה לאחד. הקובץ הסופי ייראה בערך כך: # Generated from model/s: ai.onnx;1;Transpose ai.onnx;6;Sigmoid ai.onnx;7;Add,LSTM ai.onnx;9;MatMul ai.onnx;11;Concat,Slice,Squeeze,Unsqueeze ai.onnx;1;Transpose ai.onnx;5;Reshape //other operators שלב 3: ביצוע בנייה מותאמת אישית # Generated from model/s: ai.onnx;1;Transpose ai.onnx;6;Sigmoid ai.onnx;7;Add,LSTM ai.onnx;9;MatMul ai.onnx;11;Concat,Slice,Squeeze,Unsqueeze ai.onnx;1;Transpose ai.onnx;5;Reshape //other operators לאחר שתצורת המפעיל שלך מוכנה, בנה את זמן הריצה של ONNX מהמקור עם תלויות מינימליות: --minimal_build: לא כולל ספקי ביצוע ואופרטורים מיותרים ./build.sh --android \ --android_sdk_path ~/Library/Android/sdk \ --android_ndk_path ~/Library/Android/sdk/ndk/28.0.12674087 \ --android_abi arm64-v8a \ --android_api 24 \ --minimal_build \ --include_ops_by_config path/to/required_operators.config \ --build_java \ --config=Rel ./build.sh --android \ --android_sdk_path ~/Library/Android/sdk \ --android_ndk_path ~/Library/Android/sdk/ndk/28.0.12674087 \ --android_abi arm64-v8a \ --android_api 24 \ --minimal_build \ --include_ops_by_config path/to/required_operators.config \ --build_java \ --config=Rel --include_ops_by_config: כולל רק אופרטורים שצוינו בקובץ התצורה שלך --android_abi armeabi-v7a: מכוון ל-ARM32 לתאימות מרבית למכשירים --android_api 24: שומר על תאימות עם אנדרואיד 7.0+ אם ברצונך לתמוך גם במכשירים ישנים, חזור על שלב 3 עם –android_abi armeabi-v7a והם ימזגו את שני קבצי ה-aar שנוצרו באמצעות הסקריפט הבא: גישת הבנייה המינימלית הופכת את זמן הריצה של ONNX מנטל פריסה ליתרון אסטרטגי. המשתמשים שלכם מקבלים את מלוא יכולות הבינה המלאכותית ללא הנפח, והאפליקציה שלכם שומרת על הפרופיל הרזה שפיתוח מובייל מודרני דורש. #!/usr/bin/env sh # Clean up from previous runs, if any rm -rf merge-tmp mkdir -p merge-tmp cd merge-tmp echo "Unzipping each ABI-specific AAR..." mkdir a64 unzip ../onnxruntime-arm64-v8a.aar -d a64 mkdir a32 unzip ../onnxruntime-armeabi-v7a.aar -d a32 echo "Preparing universal base from arm64 AAR..." mkdir universal cp -r a64/* universal rm -rf universal/jni mkdir -p universal/jni echo "Merging native libs from each architecture..." mkdir -p universal/jni/arm64-v8a cp a64/jni/arm64-v8a/*.so universal/jni/arm64-v8a mkdir -p universal/jni/armeabi-v7a cp a32/jni/armeabi-v7a/*.so universal/jni/armeabi-v7a # Re-zip contents of 'universal' to create a new AAR echo "Creating universal AAR..." cd universal zip -r onnxruntime-universal.aar ./* echo "Done! The merged AAR is at:" echo "$(pwd)/onnxruntime-universal.aar" #!/usr/bin/env sh # Clean up from previous runs, if any rm -rf merge-tmp mkdir -p merge-tmp cd merge-tmp echo "Unzipping each ABI-specific AAR..." mkdir a64 unzip ../onnxruntime-arm64-v8a.aar -d a64 mkdir a32 unzip ../onnxruntime-armeabi-v7a.aar -d a32 echo "Preparing universal base from arm64 AAR..." mkdir universal cp -r a64/* universal rm -rf universal/jni mkdir -p universal/jni echo "Merging native libs from each architecture..." mkdir -p universal/jni/arm64-v8a cp a64/jni/arm64-v8a/*.so universal/jni/arm64-v8a mkdir -p universal/jni/armeabi-v7a cp a32/jni/armeabi-v7a/*.so universal/jni/armeabi-v7a # Re-zip contents of 'universal' to create a new AAR echo "Creating universal AAR..." cd universal zip -r onnxruntime-universal.aar ./* echo "Done! The merged AAR is at:" echo "$(pwd)/onnxruntime-universal.aar" בשלב הבא, בואו נראה את זמן הריצה הממוטב הזה בפעולה עם דיכוי רעשי DTLN בזמן אמת. מדוע עיבוד אודיו מציג את ערך הבינה המלאכותית עיבוד אודיו הוא ההיכרות המושלמת עם בינה מלאכותית ניידת - הוא מספק ערך מיידי ומוחשי בזמן שהמתחרים שלך מתמודדים עם מודלי שפה נפוחים שמרוקנים סוללות ודורשים חיבורי אינטרנט קבועים. מלחמת האודיו היומית שבה נלחמים המשתמשים שלכם שרה מקליטה הודעות קוליות בזמן שהיא הולכת ברחוב סואן. בין צפירות מוניות, רעשי בנייה ורעש הרכבת התחתית, היא מקליטה מחדש את ההודעות שלוש פעמים לפני שהיא מוותרת ומקלידה במקום זאת. מרקוס מצטרף לשיחות לקוחות ממשרדו הביתי, המשמש גם כחדר המשחקים של הפעוט שלו. כל מצגת הופכת למעגל של "השתקה, בטל השתקה, התנצלות על הבכי". אלנה יוצרת תוכן ליוטיוב בדירתה, אבל מבלה שעות בפוסט-פרודקשן כדי לנקות את רעשי השכנים, התנועה וזמזום המזגן. אלה אינם מקרי קצה - זוהי המציאות של מחשוב נייד מודרני שבו כולם מצפים לתוצאות מקצועיות מחומרה צרכנית בסביבות כאוטיות. למה דיכוי רעשים יוצר רגעי "וואו" מיידיים שיפורי איכות השמע מעוררים תגובות רגשיות מיידיות. בניגוד ליישומי בינה מלאכותית אחרים הדורשים הסבר, דיכוי רעשים מספק סיפוק מיידי שמשתמשים יכולים לקלוט תוך שניות. השמיעו למישהו את קולו - צלול כשמש - לאחר הסרת רעשי רקע, וצפו בתגובתו. הם לא צריכים להבין רשתות LSTM; הם רק יודעים שהשמע שלהם נשמע מקצועי. היופי של עיבוד אודיו כחלון ראווה של בינה מלאכותית טמון באוניברסליות. כולם מבינים אודיו טוב, כולם חוו אודיו גרוע, וכולם מזהים מיד שיפור כאשר הרעש נעלם. אתם לא מבקשים מהמשתמשים לסמוך על הבינה המלאכותית שלכם - אתם מוכיחים את ערכה בצורה הישירה ביותר האפשרית. בניית הדגמה מוכנה להפקה: דיכוי רעשים בזמן אמת כעת, בואו נבנה פרויקט לדוגמה שמדגים את הכוח המעשי של ONNX Runtime באנדרואיד. במקום דוגמה בסיסית של "שלום עולם", ניצור משהו קרוב לאיכות הפקה - הדגמה של דיכוי רעשים בזמן אמת שבה משתמשים יכולים להקליט אודיו בסביבות רועשות ולחוות את ההבדל הבולט בין ההקלטה המקורית שלהם לגרסה שנקתה על ידי בינה מלאכותית. ניתן למצוא דוגמה מלאה כאן, בגיטהאב שלי: . https://github.com/linreal/android-onnx-showcase המודלים, ששימשו במדגם, הם מ https://github.com/breizhn/DTLN סקירת יישום מהירה לפני שנצלול לתוך הארכיטקטורה הדו-נתיבית של DTLN, בואו נבחן כיצד החלקים משתלבים יחד. היופי של יישום זה טמון בהפרדה נקייה בין התחומים - לכל רכיב יש אחריות אחת, מה שהופך את המערכת לניתנת לבדיקה ולתחזוקה כאחד. רכיבי הליבה בלב צינור דיכוי הרעשים שלנו נמצאים שלושה ממשקים מרכזיים שעובדים יחד: ה-NoiseSuppressor עוטף את כל מורכבות זמן הריצה של ONNX מאחורי ממשק פשוט. הוא מזין קטעי אודיו ומחזיר אודיו ללא רעש. האופי הסטטוסי של DTLN מוסתר לחלוטין - המימוש שומר על מצבי LSTM באופן פנימי בין קריאות. interface NoiseSuppressor { suspend fun initialize() fun processChunk(audioChunk: FloatArray): FloatArray fun release() } interface AudioRecorder { suspend fun startRecording(): Flow suspend fun stopRecording() } interface ConcurrentAudioProcessor { suspend fun startProcessing( suppressor: NoiseSuppressor, rawOutputFile: File, processedOutputFile: File ) suspend fun stopProcessing(): ProcessingResult } interface NoiseSuppressor { suspend fun initialize() fun processChunk(audioChunk: FloatArray): FloatArray fun release() } interface AudioRecorder { suspend fun startRecording(): Flow suspend fun stopRecording() } interface ConcurrentAudioProcessor { suspend fun startProcessing( suppressor: NoiseSuppressor, rawOutputFile: File, processedOutputFile: File ) suspend fun stopProcessing(): ProcessingResult } ארכיטקטורת זרימת נתונים מעבד השמע הקונקוררנטי (ConcurrentAudioProcessor) מנהל את כל תהליך העיבוד. הוא נרשם ל-Flow של מקליט השמע, ממיר פורמטי שמע, מעבד קטעים דרך מדכא הרעשים, וכותב שמע מקורי ומעובד לקבצים בו זמנית. AudioRecorder → Flow → ConcurrentAudioProcessor → NoiseSuppressor → Processed Audio Files למה הארכיטקטורה הזו עובדת rawAudioRecorder.startRecording().collect { audioChunk -> // Convert format for processing val floatChunk = AudioConversionUtils.shortArrayToFloatArray(audioChunk) // Process through DTLN val processedChunk = suppressor.processChunk(floatChunk) // Save both versions concurrently launch { rawFileWriter.writeAudioData(floatChunk) } launch { processedFileWriter.writeAudioData(processedChunk) } } rawAudioRecorder.startRecording().collect { audioChunk -> // Convert format for processing val floatChunk = AudioConversionUtils.shortArrayToFloatArray(audioChunk) // Process through DTLN val processedChunk = suppressor.processChunk(floatChunk) // Save both versions concurrently launch { rawFileWriter.writeAudioData(floatChunk) } launch { processedFileWriter.writeAudioData(processedChunk) } } העיצוב מבוסס הזרימה מבטיח שממשק המשתמש יישאר רספונסיבי. עיבוד אודיו מתרחש בשרשורי רקע בעוד שהשרשור הראשי מטפל באינטראקציות של המשתמש. עיבוד ריאקטיבי: כל רכיב עובד עם פורמט האודיו המועדף עליו. מייצר ShortArray (PCM של 16 סיביות), בעוד ש- מצפה ל-FloatArray (דגימות מנורמלות). ההמרה מתרחשת בגבול. בידוד פורמט: AudioRecorder NoiseSuppressor אם אתחול ONNX נכשל, רק רכיב ה-NoiseSuppressor מושפע. מקליט השמע וכותבי הקבצים ממשיכים לתפקד, ומבטיחים ירידה חלקה ברמת הביצועים. גבולות שגיאה: כל רכיב מנהל את המשאבים שלו. מעבד ה- מתאם אירועי מחזור חיים אך אינו הבעלים של המימושים הבסיסיים. ניהול משאבים: ConcurrentAudioProcessor גישה מודולרית זו מאפשרת להחליף את יישום ה-DTLN בכל דגם ONNX אחר, להחליף את מקליט האודיו במקור מבוסס קבצים, או לשנות את פורמט הפלט מבלי לגעת ברכיבים אחרים. הארכיטקטורה מתקדמת מהוכחת היתכנות ועד לפריסת ייצור. לאחר מכן, נחקור את ארכיטקטורת ה-DTLN שהופכת את הקסם הזה לאפשרי. הבנת ארכיטקטורת DTLN גישות מסורתיות לדיכוי רעשים מתמודדות עם פשרות מהותיות. שיטות בתחום התדרים מצטיינות בהסרת רעשים נייחים (מיזוג אוויר, זמזום מאוורר) אך מתקשות בצלילים דינמיים כמו דיבור או מוזיקה שחודרים החוצה. גישות בתחום הזמן מטפלות היטב באותות מורכבים ומשתנים, אך לעתים קרובות מציגות ארטיפקטים או נכשלות עקב רעשי רקע עקביים. DTLN עוקף מגבלה זו לחלוטין באמצעות ארכיטקטורת הנתיבים הכפולים שלו: המודל הראשון פועל בתחום התדרים, ומנתח את המאפיינים הספקטרליים של האודיו שלכם. הוא מייצר מסכת דיכוי שמזהה אילו רכיבי תדר מכילים רעש לעומת דיבור. שלב זה מצטיין בהסרת רעשי רקע נייחים - הזמזום הקבוע של מיזוג אוויר, תנועה או שיחות משרדיות. שלב 1: עיבוד תחום התדרים // Stage 1: Frequency domain mask estimation val (magnitude, phase) = fftProcessor.forward(inBuffer) val outMask = model1.run(mapOf("input_2" to magnitudeTensor, "input_3" to lstmState)) for (i in magnitude.indices) { magnitude[i] *= outMask[i] // Apply suppression mask } שלב 2: חידוד תחום הזמן // Stage 1: Frequency domain mask estimation val (magnitude, phase) = fftProcessor.forward(inBuffer) val outMask = model1.run(mapOf("input_2" to magnitudeTensor, "input_3" to lstmState)) for (i in magnitude.indices) { magnitude[i] *= outMask[i] // Apply suppression mask } אות תחום התדר המוסווה מומר חזרה לתחום הזמן, ולאחר מכן מוזן למודל שני שפועל ישירות על צורת הגל של השמע. שלב זה לוכד את מה שניתוח התדר החמיץ - טיפול בדפוסי רעש דינמיים, שמירה על טבעיות הדיבור וניקוי כל ארטיפקטים מהשלב הראשון. פילוסופיית העיצוב "מובייל תחילה" // Stage 2: Time domain refinement val estimatedBlock = fftProcessor.inverse(magnitude, phase) val finalBlock = model2.run(mapOf("input_4" to estimatedTensor, "input_5" to lstmState)) // Stage 2: Time domain refinement val estimatedBlock = fftProcessor.inverse(magnitude, phase) val finalBlock = model2.run(mapOf("input_4" to estimatedTensor, "input_5" to lstmState)) הארכיטקטורה של DTLN משקפת שנים של ניסיון מעשי בפריסה מעשית של בינה מלאכותית במובייל. כל החלטת עיצוב נותנת עדיפות לאילוצים של העולם האמיתי על פני מדדים אקדמיים. המודל מעבד אודיו בקטעים בני 512 דגימות (32ms ב-16kHz), תוך איזון אופטימלי בין השהייה (Latency) להקשר. גודל קטע זה קטן מספיק לעיבוד בזמן אמת אך גדול מספיק כדי לספק הקשר זמני משמעותי עבור רשתות LSTM. עיבוד מבוסס-קטעים (Chunk-Based Processing) companion object { private const val BLOCK_LEN = 512 // 32ms chunks private const val BLOCK_SHIFT = 128 // 75% overlap for smooth processing } רשתות LSTM בעלות מצב companion object { private const val BLOCK_LEN = 512 // 32ms chunks private const val BLOCK_SHIFT = 128 // 75% overlap for smooth processing } שני המודלים משתמשים ברשתות LSTM (זיכרון ארוך טווח קצר) אשר שומרות על מצב פנימי בין קטעים. זיכרון זמני זה מאפשר למודל להבחין בין דיבור לרעש על סמך הקשר, ולא רק על סמך מאפייני שמע מיידיים. מאפייני ביצועים שחשובים class NoiseSuppressorImpl { // These tensors maintain LSTM state between processing calls private var input3Tensor: OnnxTensor? = null // Model 1 LSTM state private var input5Tensor: OnnxTensor? = null // Model 2 LSTM state fun processChunk(audioChunk: FloatArray): FloatArray { // State automatically carries forward to next chunk val result1 = model1.run(mapOf("input_3" to input3Tensor)) input3Tensor?.close() input3Tensor = result1[1] as OnnxTensor // Update state // State continuity ensures smooth, artifact-free processing } } class NoiseSuppressorImpl { // These tensors maintain LSTM state between processing calls private var input3Tensor: OnnxTensor? = null // Model 1 LSTM state private var input5Tensor: OnnxTensor? = null // Model 2 LSTM state fun processChunk(audioChunk: FloatArray): FloatArray { // State automatically carries forward to next chunk val result1 = model1.run(mapOf("input_3" to input3Tensor)) input3Tensor?.close() input3Tensor = result1[1] as OnnxTensor // Update state // State continuity ensures smooth, artifact-free processing } } הבנת הארכיטקטורה של DTLN עוזרת לחזות את התנהגותה ביישום שלך. מאפייני ביצועים אלה משפיעים ישירות על חוויית המשתמש: פרופיל השהייה עיכוב אלגוריתמי: 32ms (זמן עיבוד של נתח אחד) זמן הסקה: 3-4 מילישניות לכל נתח בחומרת אנדרואיד בינונית השהיה כוללת: ~35ms מקצה לקצה (לא מורגש ברוב מקרי השימוש) שימוש במשאבים טביעת רגל של זיכרון: ~28MB במהלך עיבוד פעיל ניצול מעבד: 12-18% במכשיר בינוני טיפוסי השפעה על הסוללה: זניחה עבור הקלטות אופייניות מאפיינים אלה הופכים את DTLN למתאימה במיוחד עבור יישומים ניידים שבהם משתמשים מצפים לתוצאות מיידיות מבלי להתפשר על ביצועי המכשיר או חיי הסוללה. אסטרטגיית אינטגרציה בזמן ריצה של ONNX לגרום ל-ONNX Runtime לעבוד על אנדרואיד לא רק להוסיף תלות לקובץ build.gradle שלך. ההבדל בין הוכחת היתכנות שקורסת תחת עומס לבין יישום מוכן לייצור טמון בתצורת הסשן, ניהול הזיכרון ואסטרטגיית הקצאת המשאבים. מכיוון שכבר הכנו בניית זמן ריצה מינימלית, הגיע הזמן לבדוק מה צופן העתיד. הגדרת סשן עבור מציאות ניידת תצורת ברירת המחדל של ONNX Runtime מניחה שאתה פועל על שרת עם משאבים רבים. מכשירים ניידים פועלים תחת אילוצים שונים לחלוטין: זיכרון מוגבל, ויסות תרמי ומשתמשים שמצפים שאפליקציות יישארו מגיבות במהלך עיבוד בינה מלאכותית. האינסטינקט הראשון שלך עשוי להיות להשתמש בכל ליבות המעבד הזמינות לקבלת ביצועים מקסימליים. התנגד לדחף הזה. מכשירים ניידים נותנים עדיפות לחיי סוללה על פני מהירות חישוב גולמית, וניהול התרמי של אנדרואיד יבטל את השימוש האגרסיבי במעבד תוך שניות. private val sessionOptions = OrtSession.SessionOptions().apply { setIntraOpNumThreads(numThreads.coerceIn(1, 4)) setInterOpNumThreads(numThreads) setMemoryPatternOptimization(true) setOptimizationLevel(OrtSession.SessionOptions.OptLevel.ALL_OPT) setExecutionMode(OrtSession.SessionOptions.ExecutionMode.SEQUENTIAL) } private val sessionOptions = OrtSession.SessionOptions().apply { setIntraOpNumThreads(numThreads.coerceIn(1, 4)) setInterOpNumThreads(numThreads) setMemoryPatternOptimization(true) setOptimizationLevel(OrtSession.SessionOptions.OptLevel.ALL_OPT) setExecutionMode(OrtSession.SessionOptions.ExecutionMode.SEQUENTIAL) } הנקודה המתוקה לעיבוד אודיו בזמן אמת נמצאת בין 2-4 תהליכים, שנקבעים על ידי ספירת הליבות של המכשיר שלך: תצורה זו מספקת 95% מהביצועים המרביים תוך צריכת סוללה של 60% פחות בהשוואה למאגר הליכים בלתי מוגבל. המשתמשים שלך מבחינים ביתרונות היעילות יותר מאשר בהבדל הקטן בזמן ההשהיה. private val numThreads = Runtime.getRuntime().availableProcessors().coerceIn(1, 4) הפונקציה מפעילה את אופטימיזציית המובייל המשפיעה ביותר של ONNX Runtime. הגדרה זו מנתחת את דפוסי הגישה לזיכרון של המודל שלך במהלך קריאות ההסקה הראשונות, ולאחר מכן מקצה מראש מאגרי זיכרון כדי למזער את לחץ איסוף האשפה במהלך עיבוד בזמן אמת. setMemoryPatternOptimization(true) ביצוע סדרתי עשוי להיראות לא הגיוני כאשר עיבוד מקבילי מציע תפוקה גבוהה יותר. עם זאת, עיבוד אודיו בזמן אמת דורש השהייה צפויה על פני ביצועי שיא. ביצוע מקבילי יוצר קפיצות השהייה כאשר מתרחש סנכרון הלידים - בדיוק מה שרוצים להימנע ממנו במהלך עיבוד אודיו חי. setExecutionMode(OrtSession.SessionOptions.ExecutionMode.SEQUENTIAL) ביצוע סדרתי מספק זמני הסקה עקביים של 3-4 אלפיות שנייה, בעוד שמצב מקבילי נע בין 2-8 אלפיות שנייה עם קפיצות בלתי צפויות. משתמשים תופסים עקביות כאיכות. הקצאת זיכרון מראש: מכפיל הביצועים האופטימיזציה הקריטית ביותר עבור יישומי ONNX Runtime ניידים כרוכה בהקצאה מוקדמת של טנזורים אשר נמצאים בשימוש חוזר בקריאות הסקה. יצירת טנזורים במהלך הסקה גורמת להקצאת זיכרון המצטברת לצווארי בקבוק משמעותיים בביצועים. // Pre-allocate tensors during initialization input3Tensor = createZeroTensor(INP_SHAPE_2) // Model 1 LSTM state input5Tensor = createZeroTensor(INP_SHAPE_2) // Model 2 LSTM state private fun createZeroTensor(shape: LongArray): OnnxTensor { val env = requireNotNull(env) { "ONNX Environment not initialized" } val size = shape.reduce { acc, i -> acc * i }.toInt() return OnnxTensor.createTensor(env, FloatBuffer.allocate(size), shape) } הפחתת לחץ איסוף אשפה // Pre-allocate tensors during initialization input3Tensor = createZeroTensor(INP_SHAPE_2) // Model 1 LSTM state input5Tensor = createZeroTensor(INP_SHAPE_2) // Model 2 LSTM state private fun createZeroTensor(shape: LongArray): OnnxTensor { val env = requireNotNull(env) { "ONNX Environment not initialized" } val size = shape.reduce { acc, i -> acc * i }.toInt() return OnnxTensor.createTensor(env, FloatBuffer.allocate(size), shape) } - יצירת טנזורים במהלך הסקה יוצרת אובייקטים שיש לאסוף אותם כ"זבל". הקצאה מוקדמת מעבירה עלות זו לזמן האתחול, ושומרת על נתיבי הסקה פנויים מהקצאה. - יצירה חוזרת של פיצולי טנזורים אוגרת זיכרון, מה שמוביל לכשלים בלתי צפויים בהקצאה. טנזורים שהוקצו מראש שומרים על פריסת זיכרון עקבית. מניעת פיצול זיכרון - עלויות הקצאה אינן צפויות ויכולות לגרום לקפיצות בהשהיה במהלך עיבוד בזמן אמת. הקצאה מוקדמת מבטיחה תזמון הסקה עקבי. עקביות בהשהיה אסטרטגיות אינטגרציה אלו הופכות את ONNX Runtime מכלי מחקר לרכיב מוכן לייצור. בחירות התצורה, דפוסי ניהול הזיכרון וגישות הטיפול בשגיאות משפיעות ישירות על חוויית המשתמש בדרכים שמתבררות רק בתנאי שימוש אמיתיים. אתה יכול לבחון עבור קוד מקור מלא. https://github.com/linreal/android-onnx-showcase/blob/main/app/src/main/java/gos/denver/onnxshowcase/audio/impl/NoiseSuppressorImpl.kt סיכום: בינה מלאכותית כיתרון תחרותי נוף הבינה המלאכותית הניידת חווה שינוי מהותי. בעוד המתחרים רודפים אחר מודלים של שפה זוללי משאבים ופתרונות תלויי ענן, יש הזדמנות עצומה בבינה מלאכותית ייעודית, המותאמת למכשיר, ומספקת ערך מיידי למשתמשים. נקודות מפתח למפתחי אנדרואיד השילוב של יכולות האופטימיזציה של ONNX Runtime ומודלים ייעודיים כמו DTLN מספק ביצועים התואמים או עולים על פתרונות ענן, תוך ביטול דרישות השהייה וקישוריות. המשתמשים שלכם מקבלים תוצאות מיידיות, ואתם מקבלים תכונה שעובדת בכל מקום - ממנהרות רכבת תחתית ועד למצב טיסה. בינה מלאכותית במכשיר מוכנה לייצור כבר היום. בניית ONNX Runtime המינימלית שלנו הפחיתה את גודל הספרייה ב-70% מבלי להתפשר על פונקציונליות. זה לא רק עניין של אחסון - זה משפיע ישירות על רכישת משתמשים. כאשר תכונות של בינה מלאכותית מוסיפות 7MB במקום 27MB לאפליקציה שלך, משוואת העלות-תועלת משתנה באופן דרמטי לטובתך. אופטימיזציה של גודל ה-APK משנה את אסטרטגיית הפריסה. DTLN אינו מודל דיכוי הרעשים המתקדם ביותר שקיים, אך הוא משיג את האיזון המושלם בין איכות, ביצועים וצריכת משאבים לפריסה ניידת. למשתמשים לא אכפת מארכיטקטורת המודל - אכפת להם מאודיו צלול כבדולח בסביבות רועשות. חוויית המשתמש גוברת על תחכום אלגוריתמי. אפליקציות המיישמות בינה מלאכותית במכשיר משיגות שלושה יתרונות תחרותיים: פרטיות מעוצבת (לא עוזבים נתונים רגישים את המכשיר), אמינות לא מקוונת (חוויה עקבית ללא קשר לתנאי הרשת) ויתרונות מבנה עלויות (ללא עלויות הסקה של ענן או הוצאות תפעול שמתרחבות בהתאם לשימוש). הצעדים הבאים והחקירה הטכניקות המוצגות כאן מרחיקות לכת הרבה מעבר לדיכוי רעשים. זמן הריצה של ONNX מאפשר פריסה מעשית של מודלים לעיבוד אודיו, ראייה ממוחשבת, משימות שפה טבעית ויישומי מיזוג חיישנים. המימוש המלא זמין ב-GitHub: השתמשו בו כבסיס לתכונות שלכם המופעלות על ידי בינה מלאכותית. אנדרואיד-onnx-showcase אפליקציית האנדרואיד שלך ראויה לבינה מלאכותית שתשפר את חוויית המשתמש מבלי להתפשר על ביצועים, פרטיות או אמינות. ONNX Runtime מאפשרת את החזון הזה להישגים כבר היום. הכלים מוכנים, הביצועים מוכחים - הגיע הזמן לבנות משהו מדהים. מצאתם את היישום הזה שימושי? סמנו בכוכב ושתפו את התוצאות שלכם. קהילת הבינה המלאכותית הניידת מתחזקת כשאנחנו חולקים ידע מעשי. מאגר גיטהאב עקבו אחריי לעוד היכרות מעמיקה עם יישומי בינה מלאכותית ניידת מוכנים לייצור, שהמשתמשים שלכם באמת ישימו לב אליהם ויעריכו.