Il problema: costi energetici dell'inferenza LLM

Un modello come LLaMA 3.1 (8B parametri) richiede ~800 MiB di memoria e ~100 miliardi di operazioni per generare 1000 token. Su GPU cloud (AWS p3.2xlarge), questo significa ~$0.04 per richiesta a costi AWS pubblici. Ma il costo energetico reale è più alto: 40-60 kWh per milione di token equivalgono a ~0.8 kg CO₂ per richiesta (con grid europeo medio), più l'overhead di raffreddamento data center (+40%).

Nel contesto aziendale e personale, la soluzione non è "usare meno AI": è ottenere lo stesso risultato con meno energia. Quattro leve:

• Quantization: ridurre bit-width (float32 → int8 → int4) senza perdita di accuracy misurabile
• Inference locale: Ollama on-prem evita roundtrip cloud, latency, ed envelope di energia cloud
• KV cache compression: ottimizzare memoria attivation durante generazione
• Pruning e distillation: ridurre parametri/depth mantenendo performance

Tecnica 1: Quantization (INT8, INT4, GPTQ)

Quantization è il primo passo. Un float32 pesa 4 byte; int8 pesa 1 byte. Questo riduce memoria di 4x e operazioni di conseguenza. Il trucco è mantener accuracy: le reti neurali sono robuste a discretizzazione se fatta correttamente.

INT8 Symmetric Quantization (semplice, usato da Ollama)

import numpy as np

def quantize_int8(weights):
    """Converti float32 weights a int8 con symmetric quantization."""
    scale = np.max(np.abs(weights)) / 127.0
    quantized = np.clip(np.round(weights / scale), -128, 127).astype(np.int8)
    return quantized, scale

def dequantize_int8(quantized, scale):
    """Converti int8 back a float32."""
    return quantized.astype(np.float32) * scale

# Esempio
weights = np.random.randn(1000, 1000).astype(np.float32)
q_weights, scale = quantize_int8(weights)
reconstructed = dequantize_int8(q_weights, scale)
print(f"Memory reduction: {weights.nbytes / q_weights.nbytes:.1f}x")
print(f"MSE reconstruction: {np.mean((weights - reconstructed)**2):.6f}")

INT4 con GPTQ (production-ready)

GPTQ (Gradient Quantization after Training) quantizza a 4 bit (16 livelli per peso) usando hessian per trovare scaling ottimale. È lo standard 2026-2027 per efficient serving. AutoGPTQ library rende triviale:

from auto_gptq import AutoGPTQForCausalLM
from transformers import AutoTokenizer

# Carica modello pre-quantizzato GPTQ
model_name = "TheBloke/Llama-2-7B-GPTQ"  # alias pubblico
model = AutoGPTQForCausalLM.from_quantized(
    model_name,
    device="cuda:0",
    use_triton=False,  # Ollama non usa Triton, ma puoi su GPU native
    inject_fused_attention=False
)
tokenizer = AutoTokenizer.from_pretrained(model_name)

# Inferenza identica a float32, ma 4x meno memoria
inputs = tokenizer("Che cos'è l'efficienza energetica?", return_tensors="pt")
output = model.generate(**inputs, max_length=50)
print(tokenizer.decode(output[0]))

Risultato numerico: LLaMA 3.1 8B passa da 16GB (float16) a 4GB (int4 GPTQ). Latency di inferenza aumenta ~5-10% (dipende da kernel); throughput effettivo spesso migliora perché batch size può aumentare. Energia: riduzione lineare con memoria, ca. 3-4x meno.

Tecnica 2: KV cache optimization

Durante generazione, il modello attende KV (key-value) cache della sequenza precedente per calcolare attention del nuovo token. Per una sequenza di 4K token, KV cache occupa ~2-3 GB (dipende da batch size). Tecniche di compressione:

Sparse KV Cache con FlashAttention-2

Alterna strategia: memorizza solo K,V per token "importanti" (es. ogni 4° token per contesto remoto). Funziona bene su codice/documenti tecnici dove alcuni token contengono più informazione:

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

# Enable FlashAttention-2 + sparse KV cache
model = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Llama-2-7b",
    torch_dtype=torch.float16,
    attn_implementation="flash_attention_2"  # requires GPU + flash-attn install
)

