LLM locali.
Dimensionati correttamente.
Dal modello adatto al servizio IA gestito: DAXS pianifica l'infrastruttura LLM locale, verifica l'hardware sotto carico reale e integra la soluzione nell'IT esistente.
Un server IA parte dal profilo di carico.
Un modello linguistico locale può elaborare testi interni, supportare bozze di codice o contribuire a una ricerca nelle conoscenze. Per una soluzione utile devono essere coerenti qualità del modello, percorsi dei dati ammessi e utilizzo previsto. DAXS rileva questi requisiti, pianifica l'infrastruttura e assume installazione, integrazione e gestione concordata, insieme al vostro IT o come servizio delimitato.
Attività e qualità
Quali domande, lingue, documenti o attività di codice deve gestire la soluzione? Una chat breve e l'analisi di documenti lunghi richiedono modelli e contesti diversi.
Utilizzo e attesa
Quante richieste arrivano contemporaneamente? Quanto rapidamente deve iniziare la prima risposta e quanto può durare quella completa? Richieste singole occasionali e un servizio di team usato costantemente richiedono riserve diverse.
Dati e gestione
Quali fonti e funzioni sono approvate? Dove possono risiedere modello, indice di ricerca, registri e backup? Chi gestisce aggiornamenti ed errori, e quale ripristino serve?
Collegare correttamente applicazione, inferenza e gestione.
L'interfaccia utente è solo una parte. Prima intervengono controlli di identità e accesso; dietro operano servizio di inferenza, archivio dei modelli ed eventuali ricerca nelle conoscenze o interfacce aziendali. Monitoraggio, aggiornamenti e ripristino fanno parte dello stesso piano.
Il diagramma presenta una possibile architettura. Un reverse proxy può proteggere TLS e il punto di ingresso. L'applicazione deve comunque applicare i permessi degli utenti. Le API dei modelli vengono limitate a reti e funzioni necessarie; un servizio aziendale completo richiede anche questi controlli.
Oltre le dimensioni del file del modello.
Per la scelta consideriamo pesi, esigenze del runtime, contesto, parallelismo e intero percorso dei dati. Una GPU può avere memoria sufficiente e risultare comunque inadatta ai tempi di risposta desiderati. Un modello più piccolo e ben scelto può svolgere l'attività in modo più economico.
| Componente | Cosa verifichiamo | Perché conta |
|---|---|---|
| GPU e VRAM | Architettura, driver, backend di inferenza, formati di calcolo supportati, dimensioni e banda della memoria. | Pesi e cache KV richiedono spazio. Calcolo e trasferimenti di memoria incidono su fasi diverse; l'applicazione va valutata oltre il valore TOPS pubblicizzato. |
| Una o più GPU | Distribuzione del modello, collegamenti tra GPU, connessione PCIe, energia e raffreddamento. | La VRAM non diventa automaticamente un'unica memoria liberamente utilizzabile. Distribuzione e sincronizzazione devono essere supportate dallo stack scelto; GPU aggiuntive possono introdurre nuovi colli di bottiglia. |
| CPU e RAM di sistema | Runtime, tokenizzazione, preparazione dei dati, processi paralleli ed eventuali inferenza CPU o offloading. | L'offloading può rendere eseguibile un modello, ma ne modifica le prestazioni. I trasferimenti tra RAM e GPU possono rallentare la risposta. Anche un server GPU richiede riserve adeguate di CPU e RAM. |
| NVMe e storage | Versioni dei modelli, tempi di caricamento, indice di ricerca, dati di importazione, registri, capacità libera e backup. | SSD NVMe veloci aiutano nel caricamento dei modelli e in determinate operazioni sui dati. La generazione dei token di un modello interamente nella memoria GPU dipende soprattutto da calcolo, memoria e runtime. |
| Rete e alimentazione | Collegamento, percorsi dei dati consentiti, spazio, consumo elettrico, calore e accesso per manutenzione. | Il singolo componente di calcolo migliore aiuta poco se il servizio, sotto carico reale, è limitato termicamente, organizzativamente o nell'accesso ai dati. |
Un aiuto al calcolo per orientarsi.
Il limite inferiore dei soli pesi si può stimare con Numero di parametri × bit per peso ÷ 8 . Un modello ipotetico con otto miliardi di parametri e quattro bit per peso corrisponde a quattro gigabyte, circa 3,73 GiB.
Si aggiungono metadati di quantizzazione, eventuali parti del modello a maggiore precisione, cache KV, aree di lavoro e runtime. Questo valore non stabilisce quindi la VRAM sufficiente per l'applicazione. Nei modelli con architettura a esperti vanno distinti anche calcolo attivo e pesi complessivamente da mantenere disponibili.
Una risposta breve è un test diverso da un servizio di team.
La finestra di contesto comprende le informazioni che il modello può considerare per una richiesta. Secondo l'applicazione include istruzioni, cronologia, parti di documenti recuperate e output previsto. Una finestra nominalmente ampia non garantisce hardware adeguato né uso affidabile delle informazioni.
Cache KV
La cache key-value conserva stati intermedi dell'attenzione. Il fabbisogno dipende, tra l'altro, da architettura, tipo di dato, contesto effettivamente occupato e sequenze attive simultanee. Più contesto e parallelismo aumentano spesso sensibilmente la memoria necessaria.
Prefill e decode
Nel prefill il modello elabora il contesto in ingresso; nel decode genera ulteriori token. Le fasi impegnano l'hardware in modo diverso. Documenti lunghi possono aumentare il tempo al primo token, anche se l'output successivo appare fluido.
Batching e coda
L'elaborazione congiunta può aumentare la capacità complessiva. Al tempo stesso singoli utenti possono attendere di più. Capacità riservata, code, limiti e pianificazione del parallelismo fanno quindi parte del progetto.
Misuriamo il caso d'uso effettivo.
Un progetto pilota comprende richieste tipiche brevi e lunghe e accessi simultanei. Consideriamo il Time to First Token, il tempo di risposta completo, la velocità di output, la coda, gli errori e la memoria occupata. I token al secondo sono confrontabili in modo sensato solo insieme a versione del modello, quantizzazione, contesto, carico e condizioni di misura.
Lo stack segue modello e utilizzo.
Ollama, llama.cpp e vLLM sono componenti possibili. Scelta e configurazione seguono supporto del modello, hardware, parallelismo desiderato, gestione e integrazione. Verifichiamo le versioni concrete e progettiamo l'architettura per l'utilizzo previsto.
Ollama
Un possibile punto di partenza per gestione dei modelli e servizio locale. Archivio, modelli autorizzati, contesto, parallelismo e protezione del servizio devono adattarsi all'ambiente.
llama.cpp
Un componente flessibile per modelli adatti su diversi backend CPU/GPU, con formati quantizzati e modalità server. Supporto hardware, distribuzione e funzioni API effettivamente necessarie vengono verificati nella pratica.
vLLM
Un'opzione per profili adatti di inferenza e carico server. Scheduling, cache KV, batching ed eventuali GPU multiple vengono coordinati. Una maggiore capacità complessiva non equivale a un'attesa più breve per ogni richiesta.
Container, macchina virtuale o host dedicato?
I container possono riunire versioni software in modo riproducibile. Una macchina virtuale può delimitare ulteriormente l'ambiente sul piano organizzativo e tecnico. La scelta dipende da passthrough dei dispositivi, driver, manutenzione e procedure esistenti. Un'API compatibile agevola il collegamento, ma serve comunque un test con la vostra applicazione.
Quando è adatto Proxmox con GPU passthrough?
Il GPU passthrough assegna una GPU fisica adatta a una macchina virtuale. Devono essere compatibili, tra l'altro, piattaforma e firmware, gruppi IOMMU, driver host e guest e comportamento del reset del dispositivo. Verifichiamo la combinazione concreta prima di assumere impegni.
Una GPU assegnata non è automaticamente condivisibile tra più VM. vGPU e passthrough diretto sono concetti diversi con requisiti propri ed eventuali condizioni di licenza. Anche manutenzione, backup e un eventuale cambio host richiedono un processo appropriato; la migrazione live va valutata concretamente.
Infrastruttura e virtualizzazione · Valutare la migrazione Proxmox
Il modello adatto deve superare la prova dell'attività.
Confrontiamo modelli con esempi autorizzati dell'impiego futuro: domande tecniche in tedesco, estratti di documenti, richieste multilingue o uno script concreto. Modelli di coding ed embedding svolgono compiti diversi. Per una ricerca nelle conoscenze devono essere coerenti ricerca, embedding e modello di risposta.
La quantizzazione riduce spesso la memoria necessaria. Effetti su qualità delle risposte, chiamate agli strumenti e velocità vengono verificati nel formato scelto. Un modello più grande non è automaticamente migliore o più economico. Un contesto massimo lungo non prova che ogni informazione venga utilizzata con affidabilità.
- Licenza: verificare concretamente pesi scelti, utilizzo commerciale, distribuzione e avvisi necessari; il semplice download non sostituisce la verifica.
- Versione: registrare in modo tracciabile modello, quantizzazione, tokenizer e runtime.
- Collaudo: verificare idoneità operativa, risposte non ammesse, qualità linguistica ed errori con un insieme ripetibile di domande.
- Modifiche: testare prima le nuove versioni, mantenere una possibilità di ritorno valida e rigenerare adeguatamente gli indici se cambiano gli embedding.
Locale, esterno o una combinazione adatta.
Hardware proprio può essere sensato con utilizzo appropriato, requisiti sui dati chiari e un modello operativo esistente. Un servizio esterno può essere più adatto con utilizzo variabile, capacità particolari dei modelli o risorse operative proprie limitate. L'ibrido collega attività e percorsi dei dati ben delimitati.
Il confronto comprende acquisto o consumo, elettricità e raffreddamento, licenze, integrazione, aggiornamenti, assistenza, riserva e conseguenze dei guasti. L'elaborazione locale non garantisce automaticamente sicurezza o conformità GDPR: anche modelli, embedding, telemetria, aggiornamenti, strumenti esterni e registri devono rispettare il modello dei dati concordato.
Pianifichiamo prima un progetto pilota delimitato con requisiti misurabili. I risultati guidano ampliamento, adattamento o scelta di un'alternativa più semplice. Ulteriori basi si trovano in Cloud e SaaS.
Un servizio gestito richiede responsabilità tracciabili.
DAXS può pianificare e installare hardware e software, collegarli a identità e applicazioni esistenti e assumere la gestione continuativa concordata. Comprende osservazione di raggiungibilità e risorse, manutenzione delle versioni, gestione errori e documentazione. Disponibilità e percorsi di risposta necessari vengono concordati concretamente.
Definiamo quali configurazioni, componenti applicativi, indici ed eventuali modelli adattati vengono salvati. Pesi dei modelli recuperabili e dati aziendali da proteggere richiedono backup diversi. Un test di ripristino fa parte del modello operativo adatto.
Rilevazione dei requisiti, proposta architetturale, test di modello e carico, percorsi dei dati documentati e una raccomandazione tracciabile per hardware, modalità operativa e prossime integrazioni.
Lo chiariamo nel colloquio.
Quanta VRAM serve a un LLM locale?
Dipende da modello, quantizzazione, runtime, contesto e richieste simultanee. Il solo file del modello non basta come base. Testiamo l'attività desiderata con richieste lunghe e picchi di carico prima di raccomandare una dotazione concreta.
Una seconda GPU è automaticamente più veloce?
No. Lo stack scelto deve supportare la distribuzione. Collegamenti tra GPU, sincronizzazione e architettura del modello influenzano il risultato. Più memoria può consentire l'esecuzione senza accelerare ogni singola risposta.
Si può utilizzare un server Proxmox esistente?
Può essere adatto se hardware, gruppi IOMMU, driver e passthrough GPU sono compatibili. Devono esserlo anche riserve per altri servizi e procedure di manutenzione, backup e ripristino. Verifichiamo concretamente la piattaforma esistente.
I documenti interni vengono usati per addestrare il modello?
Spesso non è necessario per la ricerca nelle conoscenze. RAG cerca parti di documenti adatte e autorizzate e le fornisce al modello come contesto. Modificare i pesi è un intervento diverso, da motivare separatamente.
Quando un servizio esterno è più economico?
Con utilizzo ridotto o molto variabile, requisiti particolari dei modelli o risorse operative insufficienti può essere più adatto. Confrontiamo costi, percorsi dei dati, qualità e gestione nel periodo d'uso previsto.
Osservare insieme modelli, carico e costi.
Oltre a utilizzo GPU e tempi di risposta consideriamo i costi per attività utile. Un aggiornamento del modello viene confrontato prima con i test approvati. Errori, code, limiti di memoria e guasti richiedono responsabili nominati e possibilità di ritorno. Un servizio esterno sostitutivo è ammesso solo se classificazione dei dati e approvazioni lo consentono.
Discutiamo il vostro caso d'uso.
Cosa deve diventare più semplice, quali dati sono coinvolti e quali sistemi sono già presenti? Su questa base sviluppiamo un inizio sensato e un prossimo passo delimitato.