PyTorch: Il Runtime di Inferenza Dietro i Nostri Sistemi AI
Ogni volta che RAG Enterprise risponde a una domanda, che CRM81 classifica un ticket o che LetsAI genera un'immagine, sotto il cofano gira PyTorch. Non lo vedi, ma è lui che trasforma i modelli in risultati. Ecco perché lo abbiamo scelto e come lo usiamo in produzione con GPU NVIDIA.
PyTorch vs TensorFlow: Perché Abbiamo Scelto PyTorch
Quando abbiamo iniziato a costruire il nostro stack AI nel 2023, TensorFlow era ancora il framework più diffuso in produzione. Ma la comunità di ricerca si era già spostata massicciamente su PyTorch, e con essa tutto l'ecosistema dei modelli moderni. Hugging Face, la nostra fonte primaria di modelli, è nata attorno a PyTorch. Quasi tutti i modelli state-of-the-art — BERT, GPT, LLaMA, Stable Diffusion — sono sviluppati prima in PyTorch. La ragione tecnica principale è il paradigma eager execution di PyTorch. Quando prototipavamo nuove pipeline per RAG Enterprise, avevamo bisogno di debuggare i tensori passo dopo passo, ispezionare le dimensioni intermedie, inserire breakpoint. Con PyTorch il codice gira come normale Python: usi pdb, stampi i tensori, e vedi esattamente cosa succede. Con TensorFlow 1.x dovevi costruire un grafo statico e poi eseguirlo — un incubo per il debugging. TensorFlow 2.x ha introdotto eager execution, ma l'ecosistema era già migrato. Il 78% dei paper accademici su arXiv nel 2025 usa PyTorch. Quando cerchi un'implementazione di riferimento di un nuovo algoritmo, la trovi in PyTorch. Punto. C'è un aspetto pratico che pochi menzionano: il recruiting. Gli sviluppatori ML junior escono dalle università avendo usato PyTorch. Formare qualcuno su TensorFlow richiede tempo extra che non possiamo permetterci.
Accelerazione CUDA: GPU On-Premise per i Nostri Clienti
Una delle ragioni per cui i nostri clienti enterprise scelgono RAG Enterprise PRO è il deployment on-premise: i dati non escono mai dall'azienda. Questo significa che l'inferenza deve girare su hardware locale, e per avere tempi di risposta accettabili servono GPU NVIDIA. PyTorch rende il passaggio da CPU a GPU quasi banale. Il codice è lo stesso; cambia solo il device su cui vengono allocati i tensori. In pratica, il nostro codice di inferenza ha una singola variabile di configurazione: DEVICE=cuda:0 oppure DEVICE=cpu. Il resto della pipeline non cambia. I numeri sono impressionanti. Sul nostro benchmark standard con 50.000 documenti e il modello BGE-M3: su CPU (Xeon E5-2680) il calcolo degli embeddings per un documento medio richiede 180ms. Su GPU (RTX 4090) lo stesso calcolo richiede 12ms. Un fattore 15x che fa la differenza tra un sistema usabile e uno frustrante. Per i clienti con budget più limitati, offriamo una configurazione con RTX 3060 (12GB VRAM) che è sufficiente per carichi fino a 30 utenti contemporanei. Per clienti enterprise più grandi, usiamo server con 2x A100 e PyTorch DataParallel per distribuire il carico. Un aspetto critico che abbiamo imparato: la gestione della memoria VRAM. PyTorch non rilascia automaticamente la memoria GPU dopo l'inferenza. Abbiamo implementato un memory pool custom con torch.cuda.empty_cache() e batch processing per evitare OOM (Out of Memory) sotto carico pesante.
ONNX Export: Ottimizzare i Modelli per la Produzione
PyTorch è eccellente per lo sviluppo e il training, ma in produzione ogni millisecondo conta. Per questo, una volta validato un modello, lo esportiamo in formato ONNX (Open Neural Network Exchange) usando torch.onnx.export(). Il modello ONNX può poi essere ottimizzato con ONNX Runtime, che applica fusione degli operatori, quantizzazione e ottimizzazioni specifiche per l'hardware. I risultati sono consistenti. Il nostro modello di classificazione per CRM81 in PyTorch nativo ha una latenza media di 45ms per inferenza. Dopo l'export ONNX con ottimizzazioni O2, la latenza scende a 18ms — un miglioramento del 60% senza alcuna perdita di accuratezza. Per un sistema che classifica centinaia di ticket al minuto, questa differenza è significativa. L'export ONNX ci dà anche flessibilità di deployment. Un cliente voleva il modello di classificazione su un server Windows senza GPU. Con il modello PyTorch nativo avremmo dovuto installare l'intero stack CUDA. Con ONNX Runtime bastano 50 MB di dipendenze e il modello gira su CPU con performance accettabili. Per RAG Enterprise, non esportiamo il modello di embedding in ONNX perché sentence-transformers gestisce già l'ottimizzazione internamente. Ma per i modelli custom che addestriamo internamente, l'export ONNX è diventato uno step standard della nostra pipeline CI/CD: train con PyTorch, validate, export ONNX, benchmark, deploy. Una lezione appresa: non tutti i modelli si esportano facilmente in ONNX. I modelli con logica condizionale complessa o operazioni dinamiche possono richiedere modifiche al codice. Consigliamo di testare l'export ONNX presto nel ciclo di sviluppo, non alla fine.
Servizi Correlati
Scopri come applichiamo queste tecnologie nei nostri progetti enterprise.
Interessato?
Contattaci per ricevere un preventivo personalizzato.
Securvita S.r.l. — i3k.eu