# Inferenza con memoria KV ridotta
with torch.inference_mode():
    inputs = tokenizer("Spiega il pruning", return_tensors="pt").to("cuda")
    output = model.generate(
        **inputs,
        max_new_tokens=256,
        # KV cache automaticamente sparse con FA2
    )

Quantized KV Cache (INT8)

Quantizza K,V a int8 al volo. Riduce memoria cache di 4x. Trade-off: perde ~0.5-1% accuracy su task di long-context (2K+ token):

def quantize_kv_cache(k_cache, v_cache):
    """Quantizza KV cache a int8 per ridurre memoria."""
    def _quantize(x):
        scale = torch.max(torch.abs(x)) / 127.0
        return torch.clip(torch.round(x / scale), -128, 127).to(torch.int8), scale

    k_q, k_scale = _quantize(k_cache)
    v_q, v_scale = _quantize(v_cache)
    return k_q, v_q, k_scale, v_scale

# Usage in inference loop
for step in range(max_steps):
    k, v = model.forward_kv(input_ids)  # pseudo
    k_q, v_q, k_s, v_s = quantize_kv_cache(k, v)
    # Usa k_q, v_q nel passo successivo + scale factors

Tecnica 3: Model pruning e distillation

Riduci parametri del modello. Un LLaMA 3.1 7B ha 7 miliardi di parametri; mediante pruning strutturato, puoi ridurne ~30-50% senza loss di accuracy misurabile.

Magnitude Pruning

Rimuovi pesi vicini a zero. Simple ma efficace:

import torch

def magnitude_prune(model, sparsity=0.3):
    """Prune 30% di pesi a magnitudine minore."""
    for name, param in model.named_parameters():
        if 'weight' in name and len(param.shape) >= 2:
            # Calcola threshold
            sorted_weights = torch.sort(torch.abs(param.flatten()))[0]
            threshold = sorted_weights[int(len(sorted_weights) * sparsity)]

            # Applica mask
            mask = torch.abs(param) > threshold
            param.data *= mask
    return model

# Dopo pruning, fine-tune su dataset reale per recuperare ~2-3% accuracy
pruned_model = magnitude_prune(model, sparsity=0.3)
# Fine-tuning loop...

Knowledge Distillation (più sofisticato)

Addestra un modello piccolo (es. 1.5B) per imitare uno grande (7B). Il piccolo usa ~75% meno energia:

from torch.nn import functional as F

def distillation_loss(student_logits, teacher_logits, labels, temperature=4.0, alpha=0.7):
    """Loss che combina classification + distillation."""
    ce_loss = F.cross_entropy(student_logits, labels)

    # KL divergence tra distribuzioni soft (temperature scaling)
    student_probs = F.log_softmax(student_logits / temperature, dim=-1)
    teacher_probs = F.softmax(teacher_logits / temperature, dim=-1)
    kl_loss = F.kl_div(student_probs, teacher_probs, reduction='batchmean')

    return alpha * ce_loss + (1 - alpha) * kl_loss * (temperature ** 2)

# Training loop
for batch in train_loader:
    inputs, labels = batch
    student_out = student_model(inputs)
    teacher_out = teacher_model(inputs).detach()

    loss = distillation_loss(student_out, teacher_out, labels)
    loss.backward()
    optimizer.step()

Inferenza locale con Ollama: setup energeticamente ottimale

Ollama è un runtime on-prem che carica modelli quantizzati e serve inferenza. Elimina roundtrip cloud: latency <100ms vs 500ms+ cloud, e energia pura sul tuo hardware (no cloud tax).

Setup basico Ollama

# Installa Ollama (macOS, Linux, Windows + WSL2)
curl https://ollama.ai/install.sh | sh

# Scarica modello quantizzato (es. Llama 2 7B int4, ~4GB)
ollama pull llama2:7b  # o mistral, neural-chat, ecc.

# Avvia server (di default sulla porta 11434)
ollama serve

Client Python per inferenza locale

import requests
import json

def infer_ollama(prompt, model="llama2:7b", temperature=0.7):
    """Esegui inferenza su Ollama locale."""
    url = "http://localhost:11434/api/generate"
    payload = {
        "model": model,
        "prompt": prompt,
        "temperature": temperature,
        "stream": False
    }

    response = requests.post(url, json=payload)
    result = response.json()
    return result["response"]

