Betrieb von Private ASR auf dem Ascend 910B: Einrichtung, Anpassung des Betreibers und Durchsatz

Dieser Beitrag behandelt die Landung einer chinesischen Sprach-zu - Text-Engine auf Huawei Ascend NPUs in einer privaten Umgebung - Versionen der Umgebung, Modellkonvertierung, Bereitstellungsbefehle, Fallstricke und Referenzleistungszahlen.

Über die Zahlen: Zahlen mit "Spezifikation" stammen aus dem veröffentlichten Produkt Spezifikationen. Die Leistungstabelle gibt Referenzgrößen unter typischen Bedingungen an; tatsächliche Werte variieren je nach Audiobedingungen, Modellgröße und Gleichzeitungsstrategie. Messen Sie stets an Ihrer eigenen Arbeitslast.

Warum es auf heimischer Hardware läuft

In Regierung, Finanzen und Verteidigung müssen Systeme nicht nur „Daten-on - premises", sondern auch „technologisch selbständig" sein. "Das bedeutet, die zugrunde liegende Berechnung von importierten GPUs auf Ascend, Cambricon und Hygon inländische Chips und das Betriebssystem auf Kylin, UnionTech und andere inländische Systeme zu verlagern.

In technischer Hinsicht wird dies zu drei harten Einschränkungen:

• Datenresidenz - Audio-Meeting enthält interne Diskussionen, und viele Organisationen verbieten ausdrücklich Audio das Verlassen des Intranets
• Xinchuang Beschaffung - importierte GPUs erscheinen möglicherweise nicht auf der genehmigten Kaufliste
• Air-Gapped Operation - manche Standorte haben keine externe Konnektivität, daher müssen Modellgewichte im Voraus in die Umgebung verpackt werden

Kernpunkt: On-Premise-Bereitstellung beantwortet „wo sich die Daten befinden"; Lokalisierung beantwortet „wer die Technologie steuert. Gemeinsam „Sie konvergieren zu einer einzigen Aufgabe" - ASR läuft auf inländischen NPUs und läuft schnell genug.

Unterstützte Beschleuniger

Aufbauend auf der Forschung von NEU NLP (Northeastern University) unterstützt der VoiVision-Motor nativ Mainstream-Beschleuniger:

Typ	Vertreter	Nutzen
NVIDIA	T4 / L4 / A10 / A100	Allgemein, hohe Leistung
Ascend	310P und 910B	Lokalisierte, heimische Server
Cambricon	MLU370 / MLU590	Lokalisierte, heimische Server
Hygon DCU	Die DCU-Serie	Inländischer x86 - Pfad
Nur CPU	x86 / ARM	Wiederverwendung bestehender, geringe Konkurrenz

Ascend verfügt derzeit über das vollständigste Ökosystem unter den inländischen Beschleuniger (CANN + MindSpore + Modellzoo). Der 910B zielt auf Training und High-Through - Inferenz ab, während der 310P auf Edge und Low-Power - Nutzung abzielt. Für das anhaltende gleichzeitige Meeting Sprachtranskription ist ein gemeinsames Muster 910B für die zentrale Inferenz und 310P für die Kantenknoten.

Environment Setup: Versionenausrichtung ist die größte Falle

Der Schmerz im Ascend Ökosystem ist keine Berechnung, es ist der Versionen Matrix. Treiber, Firmware, CANN, Framework und Modellformat - wenn einer der fünf nicht synchronisiert ist, erzeugt erstaunliche Ausfälle.

Eine Kombination, die wir normalerweise stabil sehen:

Komponenten	Versionen	Hinweis
Treiber / Firmware	Eng an Cannes gebunden	Überprüfen Sie die offizielle Kompatibilitätstabelle vor dem Upgrade
Kann	8.x-Serie	Operator-Bibliothek und Modellkonvertierungstools live hier
Der Container	Ascend Docker Runtime	Erforderlich - plain Docker kann die NPU nicht montieren
Inferenz-Framework	ONNX Laufzeit + ACL	OM-Modelle funktionieren ohne MindSpore gut
OS	OpenEuler / Kylin V10 / UnionTech UOS	Gemeinsam in Xinchuang Umgebungen

Der erste Schritt ist, immer zu bestätigen, dass die NPU sichtbar ist:

# List NPU devices and status
npu-smi info

# Expect a device list with 910B entries in a healthy state
# If the card is not visible here, nothing downstream matters — fix the driver first

Fallfall: Auf einigen Kylin V10 - Systemen meldet npu-smi info einen dmp-Daemon - Fehler unmittelbar nach der Installation des Treibers. Die Ursache stellte sich als ein Konflikt zwischen der dkms-Version des Systems und dem Treiber-Installer heraus. Der Fix besteht darin, das Systemdkms zu entfernen und mithilfe der Version neu zu installieren, die mit dem Treiberpaket geliefert wurde. Anpassungsprobleme auf Vertriebsebene wie diese werden selten dokumentiert und gehören zu den häufigsten Blockern vor Ort.

