Mobilní umělá inteligence s běhovým prostředím ONNX: Jak vytvořit funkční potlačení hluku v reálném čase

Váš telefon je výkonnější než stolní počítač z doby před pěti lety. Nejnovější vlajková loď zařízení s Androidem je vybavena neuronovými procesory, vícejádrovými procesory, kterým by záviděly i notebooky z roku 2019, a konfiguracemi RAM, které se ještě před pár lety zdály nemožné. Proč se tedy zdá, že sotva docházíme k tomu, co je možné s umělou inteligencí na mobilních telefonech? Jistě, nyní můžete dokonce lokálně na svém zařízení spouštět kvantizované verze modelů Llama a DeepSeek. Ale buďme upřímní – tyto konverzace se stále zdají neohrabané, pomalé a zdaleka se neblíží plynulému zážitku, který uživatelé od svých aplikací očekávají. Humbuk kolem konverzační umělé inteligence v zařízení je skutečný, ale praktická realita? Ještě tam docela nejsme. A právě zde většina vývojářů promešká příležitost: konverzační umělá inteligence není jedinou možností. Zatímco všichni usilují o další klon ChatGPT, existuje obrovský nevyužitý potenciál ve specializovaných aplikacích umělé inteligence, které skvěle fungují na mobilním hardwaru. v současné době Vezměte si například potlačení hluku. Vaši uživatelé neustále bojují s hlukem na pozadí během hovorů, nahrávek a hlasových zpráv. Vítr, doprava, pláč dětí, štěkající psi – je to nekonečná válka proti zvukovému chaosu. Ale co kdyby vaše aplikace dokázala tento hluk eliminovat v reálném čase, lokálně, aniž by do cloudu odeslala jediný bajt? Tohle není sci-fi. Děje se to dnes a každý vývojář pro Android to dokáže implementovat. Nástroje jsou vyspělé, výkon je dostatečný a vaši uživatelé si rozdílu okamžitě všimnou. ONNX Runtime: Vaše brána k mobilní umělé inteligenci Prostředí mobilní umělé inteligence je fragmentované. PyTorch dominuje výzkumu, tvorbě pravidel TensorFlow a pro specifické případy použití vzniká nespočet specializovaných frameworků. Pro vývojáře Androidu to představuje bolestivou volbu: zavázat se k jednomu ekosystému nebo udržovat oddělené vývojové postupy pro různé modely. Po vyhodnocení mobilních frameworků pro umělou inteligenci jsme z několika přesvědčivých důvodů, které přímo ovlivňují vývoj pro Android, zvolili ONNX Runtime. Širší kompatibilita napříč verzemi Androidu Na rozdíl od Google LiteRT (dříve TensorFlow Lite), který vyžaduje minimální úroveň SDK 31 (Android 12), ONNX Runtime pohodlně podporuje úrovně Android API až 24 (nebo dokonce 21, pokud jste kouzelník). Minimální podporovaná verze našeho projektu byla API 28, což z ONNX Runtime dělá jasnou volbu pro oslovení širšího publika, aniž by byly vyloučeny miliony aktivních uživatelů na zařízeních s Androidem 10 a staršími verzemi. Bezproblémová integrace napříč frameworky Největší silnou stránkou běhového prostředí ONNX je jeho nezávislost na daném frameworku. Ať už vaše modely umělé inteligence pocházejí z PyTorch, TensorFlow nebo dokonce z tradičních knihoven strojového učení, jako je scikit-learn, export modelů do ONNX umožňuje jednotné nasazení v prostředí Android, iOS, desktopů a cloudu. Tato flexibilita výrazně zjednodušuje údržbu a umožňuje sjednocený procesní proces, namísto žonglování s více nástroji specifickými pro daný framework. Lehké a modulární nasazení Integrace s ONNX Runtime je přímočará. Díky kompaktnímu souboru Maven AAR (kolem 5–7 MB pro sestavení pro CPU) se knihovna čistě integruje do vaší stávající aplikace pro Android, aniž by zaváděla zbytečné závislosti, jako jsou služby Google Play, nebo vyžadovala další uživatelská oprávnění. Toto zjednodušené nasazení udržuje vaši aplikaci štíhlou, výkonnou a bezpečnou. Osvědčený výkon v reálném čase ONNX Runtime je otestován v náročných reálných scénářích. Modely zpracování zvuku, jako je potlačení šumu nebo vylepšení řeči, konzistentně dosahují rychlosti inference pod 4 ms na zvukový snímek na standardním mobilním hardwaru – což pohodlně splňuje požadavky na výkon v reálném čase. Náš tým využil právě tuto schopnost pro spolehlivé potlačení šumu s nízkou latencí. ONNX Runtime našemu týmu v konečném důsledku poskytl nejen pohodlí, ale i strategickou výhodu – umožnil nám zachovat kompatibilitu, výkon a jednoduchost bez kompromisů. Pokud váš projekt vyžaduje dostupnou, výkonnou a škálovatelnou mobilní umělou inteligenci, ONNX Runtime by mohl být pro vás optimální volbou. Plán integrace: Nastavení běhového prostředí ONNX Výchozí balíček ONNX Runtime váží úctyhodných 27 MB. Pro mobilní aplikaci to není jen nadměrná velikost – je to zabiják akvizice uživatelů. Výzkum ukazuje, že s každým 6 MB nárůstem velikosti APK klesá míra konverze instalací o 1 % (měl bych poznamenat, že studie není nejnovější a netýká se převážně nejrozvinutějších zemí, ale přesto stojí za zvážení). Řešení? Vlastní minimalistická sestava, která zjednoduší vaše nasazení přesně na to, co potřebujete. Naše implementace potlačení šumu DTLN má velikost pouhých 7,1 MB – což je o 70 % menší velikost, díky čemuž bude vaše aplikace štíhlá a vaši uživatelé spokojení. Architektura běhového prostředí ONNX je modulární. Kompletní balíček zahrnuje poskytovatele pro akceleraci GPU (NNAPI, Vulkan), desítky operátorů, které nikdy nepoužijete, a vrstvy kompatibility pro okrajové případy, které se nevztahují na váš konkrétní model. Vytvořením pouze toho, co potřebujete, tuto režii zcela eliminujete. Krok 1: Převeďte své modely do formátu ORT Před sestavením převeďte své modely ONNX do formátu ORT. Tento optimalizovaný formát odstraňuje nepoužívané uzly grafu a definice operátorů, čímž dále snižuje konečnou velikost binárního souboru. Krok 2: Vytvoření konfigurace operátora python -m onnxruntime.tools.convert_onnx_models_to_ort --target_platform {arm,amd64} Po převodu všech potřebných modelů budou také vygenerovány konfigurační soubory s potřebnými operátory, které budou potřebné pro minimální sestavení ONNX. Při použití několika modelů sloučte všechny konfigurační soubory do jednoho. Finální soubor bude vypadat nějak takto: # 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 Krok 3: Spuštění vlastní sestavy # 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 S připravenou konfigurací operátora sestavte ONNX Runtime ze zdrojového kódu s minimálními závislostmi: --minimal_build: Vylučuje nepotřebné poskytovatele a operátory provádění ./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: Zahrnuje pouze operátory uvedené v konfiguračním souboru --android_abi armeabi-v7a: Cílí na ARM32 pro maximální kompatibilitu se zařízeními --android_api 24: Zachovává kompatibilitu s Androidem 7.0+ Pokud chcete podporovat i starší zařízení, opakujte krok 3 s –android_abi armeabi-v7a a sloučte oba výsledné soubory AAR pomocí následujícího skriptu: Minimální přístup k sestavení transformuje ONNX Runtime z překážky při nasazení na strategickou výhodu. Vaši uživatelé získají plnou funkcionalitu umělé inteligence bez zbytečných komplikací a vaše aplikace si zachovává štíhlý profil, který moderní vývoj mobilních aplikací vyžaduje. #!/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" Dále se podívejme na tento optimalizovaný běhový modul v akci s potlačením šumu DTLN v reálném čase. Proč zpracování zvuku ukazuje hodnotu umělé inteligence Zpracování zvuku je perfektním úvodem do světa mobilní umělé inteligence – přináší okamžitou a hmatatelnou hodnotu, zatímco vaši konkurenti se potýkají s nafouklými jazykovými modely, které vyčerpávají baterie a vyžadují neustálé připojení k internetu. Denní audio válka, kterou vaši uživatelé bojují Sarah nahrává hlasové zprávy při procházce rušnou ulicí. Mezi troubením taxíků, hlukem ze stavby a duněním metra si zprávy třikrát znovu nahraje, než to vzdá a začne psát. Marcus se připojuje k hovorům s klienty ze své domácí kanceláře, která slouží zároveň jako herna pro jeho batole. Každá prezentace se stává cyklem „ztlumit, zapnout zvuk, omluvit se za pláč“. Elena vytváří obsah pro YouTube ve svém bytě, ale v postprodukci tráví hodiny úklidem hluku od sousedů, dopravy a hučení klimatizace. Nejedná se o žádné extrémní případy – je to realita moderní mobilní výpočetní techniky, kde každý očekává profesionální výsledky od spotřebitelského hardwaru v chaotickém prostředí. Proč potlačení hluku vytváří okamžité momenty „wow“ Vylepšení kvality zvuku vyvolává okamžité emocionální reakce. Na rozdíl od jiných aplikací s umělou inteligencí, které vyžadují vysvětlení, poskytuje potlačení šumu okamžité uspokojení, které uživatelé vnímají během několika sekund. Přehrajte někomu jeho vlastní hlas – křišťálově čistě – po odstranění šumu v pozadí a sledujte jeho reakci. Nemusí rozumět sítím LSTM; stačí, když vědí, že jejich zvuk zní profesionálně. Krása zpracování zvuku jakožto ukázky umělé inteligence spočívá v univerzálnosti. Každý rozumí dobrému zvuku, každý už zažil špatný zvuk a každý okamžitě pozná zlepšení, když zmizí šum. Nechcete po uživatelích, aby vaší umělé inteligenci důvěřovali – dokazujete její hodnotu tím nejpřímějším možným způsobem. Vytvoření dema připraveného pro produkci: Potlačení šumu v reálném čase Nyní si vytvořme ukázkový projekt, který demonstruje praktickou sílu ONNX Runtime na Androidu. Místo jednoduchého příkladu „hello world“ vytvoříme něco blízkého produkční kvalitě – demonstraci potlačení šumu v reálném čase, kde si uživatelé mohou nahrávat zvuk v hlučném prostředí a zažít výrazný rozdíl mezi původní nahrávkou a verzí upravenou umělou inteligencí. Kompletní ukázku najdete zde, na mém Githubu: . https://github.com/linreal/android-onnx-showcase Modely použité ve vzorku pocházejí z https://github.com/breizhn/DTLN Rychlý přehled implementace Než se ponoříme do architektury DTLN s dvojitou cestou, pojďme si ujasnit, jak jednotlivé části do sebe zapadají. Krása této implementace spočívá v jasném oddělení odpovědností – každá komponenta má jednu odpovědnost, díky čemuž je systém testovatelný i udržovatelný. Základní komponenty V srdci našeho systému potlačování hluku se nacházejí tři klíčová rozhraní, která spolupracují: NoiseSuppressor zapouzdřuje veškerou složitost běhového prostředí ONNX za jednoduchým rozhraním. Posílá audio bloky a získává zpět odšumený zvuk. Stavová povaha DTLN je zcela skrytá – implementace interně udržuje stavy LSTM mezi voláními. 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 } Architektura datového toku ConcurrentAudioProcessor řídí celý proces. Přihlásí se k odběru toku zvukového záznamníku, převádí zvukové formáty, zpracovává části zvuku pomocí potlačovače šumu a zapisuje původní i zpracovaný zvuk do souborů současně. AudioRecorder → Flow → ConcurrentAudioProcessor → NoiseSuppressor → Processed Audio Files Proč tato architektura funguje 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) } } Design založený na flow zajišťuje, že vaše uživatelské rozhraní zůstane responzivní. Zpracování zvuku probíhá ve vláknech na pozadí, zatímco hlavní vlákno se stará o interakce s uživateli. Reaktivní zpracování: Každá komponenta pracuje se svým preferovaným zvukovým formátem. produkuje ShortArray (16bitový PCM), zatímco očekává FloatArray (normalizované vzorky). Konverze probíhá na hranici. Izolace formátu: AudioRecorder NoiseSuppressor Pokud se inicializace ONNX nezdaří, ovlivní se pouze komponenta NoiseSuppressor. Zvukový záznamník a zapisovače souborů fungují nadále, což zajišťuje plynulou degradaci. Hranice chyb: Každá komponenta spravuje své vlastní zdroje. koordinuje události životního cyklu, ale nevlastní podkladové implementace. Správa zdrojů: ConcurrentAudioProcessor Tento modulární přístup znamená, že můžete vyměnit implementaci DTLN za jakýkoli jiný model ONNX, nahradit zvukový záznamník zdrojem založeným na souborech nebo upravit výstupní formát bez nutnosti zásahu do jiných komponent. Architektura se škáluje od testování konceptu až po produkční nasazení. Dále prozkoumáme architekturu DTLN, která tuto magii umožňuje. Pochopení architektury DTLN Tradiční přístupy k potlačení šumu čelí zásadnímu kompromisu. Metody frekvenční domény vynikají v odstraňování stacionárního šumu (klimatizace, hučení ventilátoru), ale potýkají se s dynamickými zvuky, jako je prosakování řeči nebo hudby. Přístupy v časové doméně si dobře poradí se složitými, proměnlivými signály, ale často zavádějí artefakty nebo selhávají s konzistentním šumem v pozadí. DTLN toto omezení zcela obchází díky své architektuře s dvojitou cestou: První model pracuje ve frekvenční doméně a analyzuje spektrální charakteristiky zvuku. Generuje potlačovací masku, která identifikuje, které frekvenční složky obsahují šum oproti řeči. Tato fáze vyniká v odstraňování stacionárního šumu na pozadí – stálého hučení klimatizace, dopravy nebo kancelářského hovoru. Fáze 1: Zpracování ve frekvenční doméně // 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 } Fáze 2: Zpřesnění časové domény // 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 } Maskovaný signál ve frekvenční doméně se převede zpět do časové domény a poté se přivede do druhého modelu, který pracuje přímo s průběhem zvuku. Tato fáze zachycuje to, co frekvenční analýza přehlédla – zpracovává dynamické šumové vzory, zachovává přirozenost řeči a odstraňuje veškeré artefakty z první fáze. Filozofie designu zaměřeného na mobilní zařízení // 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)) Architektura DTLN odráží dlouholeté praktické zkušenosti s nasazením mobilní umělé inteligence. Každé návrhové rozhodnutí upřednostňuje omezení reálného světa před akademickými kritérii. Model zpracovává zvuk v blocích o 512 vzorkech (32 ms při 16 kHz), čímž dosahuje optimální rovnováhy mezi latencí a kontextem. Velikost tohoto bloku je dostatečně malá pro zpracování v reálném čase, ale zároveň dostatečně velká, aby poskytla smysluplný časový kontext pro sítě LSTM. Zpracování založené na blocích companion object { private const val BLOCK_LEN = 512 // 32ms chunks private const val BLOCK_SHIFT = 128 // 75% overlap for smooth processing } Stavové sítě LSTM companion object { private const val BLOCK_LEN = 512 // 32ms chunks private const val BLOCK_SHIFT = 128 // 75% overlap for smooth processing } Oba modely používají sítě LSTM (dlouhá krátkodobá paměť), které uchovávají vnitřní stav mezi jednotlivými segmenty paměti. Tato časová paměť umožňuje modelu rozlišovat mezi řečí a šumem na základě kontextu, nikoli pouze okamžitých zvukových charakteristik. Výkonnostní charakteristiky, na kterých záleží 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 } } Pochopení architektury DTLN pomáhá předvídat jeho chování ve vaší aplikaci. Tyto výkonnostní charakteristiky přímo ovlivňují uživatelskou zkušenost: Profil latence Algoritmické zpoždění: 32 ms (doba zpracování jednoho bloku) Doba inference: 3-4 ms na blok na hardwaru Android střední třídy Celková latence: ~35 ms mezi konci (pro většinu případů použití nepostřehnutelná) Využití zdrojů Zatížení paměti: ~28 MB během aktivního zpracování Využití CPU: 12-18 % na typickém zařízení střední třídy Dopad na baterii: Zanedbatelný pro typické nahrávání Díky těmto vlastnostem je DTLN obzvláště vhodný pro mobilní aplikace, kde uživatelé očekávají okamžité výsledky bez kompromisů v oblasti výkonu zařízení nebo výdrže baterie. Strategie integrace běhového prostředí ONNX Zprovoznění ONNX Runtime na Androidu není jen o přidání závislosti do souboru build.gradle. Rozdíl mezi proof-of-concept implementací, která při zátěži padá, a implementací připravenou pro produkční prostředí spočívá v konfiguraci relace, správě paměti a strategii alokace zdrojů. Protože jsme již připravili minimální běhovou verzi, je čas podívat se, co bude dál. Konfigurace relace pro mobilní realitu Výchozí konfigurace běhového prostředí ONNX předpokládá, že běžíte na serveru s dostatkem zdrojů. Mobilní zařízení fungují se zcela jinými omezeními: omezenou pamětí, tepelným omezením a uživateli, kteří očekávají, že aplikace budou během zpracování umělou inteligencí reagovat. Vaším prvním instinktem by mohlo být využít všechna dostupná jádra procesoru pro maximální výkon. Odolejte tomuto nutkání. Mobilní zařízení upřednostňují výdrž baterie před hrubou výpočetní rychlostí a systém Androidu dokáže agresivní využití procesoru během několika sekund snížit. 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) } Ideální počet vláken pro zpracování zvuku v reálném čase je 2–4, což závisí na počtu jader vašeho zařízení: Tato konfigurace poskytuje 95 % maximálního výkonu a zároveň spotřebovává o 60 % méně baterie než neomezený fond vláken. Uživatelé si více všimnou zvýšení efektivity než malého rozdílu v latenci. private val numThreads = Runtime.getRuntime().availableProcessors().coerceIn(1, 4) aktivuje nejúčinnější optimalizaci pro mobilní zařízení v ONNX Runtime. Toto nastavení analyzuje vzorce přístupu k paměti vašeho modelu během prvních několika inferenčních volání a poté předem alokuje paměťové fondy, aby se minimalizovalo zatížení garbage collection během zpracování v reálném čase. setMemoryPatternOptimization(true) Sekvenční provádění se může zdát neintuitivní, když paralelní zpracování nabízí vyšší propustnost. Zpracování zvuku v reálném čase však vyžaduje předvídatelnou latenci namísto špičkového výkonu. Paralelní provádění vytváří špičky latence, když dochází k synchronizaci vláken – přesně tomu se chcete při zpracování živého zvuku vyhnout. setExecutionMode(OrtSession.SessionOptions.ExecutionMode.SEQUENTIAL) Sekvenční provádění poskytuje konzistentní inferenční časy 3–4 ms, zatímco paralelní režim se pohybuje od 2 do 8 ms s nepředvídatelnými špičkami. Uživatelé vnímají konzistenci jako kvalitu. Předběžná alokace paměti: Násobitel výkonu Nejdůležitější optimalizace pro mobilní ONNX Runtime aplikace zahrnuje předběžnou alokaci tenzorů, které se znovu používají při inferenčních voláních. Vytváření tenzorů během inference spouští alokace paměti, které se hromadí a způsobují značná úzká hrdla výkonu. // 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) } Snížení tlaku při svozu odpadu // 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) } - Vytváření tenzorů během inference generuje objekty, které musí být uvolňovány. Předběžná alokace přesouvá tyto náklady do doby inicializace, čímž se cesty inference udržují bez nutnosti alokace. – Opakované vytváření tenzorů fragmentuje paměť haldy, což vede k neočekávaným chybám alokace. Předem alokované tenzory udržují konzistentní rozložení paměti. Prevence fragmentace paměti – Náklady na alokaci jsou nepředvídatelné a mohou způsobit špičky latence během zpracování v reálném čase. Předběžná alokace zajišťuje konzistentní načasování inference. Konzistence latence Tyto integrační strategie transformují ONNX Runtime z výzkumného nástroje na komponentu připravenou k produkčnímu prostředí. Možnosti konfigurace, vzory správy paměti a přístupy k ošetření chyb přímo ovlivňují uživatelskou zkušenost způsoby, které se projeví až v reálných podmínkách používání. Můžete se podívat do pro kompletní zdrojový kód. https://github.com/linreal/android-onnx-showcase/blob/main/app/src/main/java/gos/denver/onnxshowcase/audio/impl/NoiseSuppressorImpl.kt Závěr: Umělá inteligence jako konkurenční výhoda Oblast mobilní umělé inteligence prochází zásadním posunem. Zatímco konkurence honí jazykové modely náročné na zdroje a cloudová řešení, existuje obrovská příležitost ve specializované umělé inteligenci na zařízeních, která uživatelům přináší okamžitou hodnotu. Klíčové poznatky pro vývojáře Androidu Kombinace optimalizačních možností ONNX Runtime a účelových modelů, jako je DTLN, poskytuje výkon, který se vyrovná nebo převyšuje cloudová řešení, a zároveň eliminuje latenci a požadavky na připojení. Vaši uživatelé získají okamžité výsledky a vy získáte funkci, která funguje všude – od tunelů metra až po režim v letadle. Umělá inteligence na zařízení je připravena k produkci již dnes. Naše minimální sestavení ONNX Runtime snížilo velikost knihovny o 70 % bez obětování funkčnosti. Nejde jen o úložiště – přímo to ovlivňuje získávání uživatelů. Když funkce umělé inteligence přidají do vaší aplikace 7 MB místo 27 MB, rovnice nákladů a přínosů se dramaticky změní ve váš prospěch. Optimalizace velikosti APK transformuje strategii nasazení. DTLN není nejpokročilejším dostupným modelem potlačení šumu, ale pro mobilní nasazení dosahuje perfektní rovnováhy mezi kvalitou, výkonem a spotřebou zdrojů. Uživatelům nezáleží na architektuře modelu – záleží jim na křišťálově čistém zvuku v hlučném prostředí. Uživatelská zkušenost vítězí nad algoritmickou sofistikovaností. Aplikace implementující umělou inteligenci přímo v zařízení získávají tři konkurenční výhody: Ochrana soukromí již v návrhu (žádná citlivá data neopouštějí zařízení), spolehlivost offline (konzistentní zážitek bez ohledu na síťové podmínky) a výhody struktury nákladů (žádné náklady na cloudové inference ani provozní náklady, které se zvyšují s využitím). Další kroky a průzkum Techniky zde demonstrované sahají daleko za rámec potlačení šumu. ONNX Runtime umožňuje praktické nasazení modelů pro zpracování zvuku, počítačové vidění, úlohy přirozeného jazyka a aplikace fúze senzorů. Kompletní implementace je k dispozici na GitHubu: Použijte to jako základ pro vaše vlastní funkce poháněné umělou inteligencí. android-onnx-showcase Vaše aplikace pro Android si zaslouží umělou inteligenci, která vylepší uživatelský zážitek bez kompromisů v oblasti výkonu, soukromí nebo spolehlivosti. ONNX Runtime umožňuje tuto vizi dosáhnout již dnes. Nástroje jsou připraveny, výkon je ověřený – je čas vytvořit něco úžasného. Přišla vám tato implementace užitečná? Označte hvězdičkou a sdílejte své výsledky. Komunita mobilní umělé inteligence sílí, když sdílíme praktické znalosti. Repozitář GitHubu Sledujte mě pro další podrobnější informace o implementacích mobilní umělé inteligence připravených pro produkční prostředí, kterých si vaši uživatelé skutečně všimnou a ocení.