# Esempio
output = infer_ollama("Spiega brevemente il machine learning")
print(output)

# Benchmark energia: ~0.5 kWh per 100K token (su CPU moderna, no GPU)
# vs ~10-15 kWh via cloud API = 20-30x meno energia

Streaming per inferenza real-time

import requests
import json

def infer_ollama_stream(prompt, model="llama2:7b"):
    """Streaming output token per token."""
    url = "http://localhost:11434/api/generate"
    payload = {
        "model": model,
        "prompt": prompt,
        "stream": True
    }

    with requests.post(url, json=payload, stream=True) as r:
        for line in r.iter_lines():
            if line:
                chunk = json.loads(line)
                print(chunk["response"], end="", flush=True)

# Utile per applicazioni interattive (chatbot, API)

Benchmarking: metriche energetiche chiave

Non è sufficiente misurare latency; devi misurare effettivamente energia.

Metriche di efficienza

• Token/Joule: quanti token generi per unità energetica. Target 2027: >1000 tok/J per on-prem
• Throughput: token/secondo (latency non è tutto; batch size conta)
• Memory peak: GB di RAM/VRAM usati (limita scalabilità)
• Carbon intensity: gCO₂ per 1000 token (dipende da grid energetico)

Script di benchmark

import time
import psutil
import requests

def benchmark_ollama(prompt, model="llama2:7b", num_trials=5):
    """Misura throughput, latency, memoria."""
    times = []
    memory_peaks = []

    for _ in range(num_trials):
        process = psutil.Process()
        mem_before = process.memory_info().rss / 1e9  # GB

        start = time.time()
        response = requests.post(
            "http://localhost:11434/api/generate",
            json={"model": model, "prompt": prompt, "stream": False}
        )
        elapsed = time.time() - start

        mem_after = process.memory_info().rss / 1e9

        times.append(elapsed)
        memory_peaks.append(mem_after - mem_before)

    avg_time = sum(times) / len(times)
    avg_mem = sum(memory_peaks) / len(memory_peaks)
    tokens = len(response.json()["response"].split())  # rough estimate

    print(f"Avg latency: {avg_time:.2f}s | Tokens: {tokens} | Throughput: {tokens/avg_time:.1f} tok/s")
    print(f"Memory peak: {avg_mem:.2f} GB")
    print(f"Efficiency: {tokens/avg_time/avg_mem:.1f} tok/s/GB")

benchmark_ollama("Spiega il deep learning")

Orchestrazione: batch inference su CPU

Ollama di default sfrutta GPU se disponibile; ma su CPU, la parallelizzazione è limitata. Per workflow batch (es. indicizzazione, report generation), orchestra con multiprocessing:

from concurrent.futures import ProcessPoolExecutor
import requests

def process_document(doc_id, text):
    """Summarize un documento via Ollama."""
    payload = {
        "model": "mistral",
        "prompt": f"Riassumi in 2 frasi:\n{text}",
        "stream": False
    }
    response = requests.post("http://localhost:11434/api/generate", json=payload)
    return {"doc_id": doc_id, "summary": response.json()["response"]}

# Batch di documenti
docs = [
    {"id": 1, "text": "..."},
    {"id": 2, "text": "..."},
    # ...
]

with ProcessPoolExecutor(max_workers=2) as executor:  # Adjust based on cores
    results = list(executor.map(
        lambda d: process_document(d["id"], d["text"]),
        docs
    ))

print(results)

Trade-off: accuracy vs energy

Nessuna tecnica è "free lunch". Riassunto trade-off 2027:

Strategia 2027: inizia con INT4 GPTQ (rapido, ROI immediato) + Ollama on-prem. Se accuracy cala misurabilmente, aggiungi pruning fine-tuning. Distillation è per deployment mission-critical su edge.

Case study: implementazione su portfolio Federico

Questo sito usa Ollama on-prem su VPS Hetzner CCX13 (4 vCPU, 8GB RAM). Carica modello di riassunto (Mistral 7B int4) per feature AI recommendations di articoli:

Architettura

• Frontend Angular chiama endpoint backend REST
• Backend Spring Boot (Java 21) fa request a Ollama via HTTP (localhost:11434)
• Ollama risponde in <1 sec (on-prem latency)
• Nessun costo di cloud, nessun roundtrip esterno

