Intelligenza artificiale mobile con ONNX Runtime: come creare una soppressione del rumore in tempo reale efficace

Il tuo telefono è più potente di un computer desktop di cinque anni fa. Gli ultimi dispositivi Android di punta sono dotati di unità di elaborazione neurale, CPU multi-core che farebbero invidia ai laptop del 2019 e configurazioni di RAM che sembravano impossibili solo pochi anni fa. Allora perché abbiamo la sensazione di aver appena scalfito la superficie di ciò che è possibile con l'intelligenza artificiale sui dispositivi mobili? Certo, ora puoi persino eseguire versioni quantizzate dei modelli Llama e DeepSeek localmente sul tuo dispositivo. Ma siamo onesti: quelle conversazioni risultano ancora macchinose, lente e ben lontane dall'esperienza fluida che gli utenti si aspettano dalle loro app. L'entusiasmo per l'intelligenza artificiale conversazionale sui dispositivi è reale, ma la realtà pratica? Non ci siamo ancora arrivati. Ed è qui che la maggior parte degli sviluppatori perde l'opportunità: l'intelligenza artificiale conversazionale non è l'unica opzione disponibile. Mentre tutti sono alla ricerca del prossimo clone di ChatGPT, c'è un enorme potenziale inesplorato in applicazioni di intelligenza artificiale specializzate che funzionano brillantemente sull'hardware mobile. al momento Prendiamo la soppressione del rumore. I tuoi utenti sono costantemente alle prese con il rumore di fondo durante chiamate, registrazioni e messaggi vocali. Vento, traffico, bambini che piangono, cani che abbaiano: è una guerra senza fine contro il caos audio. Ma cosa succederebbe se la tua app potesse eliminare quel rumore in tempo reale, localmente, senza inviare un singolo byte al cloud? Non è fantascienza. È già realtà e qualsiasi sviluppatore Android può implementarla. Gli strumenti sono maturi, le prestazioni sono elevate e i tuoi utenti noteranno immediatamente la differenza. ONNX Runtime: il tuo gateway per l'intelligenza artificiale mobile Il panorama dell'intelligenza artificiale mobile è frammentato. PyTorch domina la ricerca, TensorFlow produce regole e innumerevoli framework specializzati emergono per casi d'uso specifici. Per gli sviluppatori Android, questo pone una scelta dolorosa: impegnarsi in un unico ecosistema o mantenere pipeline separate per modelli diversi. Dopo aver valutato i framework di intelligenza artificiale mobile, abbiamo scelto ONNX Runtime per diverse valide ragioni che hanno un impatto diretto sullo sviluppo Android. Maggiore compatibilità tra le versioni di Android A differenza di LiteRT di Google (precedentemente TensorFlow Lite), che richiede un livello minimo di SDK pari a 31 (Android 12), ONNX Runtime supporta comodamente livelli API Android fino a 24 (o persino 21, se siete dei maghi). La versione minima supportata dal nostro progetto era l'API 28, rendendo ONNX Runtime la scelta ideale per raggiungere un pubblico più ampio senza escludere milioni di utenti attivi su dispositivi Android 10 e precedenti. Integrazione multi-framework senza soluzione di continuità Il punto di forza di ONNX Runtime risiede nella sua natura indipendente dal framework. Che i modelli di intelligenza artificiale provengano da PyTorch, TensorFlow o persino da librerie di apprendimento automatico tradizionali come scikit-learn, l'esportazione dei modelli in ONNX consente una distribuzione uniforme su Android, iOS, desktop e ambienti cloud. Questa flessibilità semplifica notevolmente la manutenzione, consentendo una pipeline unificata anziché dover gestire più strumenti specifici per ogni framework. Distribuzione leggera e modulare L'integrazione con ONNX Runtime è semplice. Con un AAR Maven compatto (circa 5-7 MB per le build CPU), la libreria si integra perfettamente nella tua app Android esistente senza introdurre dipendenze non necessarie come Google Play Services o richiedere autorizzazioni utente aggiuntive. Questa distribuzione semplificata mantiene la tua app snella, performante e sicura. Prestazioni comprovate in tempo reale ONNX Runtime è stato testato sul campo in scenari complessi in tempo reale. I modelli di elaborazione audio, come la soppressione del rumore o il miglioramento del parlato, garantiscono costantemente velocità di inferenza inferiori a 4 ms per frame audio su hardware mobile standard, ampiamente conformi ai requisiti prestazionali in tempo reale. Il nostro team ha sfruttato proprio questa capacità per una soppressione del rumore affidabile e a bassa latenza. In definitiva, ONNX Runtime ha offerto al nostro team non solo praticità, ma anche un vantaggio strategico, consentendoci di mantenere compatibilità, prestazioni e semplicità senza compromessi. Se il vostro progetto richiede un'intelligenza artificiale mobile accessibile, performante e scalabile, ONNX Runtime potrebbe essere la scelta ideale. Piano di integrazione: configurazione di ONNX Runtime Il pacchetto ONNX Runtime predefinito pesa ben 27 MB. Per un'app mobile, non è solo un peso eccessivo, ma un vero e proprio killer dell'acquisizione utenti. Le ricerche dimostrano che per ogni aumento di 6 MB delle dimensioni dell'APK, i tassi di conversione delle installazioni diminuiscono dell'1% (è importante sottolineare che lo studio non è il più recente e non riguarda principalmente i Paesi più sviluppati, ma vale comunque la pena di prenderlo in considerazione). La soluzione? Una build minimale personalizzata che riduce la distribuzione esattamente a ciò di cui hai bisogno. La nostra implementazione di soppressione del rumore DTLN occupa solo 7,1 MB, una riduzione del 70% che mantiene la tua app snella e i tuoi utenti soddisfatti. L'architettura di ONNX Runtime è modulare per definizione. Il pacchetto completo include provider di esecuzione per l'accelerazione GPU (NNAPI, Vulkan), decine di operatori che non utilizzerai mai e livelli di compatibilità per casi limite non applicabili al tuo modello specifico. Sviluppando solo ciò di cui hai bisogno, elimini completamente questo sovraccarico. Passaggio 1: convertire i modelli in formato ORT Prima di procedere alla compilazione, converti i tuoi modelli ONNX in formato ORT. Questo formato ottimizzato rimuove i nodi del grafico e le definizioni degli operatori non utilizzati, riducendo ulteriormente la dimensione binaria finale. Passaggio 2: creare la configurazione dell'operatore python -m onnxruntime.tools.convert_onnx_models_to_ort --target_platform {arm,amd64} Dopo aver convertito tutti i modelli necessari, verranno generati anche i file di configurazione con gli operatori necessari per la build minima di ONNX. Quando si utilizzano più modelli, combinare tutti i file di configurazione in uno solo. Il file finale avrà un aspetto simile a questo: # 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 Passaggio 3: eseguire la build personalizzata # 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 Una volta pronta la configurazione dell'operatore, compila ONNX Runtime dal codice sorgente con dipendenze minime: --minimal_build: esclude i provider e gli operatori di esecuzione non necessari ./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: include solo gli operatori specificati nel file di configurazione --android_abi armeabi-v7a: mira ad ARM32 per la massima compatibilità con i dispositivi --android_api 24: Mantiene la compatibilità con Android 7.0+ Se vuoi supportare anche i vecchi dispositivi, ripeti il passaggio 3 con –android_abi armeabi-v7a e quindi unisci entrambi i file aar risultanti con il seguente script: L'approccio di build minimale trasforma ONNX Runtime da un ostacolo all'implementazione in un vantaggio strategico. I tuoi utenti ottengono tutte le funzionalità di intelligenza artificiale senza il peso eccessivo e la tua app mantiene il profilo snello richiesto dallo sviluppo mobile moderno. #!/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" Ora vediamo in azione questo runtime ottimizzato con la soppressione del rumore DTLN in tempo reale. Perché l'elaborazione audio mette in mostra il valore dell'intelligenza artificiale L'elaborazione audio è l'introduzione perfetta all'intelligenza artificiale mobile, poiché offre un valore immediato e tangibile mentre i tuoi concorrenti lottano con modelli linguistici gonfi che consumano le batterie e richiedono connessioni Internet costanti. La guerra audio quotidiana che i tuoi utenti stanno combattendo Sarah registra messaggi vocali mentre cammina in una strada trafficata. Tra il clacson dei taxi, il rumore dei lavori in corso e il rombo della metropolitana, registra nuovamente i messaggi tre volte prima di rinunciare e ricominciare a digitare. Marcus risponde alle chiamate dei clienti dal suo ufficio di casa, che funge anche da sala giochi per il suo bambino. Ogni presentazione diventa un ciclo di "muto, riattivato, scusa per il pianto". Elena crea contenuti per YouTube nel suo appartamento, ma trascorre ore in post-produzione per eliminare i rumori dei vicini, il traffico e il ronzio dell'aria condizionata. Questi non sono casi limite: sono la realtà dell'informatica mobile moderna, in cui tutti si aspettano risultati professionali dall'hardware consumer in ambienti caotici. Perché la soppressione del rumore crea momenti "wow" immediati I miglioramenti della qualità audio innescano risposte emotive immediate. A differenza di altre applicazioni di intelligenza artificiale che richiedono spiegazioni, la soppressione del rumore offre una gratificazione immediata che gli utenti possono percepire in pochi secondi. Ascoltate la voce di qualcuno, cristallina, dopo aver rimosso il rumore di fondo, e osservate la sua reazione. Non è necessario che comprendano le reti LSTM; è sufficiente che sappiano che il loro audio suona professionale. La bellezza dell'elaborazione audio come strumento di intelligenza artificiale risiede nell'universalità. Tutti capiscono cosa sia un buon audio, tutti hanno sperimentato un audio scadente e tutti riconoscono immediatamente un miglioramento quando il rumore scompare. Non stai chiedendo agli utenti di fidarsi della tua intelligenza artificiale: stai dimostrando il suo valore nel modo più diretto possibile. Creazione di una demo pronta per la produzione: soppressione del rumore in tempo reale Ora, creiamo un progetto di esempio che dimostri la potenza pratica di ONNX Runtime su Android. Invece di un semplice esempio "Hello World", creeremo qualcosa di simile alla qualità di produzione: una dimostrazione di soppressione del rumore in tempo reale in cui gli utenti possono registrare audio in ambienti rumorosi e sperimentare la sorprendente differenza tra la registrazione originale e la versione ripulita dall'intelligenza artificiale. Potete trovare un esempio completo qui, sul mio Github: . https://github.com/linreal/android-onnx-showcase I modelli utilizzati nel campione provengono da https://github.com/breizhn/DTLN Panoramica rapida dell'implementazione Prima di addentrarci nell'architettura a doppio percorso di DTLN, vediamo come si integrano i vari elementi. La bellezza di questa implementazione risiede nella netta separazione delle attività: ogni componente ha una singola responsabilità, rendendo il sistema testabile e manutenibile. I componenti principali Al centro del nostro processo di soppressione del rumore ci sono tre interfacce chiave che lavorano insieme: NoiseSuppressor incapsula tutta la complessità di ONNX Runtime dietro un'interfaccia semplice. Bastano frammenti audio per ottenere audio privo di rumore. La natura stateful di DTLN è completamente nascosta: l'implementazione mantiene internamente gli stati LSTM tra una chiamata e l'altra. 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 } Architettura del flusso di dati Il ConcurrentAudioProcessor orchestra l'intera pipeline. Si iscrive al Flow del registratore audio, converte i formati audio, elabora i blocchi attraverso il soppressore di rumore e scrive simultaneamente sia l'audio originale che quello elaborato sui file. AudioRecorder → Flow → ConcurrentAudioProcessor → NoiseSuppressor → Processed Audio Files Perché questa architettura funziona 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) } } il design basato su Flow garantisce che l'interfaccia utente rimanga reattiva. L'elaborazione audio avviene su thread in background, mentre il thread principale gestisce le interazioni dell'utente. Elaborazione reattiva: ogni componente funziona con il suo formato audio preferito. produce ShortArray (PCM a 16 bit), mentre si aspetta FloatArray (campioni normalizzati). La conversione avviene al confine. Isolamento del formato: AudioRecorder NoiseSuppressor se l'inizializzazione di ONNX fallisce, viene interessato solo il componente NoiseSuppressor. Il registratore audio e i dispositivi di scrittura file continuano a funzionare, garantendo un degrado graduale. Limiti di errore: ogni componente gestisce le proprie risorse. coordina gli eventi del ciclo di vita, ma non è proprietario delle implementazioni sottostanti. Gestione delle risorse: ConcurrentAudioProcessor Questo approccio modulare consente di sostituire l'implementazione DTLN con qualsiasi altro modello ONNX, sostituire il registratore audio con una sorgente basata su file o modificare il formato di output senza toccare altri componenti. L'architettura è scalabile, dalla fase di proof-of-concept alla distribuzione in produzione. Ora esploreremo l'architettura DTLN che rende possibile questa magia. Comprensione dell'architettura DTLN Gli approcci tradizionali alla soppressione del rumore si trovano ad affrontare un compromesso fondamentale. I metodi nel dominio della frequenza sono eccellenti nella rimozione del rumore stazionario (aria condizionata, ronzio di ventilatori), ma hanno difficoltà con suoni dinamici come il parlato o la musica che si insinuano. Gli approcci nel dominio del tempo gestiscono bene segnali complessi e mutevoli, ma spesso introducono artefatti o falliscono con un rumore di fondo costante. DTLN aggira completamente questa limitazione grazie alla sua architettura a doppio percorso: Il primo modello opera nel dominio della frequenza, analizzando le caratteristiche spettrali dell'audio. Genera una maschera di soppressione che identifica quali componenti di frequenza contengono rumore rispetto al parlato. Questa fase eccelle nella rimozione del rumore di fondo stazionario, come il ronzio costante dell'aria condizionata, del traffico o del chiacchiericcio in ufficio. Fase 1: Elaborazione nel dominio della frequenza. // 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 } Fase 2: Raffinamento del dominio del tempo // 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 } Il segnale mascherato nel dominio della frequenza viene riconvertito nel dominio del tempo, quindi immesso in un secondo modello che opera direttamente sulla forma d'onda audio. Questa fase cattura ciò che l'analisi in frequenza ha tralasciato: la gestione dei pattern di rumore dinamico, il mantenimento della naturalezza del parlato e la rimozione di eventuali artefatti dalla prima fase. La filosofia del design Mobile-First // 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)) L'architettura di DTLN riflette anni di esperienza pratica nell'implementazione di intelligenza artificiale mobile. Ogni decisione progettuale privilegia i vincoli del mondo reale rispetto ai benchmark accademici. il modello elabora l'audio in blocchi da 512 campioni (32 ms a 16 kHz), raggiungendo l'equilibrio ottimale tra latenza e contesto. Le dimensioni di questi blocchi sono sufficientemente ridotte per l'elaborazione in tempo reale, ma sufficientemente grandi da fornire un contesto temporale significativo per le reti LSTM. Elaborazione basata su blocchi: companion object { private const val BLOCK_LEN = 512 // 32ms chunks private const val BLOCK_SHIFT = 128 // 75% overlap for smooth processing } Reti LSTM con stato companion object { private const val BLOCK_LEN = 512 // 32ms chunks private const val BLOCK_SHIFT = 128 // 75% overlap for smooth processing } Entrambi i modelli utilizzano reti LSTM (Long Short-Term Memory) che mantengono lo stato interno tra i blocchi. Questa memoria temporale consente al modello di distinguere tra parlato e rumore in base al contesto, non solo alle caratteristiche audio istantanee. Caratteristiche prestazionali che contano 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 } } Comprendere l'architettura di DTLN aiuta a prevederne il comportamento nella tua applicazione. Queste caratteristiche prestazionali hanno un impatto diretto sull'esperienza utente: Profilo di latenza Ritardo algoritmico: 32 ms (tempo di elaborazione di un blocco) Tempo di inferenza: 3-4 ms per blocco su hardware Android di fascia media Latenza totale: ~35 ms end-to-end (impercettibile per la maggior parte dei casi d'uso) Utilizzo delle risorse Impronta di memoria: ~28 MB durante l'elaborazione attiva Utilizzo CPU: 12-18% su un tipico dispositivo di fascia media Impatto sulla batteria: trascurabile per le tipiche sessioni di registrazione Queste caratteristiche rendono DTLN particolarmente adatto alle applicazioni mobili in cui gli utenti si aspettano risultati immediati senza sacrificare le prestazioni del dispositivo o la durata della batteria. Strategia di integrazione del runtime ONNX Per far funzionare ONNX Runtime su Android non basta aggiungere una dipendenza al file build.gradle. La differenza tra una proof-of-concept che si blocca sotto carico e un'implementazione pronta per la produzione risiede nella configurazione della sessione, nella gestione della memoria e nella strategia di allocazione delle risorse. Poiché abbiamo già preparato una build di runtime minima, è il momento di esaminare cosa ci aspetta. Configurazione della sessione per la realtà mobile La configurazione predefinita della sessione di ONNX Runtime presuppone che l'applicazione sia in esecuzione su un server con risorse abbondanti. I dispositivi mobili operano con vincoli completamente diversi: memoria limitata, limitazione termica e utenti che si aspettano che le app rimangano reattive durante l'elaborazione dell'intelligenza artificiale. Il tuo primo istinto potrebbe essere quello di utilizzare tutti i core della CPU disponibili per ottenere le massime prestazioni. Resisti a questa tentazione. I dispositivi mobili danno priorità alla durata della batteria rispetto alla pura velocità di calcolo, e la gestione termica di Android limiterà l'utilizzo aggressivo della CPU in pochi secondi. 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) } Il punto ottimale per l'elaborazione audio in tempo reale si trova tra 2 e 4 thread, in base al numero di core del dispositivo: Questa configurazione offre il 95% delle prestazioni massime consumando il 60% di batteria in meno rispetto a un pool di thread senza restrizioni. Gli utenti noteranno i guadagni in termini di efficienza più della lieve differenza di latenza. private val numThreads = Runtime.getRuntime().availableProcessors().coerceIn(1, 4) attiva l'ottimizzazione mobile più efficace di ONNX Runtime. Questa impostazione analizza i pattern di accesso alla memoria del modello durante le prime chiamate di inferenza, quindi prealloca i pool di memoria per ridurre al minimo la pressione della garbage collection durante l'elaborazione in tempo reale. setMemoryPatternOptimization(true) L'esecuzione sequenziale potrebbe sembrare controintuitiva quando l'elaborazione parallela offre una maggiore produttività. Tuttavia, l'elaborazione audio in tempo reale richiede una latenza prevedibile rispetto alle prestazioni di picco. L'esecuzione parallela crea picchi di latenza quando si verifica la sincronizzazione dei thread, esattamente ciò che si desidera evitare durante l'elaborazione audio in tempo reale. setExecutionMode(OrtSession.SessionOptions.ExecutionMode.SEQUENTIAL) L'esecuzione sequenziale garantisce tempi di inferenza costanti di 3-4 ms, mentre la modalità parallela varia da 2 a 8 ms con picchi imprevedibili. Gli utenti percepiscono la coerenza come qualità. Pre-allocazione della memoria: il moltiplicatore delle prestazioni L'ottimizzazione più critica per le applicazioni ONNX Runtime mobili prevede la pre-allocazione di tensori che vengono riutilizzati nelle chiamate di inferenza. La creazione di tensori durante l'inferenza innesca allocazioni di memoria che si accumulano, creando significativi colli di bottiglia nelle prestazioni. // 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) } Riduzione della pressione nella raccolta dei rifiuti // 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) } - La creazione di tensori durante l'inferenza genera oggetti che devono essere sottoposti a garbage collection. La pre-allocazione sposta questo costo al momento dell'inizializzazione, mantenendo i percorsi di inferenza liberi da allocazione. : la creazione ripetuta di tensori frammenta la memoria heap, causando errori di allocazione imprevisti. I tensori preallocati mantengono un layout di memoria coerente. Prevenzione della frammentazione della memoria : i costi di allocazione sono imprevedibili e possono causare picchi di latenza durante l'elaborazione in tempo reale. La pre-allocazione garantisce tempi di inferenza coerenti. Coerenza della latenza Queste strategie di integrazione trasformano ONNX Runtime da uno strumento di ricerca a un componente pronto per la produzione. Le scelte di configurazione, i modelli di gestione della memoria e gli approcci di gestione degli errori hanno un impatto diretto sull'esperienza utente, in modi che diventano evidenti solo in condizioni di utilizzo reali. Puoi guardare dentro per un codice sorgente completo. https://github.com/linreal/android-onnx-showcase/blob/main/app/src/main/java/gos/denver/onnxshowcase/audio/impl/NoiseSuppressorImpl.kt Conclusione: l'intelligenza artificiale come vantaggio competitivo Il panorama dell'intelligenza artificiale mobile sta vivendo un cambiamento radicale. Mentre i concorrenti inseguono modelli linguistici ad alto consumo di risorse e soluzioni basate sul cloud, l'intelligenza artificiale specializzata e integrata nei dispositivi offre enormi opportunità di guadagno agli utenti. Punti chiave per gli sviluppatori Android La combinazione delle capacità di ottimizzazione di ONNX Runtime e di modelli specifici come DTLN offre prestazioni pari o superiori a quelle delle soluzioni cloud, eliminando al contempo i requisiti di latenza e connettività. I tuoi utenti ottengono risultati immediati e tu ottieni una funzionalità che funziona ovunque, dai tunnel della metropolitana alla modalità aereo. L'intelligenza artificiale integrata nei dispositivi è già pronta per la produzione. La nostra build minima di ONNX Runtime ha ridotto le dimensioni della libreria del 70% senza sacrificare le funzionalità. Non si tratta solo di una questione di spazio di archiviazione: ha un impatto diretto sull'acquisizione di utenti. Quando le funzionalità di intelligenza artificiale aggiungono 7 MB anziché 27 MB alla tua app, l'equazione costi-benefici cambia radicalmente a tuo favore. L'ottimizzazione delle dimensioni dell'APK trasforma la strategia di distribuzione. DTLN non è il modello di soppressione del rumore più avanzato disponibile, ma raggiunge il perfetto equilibrio tra qualità, prestazioni e consumo di risorse per l'implementazione mobile. Agli utenti non interessa l'architettura del modello: ciò che conta è un audio cristallino in ambienti rumorosi. L'esperienza utente supera la complessità algoritmica. Le app che implementano l'intelligenza artificiale sul dispositivo ottengono tre vantaggi competitivi: privacy by design (nessun dato sensibile esce dal dispositivo), affidabilità offline (esperienza coerente indipendentemente dalle condizioni della rete) e vantaggi della struttura dei costi (nessun costo di inferenza cloud o spese operative che si adattano all'utilizzo). Prossimi passi ed esplorazione Le tecniche illustrate qui vanno ben oltre la soppressione del rumore. ONNX Runtime consente l'implementazione pratica di modelli per l'elaborazione audio, la visione artificiale, le attività di linguaggio naturale e le applicazioni di fusione di sensori. L'implementazione completa è disponibile su GitHub: Utilizzalo come base per le tue funzionalità basate sull'intelligenza artificiale. vetrina-android-onnx La tua app Android merita un'intelligenza artificiale che migliori l'esperienza utente senza compromettere prestazioni, privacy o affidabilità. ONNX Runtime rende questa visione realizzabile oggi stesso. Gli strumenti sono pronti, le prestazioni sono comprovate: è il momento di creare qualcosa di straordinario. Hai trovato utile questa implementazione? Aggiungi a Preferiti e condividi i tuoi risultati. La comunità dell'intelligenza artificiale mobile si rafforza quando condividiamo conoscenze pratiche. Repository GitHub Seguitemi per ulteriori approfondimenti sulle implementazioni di intelligenza artificiale mobile pronte per la produzione che i vostri utenti noteranno e apprezzeranno.