Il pianificatore non chiede direttamente «Qwen» o «Claude»: chiede un ruolo come wise o fast.micro. La configurazione dell'istanza decide quale fornitore, modello ed endpoint devono svolgere quel ruolo. In questo modo si può cambiare modello senza riscrivere il componente che lo usa.

La pagina Settings > Sistema > Modelli mostra sia il collegamento configurato sia, quando il fornitore lo consente, il nome del modello che il servizio dichiara di avere realmente in esecuzione. Per esempio, un tier può essere configurato con provider=llamacpp e model=Qwen….gguf; il riquadro Modello osservato permette di confrontare quel valore con l'identità restituita dall'endpoint.

1. Usare la pagina Modelli

1. Apri la chat web di Metnos ed entra come amministratore.
2. Apri Settings > Sistema > Modelli. La stessa pagina risponde all'indirizzo /admin/virt.
3. Scegli la famiglia che vuoi esaminare: modelli linguistici, embedding o modello visivo-linguistico.
4. Per i modelli linguistici e visivo-linguistici, premi Modifica per rendere modificabili i valori visibili.
5. L’embedding è consultabile: sostituirne il sistema che lo produce richiede una procedura dedicata, compatibilità verificata e la ricostruzione degli indici.
6. Controlla i valori e premi Salva modifiche. Il messaggio di conferma indica che le chiamate successive useranno la nuova configurazione.

La pagina si apre in modalità di consultazione. Il pulsante Rileggi configurazione rilegge i file e aggiorna la pagina; non salva modifiche, non riavvia i modelli e non forza una nuova interrogazione degli endpoint. Le modifiche sono separate tra LLM e VLM. L’embedding resta consultabile e non viene riscritto dalla UI.

Questa configurazione appartiene all'istanza Metnos eseguita da quell'account di sistema. Non è una preferenza personale dell'utente della conversazione.

2. Ruoli logici e interfacce del runtime

Un componente dichiara il tipo di elaborazione di cui ha bisogno, non il prodotto che deve fornirla. La risoluzione passa da tre interfacce pubbliche del pacchetto runtime/virt:

I nomi dei tier esprimono il tipo di lavoro richiesto, non garantiscono la qualità del modello concreto. È l'amministratore a decidere quale fornitore e quale modello associare a ciascun ruolo. Un file LLM parziale sostituisce solo le sezioni che contiene: per fast, middle e wise omessi restano validi i valori predefiniti. I tre livelli di fast condividono normalmente la sua associazione, ma possono essere personalizzati nelle sezioni [fast.level.micro], [fast.level.procedural] e [fast.level.fidelity]. Se creative manca, usa lo stesso fornitore e modello di wise, mantenendo però i propri parametri di generazione. frontier è facoltativo: un componente che lo richiede deve saper gestire la sua eventuale indisponibilità.

from virt import get_embedder, get_llm, get_vlm

text_encoder = get_embedder("text")
planner = get_llm("wise")
translator = get_llm("fast", level="fidelity")
vision_spec = get_vlm("default")

La virtualizzazione separa quindi due decisioni: il componente sceglie il ruolo; la configurazione dell'istanza sceglie fornitore e modello. Cambiare l'associazione tra fornitori già supportati non richiede di modificare gli executor o il pianificatore. Aggiungere un tipo di fornitore che il runtime non conosce, invece, richiede una sua implementazione.

3. Che cosa mostra la pagina

Per ciascuna famiglia la pagina presenta:

• il percorso del file effettivamente letto e l'eventuale variabile d'ambiente che lo sostituisce;
• lo stato configurato, valori iniziali o non valido;
• i ruoli risolti e la provenienza di ogni valore: configurazione, valori iniziali, alias o ripiego;
• il collegamento configurato a fornitore, modello ed endpoint;
• l'identità del modello osservata direttamente sul servizio, quando il protocollo del fornitore permette di interrogarla;
• i parametri di generazione dei tier LLM, compresi think, temperature e reasoning_budget quando presenti;
• gli altri parametri effettivi, per esempio il tempo massimo di attesa e i percorsi dei modelli.

La pagina mostra i parametri di generazione effettivi, ottenuti unendo il file di configurazione ai valori predefiniti. La singola operazione sceglie un tier, ma non ne ridefinisce questi parametri. Può comunque imporre limiti propri, come la lunghezza massima della risposta, il tempo disponibile e lo schema che l'output deve rispettare.

Password, token, chiavi, credenziali e parti sensibili degli URL non vengono mostrati. Restano esclusi anche dai campi inviati dal modulo. I segreti già presenti nel documento vengono conservati durante il salvataggio, ma si gestiscono attraverso il flusso protetto delle credenziali o l'ambiente del servizio, non da questa pagina.