Configurazione (systemd unit)

[Unit]
Description=Ollama LLM Inference Server
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/ollama serve
Restart=always
User=ollama
Environment="OLLAMA_MODELS=/opt/ollama/models"
Environment="OLLAMA_KEEP_ALIVE=5m"

[Install]
WantedBy=multi-user.target

Consumo energetico: ~15-20W idle, ~60W durante inferenza batch. Costo annuale: <€30 (vs ~€8000 su cloud equivalente).

Problemi comuni e soluzioni

Problema 1: OOM (Out of Memory) con modelli 7B+ su CPU

Soluzione: usa quantization INT4 (obbligatorio); riduci batch size a 1; attiva mmap in Ollama. Se ancora insufficiente, usa distilled model (1.5B).

Problema 2: Accuracy cala troppo con INT4

Soluzione: verifica che il modello quantizzato sia GPTQ-trained (non solo convertito). Modelli dalle repo TheBloke (HuggingFace) sono affidabili. Altrimenti, quantizza tu su dataset specifico (AutoGPTQ library).

Problema 3: Latency inference Ollama è 10x peggio del cloud

Soluzione: aspettare è OK se è batch. Per online inference, aggiungi caching (Redis) e pre-computa embeddings. Oppure, migra a GPU locale (RTX 4070 ~€500, 200x più veloce che CPU).

Problema 4: Token distribution shift

Situazione: modello quantizzato perfetto su benchmark, ma output degrada su testi reali. Soluzione: calibra quantization scale su dataset in-domain (non solo benchmark). Usa calibration set di 100-500 sample reali.

Roadmap energetica 2027-2028

Previsioni tecnologia:

• Spec-Decoding (inizio 2027): produce più token per forward pass usando mini-model drafting. Riduzione latency 2-3x senza accuracy loss
• Mixture of Experts (MoE) inference: attiva solo subset di parametri. Modelli come Mixtral diventano standard; 5x risparmio energetico
• Hardware quantization-native (2027+): nuovi chip (es. SambaNova, Cerebras) con native INT4 compute. 10-100x più efficienti di GPU float32
• On-device LLM (edge): modelli distilled <1B su smartphone. Batteria per 10K token, zero latency, zero privacy risk

FAQ

1. Quantization causa output non-deterministico?

No. Quantization è deterministico (stessa input = stessa output). Però piccole variazioni numeriche possono amplificarsi su sequenze lunghe. Se serve riproducibilità assoluta, usa seed fixing + float32 computation path in parallelo (benchmarking only).

2. Posso quantizzare un modello custom fine-tuned?

Sì, ma richiede calibration. Usa AutoGPTQ con custom dataset (~100-500 sample della tua distribuzione). Risultato: INT4 con <1% accuracy loss.

3. Ollama è production-ready?

Per inference read-only, sì. Per sistemi che scrivono (es. RAG con update embedding real-time), è stabile ma giovane. Monitoraggio con rate limiting + circuit breaker (backend) consigliato.

4. Conviene sempre on-prem, o ci sono casi dove cloud è migliore?

Cloud è migliore se: (a) traffic burst non predicibile (scaling elastico), (b) modelli eterogenei (non vuoi gestire 20 container diversi), (c) compliance no-data-residency. Altrimenti on-prem vince su costo + latency + privacy.

5. Come monitorare energia reale durante inference?

Su Linux: `turbostat`, `powertop` (kernel profiling). Su HW specifico: PDU smart (smartctl). Metric integrata: Python `pyjoule` library traccia CPU time + memory bandwidth → stima joule. Benchmark cloud: usa loro cost model (AWS Pricing API).

Conclusione

Nel 2027, ottimizzare energia dell'AI non è una scelta etica—è una scelta economica. Quantization INT4, KV cache compression, e inferenza Ollama on-prem riducono footprint di 10-30x rispetto a cloud convenzionale, con investimento tecnico basso. Implementa a step: quantization GPTQ → on-prem Ollama → pruning fine-tuning se accuracy degrada. Il codice di questa guida scala da prototipo a produzione con poche modifiche.

Prossimo articolo della serie: "Sustainable AI" — Carbon accounting frameworks e green LLM training 2027.