The Domestic AI Accelerator Ecosystem and Compute Ledger: Ascend, Cambricon, Hygon & More

Note: This is a review article (no first-hand experimental data), based on public materials; vendor data per official releases.

Experiment Objective

Domestic AI chips (Ascend, Cambricon, Hygon, Enflame, etc.) have moved from "usable?" to "which one?" — but ecosystem maturity varies, operator coverage differs, and migration costs diverge wildly. Goal: an evaluation framework for domestic chips — major chip roadmaps and positioning → software-stack maturity comparison (framework adaptation/operator coverage) → migration-cost estimation (linking ch07's porting article) → compute/price/availability ledger → selection advice. After reading you can answer: which domestic chip, how to estimate migration cost, and how to set acceptance criteria.

Code Walkthrough

Part 1: Migration-cost estimation — list operators first

# Pre-migration must-do: operator coverage audit (ch07 porting method applied)
# 1) export the model's operator list
import torch
ops = collect_ops(model)          # traverse the model, collect all ops/fused groups
# 2) compare against the target chip's coverage table (vendor + community verified)
coverage = check_coverage(ops, target_chip)   # per-op: native/mapped/fallback
# 3) estimate migration effort:
#    coverage["native"]  → hours
#    coverage["mapped"]  → days (performance verification)
#    coverage["fallback"]→ weeks (operator rewrite/alternatives)
print(migration_estimate(coverage))

Key points:

1. Operator coverage audit is the first migration task: not "try running it" but a static audit of operator list vs the target ecosystem's coverage table — the native/mapped/fallback three tiers decide the migration effort magnitude (ch07's porting methodology here).
2. Fallback operators are the cost body: each fallback needs a hand-written replacement or an alternative implementation, days-weeks — audit the fallback list first, then decide whether the alternatives are acceptable.
3. Performance parity is the second task: it runs ≠ it runs fast; post-migration per-op comparison (ch08's nsight/rocprof methodology applies to domestic chips too).

Part 2: Setting acceptance criteria

def acceptance_criteria(model, chip, baseline_gpu):
    # 1) functional: end-to-end runs, loss curves comparable (same seed, same data)
    # 2) accuracy: output error within threshold (e.g. numerical < 1e-3 or downstream metrics)
    # 3) performance: per-op comparison, key ops gap < 30%
    # 4) stability: 72h long run, no crash / no memory leak
    ...

Key points:

• Acceptance quartet: functional (runs), accuracy (metrics comparable), performance (per-op gap threshold), stability (long run) — missing any one means not accepted.
• Accuracy acceptance uses "same seed, same data": compare against FP32 reference or same-framework GPU results with a quantified error threshold — not "looks about the same."
• Performance acceptance per-op: beyond end-to-end, break down by op (ch08 profiling), knowing whether the gap is "ecosystem coverage" or "hardware peak."

Principles

Major chip roadmaps and positioning (public info, illustrative)

Vendor/Chip	Positioning	Ecosystem maturity (est.)	Main scenarios
Ascend (910B)	training-first	high (MindSpore + CANN)	large-model training/inference
Cambricon (Siyuan 590)	training/inference	medium-high (Cambricon SDK)	large models/scientific computing
Hygon (DCU, MI architecture)	training/inference	medium (HIP/ROCm-compatible)	HPC/training
Enflame (YunTun)	training/inference	medium	large models

(Maturity changes fast with releases; follow latest official announcements.)

Core insight: the shared status quo of domestic chips — hardware compute is usable; the ecosystem (operator coverage/framework adaptation/toolchains) is the main gap. Selection is not "highest compute" but "whose ecosystem covers your model most completely + lowest migration cost."

Software-stack maturity dimensions

1. Framework adaptation: PyTorch compatibility-layer maturity (Ascend CANN/PyTorch, Hygon HIP, Cambricon PyTorch extensions).
2. Operator coverage: your model's actual ops as native/mapped/fallback.
3. Distributed support: collective-communication library maturity (NCCL alternatives: HCCL/CANL).
4. Toolchains: profiler/debugger completeness (Nsight counterpart).

Selection matrix (empirical): deep PyTorch ecosystem dependency → prioritize Ascend (most mature PyTorch adaptation) or Hygon (clear HIP migration path); scientific computing/HPC → Hygon (MI architecture + ROCm ecosystem); specific-industry compliance → by supply-chain requirements.

Compute ledger (estimated; must measure)

Dimension	Domestic chip	Same-tier imported (H100)
per-unit compute	approaching/comparable	baseline
price	lower (policy/subsidies)	high
availability	high (supply-chain autonomy)	constrained
ecosystem cost	high (migration + tuning labor)	low
full-lifecycle cost	needs comprehensive accounting	—

Core insight: the "total cost" of domestic chips must include migration labor, tuning cycles, and ecosystem risk — hardware savings can be eaten by migration costs, or domestic becomes the only choice when imported cards are unavailable.

Results

(Estimated, not measured)

Migration type	Effort	Notes
pure PyTorch + full ecosystem coverage	days	change runtime + verify
with custom ops (many fallbacks)	weeks	operator rewrite dominant
deep CUDA library/toolchain dependency	weeks-months	needs alternative design

Engineering Takeaways

1. Audit operator coverage before selection: the native/mapped/fallback list decides migration duration — static audit first, no "try it and see."
2. Acceptance quartet is non-negotiable: functional/accuracy/performance/stability; accuracy with same seed and data, performance per-op.
3. Selection looks at "ecosystem covering your model," not compute peak: framework adaptation + operator coverage + distributed support + toolchains, four dimensions (linking ch07's porting article).
4. Total lifecycle cost, computed together: hardware price gap vs migration labor vs availability — one ledger, then decide.

Next article preview: the domestic-chip ledger done; ch03/07/12 each gained one this round; next could pivot to SEO wrap-up (submit the 426-url sitemap to GSC) or deepen ch13/14. Your call.