Hi @Alex-Wengg — I'm adapting the public Qwen3-TTS CoreML conversion work in this repo for Qwen/Qwen3-TTS-12Hz-1.7B-Base.
I found the current converter under models/tts/qwen3/coreml/convert/, especially convert_argmax_code_decoder.py. This is much closer to what we need than starting from scratch.
The current CodeDecoder converter appears to have two 0.6B/256-specific assumptions:
MAX_SEQ_LEN = 256;
- the test/input embedding tensor is fixed at hidden size 1024, while 1.7B Base uses hidden size 2048.
Before we patch it blindly, could you clarify:
- Have you already tested or internally converted Qwen3-TTS 1.7B (Base or CustomVoice) with this converter family?
- Is changing
MAX_SEQ_LEN from 256 to 1024 intended to be a mechanical regeneration of cache/mask/attention shapes, or are there other sequence-length-dependent graph constants/steps we need to change?
- For 1.7B, is the intended adaptation simply to derive all hidden/KV dimensions from
talker.config (including the input embedding shape), or are there known 1.7B-specific conversion issues?
- Is the current explicit-KV export + later MLState/stateful conversion still the recommended path, or is there a newer stateful exporter we should use?
- If you have a newer 1.7B/longer-context branch or script that is not yet on main, a pointer would be extremely helpful.
We only need the auditable recipe/constraints, not prebuilt weights. Thanks!
Hi @Alex-Wengg — I'm adapting the public Qwen3-TTS CoreML conversion work in this repo for
Qwen/Qwen3-TTS-12Hz-1.7B-Base.I found the current converter under
models/tts/qwen3/coreml/convert/, especiallyconvert_argmax_code_decoder.py. This is much closer to what we need than starting from scratch.The current CodeDecoder converter appears to have two 0.6B/256-specific assumptions:
MAX_SEQ_LEN = 256;Before we patch it blindly, could you clarify:
MAX_SEQ_LENfrom 256 to 1024 intended to be a mechanical regeneration of cache/mask/attention shapes, or are there other sequence-length-dependent graph constants/steps we need to change?talker.config(including the input embedding shape), or are there known 1.7B-specific conversion issues?We only need the auditable recipe/constraints, not prebuilt weights. Thanks!