LOOM
Quanto può diventare utilizzabile un modello locale di classe 30B su un Mac M1 con 8 GB se il runtime circostante, lo storage e il percorso di accesso agli esperti vengono progettati in modo aggressivo?
Uno studio del runtime di un modello locale di classe 30B su Apple Silicon M1 con 8 GB.
LOOM ha indagato se un lavoro aggressivo su runtime, storage e accesso agli expert potesse rendere praticamente utile un modello locale di classe 30B su hardware molto al di sotto del suo normale envelope di memoria. Il runtime mantenuto è diventato sensibilmente più veloce e utilizzabile. La ricerca è stata comunque chiusa perché il vincolo residuo era la capacità del modello, non il throughput.
Separare le prestazioni del runtime dalla capacità del modello.
Lo studio ha trattato serving, permanenza degli expert, accesso routed-expert, posizione dello storage, layout lossless della sidecar, quantizzazione, gestione del contesto e speculative decoding come variabili ingegneristiche circoscritte. I candidati venivano promossi solo preservando riferimenti comportamentali congelati; i risultati negativi sono stati conservati, non nascosti.
Una linea di ricerca a stadi con decisioni GO / NO_GO esplicite.
UNLOCKED UOPT-003 S40
Le misure confrontano il profilo S40 mantenuto con la baseline S32 quando è disponibile un confronto controllato. Descrivono questa configurazione di progetto, non una generalizzazione sui modelli 30B o su Apple Silicon.
- Decode
- 6.660 tok/s7.557 tok/s+13.46%
- Prefill a freddo · 1.155 token
- 11.306 tok/s
- TTFT a freddo · 1.155 token
- 161.676 s102.242 s−36.76%
- Expert hit rate
- 81.745%89.831%
- Expert misses
- 90,22950,260
I miglioramenti prestazionali venivano mantenuti solo con i controlli comportamentali intatti.
- 0 / 6
- Refusal gate
- 0 / 6
- Held-out degeneration gate
- 8 / 8
- Benign capability gate
Cosa hanno stabilito gli esperimenti.
I cambiamenti lossless del layout hanno avuto alta leva.
UOPT-002 ha ridotto l’I/O dei miss routed-expert tramite una sidecar expert-major preservando il contenuto matematico del modello.
La permanenza degli expert ha modificato materialmente il comportamento del runtime.
UOPT-003 S40 ha migliorato decode e cold start senza cambiare i pesi del modello ed è diventato il profilo finale mantenuto.
La quantizzazione expert a bit inferiori ha superato il confine di qualità.
UOPT-004 e UOPT-005 hanno ridotto il footprint ma fallito il riferimento aritmetico funzionale congelato; i candidati più piccoli ma degradati non sono stati promossi.
La posizione dello storage può dominare le prestazioni apparenti.
Un esperimento diagnostico ha isolato una sidecar su volume esterno come collo di bottiglia, escludendo modello e logica runtime come causa.
La speculazione draftless non si è attivata.
UOPT-006 ngram-simple e ngram-mod hanno prodotto 0 token drafted e 0 accepted senza raggiungere il gate immediato del 5% di miglioramento decode.
Il collo di bottiglia finale era la capacità.
Restavano possibili ulteriori idee di velocizzazione, ma non sono state perseguite perché non avrebbero spostato il limite di capacità pratica del modello mantenuto.
Un esperimento sullo storage ha cambiato le prestazioni apparenti di un ordine di grandezza.
Si tratta di un confronto diagnostico, non della baseline di progetto: spostare soltanto una sidecar temporanea da un volume archivio esterno allo storage interno ha isolato la posizione dello storage come causa delle prestazioni patologiche.
- Decode
- 0.69 tok/s→9.63 tok/s
- TTFT
- 148.277 s→5.605 s
Il bersaglio corretto dell’ottimizzazione era cambiato.
LOOM non si è concluso per un errore irrisolto del runtime. Alla chiusura, il lavoro sul runtime aveva avuto abbastanza successo da rendere ulteriore throughput un’ottimizzazione del vincolo sbagliato. Il modello 30B mantenuto non raggiungeva ancora la capacità pratica necessaria ai workload previsti.
Rivalutare il modello target prima di investire in ulteriori ottimizzazioni del runtime.
Un record di ricerca, non una repository di distribuzione del modello.
L’archivio pubblico conserva sorgente durevole, configurazioni, patch e documentazione sperimentale. Gli artefatti grandi o locali alla macchina sono intenzionalmente esclusi, così la repository registra la provenienza ingegneristica senza ridistribuire modelli o bundle di evidenze locali.
Apri archivio di ricerca ↗- Repository chiusa, archiviata e read-only per impostazione predefinita.
- GGUF del modello, sidecar degli expert, build runtime, cache ed evidenze benchmark locali restano fuori da Git.
- I record sperimentali storici preservano misure, note di rollback e provenienza implementativa.
- Un eventuale riavvio dovrebbe rivalutare prima il presupposto modello/hardware, invece di continuare automaticamente il vecchio frontier di ottimizzazione.