Configurato e osservato non sono sinonimi. Il primo valore è ciò che Metnos chiederà al fornitore; il secondo è ciò che quel fornitore dichiara attraverso la propria API. Se l'endpoint espone più identità, la pagina le mostra e segnala un risultato ambiguo. Se non risponde, non supporta il controllo o il dato è ormai vecchio, lo stato lo dice esplicitamente. L'osservazione aiuta a scoprire una configurazione incoerente, ma non cambia il routing e non costituisce una prova crittografica del modello caricato.

Il controllo degli endpoint avviene in un'attività di servizio separata, per impostazione predefinita una volta al minuto; dopo tre minuti un dato non aggiornato viene indicato come obsoleto. Aprire la pagina non inizializza fornitori, non carica modelli e non effettua chiamate di rete: costruisce una vista limitata e priva di segreti della configurazione e delle ultime osservazioni conservate in memoria.

4. Modificare e salvare

Per LLM e VLM, premendo Modifica, Metnos rende modificabili soltanto i valori semplici che può rappresentare senza cambiarne il tipo. I campi sensibili e i valori non modificabili restano in sola lettura. Al salvataggio il runtime:

1. accetta soltanto l'insieme di campi mostrato dall'editor;
2. converte ogni valore nel tipo TOML previsto e valida fornitori, URL, numeri e vincoli della famiglia;
3. rifiuta una versione non più corrente, evitando di sovrascrivere una modifica concorrente;
4. conserva una copia privata del file precedente, se esiste;
5. scrive il nuovo documento in modo atomico con permessi 0600;
6. invalida le cache pertinenti del runtime.

Una configurazione non valida non sostituisce il file precedente. Dopo un salvataggio valido non servono una reinstallazione, una ricompilazione o il riavvio del server: le chiamate successive risolvono i nuovi valori. Un turno già in esecuzione conclude invece il proprio lavoro con le risorse che aveva già acquisito.

5. Ripristino e copie di recupero

Il pulsante Ripristina opera su LLM o VLM e richiede conferma. Riscrive i valori iniziali forniti dalla versione di Metnos installata. Non sceglie automaticamente una vecchia configurazione personale e non ricostruisce le scelte compiute durante un'installazione precedente.

Prima del ripristino Metnos conserva una copia privata del file corrente, se il file esiste. Le copie create da salvataggi e ripristini si trovano sotto $METNOS_USER_STATE/virt-config-history/<famiglia>/; con i percorsi predefiniti, la radice è ~/.local/state/metnos/virt-config-history/. La pagina non offre un selettore delle versioni storiche: il recupero di una copia specifica è un'operazione amministrativa distinta.

6. File effettivi e precedenza

La pagina mostra sempre il percorso effettivo, che è più affidabile di un percorso ricordato a memoria. In assenza di sostituzioni, i documenti appartengono all'account di sistema che esegue Metnos.

$METNOS_USER_CONFIG vale normalmente ~/.config/metnos. Se un file non esiste, il runtime usa i valori iniziali della versione installata e la pagina lo dichiara. Se il documento non è leggibile o non supera la validazione, la pagina segnala lo stato non valido e distingue gli eventuali valori di ripiego da una configurazione valida.

7. Confini locali e remoti

Servizi scelti durante l'installazione

L'installer legge il file facoltativo ~/.config/metnos/services.toml dell'utente che lo avvia. Senza file predispone i servizi localmente; con un file parziale riusa solo gli indirizzi indicati e predispone localmente tutti gli altri componenti. Il file non cerca server nella rete: nel container localhost indica il container stesso.

Le sezioni disponibili sono llm, vlm, searxng, photon e playwright; BGE-M3 resta locale. La verifica degli indirizzi precede download e avvio. Un servizio indicato ma non disponibile ferma l'installazione, senza copie locali né sostituzioni cloud. Il profilo mantiene frontier spento salvo abilitazione esplicita. Un controllo del protocollo non sostituisce una prova reale della chat o delle immagini.

Il percorso a sei fasi richiede accesso amministrativo e usa un account Metnos separato. Prepara i componenti senza avviarli, verifica distribuzione e catalogo iniziale e attiva le unità di sistema previste. Il profilo fa parte della distribuzione firmata: i servizi esterni conservano la propria gestione e non ricevono unità locali. Dopo la fase 2 il profilo resta invariato durante la ripresa; per cambiarlo su un'istanza installata occorre un aggiornamento amministrativo con finestra di riavvio. Le fasi completate non sostituiscono i controlli di autorità. L'opzione --skip non è supportata da questo percorso.