Modellumwandlung: ONNX nach OM

ASR-Modelle werden typischerweise in PyTorch trainiert, in ONNX exportiert und dann in das OM-Format von Ascend konvertiert.

Drei Dinge, die Sie beim Export von ONNX beachten sollten

torch.onnx.export(
    model, dummy_input,
    "asr.onnx",
    opset_version=14,          # Ascend supports lower opsets better — avoid the newest
    do_constant_folding=True,
    input_names=["audio", "audio_len"],
    output_names=["logits"],
    dynamic_axes={              # critical: audio length is variable
        "audio": {0: "batch", 1: "time"},
        "logits": {0: "batch", 1: "time"},
    },
)

Drei Orte, an denen das häufig falsch läuft:

1. Opset Versionen - Neuer ist nicht besser. High-Opset - Versionen treffen häufiger ununterstützte Operatoren während der Konvertierung; 14 ist eine gut getestete Wahl.
2. Dynamische Achsen - Audiolänge ist von Natur aus variabel, daher muss dynamic_axes deklariert werden, sonst sind Sie auf Eingabe mit fester Länge beschränkt und das Ergebnis ist in der Produktion nicht nutzbar.
3. Konstantes Folding - do_constant_folding=True verkleinert den Graph spürbar und verbessert den Conversion-Erfolg.

Umwandlung mit ATC

atc --model=asr.onnx \
    --framework=5 \
    --output=asr_om \
    --input_format=ND \
    --input_shape="audio:-1,-1;audio_len:-1" \
    --dynamic_dims="1,16000;1,32000;1,48000" \
    --soc_version=Ascend910B \
    --precision_mode=allow_fp16 \
    --log=error

Was die Parameter eigentlich bedeuten:

• --soc_version - muss der physischen Hardware exakt entsprechen. Die Angabe von 910A auf einem 910B fehlschlägt bei der Ladezeit mit einem vage Fehler.
• --dynamic_dims - dynamische Formprofile. Für Audio, Profil nach Dauer; zu viele Profile erhöhen die Kompilierungszeit, zu wenige lösen häufige Rekompilierung und Latenz-Jitter aus.
• --precision_mode - allow_fp16 kostet bei ASR typischerweise vernachlässigliche Genauigkeit, während der Durchsatz deutlich verbessert wird.

Sollten Sie quantifizieren?

Präzision	Durchput	Genauigkeit
FP16	Baseline	Baseline
INT8	Klarer Gewinn	Bemerkenswerte Kosten

Urteil: Halten Sie FP16, wo Genauigkeit von entscheidender Bedeutung ist (medizinische, juristische Meetings); INT8 ist der bessere Handel, wo die Fehlertoleranz höher ist, wie interne Stand-ups und Trainingsaufnahmen.

Deployment: Container sind die einzige sinnvolle Option

Bare-Metall - Installationen sind an den Standorten von Xinchuang nahezu unhaltbar. Lieferung von Containern:

docker run -it --name asr_server \
  --device /dev/davinci0 \
  --device /dev/davinci_manager \
  --device /dev/devmm_svm \
  --device /dev/hisi_hdc \
  -v /usr/local/Ascend/driver:/usr/local/Ascend/driver \
  -v /data/models:/models \
  -p 8000:8000 \
  asr-server:910b \
  ./asr_server --model /models/asr_om --port 8000

• Laufen auf Bare Metal, Government Cloud und lokalisierten Umgebungen;
• Integration mit OA und Meeting-Systemen über Standard-RESTful / WebSocket APIs;
• Elastisch durch Konkurrenz skalieren.

Beachten Sie diese --device-Einträge: Fehlen eines dieser Faktoren führt zu einem ACL-Initialisierungsfehler, und der Fehler wird Ihnen nicht sagen, dass ein Gerät fehlt. Dies ist der häufigste Stolperstein für Newcomers.

Erfindet kein privates Protokoll - Standard-REST (Datei Sprachtranskription) und WebSocket (Echtzeit-Streaming) verwenden, oder die Integration mit den OA- und Meeting-Systemen des Kunden wird schmerzhaft.

Wenn Sie bereits über Server verfügen, nutzen Sie die software-only engine, um private Sprachtranskription auf inländischen Beschleunigern zu erhalten, ohne Hardware zu kaufen.

Referenz Performance

Testbedingungen: Ascend 910B, FP16, chinesische Meeting-Audio, 16 kHz Mono.

