La previsione TensorFlow dovrebbe essere disaccoppiata dalla post-elaborazione?

Question

La previsione TensorFlow dovrebbe essere disaccoppiata dalla post-elaborazione?

#1 da (1 voti)
#2 da (0 voti)

2

Ho un'API che consiste fondamentalmente in due parti: 1. Una rete neurale TensorFlow che fornisce previsioni basate sull'immagine di input (principalmente calcoli GPU) e 2. Post processing su tali previsioni (principalmente CPU)

Questo è un tipo di best practice / domanda di raccomandazione. Quello che mi chiedo è se queste due sezioni dell'applicazione debbano essere disaccoppiate, collocate in contenitori Docker separati e ridimensionate separatamente. Non c'è altro uso per le previsioni di TensorFlow (nessuna altra app vorrebbe ricevere previsioni direttamente, quindi non c'è bisogno di disaccoppiare in termini di accessibilità).

L'unico scenario che posso pensare che garantirebbe il disaccoppiamento è se la Post-elaborazione consumasse una grande quantità di risorse della CPU che costringevano l'applicazione a ridimensionarsi quando la GPU veniva sottoposta a sottoutilizzo (la parte di previsione dell'app stava gestendo il carico va bene) e forzando l'applicazione a ridimensionare stiamo usando più risorse GPU del necessario.

Tuttavia, purché risorse sufficienti della CPU possano essere allocate al server in modo che il punto in cui l'app viene ridimensionata sia un punto di utilizzo elevato su CPU e GPU, non vedrei motivo per cui i servizi dovrebbero essere disaccoppiati.

Speriamo che questo abbia senso - qualche suggerimento?

architecture backend

posta abagshaw 02.04.2017 - 07:06

fonte

2 risposte

Leggi altre domande sui tag architecture backend

Come posso testare le prestazioni del codice di manipolazione DOM in JS Mantenere l'idea dell'algoritmo di priorità dell'ordine

score 1 · Answer 1

Dall'esperienza al mio attuale lavoro, disaccoppia il prima possibile. Progettare le cose il più lontano possibile. Abbiamo alcuni flussi di lavoro simili al mio attuale lavoro dal suono, quindi lasciatemi dare un aneddoto dal mio mondo.

All'inizio abbiamo fatto A e B, B era dipendente da A, quindi aveva senso solo buttarli insieme. Poi abbiamo iniziato a fare C che era veramente indipendente da A e B, ma ciao, è più facile buttarlo subito dopo B piuttosto che rielaborare alcuni piccoli aspetti del nostro prodotto. Poi un giorno D ed E si presentarono alla porta. D era indipendente da tutto a questo punto, ma E richiede C e D. Lo sforzo per suddividere il lavoro è molto più grande di quando avevamo solo A, B e C. Quindi buttiamo D ed E in linea.

Oh guarda F, G, H e J, appena entrato dalla porta, ognuno con una grande quantità di denaro; ora dobbiamo lavorare velocemente, non c'è tempo per rielaborare le cose. A chi importa che tre dei 4 siano indipendenti e lanciandoli nel mix uno dopo l'altro stiamo facendo enormi quantità di lavoro non necessario.

Ora facciamo tutto il lavoro per tutti, ma i clienti ci pagano solo per quello che vogliono vedere, quindi non restituiamo le parti della risposta che un cliente non ci paga.

(A proposito, sembra che io stia strascicando il mio datore di lavoro, ma adoro il lavoro, per fortuna lavoro quasi esclusivamente sui singoli moduli e non sulla colla, incollandoli insieme, le persone che lavorano per lo più sulla colla però hanno un un po 'di un atteggiamento diverso che è una storia completamente diversa.)

score 0 · Answer 2

La mia preferenza sarà il disaccoppiamento, dal momento che non avrai bisogno di post-elaborazione per ogni immagine che hai. Ti fornirà un portafoglio di servizi più flessibile per l'ottimizzazione e la scalabilità future, come hai affermato.

La tua funzionalità desiderata, i requisiti per la velocità e l'assegnazione delle risorse decideranno comunque. Puoi iniziare con un'implementazione e dare un mese per una corsa a secco, e se non sei soddisfatto dei tuoi risultati puoi tornare anche all'altro. L'opzione migliore potrebbe essere fornire un'interfaccia unificata all'utente, ma implementarla in modo disaccoppiato.