A leading intelligent-driving company stores billions of rows of labeled data across multiple clouds and data centers. The core problem was not a lack of model capability, but GPUs frequently waiting for data: Lance reduces how much data must be read, while JuiceFS accelerates access—but this combination is worth the investment only when both kinds of bottleneck are present.
What this is
Lance is an open-source columnar lakehouse format designed for multimodal AI. It organizes data by columns so workloads can read only the fields they need, while managing images, video, text, and vectors. JuiceFS is a distributed file system positioned between business applications and object storage. Through local caching, data prefetching, and a unified namespace, it delivers training data to compute nodes in time.
Put simply, Lance addresses “how much data do we need to read?” while JuiceFS addresses “how long do we have to wait to read it?” In the architecture of a leading autonomous-driving company, object storage holds the raw data, Lance organizes it and generates training manifests, and JuiceFS then prefetches the data listed in those manifests into the GPU nodes’ local chunk cache.
Industry view
We believe this reflects a shift in AI infrastructure competition from model parameter scale toward the efficiency of data delivery. As training datasets grow larger and more complex, read amplification and cross-cloud latency directly reduce the utilization of expensive GPUs. Connecting Lance and JuiceFS provides an engineering path that follows “filter first, then prefetch.”
But this combination is not a universal solution. Tasks such as offline retrieval and data annotation are not latency-sensitive, so the benefits of caching may be limited. The article cites a TOP20000 vector-search case involving 100 million rows: total execution time was about 20 seconds, with the primary bottleneck being CPU vector computation rather than network reads.
The risks are equally clear: the Lance–JuiceFS combination is still relatively new, with limited publicly documented production deployments. Adding a caching layer also introduces deployment, operations, and troubleshooting costs. If the real bottleneck lies in compute, models, or data quality, simply accelerating storage will only create more expensive waiting.
Impact on regular people
For enterprise IT: Multimodal training cannot be evaluated solely by the number of GPUs purchased. Whether data arrives on time is just as important in determining project cost. Technical teams need to measure unnecessary reads, network latency, and GPU idle time separately before deciding whether to add a caching layer.
For individual careers: Roles in data engineering, platform engineering, and AI infrastructure are moving closer to the model-training workflow. Professionals who can connect storage, data organization, and compute scheduling are expanding their responsibilities from “maintaining systems” to “ensuring training efficiency.”
For consumer markets: Behind autonomous driving, video generation, and smart devices, data-pipeline efficiency will indirectly affect iteration speed and cost. In the near term, this looks more like a change to industrial infrastructure than a new consumer feature.