Metrisch	Referenz	Hinweis
Echtzeitfaktor (RTF)	~ 0.1 Ordnung	Eine Stunde Audio in wenigen Besprechungsprotokoll
Gleichzeitige Streams pro Karte	Zehn	Pure Sprachtranskription, nachhaltige Meeting-Konkurrenz
First-Token - Latenz	Sub-Sekunden	Streaming-Modus; typischerweise unter 1s in der Praxis
Chinesische Sprachtranskription Genauigkeit	≥ 98%	Standard Mandarin-Meeting - Szenarien (Spezifikation)
Dialekt Abdeckung	22	Auto-Erkennung (Spezifikation)

und️ Die gleichzeitige Zahl oben ist Nur Sprachtranskription (einzel ASR-Karte, keine Sprechertrennung oder Minutenstruktur). Die Hinzufügung der Lautsprechertrennung sowie der Extraktion von Themen / Aktionen reduziert die Kapazität pro Karte erheblich - das Gerät wird bei 10 gleichzeitigen Meetings bewertet, die sich auf die vollständige Pipeline bezieht (Sprachtranskription + Trennung + Strukturierung); die Clusterform wird auf 50+ Ströme bewertet. Fragen Sie immer, welche Schicht ein Anbieter angibt - die drei unterscheiden sich um ein Vielfaches.

Sechs Fallstricke aus echten Deployments

Dies ist der wertvollste Teil des Postes. Jeder von ihnen wurde vor Ort getroffen.

1. Dynamische Formen verursachen eine ständige Rekompilation Ohne --dynamic_dims löste jede neue Audiolänge eine Graphrekompilierung aus und die Latenz stieg auf Sekunden. Das Profiling nach Dauer brachte es in weniger als einer Sekunde zurück.

2. Langes Audio erschöpft Gedächtnis Das Einführen einer zweistündigen Besprechungsaufzeichnung direkt in das Modell OOMs das Gerät. Sie benötigen Inkrementelle Inferenz - Segment für VAD und decodieren Segment für Segment, anstatt die gesamte Datei zu laden.

3. Ununterstützte Operatoren scheitern leise Eine LayerNorm Variante hatte kein Ascend-Gegenstück. ATC erzeugte während der Konvertierung keinen Fehler, und das Modell liefert alle Nullen zur Laufzeit aus. Führen Sie nach der Konvertierung immer eine Äquivalenzprüfung durch: Führen Sie das gleiche Audio über ONNX Runtime (CPU) und OM (NPU) aus und vergleichen Sie die Ausgänge.

4. Kontextlecks unter Multi-Threaded - Gleichzeitigkeit Eine frühe Version erstellte einen separaten ACL-Kontext pro Anforderung und erschöpfte Kontexte unter Last. Das Context-Pooling hat das behoben.

5. Modelle müssen nach Fahrer-Upgrades neu konvertiert werden Nach einem großen CANN-Upgrade können ältere OM-Modelle nicht geladen werden oder die Leistung verlieren.

6. Offline-Verpackung für Air-Gapped - Standorte In physisch isolierten Umgebungen müssen CANN-Abhängigkeiten, Treiber, Modellgewichte, Schriftarten und Zertifikate im Voraus verpackt werden. Wir kamen einmal vor Ort, um eine fehlende CJK-Schrift zu finden, und jedes Transkript kam als Tofu-Kisten zurück. Üben Sie die vollständige Bereitstellung in einer gleichwertigen Umgebung, bevor Sie das Offline-Bundel versenden.

Wenn Sie sich nicht für einen inländischen Beschleuniger entscheiden sollten

Seien Sie direkt mit Ihnen. Skip it, wenn:

• Es gibt kein Xinchuang- oder Lokalisierungsmandat → der GPU Ökosystem ist viel reifer, machen Sie keine Arbeit für sich selbst
• Niemand im Team weiß, dass die Betriebskosten von CANN weit übersteigen werden, was die Hardware spart
• Concurrency ist einstellig → plain CPU ist genug, überspringen Sie den Beschleuniger

Inländische Beschleuniger sind der richtige Anruf, wenn: Es gibt ein klares Compliance-Mandat + anhaltender Koncurrency-Druck + Engineering-Kapazität, um es zu unterstützen.

Größenberatung

• Neuer lokalisierter Cluster: VV05 / VV10+ Ascend oder Cambricon Beschleuniger;
• Vorhandene x86 wiederverwenden: Motor auf CPU oder Hygon DCU;
• Gemischte Umwelt: vereinheitlicht NVIDIA und inländische Beschleuniger, Zeitplan nach Last.

Wenn Sie privat gegen Cloud abwägen, sehen Sie die on-premise ASR selection guide.

Siehe die private deployment guide und MLPS Level 3 compliance.