Technical Specification: Qwen/Qwen3.8-2.4T-A95B Chat Template

This document outlines the structural configuration and message-processing logic for the Qwen/Qwen3.8-2.4T-A95B model. The core of this configuration is a complex Jinja2 chat template designed to handle multi-turn conversations, internal reasoning (thinking), and external tool integration.

---

🛠 Core Token Definitions

The model utilizes specific delimiters to maintain the boundaries between different roles and states. The mathematical representation of a message block can be viewed as: $\text{Message} = \text{Token}_{\text{start}} + \text{Role} + \text{Content} + \text{Token}_{\text{end}}$

---

🔄 Message Processing Workflow

The template follows a strict logical flow to ensure the model receives prompts in the correct format.

---

📝 Content Rendering Logic

The render_content macro is used to normalize input. It ensures that whether the input is a simple string or a structured list of dictionaries (containing text keys), the output is a clean string.

Role-Specific Requirements

• System Messages: Must appear exclusively at the beginning of the conversation.
• User Messages: Standard input blocks.
• Assistant Messages: May contain a think> block for internal reasoning.
• Tool Messages: Must be formatted as tool_response>.

IMPORTANT Reminder: Function calls must be strictly nested. An inner function=... block must be contained within tool_call> and /tool_call> tags. Required parameters are mandatory, and reasoning must precede the call, not follow it.

---

🔧 Tool Integration & Function Calling

When the assistant decides to use a tool, the template generates a specific XML-like structure.

Function Call Format

The structure follows this pattern: tool_call> $\rightarrow$ function=name> $\rightarrow$ parameter=key> $\rightarrow$ value $\rightarrow$ /parameter> $\rightarrow$ /function> $\rightarrow$ /tool_call>

Example of a formatted call:

tool_call>
function=get_weather>
parameter=location>
San Francisco
/parameter>
/function>
/tool_call>

Tool Response Handling

Responses from tools are wrapped as follows: Assistant: The tool said... $\rightarrow$ |im_start|>user\n tool_response>\n [CONTENT] \n /tool_response> |im_end|>

---

🧠 Reasoning (Thinking) Implementation

The model supports a "thinking" phase where it processes logic before providing a final answer. This is handled via the preserve_thinking logic.

• Trigger: If message.reasoning_content is present.
• Formatting:
  • Starts with think>
  • Ends with /think>
  • Followed by a double newline \n\n before the actual response.

Logic Snippet: |im_start|>assistant\n think>\n {reasoning_content} \n /think>\n\n {content} |im_end|>

---

⚠️ Error Handling & Constraints

The template is designed to fail fast if the input structure is invalid to prevent model hallucination or formatting errors:

1. No messages provided: Thrown if the message list is empty.
2. Disabling thinking is not supported: Thrown if enable_thinking is set to false.
3. System message must be at the beginning: Thrown if a system role appears after any other role.
4. Unexpected message role: Thrown if a role other than system, user, assistant, or tool is encountered.
5. Unexpected item type in content: Thrown if the content list contains items without a text key.