admin-mrrm/mrrmlabapp
1
0
Fork 0
Code Issues 15 Pull requests Projects Releases 40 Packages 5 Wiki Activity Actions
40 releases 47 tags
  • v0.6.6-rc13 336632c269

    v0.6.6-rc13
    All checks were successful
    continuous-integration/drone/push Build is passing
    Details
    continuous-integration/drone/tag Build is passing
    Details
    Stable

    admin-mrrm released this 2026-06-07 15:57:57 +02:00 | 115 commits to main since this release

    rc12-Gerätetest ist DER entscheidende Befund: die Debug-Bar zeigt 'embedder: loading tokenizer · [awaiting from_pretrained]' und kein einziges 'fetch#N ' folgt — AutoTokenizer.from_pretrained hängt SYNCHRON bevor der erste fetch-Call überhaupt rausgeht. Patchen am fetch-Layer hilft prinzipiell nicht; der Hang liegt vor der HTTP-Schicht (vermutlich in transformers' get_file_metadata / Cache-Lookup auf Hermes). Quellanalyse zeigt: from_pretrained ist nur ein Convenience-Wrapper, der die zwei JSONs lädt und sie an new PreTrainedTokenizer(tokenizerJSON, tokenizerConfig) weiterreicht. Die Dateien haben wir bereits seit rc8 lokal — rc13 überspringt from_pretrained komplett und ruft den Konstruktor direkt. Der ganze fetch-Interceptor wird obsolet und entfällt.

    Highlights

    • feat(embedding): PreTrainedTokenizer wird direkt mit den geparsten JSONs auf Disk konstruiert (#122) — AutoTokenizer.from_pretrained wird nie mehr aufgerufen. Bypass des Hangs auf Hermes.
    • remove(embedding): hf-fetch-interceptor-Modul + Spec entfernt — kein Code-Path mehr, der huggingface.co anspricht (Tokenizer-Konstruktor ist synchron, ONNX-Session lädt nur lokale Datei). Cleanup von ~150 LOC.
    • ensureModelFilesDownloaded() gibt jetzt {modelPath, tokenizerJsonPath, tokenizerConfigPath} zurück; initialize() liest beide JSONs und konstruiert den Tokenizer in einem Schritt.
    • Tests umgebaut: '@huggingface/transformers'-Mock liefert jetzt PreTrainedTokenizer als Konstruktor-Mock; AutoTokenizer-Spielereien fliegen raus.
    Downloads