Uno sviluppatore che firma CodeMichaelD su Reddit ha condensato in poche righe l'illusione e la resa di un progetto fai-da-te: costruire il proprio motore di inference per LLM direttamente nel browser. Il tono è didascalico: «vibecoding your own inference engine is easy, they said» – dicono che sia facile fare vibecoding di un motore di inference. Poi l'ammissione: meglio clonare llama.cpp. In mezzo c'è un dettaglio tecnico che spiega perché.

Il tentativo descritto prevedeva l'esecuzione di un modello GGUF in quantization Q4, paginato dentro compute buffer embedded via WebGL2 e GLSL, tutto dentro HTML. La parte tokenizer e vocabolario viene definita parte di un «endless debug hell». Non è una lamentela generica: è il punto in cui i progetti di inference locale si scontrano con la realtà.

La tokenizzazione non è un semplice dizionario da parola a numero. Comprende regole di normalizzazione, gestione dei token speciali, padding, attenzione ai byte-level BPE e ai pezzi di vocabolario che cambiano a seconda del modello. Nella pipeline di inference, un errore di tokenizzazione produce output incoerenti o crash difficili da isolare, perché l'errore si manifesta a valle, nel calcolo tensoriale, ma la causa è a monte. Chi parte dal vibecoding tende a concentrarsi sulla parte visibile – caricare il modello, moltiplicare matrici – e scopre tardi che il collante linguistico è la parte più ostica.

L'indicazione di clonare llama.cpp non è un semplice consiglio da forum. Segnala che nell'ecosistema locale e self-hosted esiste già un runtime maturo, capace di gestire più backend GPU, formati GGUF, quantization e una tokenizzazione collaudata. Per chi valuta deployment on-premise o edge di LLM, la domanda non è se scrivere un motore da zero, ma se il differenziale competitivo stia nell'engine o nell'integrazione con i propri dati e processi. AI-RADAR offre framework analitici su /llm-onpremise per valutare questi trade-off, senza suggerire una scelta unica.

Il fatto che qualcuno tenti di far girare un LLM dentro una pagina HTML con WebGL2 rivela una pressione reale: eseguire modelli localmente, senza server, con latenza minima e dati che non lasciano il dispositivo. Ma WebGL2, pur supportando compute shader, non è nato per l'inference: i limiti nei buffer, nella gestione della memoria e nel debugging sono noti a chi sviluppa applicazioni grafiche complesse. L'arrivo di WebGPU sposta il baricentro, ma la lezione resta: il runtime non è solo algebra lineare.

Alla fine, chi ha scritto il post non ha fallito per incapacità. Ha fallito perché il problema era più grande di quanto il vibecoding lasciasse intendere. La prossima volta, forse, basterà clonare un repository e concentrarsi su ciò che rende diversa la propria applicazione. Oppure no: il fascino di costruire da zero resta, ma ha un costo in ore di debug che il post racconta con onestà.