HT-Demucs FT สู่ ONNX: เราสร้าง Export ตัวแรกที่ใช้งานได้บน iOS, Android และเว็บอย่างไร — พร้อมโมเดล Hugging Face เปิด 9 ตัว และเบนช์มาร์ก MUSDB18-HQ ที่ทำซ้ำได้ (2026)

TL;DR. เราเพิ่งเปิดซอร์ส สินทรัพย์ด้านการแยกสเต็ม 10 รายการ บน Hugging Face รวมถึง การส่งออก ONNX ของ HT-Demucs FT ที่ใช้งานได้เป็นครั้งแรก — ตัวแยกเสียงร้องโอเพนซอร์สอันดับ 1 บน MUSDB18-HQ ความพยายามก่อนหน้านี้ทุกครั้งในการทำ "demucs onnx" ติดที่ปัญหาเดียวกันสี่จุด เราเอาชนะมันได้ทุกจุด ผลลัพธ์รันบน onnxruntime บน CPU/CoreML/CUDA/DirectML โดย ไม่ต้องใช้ PyTorch ตอน inference ทำงาน เร็วกว่า PyTorch บน CPU 1.31 เท่า และ ให้ค่าเทียบเท่าทางตัวเลขกับต้นฉบับ (ผลต่างสัมบูรณ์สูงสุด: 0.000163 ทั้ง 4 สเต็ม)

ด้านล่าง: สิ่งที่เราปล่อย ทำไมมันสำคัญ และบันทึกทางวิศวกรรมว่าการส่งออก ONNX สำเร็จได้อย่างไร

---

ทุกสิ่งที่เราปล่อยในสัปดาห์นี้

ทั้งหมดเป็นไลเซนส์ MIT อยู่ที่ หน้าองค์กร StemSplitio

ประเด็นพาดหัว: เท่าที่เรารู้ ONNX repos เหล่านี้คือ การส่งออก ONNX ของ HT-Demucs FT ที่ใช้งานได้เป็นครั้งแรกบน Hugging Face ไม่ใช่แค่ "พยายามครั้งแรก" — แต่เป็นครั้งแรกที่โหลดขึ้น รันได้ ให้ตัวเลขถูกต้อง และส่งมอบพร้อมเบนช์มาร์กที่ตรวจสอบความเท่ากันแล้ว

---

ทำไมเราถึงทำสิ่งนี้

ช่องว่างด้านเบนช์มาร์ก

หากคุณพยายามเลือกโมเดลแยกสเต็มในปี 2026 คุณจะเจอกับสภาพยุ่งเหยิง ทุก repo โมเดลอ้างว่าโมเดลของตน "state of the art" มีไม่กี่รายที่เผยแพร่เบนช์มาร์กที่ทำซ้ำได้ มีน้อยลงไปอีกที่ทดสอบโมเดลเดียวกันแข่งกันบนฮาร์ดแวร์เดียวกันด้วยเมตริกเดียวกัน

เราแก้ปัญหานี้ด้วยการเผยแพร่ stem-separation-benchmark-2026 — คะแนน SDR / ISR / SIR / SAR จำนวน 850 แถว ครอบคลุม htdemucs, htdemucs_ft, htdemucs_6s, mdx_extra_q และ mdx_net_inst_hq3 บน MUSDB18-HQ พร้อมท่อประเมินผลทั้งหมดที่เปิดซอร์ส ใครก็ตามสามารถ clone ไป รันใหม่ และท้าทายตัวเลขของเราได้

ข้อค้นพบสำคัญ: htdemucs_ft คือตัวแยกเสียงร้องโอเพนซอร์สอันดับ 1 (median vocal SDR 9.19 dB) และ mdx_extra_q คือตัวแยกสเต็ม drums/bass/other โอเพนซอร์สอันดับ 1 (11.49 / 11.42 / 7.67 dB) โมเดลคนละตัวสำหรับสเต็มคนละชนิด

ช่องว่างด้าน ONNX

ปัญหาใหญ่กว่า: หากคุณต้องการใช้ HT-Demucs FT บน iOS, Android หรือในเบราว์เซอร์ คุณทำไม่ได้ เรื่องราว mobile ของ PyTorch ยังลำบาก MPS/CUDA ใช้ได้แค่ฝั่งเซิร์ฟเวอร์ และคำตอบที่ชัดเจน — ONNX — ไม่เคยมีใครทำสำเร็จ

