Define Acceptance Criteria for Compute Partnerships

In compute partnerships, acceptance criteria that merely state "performance meets requirements" are almost equivalent to having no criteria at all. The experience of AI applications (such as agent inference and video generation) depends heavily on the coordination between underlying storage and compute, and performance figures under different test conditions can vary by severalfold. Mingxin's recommendation is to write the measured conditions—including hardware platform, model, concurrency, cold/hot state, and metric definitions—into the contract item by item, using a reproducible test process as the basis for acceptance. This article uses measured data from the Mingxin FX100 on a 480B model as an example to illustrate how to structure such acceptance clauses.

Why Must "Performance Compliance" Be Tied to Test Conditions?

The performance of a compute system is not a single number but a function determined by test conditions. Taking KV Cache acceleration as an example, the Mingxin FX100 achieves a 26–32% reduction in time-to-first-token (TTFT) on a 480B model with TP8 deployment [source: measured, report R2]. However, this figure is predicated on: an 8-card AMD MI308X platform, the Qwen3-Coder-480B-FP8 model, concurrency levels of 8/16, and a long-context cold-restore workload. If concurrency is changed to 4, or a smaller model is used, the results could be entirely different.

Therefore, performance metrics in a contract must include the following elements:

• Hardware baseline: GPU model and count, CPU, memory, network (e.g., RoCEv2)
• Model and workload: specific model name, parameter count, context length, cold start or warm start
• Concurrency and measurement points: e.g., TTFT p50, throughput (tok/s) at specified concurrency levels
• Comparison baseline: whether compared against a local NVMe single drive or against NFS (acceleration multiples differ significantly across baselines)

For the Mingxin FX100, the acceleration multiple versus a local NVMe single drive is 8.6–20× [source: measured, report R2]; versus NFS, the model loading acceleration is 6.2–9.3× [source: measured, report R9 (Ascend platform)]. If the contract does not specify the comparison baseline, disputes during acceptance are highly likely.

How to Design a Reproducible Acceptance Test Process?

We recommend a "gate-based" acceptance model, breaking the test into multiple stages, each with clear pass criteria. A typical Mingxin–customer collaboration cycle is approximately 10 weeks, divided into four gates:

• G1 (delivery acceptance): hardware configuration verification, basic connectivity
• G2 (single-node baseline): run test scripts on the customer-specified platform to establish a performance baseline
• G3 (primary gate): core metrics must be met—TTFT reduction ≥25%, throughput improvement of 29–40% (measured in-band) [source: measured, reports R2/R3]
• G4 (stability): 72-hour continuous operation with performance fluctuation within the agreed range

The key to this model is "stop-loss on failure"—if G3 is not passed, either party may terminate the contract. Additionally, test scripts should be delivered in advance so the customer can reproduce results independently. Mingxin provides a Python-reproducible measurement model (available under NDA) to ensure transparency in the acceptance process.

For AI application scenarios, we recommend adding two additional test types:

• Agent-class workloads: simulate multi-turn dialogue and tool-call KV Cache read/write patterns, measuring TTFT and throughput stability
• Video generation workloads: e.g., ComfyUI + LTX-Video 2.3 deployment (covered in Mingxin reports R6/R7), focusing on model loading time and end-to-end latency of generation tasks

In Private Deployment Scenarios, What Else Should Acceptance Criteria Address?

Private deployment means the hardware platform may differ from Mingxin's test environment (e.g., the customer already has an Ascend or NVIDIA cluster). In this case, the contract should clarify "adaptation responsibility"—for example, the Mingxin FX100 achieves 6.2–9.3× model loading acceleration on the Huawei Atlas 910B platform [source: measured, report R9], but this figure is based on a specific software stack (Ascend CANN version, vLLM adaptation). If the customer's platform version differs, the contract should stipulate that "the re-measured results after actual adaptation shall prevail."

Furthermore, private deployment often involves data security requirements. Acceptance testing should be conducted in the customer's isolated environment, ensuring test data never leaves the customer's data center. The AMD MI308X platform and ROCm 7.2 software stack used in Mingxin's R1–R4 tests can be listed in the contract appendix as a "recommended environment" rather than a mandatory one—the final result is based on the jointly confirmed test outcome.

Conclusion

Acceptance criteria in compute partnerships are, at their core, a constraint on "performance authenticity." Mingxin Technology, while offering the FX series products (FX100 through FX400), also supports approximately 10-week gate-based joint testing with customers, replacing vague performance promises with reproducible test conditions. If you are planning compute procurement for AI applications (agents, video generation, etc.), feel free to contact Mingxin for test script templates or to schedule joint testing.

Key Q&A

Q: How should acceptance performance metrics be described in a compute contract?
A: They must include complete test conditions such as hardware platform, model and workload, concurrency levels, cold/hot state, and comparison baseline. For example: "Under 8-card AMD MI308X, Qwen3-Coder-480B-FP8, concurrency 16, cold start, TTFT p50 reduction ≥25%" [source: measured, report R2].

Q: Can the Mingxin FX100's acceleration figures be reproduced on different hardware platforms?
A: Some figures depend on specific platforms. For instance, the 6.2–9.3× loading acceleration versus NFS is based on the Huawei 910B platform [source: measured, report R9]; if the customer's platform differs, the re-measured results after actual adaptation shall prevail, and we recommend stipulating adaptation responsibility in the contract.

Q: How long does the acceptance test cycle typically take?
A: Mingxin recommends approximately 10 weeks, divided into four gates (G1 delivery, G2 single-node baseline, G3 primary gate, G4 stability). G3 is the core metric acceptance; failure allows termination of the partnership, and test scripts are delivered in advance for customer reproduction.