La demo dell’appliance funziona benissimo quando un partner pone una breve domanda su un PDF pulito. La decisione cambia la mattina seguente. Due colleghi aprono lunghi file di clienti mentre lo scanner avvia un lotto di indicizzazione. La prima risposta tarda abbastanza da spingere un utente verso uno strumento web non approvato.
L’hardware può funzionare esattamente secondo le specifiche. L’ufficio ha semplicemente acquistato in base al nome del modello e a un valore di memoria, invece che al lavoro da svolgere.
Un appliance AI per un piccolo ufficio va dimensionato su documenti misurati, utenti simultanei al picco, obiettivi di risposta e tempo di ripristino. Le specifiche hardware aiutano a spiegare un risultato. L’acquisto si giustifica soltanto quando l’intero processo supera una prova di accettazione dell’ufficio.
Un progetto mirato di sviluppo AI può trasformare il lavoro rappresentativo in quella prova prima dell’ordine. Gli aspetti economici più ampi dell’hardware di inferenza sono trattati in un cluster di inferenza locale. Qui affrontiamo una scelta più piccola: un dispositivo da ufficio adatto al lavoro e ripristinabile in caso di guasto.
Raccogli il carico di lavoro prima di guardare i dispositivi
Comincia con un campione proposto di due settimane di lavoro ordinario. Registra che cosa le persone chiedono all’assistente e come sono davvero i documenti. La scheda di dimensionamento deve includere lunghezza tipica e massima dell’input, lunghezza prevista del risultato, pagine per documento, volume OCR, lingue, profondità del recupero, utenti simultanei e lotti di picco.
Separa il lavoro interattivo da quello in background. Un avvocato che attende una clausola citata ha un requisito di latenza diverso da un’indicizzazione notturna. Una fiduciaria che esamina un’eccezione salariale usa la memoria diversamente da un team che confronta un anno di estratti bancari. Lo stesso appliance può gestire bene un carico e mettere in coda l’altro.
Scrivi obiettivi specifici per:
- Tempo alla prima risposta visibile e alla risposta completa
- Numero massimo di utenti simultanei nell’ora più intensa
- Insieme documentale rappresentativo più grande e carico OCR giornaliero
- Qualità minima di citazione o estrazione accettabile per un revisore
- Tempo di ripristino dopo l’indisponibilità del dispositivo o di un servizio dipendente
Sono requisiti di accettazione, non benchmark di settore. Un partner può accettare 20 secondi per un confronto accurato tra contratti e rifiutare lo stesso ritardo in una ricerca breve. Il numero ha senso soltanto rispetto all’attività.
Includi campioni in tedesco, francese, italiano e inglese se l’ufficio usa queste lingue. Conta scansioni, tabelle e scrittura a mano. PDF digitali puliti danno un’immagine troppo ottimista di memoria, qualità del recupero e tempo di revisione.
Crea un budget di memoria per l’intero stack
I pesi del modello sono soltanto la prima riga. Aggiungi buffer del runtime, cache di contesto per le sessioni attive, servizio di embedding o reranking, OCR, sistema operativo, indice documentale e applicazione. Lascia spazio di lavoro per aggiornamenti e file temporanei.
La quantizzazione riduce l’uso di memoria archiviando i pesi a precisione inferiore. L’attuale documentazione di llama.cpp descrive opzioni di quantizzazione, più backend hardware e inferenza ibrida su CPU e GPU. Queste tecniche ampliano i modelli eseguibili su un dispositivo.
Idoneità tecnica e utilità sono due prove distinte. Spostare parte del modello o del carico nella memoria di sistema può permettere il caricamento, mentre la risposta supera l’obiettivo dell’ufficio. Contesti più lunghi e più sessioni simultanee aumentano a loro volta la memoria attiva. Misura quindi il dispositivo candidato con modello, quantizzazione, runtime e carico reale di picco insieme.
Usa una tabella durante la prova:
| Componente | Misura a riposo | Misura al picco | Margine richiesto |
|---|---|---|---|
| Modello e runtime | Registrare sul candidato | Registrare sul candidato | Definito dal piano di aggiornamento |
| Contesto delle sessioni attive | Registrare alla lunghezza obiettivo | Registrare agli utenti di picco | Margine per una richiesta lenta |
| Recupero, OCR e indice | Registrare durante la ricerca | Registrare durante l’indicizzazione | Margine per il lotto più grande |
| Sistema operativo e applicazione | Registrare dopo il riavvio | Registrare durante la prova completa | Margine per un servizio stabile |
L’ufficio deve fissare il margine in base al piano di modifica e ripristino. Una percentuale universale nasconderebbe le differenze tra runtime e carichi.
Scegli la classe hardware dopo il budget
Per una prova con un solo dispositivo, confronta tre classi. Un server orientato alla CPU può servire modelli piccoli, embedding, OCR e scrittura con poche richieste simultanee. Un desktop a memoria unificata può offrire un pool condiviso più grande. Una workstation con GPU dedicata può servire carichi che rientrano nella VRAM e sfruttano lo stack di accelerazione supportato.
Ogni classe ha un vincolo. L’inferenza solo CPU può mancare gli obiettivi interattivi. La memoria unificata è condivisa tra modello, sistema operativo e indice. La VRAM dedicata limita i carichi residenti nella GPU. L’offload ibrido può estendere l’idoneità tecnica alla memoria di sistema, ma latenza e prestazioni con richieste simultanee possono peggiorare. La workstation completa richiede alimentazione e raffreddamento adeguati.
Per una specifica concreta, NVIDIA indica la GeForce RTX 5090 con 32 GB di memoria GDDR7 e 575 W di potenza grafica totale, insieme a 1.000 W di potenza di sistema richiesta nei dettagli di riferimento. Le schede dei produttori possono variare. Questi dati descrivono una classe di componente. Non prevedono qualità del modello, utenti simultanei o consumo misurato dell’intero sistema.
Archiviazione e operazioni spesso decidono l’acquisto. Servono spazio per modello corrente, versione precedente approvata, indici, backup o snapshot previsti, log e file temporanei. Verifica garanzia, tempi di sostituzione, supporto dei driver e familiarità dell’amministratore con lo stack.
Non acquistare il valore di memoria più alto come semplice assicurazione. La capacità aggiuntiva vale soltanto se viene usata dal carico di accettazione o richiesta dalla roadmap approvata.
Misura l’intera esperienza utente
Esegui prima un benchmark riproducibile, poi lo stesso carico nell’interfaccia reale. La documentazione di llama-bench spiega le misure di elaborazione dei prompt e generazione su più ripetizioni. I risultati escludono tokenizzazione e campionamento, quindi non rappresentano la latenza end-to-end dell’utente.
Per ogni esecuzione registra file del modello, quantizzazione, commit del runtime, lunghezza del contesto, prompt, hardware, sistema operativo e impostazioni di temperatura. Aggiungi poi i tempi di autenticazione, recupero, reranking, OCR, coda e rendering dell’interfaccia nell’applicazione reale.
Prova 1 utente, 2 utenti e il numero di picco previsto con lo stesso contesto e insieme di documenti. Aggiungi il lavoro in background svolto durante l’orario d’ufficio. Registra:
- Coda, tempo al primo token e tempo alla risposta completa
- Prestazioni mediane e delle richieste lente rispetto all’obiettivo scritto
- Memoria CPU, GPU e di sistema al picco
- Potenza dell’intero sistema, temperatura, throttling ed errori
Le medie possono nascondere la richiesta che rimanda una persona a un servizio non gestito. Registra p50 e p95 del set di prova, indicando entrambi come misure di quella configurazione. Non sono promesse per un altro modello o carico.
Usa un set di accettazione che verifichi anche la qualità
La velocità non serve se la risposta cita la pagina sbagliata o estrae l’importo errato. Crea un set proposto da 50 a 100 prompt rappresentativi con le prove attese. È una dimensione pratica per la prova in ufficio, senza costituire una soglia universale di sufficienza.
Includi attività comuni, scansioni difficili e domande la cui risposta è assente. Valuta per attività correttezza delle citazioni, accuratezza dell’estrazione, astensione e accettabilità per il revisore. Mantieni risultati separati per lingua e tipo di file, così una buona media non nasconde una scansione francese debole.
Il set deve includere l’uso concorrente. Una configurazione supera la prova soltanto quando qualità e latenza restano accettabili al picco. Ripeti dopo ogni modifica a modello, quantizzazione, runtime, prompt, parser o recupero.
Affianca al set queste verifiche operative su un’istanza isolata con dati sintetici:
- Ferma il servizio di identità e conferma che l’applicazione rifiuti il recupero protetto.
- Riempi un volume temporaneo di prova e verifica allarme e rifiuto sicuro.
- Interrompi la rete, riavvia il dispositivo e ripristina un backup di prova.
- Passa a un nuovo modello, esegui il set e verifica che il modello precedente approvato resti disponibile fino all’accettazione.
Sono prove controllate con procedure di ripristino preparate. Non provocare mai guasti elettrici o di archiviazione su un appliance di produzione con dati reali.
Progetta il ripristino prima dell’arrivo del dispositivo
Un unico appliance è una dipendenza operativa unica. Misura riavvio, ripristino del backup, ricostruzione dell’indice e comportamento dell’applicazione quando archiviazione o identità non sono disponibili. Decidi quali documenti e dati derivati devono tornare insieme.
Conserva modello e configurazione precedenti finché un aggiornamento non supera il set. Documenta chi applica patch a sistema operativo e runtime, chi controlla spazio e log e chi decide il ritorno in servizio.
Il percorso di continuità deve corrispondere alla sensibilità del lavoro. Di solito, un processo manuale nei sistemi documentali, contabili o gestionali esistenti è l’opzione più semplice. Il personale lavora più lentamente senza spostare dati verso una nuova destinazione.
Un fallback API è adatto soltanto quando fornitore, contratto e percorso di trattamento sono approvati per la stessa classe di dati. Il passaggio automatico al cloud pubblico può contraddire il motivo dell’esecuzione locale. Lascialo disattivato, salvo un’approvazione deliberata e provata.
Includi il ripristino nella dimostrazione del fornitore. Ripristinare il modello perdendo metadati dei permessi o cronologia di audit è un recupero incompleto.
Calcola il costo di proprietà dalle misurazioni
Crea un modello di proprietà a tre anni con la stessa cura della prova di carico. Includi hardware, archiviazione cifrata, backup, UPS, rete, installazione, integrazione di modello e runtime, monitoraggio, assistenza, rischio di sostituzione, formazione e tempo di revisione professionale.
Misura alla presa la potenza dell’intero sistema durante il carico di accettazione. La potenza nominale della GPU non basta a calcolare l’energia annuale della workstation. La Commissione federale dell’energia elettrica pubblica tariffe per comune e categoria di cliente. Usa la tariffa aziendale applicabile all’ufficio invece di una stima nazionale.
In un calcolo illustrativo, un dispositivo misurato a 0,65 kW medi durante 8 ore di servizio per 220 giorni consuma 0,65 × 8 × 220 = 1.144 kWh. Con una tariffa illustrativa di CHF 0,24 per kWh, il termine energetico è 1.144 × CHF 0,24 = CHF 274,56 l’anno. L’importo illustrativo esclude inattività, raffreddamento e backup. Capitale, assistenza e amministrazione devono provenire dal preventivo datato e dalle ipotesi di personale dell’ufficio.
Confronta un servizio privato gestito allo stesso volume, obiettivo di qualità e classificazione dei dati. Aggiungi l’amministrazione interna a entrambe le opzioni. L’hardware locale può eliminare una tariffa per token aggiungendo patch e ripristino. Un servizio gestito può ridurre le operazioni introducendo questioni su fornitore, contratto e giurisdizione.
Il modello TCO personalizzato rispetto a piattaforma offre un quadro più ampio. Per questo acquisto, il carico misurato e il responsabile operativo designato contano più di una fascia hardware generica.
Acquista la configurazione più piccola che supera la prova
La decisione dovrebbe concludersi con una scheda dei risultati. Registra dispositivo e stack che hanno superato gli obiettivi di qualità, richieste simultanee, latenza e ripristino. Indica il margine al picco e le attività che richiedono ancora il percorso manuale.
Così il valore dell’inferenza locale diventa pratico. Il personale riceve un assistente utile per il lavoro sensibile approvato e l’ufficio sa come si comporta con più utenti o con un componente guasto. Il dispositivo viene dimensionato su un processo reale, invece che su una classifica di modelli.
Scegli la configurazione più piccola che supera la prova con un margine misurato sufficiente. Ripeti i test dopo modifiche rilevanti. Questa disciplina mantiene utile l’appliance dopo l’acquisto e offre prove per il prossimo aggiornamento, invece di una nuova ipotesi.
Domande frequenti
Quanta memoria serve a un appliance AI per un piccolo ufficio?
La memoria necessaria dipende da modello e quantizzazione, contesto massimo, sessioni simultanee, componenti di recupero, OCR, runtime e sistema operativo. Misura l’intero stack sul dispositivo candidato al carico di picco. La sola dimensione del file del modello è incompleta, perché contesto attivo e servizi applicativi consumano memoria. Lo spostamento tra CPU e GPU può consentire il caricamento ma produrre una latenza inaccettabile.
Quante persone possono usare contemporaneamente un dispositivo AI locale?
Non esiste un numero universale di utenti per un singolo dispositivo locale. Esegui le stesse attività programmate con 1 utente, 2 utenti e il numero di utenti simultanei previsto al picco. Registra coda, tempo al primo token, tempo alla risposta completa, memoria ed errori mentre sono attivi indicizzazione o OCR ordinari. L’appliance supera la prova soltanto se anche le richieste lente restano entro l’obiettivo scritto dell’ufficio.
Un benchmark del modello può prevedere il tempo di risposta per il personale?
Un benchmark è utile per confrontare esecuzioni controllate, ma può escludere tokenizzazione, campionamento, recupero, coda e interfaccia. Usalo per documentare file del modello, quantizzazione, runtime e hardware, poi ripeti la prova nell’applicazione completa. Le misurazioni end-to-end su documenti rappresentativi sono la prova dell’esperienza utente che l’ufficio intende acquistare.
Quale fallback deve usare un ufficio sensibile se l’appliance si guasta?
Di solito, il fallback più semplice è un processo manuale nei sistemi di origine esistenti. Una via API è adatta soltanto se l’ufficio ha approvato esplicitamente quel fornitore e quella destinazione per la stessa classe di dati. Evita il passaggio automatico al cloud pubblico. Documenta chi dichiara l’interruzione, come viene gestito il lavoro in coda e come l’appliance rientra in servizio.
Come si calcola il costo totale di un appliance AI?
Usa un modello a tre anni che includa hardware, archiviazione, backup, UPS, rete, installazione, integrazione, monitoraggio, assistenza, rischio di sostituzione, formazione e tempo di revisione. Aggiungi l’elettricità misurata dell’intero sistema alla tariffa aziendale locale. Confronta il risultato con un servizio privato gestito allo stesso carico e includi il tempo dell’amministratore, il ripristino e il costo del fallback concordato.