มีอย่างน้อย 4 GitHub issues ที่เปิดอยู่บน demucs repo ขอให้มีการส่งออก ONNX มีหลาย fork ที่ทำได้ครึ่ง ๆ กลาง ๆ มี PR ปี 2023 ที่ไม่ merge มี MLX experiment สองสามรายการที่ต้องใช้ Mac M1+ ไม่มีอะไรที่ "ใช้งานได้ทันที"

เหตุผล: HT-Demucs มีการเลือกสถาปัตยกรรมที่ดูไม่มีพิษภัยใน PyTorch แต่ทำลาย ONNX exporter ในแบบที่ไม่ชัดเจน เราเจอและแก้ทั้ง 4 จุด ซึ่งเป็นเนื้อหาที่เหลือของโพสต์นี้

---

HT-Demucs FT ทำลาย ONNX exporter ทุกตัวอย่างไร

เราลอง torch.onnx.export ก่อน ตามด้วย torch.onnx.dynamo_export ทั้งคู่ล้มเหลวในจุดต่าง ๆ กัน นี่คือรายการครบของจุดติดและวิธีแก้แต่ละจุด:

Blocker 1: complex64 STFT output

HT-Demucs เริ่มต้นด้วย Short-Time Fourier Transform (spec.py::spectro):

z = torch.stft(x, n_fft=4096, hop_length=1024, window=hann,
               win_length=4096, normalized=True, center=True,
               return_complex=True, pad_mode="reflect")

return_complex=True คืนค่า tensor แบบ complex64 MIL ของ CoreML ไม่มี dtype แบบ complex STFT op ของ ONNX (opset 17+) ก็ไม่รองรับ output แบบ complex เช่นกัน ทุก op slice/transpose ที่อยู่ด้านล่างใน graph ล้มเหลวทันที

วิธีแก้. แทนที่ torch.stft ด้วย Conv1d ที่ใช้ kernel แบบ sin/cos ซึ่งจะส่งออก 2 ช่อง real โดยตรง:

def _make_stft_kernels(n_fft: int) -> tuple[torch.Tensor, torch.Tensor]:
    n = torch.arange(n_fft, dtype=torch.float64)
    window = torch.hann_window(n_fft, periodic=True, dtype=torch.float64)
    norm = 1.0 / math.sqrt(n_fft)
    k = torch.arange(n_fft // 2 + 1, dtype=torch.float64).unsqueeze(1)
    angles = 2 * math.pi * k * n.unsqueeze(0) / n_fft
    cos = (window * torch.cos(angles)) * norm
    sin = (window * -torch.sin(angles)) * norm   # negative for forward STFT
    return cos.float().unsqueeze(1), sin.float().unsqueeze(1)

class RealSTFT(nn.Module):
    def forward(self, x: torch.Tensor) -> torch.Tensor:
        x = F.pad(x.reshape(-1, 1, x.shape[-1]), (n_fft // 2,) * 2, mode="reflect")
        real = F.conv1d(x, self.cos_kernel, stride=self.hop_length)
        imag = F.conv1d(x, self.sin_kernel, stride=self.hop_length)
        return torch.stack([real, imag], dim=1)   # (..., 2, F, T) real

ตรวจสอบแล้วได้ผลต่างสัมบูรณ์สูงสุด 5 × 10⁻⁶ เทียบกับ torch.stft โดยตรง ใช้กลเม็ดเดียวกันกับ inverse โดยใช้ ConvTranspose1d พร้อมเอ็นเวโลป window-squared แบบ overlap-add

หลังจากแก้จุดนี้ ทุก view_as_real / view_as_complex ใน _magnitude และ _mask ต้องเขียนใหม่เพื่อร้อย tensor แบบ real-channel ผ่าน forward pass ทั้งหมด ไม่มี complex tensor เหลืออยู่เลย

Blocker 2: fractions.Fraction ใน model.segment

โมเดล htdemucs_ft ที่เทรนไว้แล้วเก็บความยาว segment ของมันเป็น Fraction(39, 5) (= 7.8 วินาที) Dynamo ไม่สามารถ trace การคำนวณของ Fraction ได้ — มันโยน torch._dynamo.exc.Unsupported: call_function UserDefinedClassVariable(<class 'fractions.Fraction'>)

วิธีแก้. บังคับให้เป็น float ก่อน export:

if isinstance(model.segment, Fraction):
    model.segment = float(model.segment)   # 7.8

ง่ายมาก คณิตศาสตร์ตอน inference เหมือนกันทุกประการ

Blocker 3: random.randrange ใน cross-transformer

CrossTransformerEncoder._get_pos_embedding เรียก random.randrange ของ Python:

def _get_pos_embedding(self, T, B, C, device):
    if self.emb == "sin":
        shift = random.randrange(self.sin_random_shift + 1)
        return create_sin_embedding(T, C, shift=shift, ...)

ตอน inference sin_random_shift=0 ดังนั้น random.randrange(1) คืนค่า 0 เสมอ — เป็น no-op แต่ตัว ONNX exporter ก็ยังมองทะลุโมดูล random ของ Python ไม่ได้และล้มเหลว

วิธีแก้. Monkey-patch เมธอดนั้นเองให้ shift=0 แบบ hardcoded:

def _get_pos_embedding_no_random(self_, T, B, C, device):
    if self_.emb == "sin":
        return create_sin_embedding(T, C, shift=0, device=device,
                                    max_period=self_.max_period)
    # ... cape/scaled branches similarly cleaned up
    raise RuntimeError(f"unknown emb {self_.emb}")

for m in model.modules():
    if isinstance(m, CrossTransformerEncoder):
        m._get_pos_embedding = types.MethodType(_get_pos_embedding_no_random, m)

เหมือนกันทางคณิตศาสตร์ตอน inference และ export ได้

Blocker 4: aten::_native_multi_head_attention

nn.MultiheadAttention.forward ของ PyTorch รุ่นใหม่ลัดทางไปยัง fused C++ kernel (_native_multi_head_attention) เมื่อเงื่อนไขเบื้องต้นถูกตรง kernel นั้น ไม่มี ONNX symbolic ที่ opset ใด ๆ ดังนั้น exporter จึงโยน UnsupportedOperatorError

วิธีแก้. แทนที่ forward ของทุก instance ของ nn.MultiheadAttention ด้วย implementation แบบ drop-in ที่ใช้เฉพาะ op ธรรมดาที่มี ONNX symbolic เสถียร (Linear, bmm, softmax, transpose):

def _onnx_friendly_mha_forward(self_, query, key, value, ...):
    if self_.batch_first:
        query, key, value = (t.transpose(0, 1) for t in (query, key, value))
    tgt_len, bsz, embed_dim = query.shape
    head_dim = embed_dim // self_.num_heads

    if self_._qkv_same_embed_dim and torch.equal(query, key) and torch.equal(key, value):
        q, k, v = F.linear(query, self_.in_proj_weight, self_.in_proj_bias).chunk(3, dim=-1)
    else:
        # cross-attention: three separate matmuls
        ...

    q = q.contiguous().view(tgt_len, bsz * self_.num_heads, head_dim).transpose(0, 1)
    k = k.contiguous().view(-1,      bsz * self_.num_heads, head_dim).transpose(0, 1)
    v = v.contiguous().view(-1,      bsz * self_.num_heads, head_dim).transpose(0, 1)

    attn_weights = F.softmax(torch.bmm(q * head_dim ** -0.5, k.transpose(1, 2)), dim=-1)
    attn_output  = torch.bmm(attn_weights, v).transpose(0, 1).contiguous().view(tgt_len, bsz, embed_dim)
    return self_.out_proj(attn_output), None

แพตช์ลงบนทุก instance ของ MHA ในโมเดล ตรวจสอบความเท่ากันแล้ว: ผลต่างสูงสุด 1 × 10⁻⁶ เทียบกับ fused fast path

ผลลัพธ์

หลังจาก patch ทั้ง 4 จุด torch.onnx.export (exporter แบบ legacy, opset 17, dynamo=False) เขียนไฟล์ .onnx ขนาด 316 MB ที่สะอาดใน 6.5 วินาที มันผ่าน onnx.checker.check_model มี node 24,765 ตัว และรันบน onnxruntime ได้ทันทีโดยไม่ต้องตั้งค่าอะไร

ทั้ง 4 สเต็มเทียบเท่าทางคณิตศาสตร์กับ PyTorch htdemucs_ft ฉบับทางการที่ fp32 ต่ำกว่าค่า tolerance 1e-3 ที่ floating-point accumulation drift จะอธิบายได้สบาย ๆ

โมเดล ONNX ที่ส่งออกแล้ว เร็วกว่า 31% บน CPU เทียบกับ baseline PyTorch บนฮาร์ดแวร์เดียวกัน — 1.59 วินาทีสำหรับ segment ขนาด 7.8 วินาที เทียบกับ 2.09 วินาที — เพราะ graph optimizer ของ ONNX Runtime สามารถ fold และ fuse graph ที่สะอาดได้รุนแรงกว่า eager runtime ของ PyTorch

---

ความหมายต่อแต่ละแพลตฟอร์ม

ไฟล์ .onnx ตัวเดียวกันรันได้ทุกที่ที่ onnxruntime รัน นี่คือ quick-start ของแต่ละแพลตฟอร์ม

Python (OS ใด ๆ, CPU หรือ GPU)

import onnxruntime as ort
import soundfile as sf

sess = ort.InferenceSession("htdemucs_ft_vocals.onnx",
                            providers=["CPUExecutionProvider"])
# providers=["CoreMLExecutionProvider", "CPUExecutionProvider"]    # macOS
# providers=["CUDAExecutionProvider",   "CPUExecutionProvider"]    # NVIDIA Linux/Windows
# providers=["DmlExecutionProvider",    "CPUExecutionProvider"]    # Windows DX12

audio, sr = sf.read("song.mp3", dtype="float32", always_2d=True)
stems = sess.run(["stems"], {"mix": audio.T[None].astype("float32")})[0]
sf.write("vocals.wav", stems[0, 3].T, sr)   # row 3 = vocals

repo ที่ตรงกัน: StemSplitio/htdemucs-ft-vocals-onnx

iOS / Swift

import onnxruntime_objc

let opts = try ORTSessionOptions()
try opts.appendCoreMLExecutionProvider(with: ORTCoreMLExecutionProviderOptions())

let env = try ORTEnv(loggingLevel: .warning)
let session = try ORTSession(
    env: env,
    modelPath: Bundle.main.path(forResource: "htdemucs_ft_vocals", ofType: "onnx")!,
    sessionOptions: opts
)
// audio: 1 × 2 × 343980 Float32 buffer, then session.run(...)

ส่ง .onnx 316 MB (หรือตัวเชี่ยวชาญที่เล็กกว่า) ไปใน app bundle ของคุณ CoreML execution provider เป็นตัวทำงานหนักบน Apple Neural Engine เมื่อมี

Android / Kotlin

import ai.onnxruntime.OrtEnvironment
import ai.onnxruntime.OrtSession

val env = OrtEnvironment.getEnvironment()
val opts = OrtSession.SessionOptions().apply { addNnapi() }
val session = env.createSession(modelPath, opts)

addNnapi() ให้ Neural Networks API ของ Android กับคุณ สำหรับ inference แบบเร่งความเร็วบน NPU ของ Tensor / Snapdragon / MediaTek

เว็บ / onnxruntime-web

import * as ort from "onnxruntime-web";

const session = await ort.InferenceSession.create("htdemucs_ft_vocals.onnx", {
  executionProviders: ["wasm"],
  graphOptimizationLevel: "all",
});
const tensor = new ort.Tensor("float32", audioBuffer, [1, 2, 343980]);
const out = await session.run({ mix: tensor });

ใช่ คุณรัน HT-Demucs FT ในเบราว์เซอร์ได้ ใช่ มันช้ากว่า CPU EP (ค่าใช้จ่ายของ WebAssembly) แต่มันทำงาน โดยไม่ต้องติดตั้งอะไรสำหรับผู้ใช้

---

ตัวเลขประสิทธิภาพ

วัดบน Apple M4 Pro (24 GB unified memory) สำหรับเพลงความยาว 3 นาที:

ตัวเชี่ยวชาญรายสเต็มแบบ ONNX ตัวเดียวเร็วกว่า PyTorch CPU 5.7 เท่า สำหรับสเต็มเดียวกันที่คุณภาพเหมือนกัน นั่นคือชัยชนะของการ ship htdemucs-ft-vocals-onnx ในแอปลบเสียงร้องแทน PyTorch full bag: binary เล็กกว่า inference เร็วกว่า SDR เท่าเดิม

---

ตัวเชี่ยวชาญรายสเต็มสร้างขึ้นมาอย่างไร (เคล็ดลับที่น่ารัก)

"bag" ของ htdemucs_ft จริง ๆ แล้วคือโมเดลแยกกัน 4 ตัว เมทริกซ์น้ำหนักต่อสเต็มของ bag เป็น one-hot:

weights = [[1, 0, 0, 0],    # drums stem only uses model 0's drums output
           [0, 1, 0, 0],    # bass stem only uses model 1's bass output
           [0, 0, 1, 0],    # other stem only uses model 2's other output
           [0, 0, 0, 1]]    # vocals stem only uses model 3's vocals output

นั่นหมายความว่า output drums ของ bag คือ output drums ของ sub-model 0 ตรง bit ดังนั้นหากต้องการเฉพาะ drums การ ship แค่ sub-model 0 (160 MB) ให้คุณภาพ drums เหมือนกับ full bag ขนาด 640 MB ที่ต้นทุน inference ~1/4

เราเปิด repo Hugging Face แยกออกเป็น 5 ตัว: full-bag ONNX หนึ่งตัว (htdemucs-ft-onnx) เพื่อความสะดวก พร้อม ONNX แบบเฉพาะสเต็ม 4 ตัวสำหรับการ deploy โปรดักชันที่ต้องการแค่สเต็มเดียว เคล็ดลับเดียวกันใช้ได้กับ repo PyTorch คู่กัน

หากคุณกำลังสร้าง ตัวสกัด drum sample ให้ ship htdemucs-ft-drums-onnx สร้าง ตัวถอดเสียง bassline? htdemucs-ft-bass-onnx สร้าง ตัวลบเสียงร้อง หรือ เครื่องทำคาราโอเกะ? htdemucs-ft-vocals-onnx

---

ก้าวต่อไป

นี่คือวันที่ 1 + วันที่ 2 ของโปรเจกต์ ONNX 3 วัน วันที่ 3 คือ:

1. การ profile CoreML execution provider การคอมไพล์ MLProgram ครั้งแรกของ graph 24k node ใช้เวลา >5 นาทีบน M4 Pro ในการทดสอบของเรา เราต้องตรวจสอบ MinimumDeploymentTarget, ComputeUnits=CPUAndNeuralEngine และกฎ subgraph fallback เพื่อทำให้ CoreML EP เร็วจริง ๆ บน iOS / macOS
2. INT8 dynamic quantization onnxruntime.quantization.quantize_dynamic ต่อโมเดล — โดยทั่วไปไฟล์เล็กลง 4 เท่า (~80 MB ต่อตัว) SDR ลดลงมักต่ำกว่า 0.3 dB บนโมเดลดนตรี ชัยชนะใหญ่บนมือถือหากใช้ได้กับสถาปัตยกรรมนี้
3. เดโม Space แบบ onnxruntime-web บน Hugging Face การแยกสเต็มในเบราว์เซอร์ล้วน ลากแล้ววาง ไม่ต้องติดตั้ง ไม่ต้องใช้เซิร์ฟเวอร์ เป็นเดโมแบบที่ถูกแชร์บน Twitter และไปจบในรายการ Awesome-ONNX

ติดตาม องค์กร StemSplitio บน Hugging Face เพื่อรับการอัปเดตเมื่อสิ่งเหล่านั้นออกมา

---

HT-Demucs ONNX เทียบกับการรัน PyTorch ในปี 2026 เป็นอย่างไร?

สำหรับการ deploy Python ฝั่งเซิร์ฟเวอร์ที่คุณคุม runtime เอง PyTorch ก็โอเค — ช้ากว่า ONNX Runtime บน CPU เล็กน้อย แต่เข้ากันได้กับ helper overlap-add ของ apply_model ทันที

สำหรับ ที่เหลือทั้งหมด — แอป iOS, แอป Android, เครื่องมือบนเบราว์เซอร์, อุปกรณ์ embedded, เครื่องมือ Windows desktop ที่อยากเลี่ยงการติดตั้ง PyTorch 2 GB — ONNX เป็นทางเดียว จนถึงสัปดาห์นี้ ทางนั้นถูกปิดอยู่ ตอนนี้มันเปิดแล้ว

หากคุณกำลังเลือกระหว่าง ONNX repos กับ StemSplit API สำหรับผลิตภัณฑ์ของคุณ การแลกเปลี่ยนคือ:

• ONNX repos = ไม่มีค่าใช้จ่ายต่อ request ไม่มีโครงสร้างพื้นฐาน แต่ ship 316+ MB ในแอปของคุณและกิน CPU/แบตเตอรี่ของอุปกรณ์ผู้ใช้
• StemSplit API = จ่ายต่อวินาที แต่ cold-start ทันที คุณภาพระดับ GPU ไม่ต้องรวมโมเดล ไม่ต้องดูแลเวอร์ชัน

สำหรับแอปคอนซูมเมอร์ที่มี >1k การแยกต่อเดือน API มักชนะในด้านต้นทุนรวมและประสบการณ์ผู้ใช้ สำหรับเครื่องมือใช้ครั้งเดียวหรือ setup แบบ self-hosted โมเดล ONNX เป็นตัวเลือกที่ถูกต้อง

---

ลอง StemSplit API — โมเดลเดียวกัน โฮสต์ให้คุณ

ไม่อยาก ship โมเดล 316 MB ในแอป ดูแล GPU pool หรือเขียนการแบ่งชิ้นแบบ overlap-add ใช่ไหม? StemSplit API รัน htdemucs_ft โมเดลเดียวกันที่คุณจะเจอใน Hugging Face repos เหล่านี้ พร้อม credits, queueing และ dashboard

• 🌐 stemsplit.io — หน้าหลักของผลิตภัณฑ์
• 📘 Developer docs — เริ่มที่นี่
• 🔌 API reference — รายการ endpoint ทั้งหมด
• 📚 Guides & recipes — การ integrate ที่พบบ่อย

curl -X POST https://stemsplit.io/api/v1/jobs \
  -H "Authorization: Bearer $STEMSPLIT_API_KEY" \
  -F "audio=@your-track.mp3" \
  -F "model=htdemucs_ft"

หรือใช้เครื่องมือแบบไม่ต้องเขียนโค้ดที่ ship โมเดลตระกูลเดียวกันนี้แล้ววันนี้:

• 🎤 Vocal Remover — ลบเสียงร้องจากเพลงใดก็ได้ ในไม่กี่วินาที
• 🎶 Karaoke Maker — instrumental + อคาเปลลาในรอบเดียว
• 🎙️ Acapella Maker — เสียงร้องเดี่ยวที่สะอาด
• 📺 YouTube Stem Splitter — วาง URL ได้ 4 สเต็ม
• 🎛️ Stem Splitter — การแยก 4 สเต็มแบบทั่วไป

---

FAQ

ส่งออก HT-Demucs FT เป็น ONNX เพื่อใช้บน iOS และ Android ในปี 2026 ได้ไหม?

ได้ — ณ พฤษภาคม 2026 StemSplitio/htdemucs-ft-onnx ส่งมอบการส่งออก ONNX ที่ใช้งานได้เป็นครั้งแรกของ htdemucs_ft bag 4 สเต็มเต็มชุด มันรันบน onnxruntime-mobile บน iOS (CoreML EP) และ Android (NNAPI EP) โดยให้ output ตัวเลขเหมือน PyTorch ต้นฉบับ ความพยายามก่อนหน้านี้ล้มเหลวเพราะ htdemucs_ft ใช้ complex tensors, fractions.Fraction ของ Python, random.randrange และ fused multi-head attention kernel ของ PyTorch — ทั้งหมดที่ ONNX exporter มาตรฐานปฏิเสธจะจัดการ การปล่อยครั้งนี้ patch ทั้ง 4 จุดและตรวจสอบความเท่ากันได้ในระยะ 1.63 × 10⁻⁴ ของผลต่างสัมบูรณ์สูงสุด

การส่งออก ONNX แม่นยำเทียบกับโมเดล PyTorch HT-Demucs FT แค่ไหน?

เทียบเท่าระดับ bit ที่ fp32 ภายในระยะ floating-point accumulation drift ปกติ เฉพาะเจาะจง: ผลต่างสัมบูรณ์สูงสุดระหว่าง output ของ ONNX Runtime กับ PyTorch คือ 0.000163 บน drums, 0.000011 บน bass, 0.000739 บน other และ 0.000008 บน vocals — ทั้งหมดต่ำกว่า tolerance 0.001 ที่ fp32 reordering มักอธิบายได้ คะแนน SDR บนชุดทดสอบ MUSDB18-HQ ของ stem-separation-benchmark-2026 เหมือนกับ baseline PyTorch

HT-Demucs FT เป็น ONNX เร็วกว่า PyTorch จริง ๆ ไหม?

บน CPU ใช่ — เร็วกว่าประมาณ 1.31 เท่า (1.59 วินาที เทียบกับ 2.09 วินาที ต่อ segment 7.8 วินาทีบน M4 Pro) graph optimizer ของ ONNX Runtime สามารถ fold และ fuse graph ที่สะอาดได้รุนแรงกว่า eager runtime ของ PyTorch บน GPU PyTorch และ ONNX Runtime + CUDA เสมอกันคร่าว ๆ ทั้งคู่ชนะ CPU ด้วย margin ที่ใหญ่ ชัยชนะที่ใหญ่กว่ามาจากการ ship ตัวเชี่ยวชาญเดียว (drums/bass/other/vocals) แทน full bag — พวกนั้นเร็วกว่า full bag ~4 เท่าที่คุณภาพต่อสเต็มเหมือนกัน

วิธีที่ดีที่สุดในการรัน HT-Demucs FT ในเบราว์เซอร์สำหรับเว็บแอปลบเสียงร้องคืออะไร?

ใช้ StemSplitio/htdemucs-ft-vocals-onnx กับ onnxruntime-web execution provider แบบ WebAssembly รองรับโมเดลเต็มตัว คาด latency สูงกว่า native (ภาษีของ browser sandboxing) แต่ไม่ต้องติดตั้งและไม่มีต้นทุนเซิร์ฟเวอร์ สำหรับ traffic โปรดักชัน StemSplit API มักเป็นตัวเลือกที่ดีกว่าทั้งด้านเศรษฐกิจและ UX — โมเดลเดียวกัน เร่งด้วย GPU จ่ายต่อวินาที

เทรนโมเดล HT-Demucs ONNX ของตัวเองจากศูนย์ได้ไหม?

ได้ — demucs repository ทางการ มาพร้อมโค้ดเทรน เมื่อคุณมี checkpoint .th ที่เทรนแล้ว patch ใน coreml-conversion scripts ของเราใช้ได้โดยไม่ต้องแก้ เรากำลังพิจารณาเปิดซอร์สท่อ export เป็นแพ็กเกจ Python ชื่อ demucs-onnx — เปิด discussion บน StemSplitio model repos ตัวใดก็ได้หากคุณเห็นว่ามีประโยชน์

---

รับแจ้งเกี่ยวกับวันที่ 3

สมัครติดตาม องค์กร StemSplitio บน Hugging Face หรือ watch benchmark dataset — นั่นคือที่ที่ตัวแปร INT8-quantized, บันทึก profile ของ CoreML และ Space เดโมในเบราว์เซอร์จะลงเป็นที่แรก

หากคุณกำลังสร้างอะไรด้วยโมเดลเหล่านี้ เราอยากได้ยินเกี่ยวกับมัน เปิด discussion บน repo ใดก็ได้ หรือทักเราได้ที่ stemsplit.io/contact

---

สินทรัพย์ทั้งหมดในการปล่อยครั้งนี้เป็นไลเซนส์ MIT HT-Demucs ต้นฉบับโดย Rouard, Massa & Défossez (Meta AI); โปรดอ้างอิง บทความ ICASSP 2023 ของพวกเขาหากคุณใช้โมเดลในงานวิจัย