A Factory Veteran’s AI Ascent
Cao Dongdong spent 15 years working with industrial products in factories. He was not an algorithm engineer and had no professional software development background. After teaching himself large language models, Python, and local inference, he built the “Union·You | CNC Non-Standard Smart Manufacturing Alchemist Quoting System” and won the Professional Group OPC one-person company track at the AMD Ryzen AI Agent Application Innovation Competition.
The system is not designed to let an LLM “guess a price.” Its purpose is to turn CNC non-standard machining knowledge—scattered across drawings, Excel sheets, and veteran workers’ experience—into an executable, inspectable, and editable local workflow. Because it reads sensitive customer drawings, process parameters, historical quotes, and factory cost data, local deployment and offline operation are central to the product direction.
Key facts at a glance:
- Current version: 12th iteration
- Runtime platform: a local device powered by AMD Ryzen AI Max+ 395
- Main inference model: roughly 35B-parameter dense model, rather than a 7B small model or a 70B/MoE model
- Memory configuration: up to 128GB LPDDR5x unified memory
- Inference speed: about 20–30 tokens per second for the 35B model in this project
- Seed testing: as of the interview, the product was being tested in 3 factories
Model Boundaries: Choosing Logic, Not Doing Mental Math
The first prototype was intentionally simple. It parsed STEP-format 3D drawings, extracted geometric features such as dimensions, holes, basic surfaces, and thin walls, let a local model judge possible manufacturing processes, and then called Python formulas to calculate material, machining time, and surface-treatment costs.
From the beginning, Cao set a clear boundary: the LLM should not directly calculate the final price.
His view is that LLMs are better suited to process exploration—such as suggesting machining routes, tools, and materials—while material usage, machining time, and cost aggregation should be handled by deterministic programs. As he put it, “Asking an LLM to do arithmetic in its head is not accurate.”
The system therefore first extracts structured data from drawings, then lets the model select or generate calculation logic, and finally uses Python to execute the formulas. The model “chooses”; the program “calculates.” This is also the system’s main way to control hallucinations.
If a model directly generates a quote from a drawing, the number may look plausible, but it is hard to trace where the dimensions came from, how machining time was derived, or why a certain scrap rate was used. Cao therefore tries to make the calculation process as white-box as possible: engineers can see which features were detected, which process was selected, and which formulas were applied, and they can adjust parameters in the middle.
“You can’t just tell me one plus one equals two,” he said. “You have to show me why it equals two.”
Multi-Agent as Digitized Workflow, Not Architecture Theater
After the initial three-step loop worked, the system was split into multiple agent modules, including drawing parsing, DFM analysis, process evaluation, quality inspection, finance, and risk control. Each module handles a relatively clear task. One stage outputs structured results, then passes them to the next.
The architecture may look like the multi-agent collaboration common in today’s LLM industry, but in essence it is a digital reconstruction of the factory quoting workflow. Manual quoting is already sequential: understand the drawing, determine process and equipment, then estimate machining time, materials, and profit. The system does not invent a new method from scratch; it decomposes the old workflow and assigns parts of it to models and programs.
As the number of agents grew, resource scheduling became a problem. If drawing analysis, process judgment, finance, and risk-control agents all ran at the same time, they competed for memory and compute. If everything ran serially, waiting time increased. Growing context could also cause the model to forget earlier information or call the wrong tool in a long chain.
Cao eventually adopted a compromise: some tasks run in parallel, but results return in order. Agents pass structured fields rather than long natural-language passages to reduce context length and token consumption. Not every step needs an LLM: STEP parsing, CAD library calls, and Python cost calculations mainly run on the CPU; small knowledge-base retrieval can also run on the CPU; the local model on the GPU is used only when complex process reasoning or tool use is needed.
On efficiency, the original report notes that manual quoting for a complex drawing can take two to three hours, while in the team’s testing a simple part can be analyzed in about 3 minutes. These are not identical scenarios, but they still show that the value is not merely in a larger model. It lies in decomposing quoting into a stable, reusable computational pipeline.
| Selection Criterion | AMD Ryzen AI Max+ 395 Advantage | Limitation of a Typical CPU + Discrete GPU Setup |
|---|---|---|
| Memory architecture | Up to 128GB unified memory shared by CPU and GPU | System memory and VRAM are separate; overflow requires data movement or model quantization |
| Model capacity | Can fit a roughly 35B dense model while leaving room for knowledge base, context, and system overhead | Large-model inference is often constrained by VRAM capacity |
| Software ecosystem | Local models can run through ROCm, PyTorch, llama.cpp, and related tools | CUDA workflows cannot be reused directly and require AMD-supported backends |
| Industrial workflow | Can support drawing parsing, CAD processing, rendering, and local inference on one platform | Often requires more separate components or servers |
From Demo to Product: Operating Systems and Factory Doors
Cao eventually used a device powered by AMD Ryzen AI Max+ 395. The platform integrates CPU, GPU, and NPU. According to AMD, it uses a 16-core, 32-thread Zen 5 CPU, an integrated Radeon 8060S GPU with 40 compute units, an XDNA 2 NPU rated at up to 50 TOPS, and up to 128GB LPDDR5x unified memory. AMD’s development platform lists memory bandwidth at 256GB/s.
For this quoting system, the decisive factor is not the NPU’s headline TOPS figure, but the 128GB unified memory. In a traditional CPU plus discrete GPU system, system memory and VRAM are separate. Once model weights exceed VRAM capacity, data has to be moved frequently, or the model has to be reduced through quantization. Unified memory lets the CPU and integrated GPU use the same memory pool, allowing a relatively compact local device to hold the model, knowledge base, drawing parser, and operating system together.
But fitting the model in memory does not mean the software runs smoothly.
Cao initially configured the environment based on his past CUDA experience, only to find that CUDA could not be used directly with AMD’s integrated GPU. To let PyTorch, llama.cpp, and similar tools use the Ryzen AI Max+ 395 GPU, he had to switch to ROCm or other supported backends. On Linux, he used ROCm and llama.cpp to run local models and monitored GPU utilization, memory use, and temperature through ROCm SMI. After tuning, the 35B model generated about 20–30 tokens per second in his project.
That speed is not suitable for a high-concurrency online service, but quoting is not real-time chat. The harder problems appeared when the system entered real factories.
The team first developed mainly on Linux, then migrated the software to Windows Pro to fit customer environments. During on-site deployment, they found that some customers were using long-unupdated Windows Enterprise editions with strict security software. Components that launched normally in development could be blocked, and containers, drivers, and dependency libraries did not always meet factory IT policies.
Another challenge came from the files themselves: some STEP files had non-standard encodings, causing conventional parsers to fail or even crash. The team had to add fallback strategies: if standard parsing failed, the system tried tolerant reading, handled missing fields, and sent uncertain parts back for human review.
As Cao summarized, “Running in the development environment does not mean it will run at the customer’s site.” Local deployment protects drawings and enables offline work, but it also forces the software provider to handle more adaptation. Hardware, framework, and maintenance differences that cloud APIs hide all reappear in local environments.
Who Should Move Now, and Who Should Wait?
Cao does not believe every task should stay local. His long-term architecture is still hybrid edge-cloud: tasks involving factory trade secrets and frequent calls should stay local, including drawing parsing, private knowledge bases, historical quote lookup, and basic process judgment. For complex processes that local models cannot handle well, or tasks requiring broader industry knowledge, cloud models can be called for verification.
Good candidates for early adoption:
- Machine shops that handle sensitive drawings, historical quotes, and process data and do not want to upload them to external servers
- Production sites with weak networks, internal/external network isolation, or offline operation requirements
- Companies willing to invest time and IT effort in local deployment in exchange for end-to-end control
Cases that should be evaluated carefully:
- High-concurrency quoting services, where local generation at 20–30 tokens per second is not suitable for large-scale online access
- Factories without IT support that expect a fully plug-and-play system
- Teams whose quoting depends more on broad industry knowledge than on their own equipment, history, and shop-floor experience
Cao’s stated target of over 95% quoting accuracy is still an internal testing and planning goal. It needs further validation across more part types, factories, and real orders. The team has also created 10 initial templates based on different equipment and machining capabilities, hoping to cover about 80% of a factory’s basic cases first and then calibrate with historical orders and real feedback.
Final Note
Cao’s work shows that industrial AI agents do not necessarily begin with elite algorithmic talent. The key is whether tacit shop-floor experience can be decomposed into workflows that are executable, traceable, and correctable.
Ryzen AI Max+ 395 serves as the compute foundation, not an all-purpose brain. It helps solve the problem of fitting models and related software locally. Whether drawings can be read correctly, processes can be judged accurately, and the system can survive real factory deployment still depends on layer-by-layer engineering. As industrial knowledge meets edge compute in real scenarios, local AI quoting is moving from “demo that runs” toward “product that works.”