LeRobot trainiert jetzt direkt mit Lance-Daten aus dem Objektspeicher

LeRobot kann jetzt Lance-Datensätze nativ lesen und holt Frames direkt aus dem Objektspeicher, mit echtem globalem Shuffle und ohne Download. Laut LanceDB war das Training auf dem vollständigen DROID-Datensatz in 1:27 Stunden abgeschlossen, der Standard-Reader mit lokaler NVMe-Kopie brauchte 2:00 Stunden.
- LeRobot liest Lance-Datensätze jetzt nativ aus dem Objektspeicher, mit echtem globalem Shuffle und ohne Download.
- Auf DROID (27,6 Mio. Frames, 369 GB) dauerten 10.000 SmolVLA-Schritte auf 8 H100-GPUs 1:27 statt 2:00 Stunden, die GPU-Wartezeit lag bei 1,7 % statt 37,4 %.
- Five-Bit-RaBitQ erreichte bei 10 Mio. Vektoren mit 768 Dimensionen 96,2 % Recall bei 1.614 QPS, die verteilte Suche bei 10 Mrd. Vektoren hielt einen p50 von 18,05 ms.
- Lance v12.0.0 und LanceDB v0.39.0 erscheinen mit Breaking Changes in der API.
- LanceDB Enterprise ergänzt Secrets für Functions, SQL-Vektor-Deduplizierung sowie Pausieren und Fortsetzen von Jobs.
LeRobot-Training ohne lokale Kopie
Der Newsletter von LanceDB, veröffentlicht am 8. Oktober 2026, beginnt mit einem Ergebnis aus dem Robotertraining. LeRobot liest Lance-Datensätze jetzt nativ, sodass das Training Frames direkt aus dem Objektspeicher streamt, statt zuvor einen Download zu verlangen. Das Unternehmen gibt an, dass die Lösung einen echten globalen Shuffle bietet.
Der Test nutzte den gesamten DROID-Datensatz mit 27,6 Mio. Frames und 369 GB. 10.000 SmolVLA-Schritte auf 8 H100-GPUs dauerten mit Lance 1:27 Stunden, mit dem Standard-Reader auf einer lokalen NVMe-Kopie 2:00 Stunden. LanceDB berichtet in beiden Läufen von identischem Loss. Die GPUs warteten mit Lance in 1,7 % der Zeit auf Daten, beim Standard-Reader waren es 37,4 %.
Flottendaten durchsuchen und Vektorsuche skalieren
Ein zweiter Beitrag von Lei Xu befasst sich mit dem Data-Mining-Problem in der Physical AI. Seltene Fehlerfälle liegen im Long Tail der Flottenlogs, und das Signal, mit dem sie sich finden lassen, ist selten als Spalte gespeichert. Die Anleitung arbeitet mit einer einzelnen LanceDB-Tabelle: Sie leitet aus Gierrate und Geschwindigkeit ein is_left_turn-Flag ab, zählt mit einem Faster-R-CNN-Detektor die Fußgänger pro Clip und führt dann eine Vektorsuche über Clip-Embeddings aus, gefiltert nach Stadt, Uhrzeit, Abbiegevorgang und Fußgängerzahl.
Der dritte Schwerpunktbeitrag behandelt das Wachstum der Vektorsuche von 10 Millionen auf 10 Milliarden Vektoren. Laut LanceDB erreichte Five-Bit-RaBitQ bei 10 Mio. Vektoren mit 768 Dimensionen 96,2 % Recall bei 1.614 QPS, PQ384 kam auf 91,5 % bei 1.047 QPS. Bei 10 Mrd. Vektoren hielt die verteilte Suche einen p50 von 18,05 ms und erreichte bei 256 gleichzeitigen Anfragen 1.066 QPS.
Das Unternehmen gibt außerdem an, dass eine Ein-Bit-Distanzschranke über 99 % der Kandidaten aussortiert, bevor die vollständige Bewertung erfolgt. Der Wechsel von „fast“ auf „normal“ zur Abfragezeit hebt den Recall von 75,0 % auf 93,1 %, ganz ohne Neuaufbau des Index.
Enterprise-Updates und Open-Source-Releases
Der Newsletter nennt mehrere Performance-Änderungen in LanceDB Enterprise:
- Indexing-Worker laden standardmäßig bis zu 512 MiB an Shuffle-Offsets vor. Bei einem Shuffle-Replay mit 1 Mrd. Zeilen und IVF_RQ sank die Merge-Zeit von 61 auf 13,4 Minuten und der Spitzenspeicherbedarf von 14,2 GiB auf 9,6 GiB.
- Der Kaltstart der Function-Worker wurde verbessert: Das Aktualisieren einer Spalte mit 10.000 Zeilen mit einem 3,0 GB großen Torch-+-CUDA-Image sank bei leerem Cache auf ext4 von 409 s auf 54 s.
- Eine NumPy-Multiplikation über eine nullable float64-Spalte lief in Python-UDFs bei 1.048.576 Zeilen pro Batch 1,61-mal schneller.
- Die Tabellenerkennung in großen Datenbanken listet jeden Namespace nun einmal pro Durchlauf auf, statt einmal pro Seite mit 1.000 Tabellen.
Zu den neuen Funktionen zählen Secrets für Functions, native Vektor-Deduplizierung in SQL über vector_dedup und vector_duplicate_pairs, gruppierte Materialized Views, die Befehle PAUSE JOB und RESUME JOB sowie SQL-DML mit Primärschlüssel auf WAL-gestützten Tabellen.
Auf der Open-Source-Seite enthalten Lance v12.0.0 und LanceDB v0.39.0 jeweils Breaking Changes. In Lance akzeptiert das Namespace-merge_insert eine Liste von Schlüsselspalten für Upserts mit zusammengesetzten Schlüsseln, und json_extract-Prädikate werden nicht mehr an JSON-Indizes weitergeleitet. In LanceDB werden get_job und job_history durch open_job, describe_job und query_job_events ersetzt. Lance nennt zudem Verbesserungen bei IVF-Indizes und der Volltextsuche sowie Fragment-Reuse-Indizes, die 10, 2200× schneller öffnen.
Vorträge, Veranstaltungen und Community
Auf dem Ray Summit 2026 stellten Lei Xu und Hubert Yuan von Exa exa-d vor, Exas auf Lance und Ray Data aufbauendes Framework, mit dem sich Embeddings, extrahierte Texte und Suchsignale über Hunderte Milliarden Webseiten hinweg neu verarbeiten lassen. Eine Aufzeichnung ist verfügbar. LanceDB veröffentlichte außerdem einen Benchmark mit 19 Reranker-Konfigurationen auf fünf Datensätzen.
Zu den kommenden Auftritten zählen der Open Intelligence Summit am 12. und 13. Oktober 2026, Long Horizon am 20. und 21. Oktober 2026 sowie Reverie am 5. November 2026, alle in San Francisco. Der Newsletter dankt Beitragenden von Bytedance, Baidu, Adobe, Huawei, Tencent, DeepL und LumaLabs.
Was das bedeutet
Für Teams, die Roboter-Policies trainieren, deutet das von LanceDB berichtete DROID-Ergebnis darauf hin, dass sich mit Streaming aus dem Objektspeicher das Niveau einer lokalen Kopie erreichen oder übertreffen lässt, während die GPUs deutlich besser ausgelastet sind. Die Beiträge zu Vektorsuche und Data Mining zeigen, dass dieselbe Datenschicht für Kuratierung und Retrieval in größerem Maßstab genutzt werden kann. Die Zahlen stammen aus eigenen Tests des Unternehmens.


