Chiedi a Metnos con una richiesta come quella di questo esempio: «Mostrami dove posso modificare il modello e il budget di ragionamento del tier wise».

Metnos ti conduce alla pagina amministrativa della chat web: Settings > Sistema > Modelli. Se poni la domanda da Telegram, il Tutor può spiegarti il percorso, ma la pagina si apre nella chat web. L'indirizzo interno è /admin/virt e richiede un accesso da amministratore.

Il runtime non lega i propri componenti a un nome di modello. Ogni componente chiede un ruolo logico; la configurazione effettiva associa quel ruolo a un fornitore, a un modello, a un endpoint e ai relativi parametri. La pagina Modelli mostra questa associazione e permette di modificarla senza cambiare il codice dei componenti che la usano.

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 backend 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 carica di nuovo il file e aggiorna la visualizzazione; non salva modifiche e non riavvia i modelli. Le modifiche dalla pagina 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 consumatore dichiara che cosa gli serve, non quale prodotto o modello debba soddisfare la richiesta. La risoluzione passa da tre punti pubblici del pacchetto runtime/virt:

I nomi dei tier LLM esprimono un'intenzione del chiamante. Non certificano da soli la qualità del modello concreto: è l'amministratore a decidere quale fornitore e quale modello soddisfano ciascun ruolo. Un file LLM parziale sostituisce solo i ruoli che contiene; per fast, middle e wise omessi restano validi i valori iniziali. I tre livelli di fast ereditano il binding di fast e possono ricevere un override mirato in [fast.level.micro], [fast.level.procedural] o [fast.level.fidelity]. Se creative è assente, il suo binding fisico viene associato a wise conservando la policy creativa. frontier è facoltativo e chi lo richiede deve gestirne l'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 il backend. Cambiare un collegamento 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 a fornitore, modello ed endpoint;
• la politica di generazione dei tier LLM, compresi think, temperature e reasoning_budget quando presenti;
• gli altri parametri scalari effettivi, per esempio timeout e percorsi del modello.

I valori della politica di generazione sono i valori effettivi del tier, risolti dal file di configurazione e dai valori iniziali. Le operazioni scelgono un tier e non mantengono un secondo profilo di decodifica. Limiti di output, deadline, grammatiche e schemi dei tool restano vincoli strutturali della singola operazione.

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.

La lettura della pagina non inizializza fornitori e non carica modelli: costruisce una proiezione limitata e priva di segreti della configurazione risolta.

4. Modificare e salvare

Per LLM e VLM, premendo Modifica, Metnos espone soltanto i valori scalari visibili che sa 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. ricostruisce i tipi TOML, valida fornitori, URL, valori numerici 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

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. Censimento delle chiamate LLM

Ogni chiamata di produzione sceglie un workload logico. Il router lo risolve in un tier e, per fast, nel relativo livello. Il componente può definire requisiti propri della singola operazione, come max_tokens, timeout o una grammatica di output; non sceglie provider, modello o endpoint e non mantiene un secondo profilo di generazione. La configurazione dell'istanza è quindi l'unica responsabile dei valori effettivi di ciascun tier.

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à.

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/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.