Dal JIT al GIS semantico: quando l'astrazione incontra il costo reale
La settimana dal 14 al 20 settembre 2026 ha prodotto pochi temi davvero importanti, ma tecnicamente molto densi. Il pezzo dominante è l'analisi di Stephen Toub sulle performance di .NET 11: non una lista di percentuali, ma una radiografia del percorso che porta dal C# alle istruzioni native, passando per JIT, state machine async, GC, sincronizzazione, SIMD, syscall e diagnostica.
Sul fronte GIS, Esri ha pubblicato due contributi che meritano attenzione perché spostano l'AI geospaziale da "feature di prodotto" a modello architetturale: l'uso degli embeddings nei workflow di spatial analysis e una Agent Skill ufficiale per costruire custom widget Experience Builder. Nella stessa settimana Microsoft ha mostrato due evoluzioni complementari: un harness agentico C# costruito sopra IChatClient e un pattern in cui una competenza specialistica viene esposta come SKILL.md + tool MCP, senza necessariamente mantenere un secondo model loop.
Infine, Google ha introdotto Gemini 3.8 Live e Gemini 3.8 Live Extended Thinking, rendendo ancora più evidente una tendenza: per i voice agent il problema non è più solo speech-to-text più LLM più text-to-speech, ma orchestrare conversazione, reasoning e tool execution mantenendo viva l'interazione in tempo reale.
.NET 11 Performance Improvements: il runtime che prova a cancellare il costo delle nostre astrazioni
Il 15 settembre Stephen Toub ha pubblicato Performance Improvements in .NET 11, il consueto deep dive sulle ottimizzazioni introdotte nel runtime, nelle librerie e nel toolchain. .NET 11 è attualmente in Release Candidate e l'articolo invita esplicitamente a misurare i workload reali, perché non tutte le ottimizzazioni hanno lo stesso impatto e alcune funzionalità — in particolare runtime async — sono ancora opt-in e non completamente ottimizzate.
Fonte primaria: Microsoft .NET Blog — Performance Improvements in .NET 11
Il punto di partenza: C# non è ciò che esegue la CPU
C# source
↓
Roslyn
↓
IL
↓
CoreCLR
↓
JIT
↓
Native instructions
↓
CPU / cache / memory / kernel
Quando leggiamo un benchmark .NET, il numero finale è l'effetto di una catena. Una modifica al JIT può eliminare una branch, un bounds check o una chiamata virtuale senza cambiare una singola riga dell'applicazione. Una modifica nella BCL può evitare un'allocazione. Una modifica nel runtime può evitare la materializzazione di un Task<T>. Una modifica nella parte Linux può sostituire un percorso basato su file descriptor con una syscall diretta.
Deabstraction ed escape analysis: non pagare per ciò che il programma non può osservare
.NET continua ad ampliare la capacità del JIT di "smontare" astrazioni quando riesce a dimostrare che il comportamento osservabile resta identico. Questo comprende devirtualization, propagazione di informazioni di tipo ed escape analysis. Nell'esempio di Toub sul boxing di un Nullable<int>, .NET 11 riesce in uno dei casi a vedere che il box temporaneo non esce dal metodo e quindi elimina completamente l'allocazione heap.
Analisi tecnica. Questo è un punto architetturalmente importante: l'obiettivo non è suggerire di smettere di usare interfacce, generics o helper ben composti. È il contrario. Se il runtime riesce a rendere più economici i confini di astrazione, possiamo mantenere un codice leggibile e modulare senza trasformare ogni hot path in codice manualmente "flattened". Il rischio, come sempre, è assumere che il JIT riesca a vedere tutto: reflection, chiamate virtuali non risolte, escape reali dell'oggetto e boundary non inlinabili possono interrompere la catena di ottimizzazione.
Runtime async: la state machine si sposta dal compilatore verso VM e JIT
Questa è probabilmente la novità più interessante dell'articolo. In .NET 11 un'applicazione può abilitare runtime async con:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net11.0</TargetFramework>
<Features>$(Features);runtime-async=on</Features>
</PropertyGroup>
</Project>
Con il lowering tradizionale, Roslyn genera per ogni metodo async una state machine, campi per lo stato catturato, un MoveNext() e l'infrastruttura necessaria a rappresentare il risultato come task. Con runtime async, il metodo mantiene nel metadata la propria natura asincrona e il runtime può creare una variante di chiamata specializzata. Quando un metodo runtime-async attende direttamente un altro metodo runtime-async, il JIT può evitare di materializzare task intermedi che esistono solo per trasportare un risultato lungo la catena.
Nel micro-esempio a dieci livelli pubblicato da Toub, la DLL passa da 10.752 a 5.632 byte. In un benchmark a due livelli, la catena che completa sincronicamente passa da 21,221 ns e 144 byte allocati a 6,151 ns e zero allocazioni; dopo una sospensione reale, il benchmark mostrato passa da 254,139 ns / 248 byte a 116,927 ns / 168 byte. Sono microbenchmark del caso specifico, non percentuali applicabili automaticamente a un servizio web.
Analisi tecnica. Il vantaggio cresce dove l'architettura reale è composta da molti helper async piccoli:
HTTP endpoint
↓
authentication
↓
authorization
↓
validation
↓
business service
↓
retry / resilience
↓
HTTP / SQL / storage
Oggi ogni boundary può produrre un task/state-machine boundary. Runtime async prova a rendere alcuni di questi confini non osservabili e quindi eliminabili. È una forma di deabstraction applicata al modello asincrono.
Importante: Toub specifica che la feature non è ancora ottimizzata in tutti i casi, resta opt-in per l'applicazione e supporta Task, Task<T>, ValueTask e ValueTask<T>, ma non ancora async void, async iterator o arbitrary custom task-like return types.
Async profiling: osservare il logical stack senza distruggere il workload
Un profiler CPU tradizionale vede lo stack fisico del thread. Dopo un await, però, la continuation può riprendere su un altro thread; ricostruire la catena logica usando eventi Task molto dettagliati può diventare costoso. .NET 11 introduce un event stream più leggero, con buffer per-thread e record compatti. Toub riporta misure in cui l'overhead resta sotto l'1% e il volume di trace si riduce di circa un ordine di grandezza.
Valutazione. Per servizi ad alto throughput questo è quasi più importante del micro-ottimizzare un singolo metodo: una diagnostica abbastanza economica da restare attiva in produzione cambia la capacità di capire davvero le regressioni async.
Bounds checks e SIMD: il JIT deve dimostrare, non indovinare
La sicurezza della memoria impone a .NET di verificare che un accesso a array, stringhe e span sia entro i limiti. Il JIT elimina il check solo quando riesce a dimostrare la validità dell'indice. .NET 11 amplia diversi pattern riconosciuti dalla range analysis.
cmp ecx, dword ptr [rax+8]
jae THROW
mov edx, dword ptr [rax+rcx*4+16]
Se il JIT dimostra che ecx è sempre valido, quelle istruzioni possono scomparire dal percorso caldo.
Sul fronte SIMD, Toub mostra numerosi casi in cui .NET 11 conserva meglio valori vettoriali nei registri invece di spezzarli o passarli inutilmente dallo stack. In un esempio con un tipo numerico user-defined bitcast a Vector128<double>, il codice helper x64 mostrato nell'articolo passa da 52 a 22 byte.
Analisi tecnica. Qui entra in gioco l'hardware reale. Il guadagno dipende dall'ISA disponibile, dalla dimensione del vettore, dal costo di caricamento dei dati e dalla pressione sui registri. Un benchmark che usa AVX2 o AVX-512 non è automaticamente trasferibile a una VM con una CPU differente. Il deployment target diventa quindi parte della performance story.
GC: la generazione dei metadati conta quanto quella degli oggetti
Toub dedica una parte significativa al GC. Una delle ottimizzazioni riduce il lavoro che le raccolte ephemeral devono fare sui metadati sopravvissuti. Nel benchmark pubblicato con un milione di handle, una raccolta Gen0 passa da circa 10,7 ms a circa 0,31 ms.
Valutazione. Non significa che "il GC di .NET 11 è 34 volte più veloce". Significa che una struttura specifica che prima costringeva Gen0 a riesaminare molto stato sopravvissuto è stata riorganizzata. Il modo corretto di leggere questi numeri è chiedersi: il mio workload produce una forma simile di pressure?
Locking e false sharing: la CPU può contendere anche su dati logicamente indipendenti
Nel percorso Monitor.Wait/Pulse, .NET 11 evita una lookup separata tramite ConditionalWeakTable memorizzando direttamente sul lock la condition variable interna. Nel benchmark di ping-pong riportato da Toub il tempo medio passa da 4,194 μs a 3,517 μs.
Ancora più interessante è il caso del false sharing. Due contatori indipendenti possono trovarsi sulla stessa cache line: due core che scrivono su campi diversi finiscono comunque per contendersi la ownership della stessa linea di cache. .NET 11 riorganizza alcuni contatori di MemoryCache su cache line separate, accettando un piccolo overhead di memoria per ridurre il bouncing fra core.
Core 0 Core 1
↓ ↓
counter A counter B
\ /
SAME CACHE LINE
↓
invalidation ping-pong
Questo è il tipo di ottimizzazione che ricorda perché la performance non finisce al linguaggio o al GC: arriva fino alla coerenza delle cache CPU.
Syscall: Guid.NewGuid() su Linux
Su Linux, Guid.NewGuid() si sposta dal percorso basato su /dev/urandom alla syscall getrandom(), evitando setup e letture attraverso l'astrazione del file descriptor.
C#
↓
BCL
↓
runtime
↓
syscall
↓
kernel
Una riga di C# apparentemente banale può quindi essere ottimizzata a un livello che l'applicazione non vede direttamente.
Observability: Activity, Metrics e logging sono parte dell'hot path
Tracing e metriche vengono eseguiti potenzialmente per ogni request. In un benchmark su ObservableGauge, .NET 11 evita un array temporaneo e la relativa enumerazione: il caso mostrato passa da 17,16 ns e 72 byte allocati a 4,511 ns e zero allocazioni. Anche qui: microbenchmark specifico, non promessa di accelerazione dell'applicazione.
Technical reading. Il tema trasversale dell'articolo è questo:
devirtualize
↓
inline
↓
propagate constants/ranges
↓
eliminate checks/allocations
↓
keep data in registers
↓
reduce synchronization/kernel crossings
Le grandi performance release non derivano quasi mai da una singola "magic optimization". Derivano da centinaia di piccoli percorsi che diventano più corti.
ArcGIS + embeddings: spatial proximity e semantic proximity non sono lo stesso spazio
Il 16 settembre Esri ha pubblicato Including Embeddings in Your Spatial Analysis Workflows. L'articolo è importante perché non vende gli embeddings come una scorciatoia magica: insiste sui problemi di scala geografica, aggregazione, interpretabilità, ecological fallacy e costruzione della similarity metric.
Fonte primaria: Esri — Including Embeddings in Your Spatial Analysis Workflows
Per confronto, la documentazione ArcGIS Pro sul tool Near definisce la prossimità come distanza geometrica minima, calcolabile in modalità planar o geodesic.
Fonte primaria: ArcGIS Pro — Near (Analysis)
Due metriche, due significati
Geometry space
(x, y, z, topology, network)
↓
spatial proximity
Embedding space
[e1, e2, ... en]
↓
semantic similarity
Due quartieri possono essere lontani centinaia di chilometri ma avere embedding geodemografici molto simili. Al contrario, due poligoni confinanti possono essere semanticamente differenti.
Per ArcGIS, Near risponde a domande del tipo "qual è la feature geometricamente più vicina?". Un nearest-neighbor nello spazio vettoriale risponde invece a "quale feature è più simile nella rappresentazione appresa?".
La scala geografica deve coincidere con la scala dell'embedding
Esri raccomanda, quando possibile, di utilizzare embeddings prodotti alla stessa scala dell'analisi. Se gli embeddings sono su celle H3 più fini e l'analisi è su poligoni più grandi, si possono aggregare dimensioni con media, mediana, deviazione standard o altre statistiche, ma Esri sottolinea che l'aggregazione di embeddings fra scale è ancora un'area di ricerca e può perdere informazione.
Il problema inverso è altrettanto serio: se un embedding è definito a livello di poligono e lo si assegna a molti punti interni, tutte quelle osservazioni ereditano lo stesso vettore. Esri collega esplicitamente il problema all'ecological fallacy: proprietà aggregate non diventano automaticamente proprietà degli individui contenuti nel poligono.
Non standardizzare automaticamente un embedding
Esri raccomanda cautela nel normalizzare o standardizzare le singole dimensioni prima di clustering e similarity search. Un embedding è una geometria appresa: modificarne arbitrariamente le dimensioni può deformare lo spazio semantico. L'articolo sconsiglia inoltre di mischiare direttamente embedding dimensions e variabili tradizionali dentro la stessa similarity metric.
Analisi tecnica. Questo suggerisce una pipeline più robusta di una semplice formula del tipo:
score = α * geographicDistance + β * cosineDistance
Le due distanze hanno unità, distribuzioni e significato differenti. Sommarle senza calibrazione produce un numero, non necessariamente una metrica sensata.
Una strategia spesso più leggibile è invece:
1. Spatial constraint
ArcGIS Near / Generate Near Table / Spatial Join
↓
2. Candidate set
↓
3. Semantic ranking
cosine / dot-product / vector NN
↓
4. Domain filters
↓
5. Final ranked result
Qui la geografia non è "un'altra feature" da sommare al vettore: diventa un vincolo di ricerca. Per esempio: "tra le aree entro 30 km o 20 minuti di percorrenza, trova quelle semanticamente più simili al profilo target".
Il caso USA Geodemographic Embeddings
Esri ha introdotto in beta nel 2026 gli USA Geodemographic Embeddings: oltre 5.000 variabili demografiche, socioeconomiche, ambientali e census-derived vengono compresse in più di 250 attributi di embedding su celle Uber H3 resolution 7. Il valore architetturale non è solo la riduzione dimensionale: è la disponibilità di un contesto territoriale precomputato che può essere usato per prediction, clustering e similarity search.
Fonte primaria: Esri — Introducing USA Geodemographic Embeddings
Valutazione. Questo avvicina molto GIS e vector retrieval, ma con una differenza fondamentale: nel GIS la scala, il sistema di riferimento, la topologia e l'unità territoriale non sono dettagli di preprocessing. Sono parte del significato del dato.
Experience Builder Agent Skill: SDK inizia ad avere una rappresentazione per gli agenti
Il 14 settembre Esri ha pubblicato una Agent Skill ufficiale per lo sviluppo di custom widget ArcGIS Experience Builder. La skill contiene convenzioni, framework API, struttura dei file, skeleton del widget e reference specializzate per data source, map/layer view, message e data action, theming, state, accessibility e altri aspetti del framework. L'agente carica solo la documentazione utile al task corrente.
Fonte primaria: Esri — Building Custom Experience Builder Widgets with an Agent Skill
Il folder ufficiale è skills/arcgis-exb-widget-dev nel repository Esri Experience Builder SDK Resources. Esri documenta percorsi differenti per Copilot, Codex, Claude Code e Cursor, tutti basati sullo stesso SKILL.md.
RAG e Skill non sono la stessa cosa
RAG
↓
"Quale conoscenza devo recuperare?"
Skill
↓
"Quale procedura devo seguire per svolgere questo lavoro?"
Il confine non è assoluto, ma la distinzione è utile. La documentazione API dice che cosa esiste. La skill descrive anche convenzioni operative: dove creare il widget, come separare runtime e builder, quali API preferire, quali file non dimenticare e quali pattern sono idiomatici.
Analisi tecnica. Questo è molto vicino a un nuovo livello di SDK:
SDK for humans
API + docs + samples
SDK for agents
API + docs + samples + procedural knowledge
Da skill locale a skill distribuita via MCP
Nella stessa settimana Microsoft Agent Framework ha pubblicato un articolo ancora più interessante: From Specialist Agents to Distributed Skills over MCP. Il principio è semplice: non ogni dominio specialistico ha bisogno di un proprio model loop.
Fonte primaria: Microsoft Agent Framework — From Specialist Agents to Distributed Skills over MCP
Pattern A — specialist agent
Parent Agent
↓ A2A
Specialist Agent
↓
Model
↓
Domain tools
Pattern B — distributed skill
Parent Agent
↓
load SKILL.md
↓
MCP tools
↓
Domain service
Nel secondo pattern il servizio resta distribuito, ma il reasoning specialistico si sposta nel contesto del parent agent. Il provider espone descrizione, istruzioni e tool tipizzati. Il model loop remoto scompare se non serve autonomia indipendente.
Nel test dimostrativo pubblicato da Microsoft, il percorso con specialist agent usa sei o sette model call, mentre il percorso con skill MCP ne usa tre. Ma il dato più interessante è il caveat: il percorso skill ha consumato nel piccolo test circa il 22% di token osservati in più. Meno model call non significa automaticamente meno contesto, meno token o costo inferiore. Microsoft sottolinea che il confronto non è uno studio controllato e che cache, lavoro eseguito e runtime differiscono.
Valutazione. La scelta quindi non è "A2A è vecchio, MCP è nuovo". È:
Serve autonomia indipendente?
sì → specialist agent
no → skill + typed tools può essere sufficiente
Questa distinzione è importante anche per GIS: geocoding, query layer, network analysis, editing o validazioni di dominio possono restare servizi separati senza richiedere necessariamente un LLM dedicato per ogni capacità.
Il segnale cross-vendor: Esri, Microsoft e DevExpress stanno convergendo sullo stesso pattern
DevExpress aveva già aggiornato ad agosto le proprie Agent Skills, dichiarando esplicitamente che una skill deve guidare l'assistente sui pattern corretti e utilizzare il Documentation MCP Server come fallback quando la conoscenza locale non basta. Non è una novità di questa settimana, quindi non la tratto come news, ma è un segnale architetturale importante.
Fonte primaria: DevExpress — Agent Skills Recent Updates
Skill
↓
known procedure / best practice
↓
MCP fallback
↓
authoritative API documentation / tools
Questa potrebbe diventare una delle architetture dominanti per i coding agent enterprise: knowledge locale piccola e curata + discovery dinamica + tool tipizzati + documentazione autorevole on demand.
C# Agent Harness: dal singolo IChatClient a un runtime governabile
Il 16 settembre Bruno Capuano ha pubblicato una serie pratica sul Microsoft Agent Framework harness. L'interesse non è il demo finanziario usato come esempio, ma la trasformazione di un semplice IChatClient in un agente con planning, tool invocation, file access confinato, approval, memory, skills, shell/code execution, background agents, OpenTelemetry, governance ed evaluation.
Fonte primaria: Microsoft .NET Blog — Build Your Own AI Agent Harness in C#
AIAgent agent = chatClient.AsHarnessAgent(
new HarnessAgentOptions
{
ChatOptions = new ChatOptions
{
Instructions = instructions,
Tools = tools
}
});
Un harness non è un prompt wrapper
Model
+ instructions
+ tool loop
+ planning
+ context compaction
+ memory
+ approval
+ skill loading
+ observability
+ evaluation
+ deployment boundary
= Agent runtime
Il framework offre componenti composabili per automatic function invocation, history persistence, planning, context compaction, file memory, web search quando supportata dal model service, approval e OpenTelemetry.
File access: confinamento prima dell'approvazione
L'esempio usa un FileSystemAgentFileStore radicato in una working directory. L'agente non riceve accesso arbitrario al filesystem: il boundary è costruito dall'host.
Agent
↓
FileSystemAgentFileStore
↓
approved working directory
Questo è un pattern più forte di "chiedi conferma prima di leggere un file": l'approvazione è una policy di interazione, il confinamento è una proprietà dell'ambiente.
Approval: non tutti i tool hanno lo stesso rischio
L'articolo mostra ApprovalRequiredAIFunction per azioni con side effect e regole di auto-approval per operazioni read-only. È la distinzione giusta: se ogni GET innocuo produce un dialog di conferma, l'utente impara a premere "Approve" senza leggere.
Analisi tecnica. Un catalogo di tool dovrebbe avere metadata almeno di questo tipo:
readOnly
idempotent
destructive
externalSideEffect
requiresUserContext
requiresElevation
maxExecutionTime
networkScope
Da questi attributi deriva la policy; non dal nome del tool.
Osservabilità ed evaluation devono stare dentro l'harness
Un agente che funziona in demo ma non espone model call, tool call, token usage, approval result, latency e failure path non è realmente operabile. L'harness Microsoft integra OpenTelemetry e porta esplicitamente evaluation e governance nella fase di productionization.
Valutazione. Questo è il passaggio dal "chatbot con funzioni" a una piattaforma software: il model diventa un componente sostituibile dentro un runtime governato.
LLM Watch: Gemini 3.8 Live separa la latenza conversazionale dal reasoning di background
Il 15 settembre Google ha introdotto Gemini 3.8 Live e Gemini 3.8 Live Extended Thinking. Il primo è orientato a voice agent a bassa latenza; il secondo aggiunge reasoning di background per workflow multi-step più complessi.
Fonti primarie:
Google — Introducing Gemini 3.8 Live and 3.8 Live Extended Thinking
Gemini Live API documentation
Thinking in the Live API
Protocollo: stateful WebSocket, non request/response stateless
La Live API usa una connessione WebSocket stateful. La documentazione corrente indica input audio PCM 16-bit a 16 kHz, immagini e testo; l'output audio è PCM 16-bit a 24 kHz. Questo significa che l'architettura di rete è parte del prodotto: gestione sessione, reconnect, backpressure, token temporanei e lifecycle della connessione diventano requisiti applicativi.
Client audio/video
↕ WSS
Gemini Live session
↕
Tools / APIs
Extended Thinking: l'interazione continua mentre il tool lavora
La variante gemini-3.8-live-extended-thinking può mantenere attiva la conversazione mentre effettua reasoning e tool call asincrone in background. La documentazione introduce uno stato di interazione IN_PROGRESS/IDLE e richiede tool NON_BLOCKING per questo modello.
User speaks
↓
model acknowledges
↓
interaction_status = IN_PROGRESS
↓
background reasoning
↓
async tool calls
↓
progress narration
↓
interaction_status = IDLE
Analisi tecnica. Il punto non è il filler vocale. È la separazione tra due latenze:
interaction latency
≠
reasoning / tool latency
Un buon voice agent non deve necessariamente completare tutto il lavoro prima di tornare a parlare. Può confermare la richiesta, avviare operazioni lente, continuare il dialogo e pubblicare il risultato quando il task termina.
Il costo nascosto delle sessioni live: contesto che si ricompone
La documentazione delle best practice di Gemini Live chiarisce un punto economico importante: la sessione persistente viene fatturata a token e il contesto accumulato viene riprocessato nei turn successivi. All'aumentare della conversazione, aumenta quindi il costo di ogni turno; il contesto audio nativo contribuisce a questa crescita.
Fonte primaria: Gemini Live API — Best practices
Valutazione. Il KPI corretto per un voice agent non è soltanto prezzo per milione di token:
Cost per successful conversation
= audio/context tokens
+ reasoning tokens
+ tool calls
+ retries
+ media/network layer
La gestione del contesto diventa quindi anche un problema FinOps.
Azure Hardware Corner: dove far girare davvero un LLM locale
Quando si parla di hosting locale/open-weight su Azure, il primo errore è scegliere la VM partendo dal numero di parametri senza distinguere weight memory, KV cache, runtime overhead, batch size, concurrency e interconnect.
Le famiglie Azure attuali coprono livelli molto differenti. Alcuni esempi ufficialmente documentati:
- NCasT4_v3: NVIDIA T4 con 16 GB per GPU; famiglia orientata anche a real-time inference e GPU compute general-purpose.
- NCads H100 v5: 1 o 2 NVIDIA H100 NVL con 94 GB per GPU e fino a 640 GiB di RAM di sistema.
- ND H100 v5: 8 H100 da 80 GB, NVLink dentro la VM e InfiniBand 400 Gbps per GPU per scale-out.
- ND H200 v5: 8 H200 da 141 GB per GPU, 4,8 TB/s di memory bandwidth per GPU secondo la documentazione Azure.
- ND MI300X v5: 8 AMD Instinct MI300X da 192 GB per GPU, con Infinity Fabric intra-node e InfiniBand scale-out.
Fonti primarie:
Azure NCasT4_v3
Azure NCads H100 v5
Azure ND H100 v5
Azure ND H200 v5
Azure ND MI300X v5
Prima approssimazione: memoria dei pesi
Weight memory ≈ parameters × bits-per-weight / 8
Quindi, come ordine di grandezza:
8B @ Q4 ≈ 4 GB raw weights
70B @ Q4 ≈ 35 GB raw weights
70B @ FP16 ≈ 140 GB raw weights
Analisi tecnica. Questi sono solo i pesi. Bisogna aggiungere metadata della quantizzazione, allocator, buffer temporanei, graph/runtime e soprattutto KV cache, che cresce con context length, batch e numero di sessioni concorrenti. Dire "70B Q4 entra in 35 GB" è quindi vero solo come stima dei pesi, non come sizing della macchina.
T4 vs H100/H200: non è solo una differenza di TFLOPS
Per piccoli modelli quantizzati e pochi utenti, una GPU da 16 GB può ancora essere una scelta sensata se il modello e il contesto entrano in memoria e il throughput richiesto è modesto. Per modelli più grandi e concurrency elevata, la VRAM e la bandwidth diventano determinanti.
Durante la generazione autoregressiva di token, il decode tende spesso a diventare sensibile alla bandwidth perché ogni step deve leggere grandi quantità di pesi. Il prefill di prompt lunghi ha invece un profilo più compute-intensive. Per questo una GPU non si sceglie soltanto guardando il picco teorico di calcolo.
NC o ND?
Analisi architetturale.
Single-node inference / development
↓
NC family spesso più naturale
Very large model / distributed training / scale-out inference
↓
ND family
+ NVLink / Infinity Fabric
+ InfiniBand / RDMA
Una ND H200 o MI300X da otto GPU è una piattaforma per workload molto più grandi di un server Ollama mono-utente. Usarla per un 7B Q4 sarebbe tecnicamente possibile ma architetturalmente ed economicamente sproporzionato.
Quantizzazione: risparmiare memoria cambia anche il profilo di calcolo
Q4/Q8 non sono soltanto "compressione". Modificano kernel utilizzabili, conversioni, qualità numerica e compatibilità con il runtime. Il guadagno reale dipende dall'engine: llama.cpp/Ollama, vLLM, TensorRT-LLM, ONNX Runtime o stack ROCm/CUDA possono avere profili molto diversi.
Regola pratica da architect:
1. scegli il modello
2. scegli precisione/quantizzazione
3. definisci context e concurrency
4. stima VRAM + KV cache
5. misura tokens/s e latency
6. solo dopo scegli la VM Azure
Invertire l'ordine — scegliere una GPU e poi chiedersi quale modello farci stare — porta spesso a costi inutili.
DevExpress Watch: nessuna news da forzare, ma il trend Agent Skills è ormai chiaro
Nel feed DevExpress non risultano nuovi post .NET/XAF/Blazor pubblicati nella settimana 14–20 settembre; l'ultimo post mostrato nella sezione latest è del 7 settembre e riguarda Office & PDF File API for Java. Evito quindi di trasformare roadmap già pubblicate in una falsa "novità settimanale".
Fonte primaria: DevExpress Blogs
Resta però significativo il collegamento con le altre sezioni: DevExpress usa già Agent Skills con fallback al Documentation MCP Server, mentre la roadmap XAF v26.2 prevede ulteriori skill prodotto-specifiche e integrazione automatica del MCP documentation server. Non è una notizia della settimana, ma conferma che il pattern Skill + MCP non è confinato a un singolo vendor.
Fonte primaria: DevExpress XAF v26.2 Roadmap
Technical Takeaways
1. L'astrazione non sparisce: viene ottimizzata o resa esplicita
.NET 11 cerca di cancellare il costo delle astrazioni quando il comportamento non è osservabile: task intermedi, allocazioni temporanee, bounds check ridondanti, dispatch indiretti, lookup e buffer diagnostici.
Nel mondo agentico accade quasi il contrario: ciò che prima era implicito nel prompt viene reso esplicito come SKILL.md, schema di tool, approval policy, memory provider e telemetry.
.NET runtime
abstraction → optimize away when safe
Agent architecture
implicit behavior → make explicit and governable
2. Spatial proximity e semantic similarity devono restare concetti separati
La distanza geografica ha un sistema di riferimento, un'unità e una semantica geometrica. La distanza vettoriale è una proprietà di uno spazio appreso. Un sistema serio deve dichiarare come questi due mondi interagiscono, non semplicemente sommarli.
3. Non ogni dominio ha bisogno di un agente
Se un componente possiede autonomia, contesto privato, workflow proprio o model lifecycle indipendente, un specialist agent ha senso. Se possiede soprattutto regole operative e tool deterministici, una skill caricabile + MCP può essere più semplice da osservare e governare.
4. Voice AI sta diventando un problema di scheduling
Con reasoning e tool call asincrone in background, la domanda non è più "quanto ci mette il modello a rispondere?", ma "quali attività devono bloccare la conversazione e quali possono proseguire mentre l'utente continua a interagire?".
5. Per il local inference la GPU va scelta dopo il workload
Parametri, precisione, context, KV cache e concurrency determinano la memoria. Memory bandwidth, runtime e batching determinano il throughput. NVLink/InfiniBand diventano importanti solo quando il problema richiede davvero più GPU o più nodi.
Lab della settimana
Lab 1 — .NET 11 Runtime Async: benchmark + disassembly
Creare un servizio o un benchmark con una catena di 5–10 helper async Task<T> e compilare due versioni:
# versione classica
runtime-async = off
# versione .NET 11
<Features>$(Features);runtime-async=on</Features>
Misurare:
binary size
allocated bytes/op
mean latency
exception path
sync completion
real suspension
JIT disassembly
Obiettivo: non verificare se "runtime async è più veloce", ma capire dove scompaiono task, state machine e boundary intermedi.
Documentazione: Performance Improvements in .NET 11
Lab 2 — ArcGIS: spatial prefilter + semantic reranking
Preparare un feature layer con embeddings e scegliere una feature target.
A. Generate Near Table / Near
→ top N candidati geografici
B. cosine similarity sugli embeddings
→ reranking dei candidati
C. confronto con
pure semantic nearest neighbors
Visualizzare in mappa tre gruppi:
closest spatially
closest semantically
closest semantically inside spatial constraint
Misurare quanto cambia la risposta e verificare se la scala geografica dell'embedding è coerente con quella delle feature analizzate.
Documentazione: Esri Embeddings in Spatial Analysis — ArcGIS Pro Near
Lab 3 — Experience Builder: Agent Skill locale vs skill distribuita
Costruire lo stesso widget custom in tre modalità:
A. coding agent senza skill
B. coding agent + Esri arcgis-exb-widget-dev skill
C. agent + skill discovery + tool/documentation MCP
Valutare:
manifest correctness
folder structure
API correctness
data-source lifecycle
accessibility
manual fixes
tool calls
model calls
total tokens
elapsed time
Il test interessante non è "l'AI ha generato il widget?". È capire quale architettura produce il minor numero di deviazioni dalle convenzioni SDK e il minor costo di correzione umana.
Documentazione: Esri Experience Builder Agent Skill — Microsoft Distributed Skills over MCP
NicoGIS Tech Weekly seleziona aggiornamenti tecnici supportati da fonti primarie. Le sezioni indicate come “Analisi tecnica”, “Analisi architetturale” o “Valutazione” sono interpretazioni tecniche e non dichiarazioni dei vendor citati.
