I investigated the current state of manufacturing VSS as 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, but in the two months since then, there has been a lot of movement around VSS.
VSS 3.1.0 EA was released on March 25, and the Warehouse Blueprint was also updated to 3.1.0 as of April 30. Furthermore, at Hannover Messe 2026 (April 20–24), there was a succession of product announcements incorporating VSS for the manufacturing industry.
In this article, which serves as a sequel to the previous one, I first organized how VSS is beginning to be used on manufacturing floors as seen at Hannover Messe, using four company case studies.
VSS 3.1.0 EA Release and Movements 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 the 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 keynote) |
| 2026-04-20–24 | Hannover Messe 2026 (VSS adoption in manufacturing suddenly surfaces) |
| 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 ground (emergence of case studies) are happening at almost the same time. When I wrote the March article, VSS 3.0 EA was positioned as "architecturally flashy but still a painful EA to work with hands-on," but looking back now in May, it's clear that manufacturing sites around the world have started entering the implementation phase.
Let's now go through the four company case studies one by one. I've organized what can be seen of their involvement with VSS, based on the NVIDIA official blog and each company's official information.
Manufacturing VSS Case Study 1: Invisible AI Vision Execution System
From here on is the case study section. Based primarily on a blog post NVIDIA published in conjunction 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 NVIDIA Metropolis VSS Blueprint and Cosmos Reason 2.
The concept behind 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. Three steps are stated on their official site: Capture, Structure, and Act.
Lightweight cameras see every cycle on every line. No wearables, no operator disruption.
A key feature is that data is collected without wearables and without disrupting workers' movements. Getting workers on a manufacturing line to wear sensors is difficult to negotiate with the floor, so a design that is fully self-contained on the camera side works to lower the barrier to adoption.
The companies listed as customers on their official site are Mercedes-Benz, Ford, Toyota, BMW, General Motors, and Nissan — essentially all the major players in the automotive industry. Toyota has provided 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, appealing to effectiveness in a way that directly connects to floor-level labor hour calculations: "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."
The connection to VSS is in the part that converts video into "cycle-level structured data." The VLM (Cosmos Reason 2) reads the video and extracts events, and Behavior Analytics generates analysis events such as ROI, tripwire, and proximity violation — this corresponds to Invisible AI's Capture → Structure. Rather than exposing VSS itself directly, it is wrapped in the Invisible AI platform for delivery.
Manufacturing VSS Case Study 2: Tulip Interfaces Factory Playback
Tulip Interfaces is a frontline operations platform under the banner of "Composable AI for Frontline Operations," and Factory Playback, announced at Hannover Messe 2026, is a new feature combining VSS Blueprint and Cosmos Reason 2. The idea is to overlay video and production data onto a single timeline that can be rewound and drilled into.
Combine video and production data into a single timeline you can rewind, explore, and analyze.
The NVIDIA 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, it enables an end-to-end view of "what happened when, and here's what the video shows at that moment."
The featured adoption case is construction equipment manufacturer Terex.
estimated 3% increase in yield and 10% reduction in rework
The way they present the figures of 3% yield improvement and 10% rework reduction with "estimated" attached is careful wording. Yield and rework have complex contributing factors, and isolating the AI's contribution alone is difficult.
Incidentally, Tulip itself has plenty of case studies that don't involve VSS: a 60% reduction in inspection and rework time at TICO Tractors, and 30% faster clinical trial packaging processing at Sharp, according to their official site. It's probably most accurate to read this as: a company with a substantial platform in its own right has now added 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 firm based in London, UK. At Hannover Messe 2026, they announced a platform running NVIDIA Cosmos Reason 2 + Metropolis VSS Blueprint on ARM-based edges. Unlike the previous two companies, which aggregate processing on in-facility servers, Fogsphere strongly emphasizes a design that distributes AI at edges near CCTVs.
Distribute AI at the 'Edges' of the city. Run AI over CCTV even with unstable 4g connections.
The claim that AI can be run over CCTV even in unstable 4G environments hints at targeting deployment in demanding field conditions. The configuration processes data hierarchically through a three-tier Edge-to-Fog-to-Cloud architecture.
The target industries span nine sectors: Retail / Chemical / Construction / Smart City / Logistic / Oil & Gas / Power Generation / Healthcare / Manufacturing. The Saipem adoption case announced at Hannover Messe sits close to Oil & Gas within this list, used for detecting 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 also seems like a good fit with the Jetson Orin Nano Super line covered in the DGX Spark series. The fact that "VSS deployment on ARM edge" has emerged in the form of a commercial product feels like evidence that the ecosystem has matured.
Manufacturing VSS Case Study 4: Pegatron PCB Assembly
The last case goes slightly back in time, to Taiwanese electronics manufacturer Pegatron. Introduced in an NVIDIA official blog post from May 2025 as a flagship VSS Blueprint case study, it is used for SOP (Standard Operating Procedure) analysis and employee training in 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 use of the phrase "the agents" to describe a 7% reduction in labor costs and a 67% reduction in defect rates. The phrasing attributes the effects not to VSS itself but to agents built on top of it, revealing a structure where VSS acts as a behind-the-scenes "foundation for reading video" while agents take on the decision-making role.
A 67% reduction in defect rates can be interpreted differently depending on the baseline. If the original defect rate was high, this is an order-of-magnitude improvement; if it was already low, the absolute value is small. Since the source article doesn't provide absolute values, it's safest to treat this as a reference figure.
The same blog also covers Siemens' Industrial Copilot for Operations (30% productivity improvement) and Linker Vision in Kaohsiung, Taiwan (VSS adoption for smart city use), showing that VSS is spreading horizontally across not just manufacturing but also the public sector.
What Becomes Visible When Looking at All Four Companies
Looking at the four companies side by side, several common trends emerge.
First, VSS does not surface as a standalone product. Invisible AI, Tulip, and Fogsphere all use VSS internally within their own platforms as a "plug-in point for video understanding," while their external branding is built around proprietary product names. NVIDIA stays behind the scenes as a reference architecture provider, while solution providers handle the part that interfaces with the field — a two-tier structure.
Second, Cosmos Reason 2 is becoming virtually the default VLM. While VSS 3.0 EA had offered a choice of Cosmos-Reason2-8B / Cosmos-Reason1-7B / Qwen3-VL, all three companies that announced at Hannover Messe adopted Cosmos Reason 2. Although Qwen3-VL was added in VSS 3.1.0 as well, 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 article directly compared 3 models including Cosmos Reason 2 on Heron-Bench and JMMMU, revealing that each model has clearly different areas of strength depending on the benchmark. A future where it joins the VSS VLM candidates doesn't seem far off. Furthermore, if the next generation of Cosmos Reason 2 (whether or not it's called Cosmos Reason 3) comes out, the default recommendation should change at that point. Personally, I think how the VSS VLM lineup shifts in six months is the most exciting thing to watch.
Third, ARM-based edge deployment has turned out to be an even stronger need than expected. The Fogsphere example is emblematic, but manufacturing floors, CCTV networks, and servers near work sites are not necessarily built on an x86 + dGPU premise. NVIDIA has been addressing this need with ARM-based lineups like Jetson Thor, IGX Thor, and DGX Spark, and the VSS Warehouse Blueprint 3.1.0 officially listing DGX Spark in Validated Platforms is part of that trend.
Finally, from the perspective of introducing this into Japanese manufacturing, "building VSS from scratch" is still a heavy choice. The alternatives are: adopting VSS-embedded platforms provided by overseas solution vendors like those described here, or implementing a custom solution based on the VSS Blueprint. The former lets you move quickly but is weak on Japanese language support and process specifics, while the latter takes more effort but can be tailored to your own operations — a trade-off. I think the kind of approach tried in a previous verification article — swapping in a Japanese LLM — is one example of the latter option.
Connecting with DevelopersIO On-Site Reports
Alongside the four case studies, I'd like to point to reports from Classmethod staff who covered Hannover Messe 2026 on-site. While there are no articles specifically discussing VSS itself, the content is continuous with the movements of the four companies here, in the sense of capturing the pulse of the AI manufacturing trend firsthand.
Hamada (Hamako-san)'s AWS booth visit report (2026-04-28) summarizes the exhibition featuring Isaac Sim / Cosmos WFM / GR00T / Jetson Thor as "agents bundling legacy floor systems from above." While VSS apparently wasn't featured at the AWS booth, the note that "the AWS × NVIDIA collaboration is becoming more three-dimensional" overlaps with the VSS solution-provider deployment perspective seen in this article.
Another article covering the T-Systems × Siemens × NVIDIA initiative (2026-04-27) summarizes the Industrial AI Cloud context as "from isolated pilots to AI-driven, interconnected factories." VSS is one piece handling the video layer of the factory, and it's only by being embedded in these layers of Sovereign AI, Industrial AI, and Physical AI that it can start running as a business. The fact that VSS is not a product that sells on its own is a structure shared with the four case studies in this article.
What Changed Significantly in 3.1.0
From here is the verification section. Of the differences between 3.0.0 EA and 3.1.0 EA, I've picked up six changes that are meaningful from the perspective of running things 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 the previous article I wrote about how launching 3.0.0 EA would crowd 42 services onto the DGX Spark's 128 GB UMA. In 3.1.0, the default in warehouse/.env has been changed to MINIMAL_PROFILE="true".
MINIMAL_PROFILE="true" # Minimal profile
This Minimal Profile excludes ELK (Elasticsearch + Kibana), Video Analytics API/UI, and monitoring layers, bringing up only the minimum necessary services, so deployment time is mentioned in the official announcement as "within 5 minutes, 4x faster." This is a clear answer to what I described in the previous article as "cramming 42 services onto a single machine and having it be heavy," and it improves usability for cases like just wanting to try out Agentic Search or only needing the raw data from Behavior Analytics.
VLM-as-Verifier Promoted to Independent Service
In the previous article I wrote about "patching 4 code bugs in Alert Bridge" as a pain point — but in 3.1.0, what that targeted has been promoted 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 is incorporated as a base service in the compose.yml include, and there is now a dedicated settings directory warehouse/vlm-as-verifier/ on the Warehouse side as well. Without actually running the contents on real hardware, I can't say strictly whether the 4 patches I applied in the previous article are reflected directly, but at the design level, it's moving in the direction of "consolidating alert verification into a single service."
Perception Models + Data Directory Now Bundled in app-data
This is personally the most welcome change. As of March, even after starting the Perception container, it would error with Cannot access ONNX file '/opt/storage/rtdetr_warehouse_v1.0.fp16.onnx', requiring a separate download of NGC nvidia/tao/rtdetr_2d_warehouse 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 was manually creating with mkdir -p data_log/{elastic,kafka,redis,...} in the previous article are now included together. Since you just need to point MDX_DATA_DIR to this directory to be ready for startup, the friction of the initial setup feels about half of what it was.
DGX Spark-Specific hw env Partially Appears
In 3.0.0 EA, a hw environment file hw-DGX-SPARK.env for NIM was not provided, requiring manual creation by adapting hw-DGX-THOR.env. After checking 3.1.0, the status is as follows:
| NIM | DGX Spark hw env | Status |
|---|---|---|
cosmos-reason2-8b |
Available | Officially supported |
nvidia-nemotron-nano-9b-v2-fp8 |
Available | Officially supported (see below, uses vLLM) |
nvidia-nemotron-nano-9b-v2 (BF16) |
Not available | March pain point continues |
cosmos-reason1-7b |
Not available | Not supported on DGX Spark |
nemotron-3-nano |
Not available | Not supported on DGX Spark |
qwen3-vl-8b-instruct |
Not available | H100 series only |
llama-3.3-nemotron-super-49b-v1.5 |
Not available | H100 series only |
gpt-oss-20b |
Not available | H100 series only |
If using the combination of Cosmos Reason 2 8B (VLM) and Nemotron Nano 9B v2 FP8 (LLM), the March pain points have been addressed. On the other hand, BF16 Nemotron and large models still cannot run on local NIM on DGX Spark. The Known Limitations still contains the following note:
L4, RTX 6000 ADA, IGX-THOR and DGX-SPARK local NIMs are not supported
It's not accurate to read this as "DGX Spark now fully supports Local NIM" — rather, "the specific combination of FP8 + Cosmos Reason 2 has been addressed" is the correct interpretation. The "substitute with NGC vLLM" approach I adopted in the previous article remains a valid option.
FP8 LLM Internals Now Use Official vLLM Container
Taking a look at 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
It's using the NGC vLLM container rather than a NIM container. The workaround I wrote about in the previous article — "since LLM NIM returns exec format error on ARM64, substitute with NGC vLLM" — has essentially been promoted to the official approach. The implementation is polished to the point of fetching nemotron_toolcall_parser_no_streaming.py from the Hugging Face nvidia/NVIDIA-Nemotron-Nano-9B-v2 repository and bundling it for tool calling parsing.
The thinking behind this — prioritizing quickly delivering something based on vLLM rather than fully building out ARM64 NIM — is transparent. Personally, this change felt the most satisfying.
NIM Lineup Expanded
Finally, here's a rundown of the NIM options added since 3.0.0 EA:
| LLM Option | DGX Spark env |
|---|---|
nvidia/nvidia-nemotron-nano-9b-v2 (existing) |
Not available |
nvidia/nvidia-nemotron-nano-9b-v2-fp8 (new) |
Available |
nvidia/nemotron-3-nano (new) |
Not available |
nvidia/llama-3.3-nemotron-super-49b-v1.5 (new) |
Not available |
openai/gpt-oss-20b (new) |
Not available |
| VLM Option | DGX Spark env |
|---|---|
nvidia/cosmos-reason2-8b (existing) |
Available |
nvidia/cosmos-reason1-7b (existing) |
Not available |
Qwen/Qwen3-VL-8B-Instruct (new) |
Not available |
If running on DGX Spark alone, the realistic options are effectively Cosmos Reason 2 + Nemotron Nano FP8. However, switching to a Remote NIM configuration (LLM_MODE=remote calling build.nvidia.com) makes it possible to incorporate 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" looks likely to become an option heading toward GA.
Summary
VSS 3.0.0 EA as of March was a state of "architecturally flashy, but a continuous stream of manual work to get running on DGX Spark." After catching up with 3.1.0 EA in May, here's my impression:
- Setup has visibly improved: Minimal Profile is now the default, Perception models and sample videos are bundled in app-data, and manually pre-creating data directories is no longer necessary
- The biggest change in the DGX Spark series context is official support for the Cosmos Reason 2 + Nemotron Nano FP8 combination: the
exec format errorpain point from March can be avoided by taking this path - However, Local NIM for BF16 Nemotron and large models remains unsupported, and Remote NIM or self-operated vLLM remains the practical solution
- In terms of functionality as well — independent service for VLM-as-Verifier, Agentic Search in Alpha, Multi-turn Agent Conversation improvements — there's a sense that even between EAs, a generation has passed
And what emerged from the case study section is the fact that VSS is beginning to permeate manufacturing sites around the world as "a video understanding engine embedded inside solution providers' platforms." All of Invisible AI, Tulip, Fogsphere, and Pegatron are running VSS behind the scenes of their own products, with the solution vendors holding the interface with the field. For Japanese manufacturers looking to adopt this, the choice comes down to either adopting these embedded platforms or implementing a custom solution based on VSS Blueprint. The former allows quicker movement but is weak on Japanese language support and process specifics; the latter takes more effort but can be tailored to your own operations. The approach of swapping in a Japanese LLM tried in the previous article represents the latter approach. Replacing with Nemotron 9B-v2-Japanese via vLLM on the path of DGX Spark + FP8 + Cosmos Reason 2 that 3.1.0 has shown seems like a realistic route.
Whether to wait for GA depends on the use case. For safety monitoring or PoC-level work, 3.1.0 EA has already reached a sufficiently usable stage. On the other hand, for production operations, the security immaturity of EA (no TLS, no authentication, no rate limiting) is a concern, so waiting for GA is also a valid decision. Whether the 4 Alert Bridge patches I struggled with in the March article have been absorbed through the independent service split of VLM-as-Verifier, and whether Minimal Profile really starts up in 5 minutes — these are things I'd like to follow up on with 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
