Establish what the historical conference evidence shows
The Shanghai government English portal's July 25, 2025 preview announced a July 26–28 WAIC program, more than 800 companies and over 3,000 AI products. It described exhibition themes covering core technology, industrial applications, smart terminals and collaboration. The page credits eastday.com as its source.
These were announced program figures, not an independent audit of attendance or product performance. A large exhibition can reveal technologies worth investigating without proving that every displayed system is ready for a particular production workload.
This article preserves the 2025 event context and adds TensorBlue's evaluation framework. It does not claim first-hand conference attendance, endorse a vendor or establish that geopolitical restrictions caused a particular technical result. The operational guidance below is separate from the dated preview.
Turn a demonstration into a specific task hypothesis
Describe the task a displayed system might improve. A robot demonstration, document assistant and model-serving cluster need different evaluation methods. Specify the intended users, environment, inputs, required outputs and unacceptable failures before comparing products.
Ask what the demonstration controlled. A scripted input, curated document or fixed environment can establish that a system performed that scenario; it does not show how it handles missing information, changing conditions or unfamiliar users. Record what was observed and what remains a vendor assertion.
For a hypothetical document assistant seen in a demonstration, define an authorized set of documents, source-citation requirements and reviewer expectations. Test whether it can find evidence across those documents before judging it by the fluency of its presentation. This is an evaluation example, not a TensorBlue client result.
Compare model and hardware results under stated conditions
The June 2025 paper Serving Large Language Models on Huawei CloudMatrix384 provides technical context for one compute architecture discussed in this period. It describes the authors' serving design and results. A reported benchmark should be read with its model, workload and measurement setup, rather than converted into a claim of universal superiority.
For a relevant comparison, hold the task, model version, input and output lengths, precision and concurrency consistent where possible. Measure quality alongside latency and throughput. Separate time to the first output from the rate of later output, and report behavior at the load the application expects.
Include software compatibility, available tooling and operating effort. Hardware capacity alone does not establish whether a team can migrate its application economically. Keep vendor measurements distinct from results reproduced on the team's representative workload.
Check integration, data permissions and failure behavior
Map how the proposed system receives data and returns results. Identify authentication, storage, external services and the people responsible for each boundary. Confirm the permissions needed for the intended use before testing with confidential material.
Define the output contract and how downstream components handle invalid, incomplete or delayed responses. An attractive interface can hide a brittle integration. Test unavailable dependencies and changed input formats instead of assuming the demonstration's environment will remain stable.
Specify a fallback and a recovery route. For a draft assistant, manual work may be the fallback; for an automated operation, recovery may require checking whether a partial action already occurred. Assign ownership for those cases before allowing the system to affect production records.
Assess operating readiness with a bounded pilot
Choose a small initial scope with acceptance criteria and an owner. Use representative users and authorized inputs. Track failures and reviewer effort as well as successful outputs. A pilot should resolve a defined evidence gap, not become an open-ended deployment because a demonstration was impressive.
Check who can maintain the system, diagnose incidents and introduce updates. Include monitoring, support, training and recurring costs in the evaluation. Record dependencies that may change, including service availability and relevant contractual or jurisdictional requirements.
Evaluate the actual experience people need. A system that produces more outputs can still increase total work if each output needs extensive correction. Expand only when the evidence supports the intended workload and the team can operate the fallback.
Keep the adoption decision traceable
Maintain a decision record containing the task, baseline, alternatives, sources, test conditions and unresolved limitations. Mark conference observations, published technical claims and internal measurements separately. This lets reviewers understand how much support the recommendation has.
Revisit the decision after a material change in model, input data, software or operating environment. Historical event coverage should retain its dates; a present adoption decision needs current evidence about the specific product. Do not infer readiness or reliability from exhibitor counts or a broad national technology narrative.
Read the July 2025 AI roundup for broader historical context, use the responsible AI guide for release evidence, or discuss a scoped technology evaluation.