Il catalogo dei servizi comprende anche l'ingresso del coordinatore dell'installazione. Alla prima preparazione il proprietario del deposito crea le directory mancanti dopo averne verificato il percorso; i collegamenti simbolici non sono accettati come directory del deposito.

Gli aggiornamenti autenticano l'inventario dell'installazione originaria. Un nuovo componente che non ne ha mai fatto parte non richiede il ritiro di un file dalla copia di sviluppo. Restano obbligatori le prove dei ritiri esistenti, le protezioni dei servizi e i controlli sui processi in conflitto.

Il registro dei servizi e il Tutor osservano gli indirizzi verificati del profilo; per i servizi esterni non propongono comandi locali di avvio o arresto. Nel contenitore il controllo della memoria considera anche i limiti assegnati al contenitore stesso. Anche la compilazione iniziale del Tutor rispetta la quota CPU disponibile. La verifica HTTP finale richiede un sistema operativo, non la sola risposta della pagina di manutenzione.

Stato: raccordo alle sei fasi in collaudo, non ancora pubblicato. Esempi e procedura: manuale dei servizi esistenti.

La virtualizzazione centralizza la scelta del backend; non trasforma un endpoint remoto in una risorsa locale e non concede da sola rete, credenziali o capacità aggiuntive a un executor.

8. Come le chiamate scelgono un tier

I componenti di produzione scelgono normalmente un lavoro con un nome canonico, per esempio intent.extract o translation.i18n. Il registro centrale associa quel nome a un tier e, nel caso di fast, a uno dei suoi tre livelli. Un nome sconosciuto viene rifiutato. Il componente può fissare i limiti della singola operazione, come max_tokens, un tempo massimo o una grammatica di output; non sceglie fornitore, modello o endpoint.

L'estrattore NLU è l'unico percorso corrente che sceglie direttamente fast.procedural invece di passare dal registro dei lavori. È disattivato per impostazione predefinita e può essere abilitato in modalità di osservazione o come sostituto dell'analisi tradizionale. La pagina Modelli mostra comunque tutti i ruoli configurabili, compresi quelli che al momento non hanno un lavoro assegnato.

Un tier può puntare a un servizio locale o remoto e può essere modificato dall'amministratore. Cambiarlo cambia le chiamate successive di tutte le righe che lo usano: per questo è chi configura i tier a valutarne capacità, costo, riservatezza e disponibilità.

LRE e ciclo di vita dei modelli

LRE usa requisiti espliciti dei contratti. La scelta del fornitore e il ciclo di vita del servizio appartengono alla virtualizzazione dei modelli. Un job non sceglie programmi da avviare, porte o file dei pesi. Il modello e la politica ammessi restano verificabili anche dopo l’avvio del servizio.

Il confine fra LRE e Virt espone risorse, identità del modello e disponibilità. L’adattatore locale visivo riutilizza l’avvio condiviso esistente; gli altri fornitori mantengono il proprio ciclo di vita. Non è ancora implementato l’aumento automatico del numero di repliche.

Più repliche richiedono un indirizzo logico stabile, distribuzione delle richieste e prenotazione delle risorse fra tutti i lavori. Sulla stessa CPU, replicare un modello è utile solo se aumenta la capacità misurata; RAM, memoria GPU condivisa e altri processi devono rientrare nella decisione. Un servizio disponibile non costituisce da solo una garanzia contro l’esaurimento della memoria.

Disponibilità del modello, consegna a LRE e conclusione del lavoro sono fatti distinti. Il dominio dichiara esplicitamente se il controllo ha richiesto azioni; LRE mostra Esente solo dopo una conclusione completa e senza modifiche confermata da tutte le fasi finali. Un lavoro bloccato ritrovato dalla manutenzione notturna produce un esito parziale. Vedi gli esiti delle attività.

9. Riferimenti tecnici

• runtime/virt/__init__.py — facciate e valori iniziali di embedding e VLM;
• runtime/llm_router.py — tier LLM, associazioni, alias e politica di inferenza;
• runtime/llm_workloads.py — registro dichiarativo che associa ogni workload di produzione a un solo tier logico;
• runtime/virt/configuration.py — proiezione effettiva, provenienza e oscuramento dei segreti;
• runtime/model_identity.py — osservazione limitata e priva di segreti dei modelli dichiarati dai fornitori;
• runtime/virt/config_editor.py — modifica validata, scrittura atomica, copie di recupero e ripristino.

Per la mappa completa della chat web consulta la guida alla navigazione dell'interfaccia. Per capire come i componenti eseguibili consumano questi ruoli, prosegui con la guida agli executor o torna alla Guida all'architettura.