I investigated the current state of manufacturing VSS seen at NVIDIA VSS 3.1.0 EA and Hannover Messe
This page has been translated by machine translation. View original
Introduction
Hello, I'm Morishige from Classmethod's Manufacturing Business Technology Department.
I published the following article in March 2026, and in the two months since then, quite a lot had been happening around VSS.
VSS 3.1.0 EA was released on March 25, the Warehouse Blueprint was also updated to 3.1.0 on April 30, and at Hannover Messe 2026 (April 20–24), there was a series of announcements of products incorporating VSS aimed at the manufacturing industry.
This article is a sequel to the previous one, and I first organized how VSS is beginning to be used on the manufacturing floor as seen at Hannover Messe, using four company case studies.
VSS 3.1.0 EA Release and Developments Since March
The 3.1.0 EA was announced on the NVIDIA Developer Forum.
The Warehouse Blueprint documentation has also been updated to 3.1.0 as of April 30. While GA has not yet been released, DGX Spark has been officially listed alongside AGX/IGX Thor in the "Validated Platforms."
| Date | Event |
|---|---|
| 2026-03-25 | VSS 3.1.0 EA released (Developer Forum) |
| 2026-03-16–19 | GTC 2026 (no mention of VSS in the keynote) |
| 2026-04-20–24 | Hannover Messe 2026 (VSS adoption for manufacturing surfaces at once) |
| 2026-04-30 | Warehouse Blueprint 3.1.0 documentation updated |
What's interesting is that the evolution on the software side (3.0 → 3.1) and the movement on the field side (emergence of case studies) happened at almost the same time. When I wrote the March article, VSS 3.0 EA was positioned as "architecturally impressive but still a struggling EA in practice," but looking back now in May, it's clear that manufacturing sites around the world are beginning to enter the implementation phase.
Let's now go through four company case studies in order. Based on NVIDIA's official blog and each company's official information, I've organized what can be seen regarding their connection to VSS.
Manufacturing VSS Case Study 1: Invisible AI Vision Execution System
This is the start of the case study section. Drawing on the blog post NVIDIA published to coincide with Hannover Messe 2026, supplemented by each company's official information, I'll go through four companies in order.
The first case study is Invisible AI's Vision Execution System. It is introduced in the above blog as a product that adopts the NVIDIA Metropolis VSS Blueprint and Cosmos Reason 2.
The concept of Invisible AI is simple: install lightweight cameras at each station on the manufacturing line, and have AI automatically convert "what happened" into structured data for each work cycle. The three steps of Capture, Structure, and Act are featured on the official website.
Lightweight cameras see every cycle on every line. No wearables, no operator disruption.
A notable feature is that it collects data without wearables and without disrupting workers' movements. Getting workers on a manufacturing line to wear sensors is difficult to agree upon with the shop floor, so a design that relies solely on the camera side lowers the barrier to adoption.
The companies listed as adopters on the official website are Mercedes-Benz, Ford, Toyota, BMW, General Motors, and Nissan — essentially all major players in the automotive industry. Toyota has offered the following comment:
Invisible AI has been a great partner for Toyota as we work toward building the manufacturing processes of the future.
The numbers are also specific: "10x faster than manual time studies," "3-5x ROI on each device," "Every minute of downtime we prevent saves us $1k," and "every workstation we can remove saves us $200k per year" — all linked directly to shop floor labor cost calculations.
The connection to VSS lies in the part where video is converted into "cycle-by-cycle structured data." The VLM (Cosmos Reason 2) reads the video and extracts events, and Behavior Analytics generates analytical events such as ROI, tripwire, and proximity violations — this corresponds to Invisible AI's Capture → Structure. Rather than having users interact with VSS directly, it's delivered wrapped in the Invisible AI platform.
Manufacturing VSS Case Study 2: Tulip Interfaces Factory Playback
Tulip Interfaces is a shop floor platform positioning itself as "Composable AI for Frontline Operations," and Factory Playback — announced at Hannover Messe 2026 — is a new feature combining the VSS Blueprint and Cosmos Reason 2. The idea is to overlay video and production data onto a single timeline that you can rewind and drill into.
Combine video and production data into a single timeline you can rewind, explore, and analyze.
NVIDIA's official blog describes it as "synchronize machine telemetry, operator workflows, quality events and video." By aligning machine telemetry, operator workflows, quality events, and video on the same timeline, users can verify "what happened when, and what the video showed at that moment" all in one go.
The case study introduced here is construction equipment manufacturer Terex.
estimated 3% increase in yield and 10% reduction in rework
The fact that these figures — a 3% yield improvement and 10% reduction in rework — are presented with the qualifier "estimated" reflects careful wording. Yield and rework have complex contributing factors, making it difficult to isolate the contribution of AI alone.
Incidentally, Tulip itself has many case studies that don't involve VSS: the official website states that TICO Tractors reduced inspection and rework time by 60%, and Sharp accelerated clinical trial packaging processing by 30%. It seems more accurate to read this as: a company with a substantial platform of its own is now adding a VSS layer on top of it.
Manufacturing VSS Case Study 3: Fogsphere Vision Agent Platform
The third company, Fogsphere, is a Computer Vision AI company based in London, UK. At Hannover Messe 2026, it announced a platform running NVIDIA Cosmos Reason 2 + Metropolis VSS Blueprint on ARM-based edge devices. Unlike the first two companies, which aggregate processing onto in-facility servers, Fogsphere strongly promotes a design that distributes AI at the edge, close to each CCTV camera.
Distribute AI at the 'Edges' of the city. Run AI over CCTV even with unstable 4g connections.
The claim that AI can run on CCTV even in unstable 4G environments suggests an intent to target deployment in demanding real-world conditions. The architecture processes data hierarchically in a three-tier Edge-to-Fog-to-Cloud structure.
The target industries span nine sectors: Retail / Chemical / Construction / Smart City / Logistic / Oil & Gas / Power Generation / Healthcare / Manufacturing. The Saipem case study announced at Hannover Messe sits closest to Oil & Gas among these, used to detect safety and environmental risk events from video.
detect and respond in real time to high-risk safety and environmental events
The ARM-based edge deployment angle seems well-suited to the Jetson Orin Nano Super line covered in the DGX Spark series. The fact that "VSS deployment on ARM edge" has appeared in the form of a commercial product feels like evidence that the ecosystem is maturing.
Manufacturing VSS Case Study 4: Pegatron PCB Assembly
The last case study goes back slightly in time — it's the example of Taiwanese electronics manufacturer Pegatron. Introduced in NVIDIA's official blog in May 2025 as a representative VSS Blueprint case study, it involves SOP (Standard Operating Procedure) analysis and employee training for PCB (printed circuit board) assembly processes.
the agents have reduced Pegatron's labor costs by 7% and defect rates by 67%
What stands out is the phrasing "the agents" for a 7% reduction in labor costs and a 67% reduction in defect rates. Rather than attributing the effects to VSS itself, the description shows the agents built on top of it generating results — suggesting a picture where VSS retreats to the background as "the foundation for reading video," while agents take on the role of making decisions.
How to interpret a 67% reduction in defect rates depends on the baseline. If defect rates were already high on that line, the reduction is enormous; if they were already low, the absolute value would be small. Since the source article doesn't include absolute values, it's safer to treat this as a reference figure.
The same blog also introduces Siemens' Industrial Copilot for Operations (30% productivity improvement) and Linker Vision in Kaohsiung, Taiwan (VSS adoption for smart city purposes), showing that VSS is expanding vertically beyond manufacturing into the public sector as well.
What Becomes Visible When Looking at All Four Companies
Looking at all four companies together, several common trends emerge.
First, VSS doesn't appear as a standalone product on the surface. Invisible AI, Tulip, and Fogsphere all use VSS internally within their own platforms as an "inlet for video understanding," while their public branding is built around their own product names. NVIDIA stays in the background as a reference architecture provider, while solution providers handle the part that interfaces with the field — a two-layer structure.
Second, Cosmos Reason 2 is becoming the de facto default VLM. As of VSS 3.0 EA in March, the options of Cosmos-Reason2-8B / Cosmos-Reason1-7B / Qwen3-VL were available, but all three companies that announced at Hannover Messe adopted Cosmos Reason 2. Even in VSS 3.1.0 where Qwen3-VL was added, the trend of Cosmos Reason 2 being the default recommendation seems likely to continue for a while.
However, there's a possibility of further movement from here. NVIDIA released Nemotron 3 Nano Omni (30B-A3B, supporting 4 modalities: text / image / audio / video) at the end of April 2026.
The latter directly compared three models including Cosmos Reason 2 on Heron-Bench and JMMMU, revealing that each model has clearly distinct areas of strength depending on the benchmark. A future where it joins the VSS VLM candidates doesn't seem far off. Furthermore, when the next generation after Cosmos Reason 2 (whatever it might be called) arrives, the default recommendation will likely be replaced at that point. Personally, I think how the VSS VLM lineup shifts over the next six months is the most interesting thing to watch.
Third, ARM-based edge deployment is proving to be a stronger need than expected. The Fogsphere example is emblematic, but manufacturing shop floors, CCTV networks, and nearby servers are not necessarily built on the assumption of x86 + dGPU. NVIDIA has been addressing this need with its ARM lineup — Jetson Thor, IGX Thor, and DGX Spark — and VSS Warehouse Blueprint 3.1.0 officially listing DGX Spark in Validated Platforms is part of that flow.
Finally, from the perspective of adoption in Japanese manufacturing, "building VSS from scratch" is still a heavy choice, leaving two options: adopting a VSS-embedded platform provided by overseas solution vendors like these, or custom implementation based on the VSS Blueprint. The former lets you move quickly but is weak on Japanese language support and process-specific needs, while the latter takes more effort but can be fitted to your own business operations — a trade-off. Efforts like the Japanese LLM substitution verification from a previous article represent one example of the latter approach.
Connection to DevelopersIO On-Site Reports
Alongside the four case studies, I'd also like to recommend reading the reports from Classmethod employees who covered Hannover Messe 2026 on-site. While there are no articles specifically discussing VSS itself, the content is directly connected to the movements of these four companies, reflecting a firsthand sense of the manufacturing AI landscape.
Hamada (Hamako)-san's AWS booth visit report (2026-04-28) summarizes the exhibit featuring Isaac Sim / Cosmos WFM / GR00T / Jetson Thor as "agents bundling things together from above while leaving existing systems on the floor intact." VSS didn't appear to be at the AWS booth, but the description that "the AWS × NVIDIA collaboration has become even more three-dimensional" overlaps with the VSS solution provider deployment picture seen in this article.
Another article covering the T-Systems × Siemens × NVIDIA initiative (2026-04-27) summarizes the Industrial AI Cloud context as moving "from isolated pilots to AI-driven, interconnected factories." VSS is one piece responsible for the video layer of the factory, and it only becomes a business once embedded within these layers of Sovereign AI, Industrial AI, and Physical AI. The fact that VSS is not a product that can be sold standalone is another point where this article's four case studies share a common picture.
Major Changes in 3.1.0
From here, we move to the verification section. Of the differences between 3.0.0 EA and 3.1.0 EA, I've picked out six changes that are meaningful from the perspective of running on DGX Spark. This is based on observations of the contents of the compose package downloaded from NGC.
Minimal Profile Now Enabled by Default
In my previous article, I wrote about how launching 3.0.0 EA resulted in 42 services running simultaneously, straining the DGX Spark's 128 GB UMA. In 3.1.0, the default in warehouse/.env is now MINIMAL_PROFILE="true".
MINIMAL_PROFILE="true" # Minimal profile
In this Minimal Profile, ELK (Elasticsearch + Kibana), Video Analytics API/UI, and the monitoring layer are excluded, bringing up only the minimum necessary services. The official announcement mentions deployment time of "under 5 minutes, 4x faster." This is a clear answer to what I described in the previous article as "cramming 42 services into one machine is heavy," making it more practical for use cases like just wanting to try Agentic Search, or just needing raw data from Behavior Analytics.
VLM-as-Verifier Elevated to Independent Service
In the previous article, I wrote about "patching four code bugs in Alert Bridge" as a point of struggle. In 3.1.0, the target of those fixes has been elevated to an independent service as vlm-as-verifier/compose.yml.
deployments/
├── vlm-as-verifier/
│ ├── README.md
│ ├── compose.yml
│ └── scripts/
└── warehouse/
├── vlm-as-verifier/ # warehouse-specific settings
└── ...
It's incorporated into the compose.yml include as a base service, and there is also a dedicated configuration directory warehouse/vlm-as-verifier/ on the Warehouse side. Whether the four patches I applied in the previous article are directly reflected would require actually running it on real hardware to verify precisely, but at the design level, the direction is toward "consolidating alert verification into a single service."
Perception Model + Data Directory Bundled in app-data
This is personally the most welcome change. As of March, even launching the Perception container resulted in an error: Cannot access ONNX file '/opt/storage/rtdetr_warehouse_v1.0.fp16.onnx', requiring a separate download of nvidia/tao/rtdetr_2d_warehouse from NGC and manual placement in $MDX_DATA_DIR/models/mtmc/.
In 3.1.0, downloading vss-warehouse-app-data:3.1.0 from NGC includes the following files from the start:
vss-warehouse-app-data/
├── models/
│ ├── mtmc/rtdetr_warehouse_v1.0.1.fp16.onnx
│ └── sparse4d/ov/sparse4d_warehouse_v2.1.onnx
├── data_log/
│ ├── elastic/
│ ├── kafka/
│ ├── redis/
│ └── vss_video_analytics_api/
└── videos/
├── nv-warehouse-4cams/
├── warehouse-4cams-20mx20m-synthetic/
└── warehouse-loading-dock-3cams-synthetic/
RT-DETR has been updated from v1.0 to v1.0.1, and Sparse4D has advanced from v2.0 to v2.1. Furthermore, the data directories that I used to create manually with mkdir -p data_log/{elastic,kafka,redis,...} are now all included. Since you just need to point MDX_DATA_DIR to this directory for startup to be ready, the friction of initial setup feels like it's been cut roughly in half.
DGX Spark-Specific hw env Partially Appears
In 3.0.0 EA, there was no hw-DGX-SPARK.env for NIM hardware environment files, requiring manual creation by adapting hw-DGX-THOR.env. Checking 3.1.0, the support status is as follows:
| NIM | DGX Spark hw env | Status |
|---|---|---|
cosmos-reason2-8b |
Present | Official support |
nvidia-nemotron-nano-9b-v2-fp8 |
Present | Official support (see below; uses vLLM) |
nvidia-nemotron-nano-9b-v2 (BF16) |
Absent | March struggle point continues |
cosmos-reason1-7b |
Absent | DGX Spark not supported |
nemotron-3-nano |
Absent | DGX Spark not supported |
qwen3-vl-8b-instruct |
Absent | H100 series only |
llama-3.3-nemotron-super-49b-v1.5 |
Absent | H100 series only |
gpt-oss-20b |
Absent | H100 series only |
With the combination of Cosmos Reason 2 8B (VLM) and Nemotron Nano 9B v2 FP8 (LLM), the struggle points from March have been addressed. On the other hand, BF16 Nemotron and larger models still cannot run on local NIM on DGX Spark. The following note remains in Known Limitations:
L4, RTX 6000 ADA, IGX-THOR and DGX-SPARK local NIMs are not supported
Rather than reading this as "DGX Spark now has full Local NIM support," it's more accurate to read it as "the specific combination of FP8 + Cosmos Reason 2 has been addressed." The "NGC vLLM alternative" approach adopted in the previous article remains a valid option.
FP8 LLM Internals Now Use Official vLLM Container
Looking inside the compose for Nemotron Nano 9B v2 FP8, which now has a DGX Spark hw env, reveals another interesting finding.
services:
nvidia-nemotron-nano-9b-v2-fp8:
image: nvcr.io/nvidia/vllm:25.12.post1-py3
command:
- python3
- -m
- vllm.entrypoints.openai.api_server
- --model
- nvidia/NVIDIA-Nemotron-Nano-9B-v2-FP8
Rather than a NIM container, it uses the vLLM container from NGC. The workaround I described in the previous article — "since LLM NIM returns exec format error on ARM64, substitute with NGC vLLM" — has essentially been elevated to the official approach. It's even been built out to the point of fetching nemotron_toolcall_parser_no_streaming.py from the Hugging Face nvidia/NVIDIA-Nemotron-Nano-9B-v2 repository for the tool calling parser and bundling it in.
The decision to prioritize quickly shipping something based on vLLM rather than fully preparing an ARM64 NIM is transparent. Personally, this change felt the most satisfying.
NIM Lineup Expanded
Finally, here is a list of NIM options added since 3.0.0 EA:
| LLM Option | DGX Spark env |
|---|---|
nvidia/nvidia-nemotron-nano-9b-v2 (existing) |
Absent |
nvidia/nvidia-nemotron-nano-9b-v2-fp8 (new) |
Present |
nvidia/nemotron-3-nano (new) |
Absent |
nvidia/llama-3.3-nemotron-super-49b-v1.5 (new) |
Absent |
openai/gpt-oss-20b (new) |
Absent |
| VLM Option | DGX Spark env |
|---|---|
nvidia/cosmos-reason2-8b (existing) |
Present |
nvidia/cosmos-reason1-7b (existing) |
Absent |
Qwen/Qwen3-VL-8B-Instruct (new) |
Absent |
If running on DGX Spark alone, the realistic choice is effectively Cosmos Reason 2 + Nemotron Nano FP8. However, switching to a Remote NIM configuration (LLM_MODE=remote to call build.nvidia.com) enables incorporating Llama 3.3 Nemotron Super 49B or gpt-oss-20b via the cloud. A hybrid configuration of "DGX Spark for front-end analysis, cloud NIM for heavier inference" is likely to become an option heading toward GA.
Summary
VSS 3.0.0 EA in March was in a state of "architecturally impressive, but running it on DGX Spark meant a continuous string of manual work." After following up with 3.1.0 EA in May, here are my impressions:
- Setup has visibly improved: Minimal Profile default, Perception models and sample videos bundled in app-data, no need to pre-create data directories
- The biggest change in the DGX Spark series context is official support for the Cosmos Reason 2 + Nemotron Nano FP8 combination: the
exec format errorstruggles from March can be avoided by taking this path - However, Local NIM for BF16 Nemotron and larger models remains unsupported, and Remote NIM or self-managed vLLM deployment is the realistic solution
- In terms of features, there's also a sense that the generation has advanced one step between EAs, including VLM-as-Verifier becoming an independent service, Agentic Search in Alpha, and Multi-turn Agent Conversation improvements
And what emerged from the case study section is the fact that VSS has begun to permeate the global manufacturing industry as "a video understanding engine embedded inside solution providers' platforms." All of Invisible AI, Tulip, Fogsphere, and Pegatron are running VSS behind their own products, with solution vendors holding the point of contact with the field. For adoption in Japanese manufacturing, the choice comes down to either adopting an embedded platform from such providers, or custom implementation tailored for in-house use. The Japanese LLM substitution tested in the previous article represents the latter approach. The practical route would be to substitute Nemotron 9B-v2-Japanese via vLLM into the DGX Spark + FP8 + Cosmos Reason 2 path that 3.1.0 has laid out.
Whether to wait for GA or not will depend on the use case. For safety monitoring or PoC-level use, 3.1.0 EA has already reached a sufficiently usable stage. On the other hand, for production use, the security immaturity of EA (no TLS, no authentication, no rate limiting) is a concern, so waiting for GA is also a reasonable call. Whether the four Alert Bridge patches from the March article have been absorbed by the VLM-as-Verifier independent service, and whether the Minimal Profile really launches in 5 minutes — I'd like to follow up on these on real hardware at another opportunity.
Reference Links
- VSS 3.1.0 EA Forum Announcement
- Warehouse Blueprint 3.1.0 Release Notes
- Warehouse Blueprint 3.1.0 Known Limitations
- Warehouse Blueprint 3.1.0 Prerequisites
- Warehouse Blueprint 3.1.0 Quickstart
- Hannover Messe 2026 Manufacturing AI Blog
- NVIDIA blog: VSS Blueprint (including Pegatron case study, 2025-05-18)
- Invisible AI Official
- Tulip Interfaces Official
- Fogsphere Official
- Previous article: Trying VSS 3.0.0 EA on DGX Spark
- Running Nemotron 3 Nano Omni on DGX Spark (4 modality launch bench)
- Comparing Nemotron 3 Nano Omni × Cosmos Reason 2 × Gemma 4 on Heron-Bench / JMMMU
