Sizing an On-Premises AI Stack for a Logistics Operator
A 40-warehouse logistics operator in Southeast Asia has a three-year CNY 8 million AI budget and six Java engineers with no machine-learning experience. Customer contracts forbid sending operational data to any public cloud, so training and inference must stay on premises. The company holds 12 TB of two years of sensor and barcode data and 200 fixed cameras. Its first use cases are predicting conveyor jams ten minutes ahead and detecting damaged parcels. The CTO proposes buying eight Atlas 800 training servers plus a 200-GPU cluster and building a foundation model from scratch. The CFO wants to lease cloud GPUs instead. A consultant recommends applying Huawei's full-stack, all-scenario AI strategy, but selectively. The pilot must cut unplanned downtime by 20% within nine months.
1. Assess the CTO's hardware and foundation-model proposal. What should the company actually buy and build in the first nine months?
Read the worked answer
The proposal is oversized for the workload. Jam prediction is tabular or time-series data and is usually served well by gradient-boosted trees or a small MLP; parcel-damage detection is a vision task where fine-tuning a pretrained backbone is sufficient. Neither requires pretraining a foundation model, so a 200-GPU cluster and eight Atlas 800 training nodes would sit idle and consume most of the CNY 8 million budget before integration and staffing.
A defensible plan is two Atlas 800 nodes for training and retraining with redundancy, plus Atlas 500 or Atlas 300 inference hardware at warehouses. Use MindSpore and CANN as the software base and fine-tune pretrained vision models rather than pretraining from scratch. Build the data pipeline, labelling process, and model monitoring; buy the chips, servers, and framework support.
Interpret full-stack, all-scenario selectively: the relevant layers are Ascend hardware, CANN, MindSpore, and the application. Public-cloud scenarios are excluded by contract, so the operator should not buy a cloud-first architecture. Gate the plan on the 20% downtime reduction pilot.
2. The CFO argues that leasing cloud GPUs is cheaper than buying. How should the team respond, and what non-cost factors decide the architecture?
Read the worked answer
Cost is not the first constraint here; contractual data residency is. Sending 12 TB of operational data and camera streams to a public cloud would breach customer agreements, so the lease option is non-compliant regardless of price. The response should separate the two questions.
On cost, compare three-year total cost of ownership, not hourly GPU price: hardware, power, cooling, spares, staff, utilization, and idle time. Training utilization is likely to be bursty, which favors owned capacity only if the same nodes can also serve inference and retraining.
On non-cost factors, score data classification, latency, connectivity at 40 warehouses, availability targets, and the team's operations skills. Jam prediction tolerates minutes of latency, but inference at the warehouse must survive WAN outages, which favors edge devices. A reasonable compromise is on-premises hardware for production data and a cloud sandbox only for synthetic or anonymized development data, subject to legal review.
3. Define the pilot's success metrics and a go/no-go rule.
Read the worked answer
The pilot should test the whole loop, not just model accuracy. Primary business metric: unplanned downtime reduced by at least 20% against a measured baseline on the same conveyor lines. Secondary metrics: false alarms per warehouse per day (set a ceiling, for example five), lead time from sensor anomaly to alert (must support the ten-minute warning), and damage-detection recall at a fixed human review capacity.
Technical metrics: inference latency at the edge, data completeness, and retraining cycle time. Operational metrics: labelling throughput and the percentage of alerts that operators mark as actionable.
A go/no-go rule should be pre-registered: proceed only if downtime falls by 20%, false alarms stay under the ceiling, and the system runs for four consecutive weeks without manual intervention. If downtime improves but false alarms exceed the ceiling, fix the threshold and retrain rather than scaling out. If neither improves, stop and re-scope before buying more hardware.