Qwen3 4B GGUF

🚀 Qwen3-4B GGUF模型

Qwen3-4B GGUF模型基於特定技術生成，具備多種量化方法和不同的模型格式，能適應不同硬件和內存條件，在文本生成等任務中表現出色。

🚀 快速開始

Qwen3的代碼已集成在最新的Hugging Face transformers 庫中，建議使用最新版本的 transformers。若使用 transformers<4.51.0，會出現如下錯誤：

KeyError: 'qwen3'

以下是一段代碼示例，展示瞭如何基於給定輸入使用模型生成內容：

from transformers import AutoModelForCausalLM, AutoTokenizer

model_name = "Qwen/Qwen3-4B"

# 加載分詞器和模型
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(
    model_name,
    torch_dtype="auto",
    device_map="auto"
)

# 準備模型輸入
prompt = "Give me a short introduction to large language model."
messages = [
    {"role": "user", "content": prompt}
]
text = tokenizer.apply_chat_template(
    messages,
    tokenize=False,
    add_generation_prompt=True,
    enable_thinking=True # 在思考和非思考模式之間切換。默認為True。
)
model_inputs = tokenizer([text], return_tensors="pt").to(model.device)

# 進行文本補全
generated_ids = model.generate(
    **model_inputs,
    max_new_tokens=32768
)
output_ids = generated_ids[0][len(model_inputs.input_ids[0]):].tolist() 

# 解析思考內容
try:
    # rindex查找151668 (</think>)
    index = len(output_ids) - output_ids[::-1].index(151668)
except ValueError:
    index = 0

thinking_content = tokenizer.decode(output_ids[:index], skip_special_tokens=True).strip("\n")
content = tokenizer.decode(output_ids[index:], skip_special_tokens=True).strip("\n")

print("thinking content:", thinking_content)
print("content:", content)

對於部署，可以使用 sglang>=0.4.6.post1 或 vllm>=0.8.5 創建與OpenAI兼容的API端點：

• SGLang：

  python -m sglang.launch_server --model-path Qwen/Qwen3-4B --reasoning-parser qwen3
  

• vLLM：

  vllm serve Qwen/Qwen3-4B --enable-reasoning --reasoning-parser deepseek_r1
  

對於本地使用，像Ollama、LMStudio、MLX-LM、llama.cpp和KTransformers等應用也已支持Qwen3。

✨ 主要特性

Qwen3亮點

Qwen3是Qwen系列的最新一代大語言模型，提供了一系列密集型和專家混合（MoE）模型。經過大量訓練，Qwen3在推理、指令遵循、智能體能力和多語言支持等方面取得了突破性進展，具有以下關鍵特性：

• 獨特支持單模型內思考模式（用於複雜邏輯推理、數學和編碼）和非思考模式（用於高效通用對話）的無縫切換，確保在各種場景下都能實現最佳性能。
• 推理能力顯著增強，在數學、代碼生成和常識邏輯推理方面超越了之前的QwQ（思考模式）和Qwen2.5指令模型（非思考模式）。
• 高度符合人類偏好，在創意寫作、角色扮演、多輪對話和指令遵循方面表現出色，提供更自然、引人入勝和沉浸式的對話體驗。
• 具備強大的智能體能力，能夠在思考和非思考模式下精確集成外部工具，在複雜的基於智能體的任務中在開源模型中處於領先地位。
• 支持100多種語言和方言，具備強大的多語言指令遵循和翻譯能力。

模型概述

Qwen3-4B 具有以下特點：

屬性	詳情
模型類型	因果語言模型
訓練階段	預訓練和後訓練
參數數量	40億
非嵌入參數數量	36億
層數	36
注意力頭數量（GQA）	Q為32，KV為8
上下文長度	原生支持32,768，使用 YaRN 方法可支持131,072個標記

更多詳細信息，包括基準評估、硬件要求和推理性能，請參考我們的 博客、GitHub 和 文檔。

超低比特量化與IQ-DynamicGate（1 - 2比特）

最新的量化方法為超低比特模型（1 - 2比特）引入了精度自適應量化，經基準測試證明在 Llama-3-8B 上有顯著改進。該方法採用特定層策略，在保持極高內存效率的同時保留準確性。

基準測試環境

所有測試均在 Llama-3-8B-Instruct 上進行，使用：

• 標準困惑度評估流程
• 2048標記的上下文窗口
• 所有量化方法使用相同的提示集

方法

• 動態精度分配：
  • 前/後25%的層 → IQ4_XS（選定層）
  • 中間50% → IQ2_XXS/IQ3_S（提高效率）
• 關鍵組件保護：
  • 嵌入層/輸出層使用Q5_K
  • 與標準1 - 2比特量化相比，誤差傳播減少38%

量化性能比較（Llama-3-8B）

量化方式	標準困惑度	DynamicGate困惑度	困惑度變化	標準大小	DG大小	大小變化	標準速度	DG速度
IQ2_XXS	11.30	9.84	-12.9%	2.5G	2.6G	+0.1G	234s	246s
IQ2_XS	11.72	11.63	-0.8%	2.7G	2.8G	+0.1G	242s	246s
IQ2_S	14.31	9.02	-36.9%	2.7G	2.9G	+0.2G	238s	244s
IQ1_M	27.46	15.41	-43.9%	2.2G	2.5G	+0.3G	206s	212s
IQ1_S	53.07	32.00	-39.7%	2.1G	2.4G	+0.3G	184s	209s

關鍵說明：

• PPL = 困惑度（越低越好）
• ∆ PPL = 從標準量化到DynamicGate量化的百分比變化
• 速度 = 推理時間（CPU avx2，2048標記上下文）
• 大小差異反映了混合量化的開銷

主要改進：

• IQ1_M 困惑度大幅降低43.9%（從27.46降至15.41）
• IQ2_S 困惑度降低36.9%，僅增加0.2GB大小
• IQ1_S 儘管是1比特量化，但準確性提高了39.7%

權衡：

• 所有變體的大小都有適度增加（0.1 - 0.3GB）
• 推理速度相近（差異小於5%）

使用場景

• 將模型裝入GPU顯存
• 內存受限的部署
• 可容忍1 - 2比特誤差的CPU和邊緣設備
• 超低比特量化研究

選擇合適的模型格式

選擇正確的模型格式取決於你的硬件能力和內存限制。

BF16（Brain Float 16） - 若支持BF16加速則使用

• 一種16位浮點格式，專為更快的計算而設計，同時保留良好的精度。
• 提供與FP32相似的動態範圍，但內存使用更低。
• 若你的硬件支持BF16加速（檢查設備規格），建議使用。
• 與FP32相比，適用於高性能推理且內存佔用減少的場景。

使用建議：

• 若你的硬件具有原生BF16支持（如較新的GPU、TPU），使用BF16。
• 若你想在節省內存的同時獲得更高的精度，使用BF16。
• 若你計劃將模型重新量化為其他格式，使用BF16。

避免使用情況：

• 若你的硬件不支持BF16（可能會回退到FP32並運行較慢），避免使用。
• 若你需要與缺乏BF16優化的舊設備兼容，避免使用。

F16（Float 16） - 比BF16更廣泛支持

• 一種16位浮點格式，精度較高，但取值範圍小於BF16。
• 適用於大多數支持FP16加速的設備（包括許多GPU和一些CPU）。
• 數值精度略低於BF16，但通常足以進行推理。

使用建議：

• 若你的硬件支持FP16但不支持BF16，使用F16。
• 若你需要在速度、內存使用和準確性之間取得平衡，使用F16。
• 若你在GPU或其他針對FP16計算優化的設備上運行，使用F16。

避免使用情況：

• 若你的設備缺乏原生FP16支持（可能運行比預期慢），避免使用。
• 若你有內存限制，避免使用。

量化模型（Q4_K、Q6_K、Q8等） - 用於CPU和低顯存推理

量化可在儘可能保持準確性的同時減小模型大小和內存使用。

• 低比特模型（Q4_K） - 最適合最小化內存使用，可能精度較低。
• 高比特模型（Q6_K、Q8_0） - 準確性更好，但需要更多內存。

使用建議：

• 若你在CPU上進行推理且需要優化的模型，使用量化模型。
• 若你的設備顯存較低且無法加載全精度模型，使用量化模型。
• 若你想在保持合理準確性的同時減少內存佔用，使用量化模型。

避免使用情況：

• 若你需要最高準確性（全精度模型更適合），避免使用。
• 若你的硬件有足夠的顯存支持更高精度的格式（BF16/F16），避免使用。

極低比特量化（IQ3_XS、IQ3_S、IQ3_M、Q4_K、Q4_0）

這些模型針對極致內存效率進行了優化，非常適合低功耗設備或內存是關鍵限制因素的大規模部署。

• IQ3_XS：超低比特量化（3比特），具有極致的內存效率。
  • 使用場景：最適合超低內存設備，即使Q4_K也太大的情況。
  • 權衡：與高比特量化相比，準確性較低。
• IQ3_S：小塊大小，實現最大內存效率。
  • 使用場景：最適合低內存設備，當IQ3_XS過於激進時使用。
• IQ3_M：中等塊大小，比IQ3_S準確性更好。
  • 使用場景：適用於低內存設備，當IQ3_S限制過多時使用。
• Q4_K：4比特量化，具有逐塊優化以提高準確性。
  • 使用場景：最適合低內存設備，當Q6_K太大時使用。
• Q4_0：純4比特量化，針對ARM設備進行了優化。
  • 使用場景：最適合基於ARM的設備或低內存環境。

總結表格：模型格式選擇

模型格式	精度	內存使用	設備要求	最佳使用場景
BF16	最高	高	支持BF16的GPU/CPU	減少內存的高速推理
F16	高	高	支持FP16的設備	當BF16不可用時的GPU推理
Q4_K	中低	低	CPU或低顯存設備	內存受限環境的最佳選擇
Q6_K	中等	適中	內存較多的CPU	量化模型中準確性較好的選擇
Q8_0	高	適中	有足夠顯存的CPU或GPU	量化模型中準確性最高的選擇
IQ3_XS	極低	極低	超低內存設備	極致內存效率和低準確性
Q4_0	低	低	ARM或低內存設備	llama.cpp可針對ARM設備進行優化

📦 安裝指南

此部分原文檔未提供具體安裝命令，故跳過。

💻 使用示例

基礎用法

from transformers import AutoModelForCausalLM, AutoTokenizer

model_name = "Qwen/Qwen3-4B"

# 加載分詞器和模型
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(
    model_name,
    torch_dtype="auto",
    device_map="auto"
)

# 準備模型輸入
prompt = "Give me a short introduction to large language model."
messages = [
    {"role": "user", "content": prompt}
]
text = tokenizer.apply_chat_template(
    messages,
    tokenize=False,
    add_generation_prompt=True,
    enable_thinking=True # 在思考和非思考模式之間切換。默認為True。
)
model_inputs = tokenizer([text], return_tensors="pt").to(model.device)

# 進行文本補全
generated_ids = model.generate(
    **model_inputs,
    max_new_tokens=32768
)
output_ids = generated_ids[0][len(model_inputs.input_ids[0]):].tolist() 

# 解析思考內容
try:
    # rindex查找151668 (</think>)
    index = len(output_ids) - output_ids[::-1].index(151668)
except ValueError:
    index = 0

thinking_content = tokenizer.decode(output_ids[:index], skip_special_tokens=True).strip("\n")
content = tokenizer.decode(output_ids[index:], skip_special_tokens=True).strip("\n")

print("thinking content:", thinking_content)
print("content:", content)

高級用法

思考和非思考模式切換

enable_thinking=True

默認情況下，Qwen3啟用了思考能力，類似於QwQ - 32B。這意味著模型將使用其推理能力來提高生成響應的質量。例如，當在 tokenizer.apply_chat_template 中顯式設置 enable_thinking=True 或將其保留為默認值時，模型將進入思考模式。

text = tokenizer.apply_chat_template(
    messages,
    tokenize=False,
    add_generation_prompt=True,
    enable_thinking=True  # enable_thinking的默認值為True
)

在這種模式下，模型將生成包裹在 <think>...</think> 塊中的思考內容，然後是最終響應。

⚠️ 重要提示

對於思考模式，使用 Temperature=0.6、TopP=0.95、TopK=20 和 MinP=0（generation_config.json 中的默認設置）。請勿使用貪心解碼，因為這可能導致性能下降和無限重複。更多詳細指導，請參考 最佳實踐 部分。

enable_thinking=False

提供了一個硬開關，可嚴格禁用模型的思考行為，使其功能與之前的Qwen2.5 - Instruct模型一致。這種模式在必須禁用思考以提高效率的場景中特別有用。

text = tokenizer.apply_chat_template(
    messages,
    tokenize=False,
    add_generation_prompt=True,
    enable_thinking=False  # 設置enable_thinking=False可禁用思考模式
)

在這種模式下，模型不會生成任何思考內容，也不會包含 <think>...</think> 塊。

⚠️ 重要提示

對於非思考模式，建議使用 Temperature=0.7、TopP=0.8、TopK=20 和 MinP=0。更多詳細指導，請參考 最佳實踐 部分。

高級用法：通過用戶輸入在思考和非思考模式之間切換

提供了一個軟開關機制，允許用戶在 enable_thinking=True 時動態控制模型的行為。具體來說，你可以在用戶提示或系統消息中添加 /think 和 /no_think 來逐輪切換模型的思考模式。模型將遵循多輪對話中的最新指令。

from transformers import AutoModelForCausalLM, AutoTokenizer

class QwenChatbot:
    def __init__(self, model_name="Qwen/Qwen3-4B"):
        self.tokenizer = AutoTokenizer.from_pretrained(model_name)
        self.model = AutoModelForCausalLM.from_pretrained(model_name)
        self.history = []

    def generate_response(self, user_input):
        messages = self.history + [{"role": "user", "content": user_input}]

        text = self.tokenizer.apply_chat_template(
            messages,
            tokenize=False,
            add_generation_prompt=True
        )

        inputs = self.tokenizer(text, return_tensors="pt")
        response_ids = self.model.generate(**inputs, max_new_tokens=32768)[0][len(inputs.input_ids[0]):].tolist()
        response = self.tokenizer.decode(response_ids, skip_special_tokens=True)

        # 更新歷史記錄
        self.history.append({"role": "user", "content": user_input})
        self.history.append({"role": "assistant", "content": response})

        return response

# 示例用法
if __name__ == "__main__":
    chatbot = QwenChatbot()

    # 第一次輸入（無/think或/no_think標籤，默認啟用思考模式）
    user_input_1 = "How many r's in strawberries?"
    print(f"User: {user_input_1}")
    response_1 = chatbot.generate_response(user_input_1)
    print(f"Bot: {response_1}")
    print("----------------------")

    # 第二次輸入帶有/no_think
    user_input_2 = "Then, how many r's in blueberries? /no_think"
    print(f"User: {user_input_2}")
    response_2 = chatbot.generate_response(user_input_2)
    print(f"Bot: {response_2}") 
    print("----------------------")

    # 第三次輸入帶有/think
    user_input_3 = "Really? /think"
    print(f"User: {user_input_3}")
    response_3 = chatbot.generate_response(user_input_3)
    print(f"Bot: {response_3}")

⚠️ 重要提示

為了API兼容性，當 enable_thinking=True 時，無論用戶是否使用 /think 或 /no_think，模型都會始終輸出一個包裹在 <think>...</think> 中的塊。但是，如果思考被禁用，這個塊內的內容可能為空。當 enable_thinking=False 時，軟開關無效。無論用戶輸入任何 /think 或 /no_think 標籤，模型都不會生成思考內容，也不會包含 <think>...</think> 塊。

智能體使用

Qwen3在工具調用能力方面表現出色。建議使用 [Qwen - Agent](https://github.com/QwenLM/Qwen - Agent) 來充分發揮Qwen3的智能體能力。Qwen - Agent內部封裝了工具調用模板和工具調用解析器，大大降低了編碼複雜度。

要定義可用工具，可以使用MCP配置文件，使用Qwen - Agent的集成工具，或自行集成其他工具。

from qwen_agent.agents import Assistant

# 定義大語言模型
llm_cfg = {
    'model': 'Qwen3-4B',

    # 使用Alibaba Model Studio提供的端點：
    # 'model_type': 'qwen_dashscope',
    # 'api_key': os.getenv('DASHSCOPE_API_KEY'),

    # 使用與OpenAI API兼容的自定義端點：
    'model_server': 'http://localhost:8000/v1',  # api_base
    'api_key': 'EMPTY',

    # 其他參數：
    # 'generate_cfg': {
    #         # 添加：當響應內容為 `<think>this is the thought</think>this is the answer;
    #         # 不添加：當響應已被推理內容和內容分隔時。
    #         'thought_in_content': True,
    #     },
}

# 定義工具
tools = [
    {'mcpServers': {  # 可以指定MCP配置文件
            'time': {
                'command': 'uvx',
                'args': ['mcp-server-time', '--local-timezone=Asia/Shanghai']
            },
            "fetch": {
                "command": "uvx",
                "args": ["mcp-server-fetch"]
            }
        }
    },
  'code_interpreter',  # 內置工具
]

# 定義智能體
bot = Assistant(llm=llm_cfg, function_list=tools)

# 流式生成
messages = [{'role': 'user', 'content': 'https://qwenlm.github.io/blog/ Introduce the latest developments of Qwen'}]
for responses in bot.run(messages=messages):
    pass
print(responses)

處理長文本

Qwen3原生支持長達32,768個標記的上下文長度。對於總長度（包括輸入和輸出）顯著超過此限制的對話，建議使用RoPE縮放技術來有效處理長文本。已使用 YaRN 方法驗證了模型在長達131,072個標記的上下文長度上的性能。

YaRN目前得到了幾個推理框架的支持，例如本地使用的 transformers 和 llama.cpp，以及用於部署的 vllm 和 sglang。一般來說，有兩種方法可以為支持的框架啟用YaRN：

• 修改模型文件： 在 config.json 文件中添加 rope_scaling 字段：

  {
      ...,
      "rope_scaling": {
          "rope_type": "yarn",
          "factor": 4.0,
          "original_max_position_embeddings": 32768
      }
  }
  

  對於 llama.cpp，修改後需要重新生成GGUF文件。

• 傳遞命令行參數： 對於 vllm，可以使用

  vllm serve ... --rope-scaling '{"rope_type":"yarn","factor":4.0,"original_max_position_embeddings":32768}' --max-model-len 131072  
  

  對於 sglang，可以使用

  python -m sglang.launch_server ... --json-model-override-args '{"rope_scaling":{"rope_type":"yarn","factor":4.0,"original_max_position_embeddings":32768}}'
  

  對於 llama.cpp 中的 llama-server，可以使用

  llama-server ... --rope-scaling yarn --rope-scale 4 --yarn-orig-ctx 32768
  

⚠️ 重要提示

若遇到以下警告

Unrecognized keys in `rope_scaling` for 'rope_type'='yarn': {'original_max_position_embeddings'}

請升級 transformers>=4.51.0。

💡 使用建議

所有知名的開源框架都實現了靜態YaRN，這意味著縮放因子無論輸入長度如何都保持不變，可能會影響較短文本的性能。建議僅在需要處理長上下文時添加 rope_scaling 配置。也建議根據需要修改 factor。例如，如果你的應用程序的典型上下文長度為65,536個標記，最好將 factor 設置為2.0。

💡 使用建議

config.json 中的默認 max_position_embeddings 設置為40,960。此分配包括為輸出保留32,768個標記和為典型提示保留8,192個標記，這對於大多數短文本處理場景來說已經足夠。如果平均上下文長度不超過32,768個標記，不建議在這種情況下啟用YaRN，因為這可能會降低模型性能。

💡 使用建議

阿里巴巴模型工作室提供的端點默認支持動態YaRN，無需額外配置。

📚 詳細文檔

包含文件及詳情

Qwen3-4B-bf16.gguf

• 模型權重以BF16格式保存。
• 若要將模型重新量化為其他格式，請使用此文件。
• 若你的設備支持BF16加速，此文件為最佳選擇。

Qwen3-4B-f16.gguf

• 模型權重以F16格式存儲。
• 若你的設備支持FP16，尤其是在BF16不可用時，使用此文件。

Qwen3-4B-bf16-q8_0.gguf

• 輸出和嵌入層保持為BF16。
• 所有其他層量化為Q8_0。
• 若你的設備支持BF16且需要量化版本，使用此文件。

Qwen3-4B-f16-q8_0.gguf

• 輸出和嵌入層保持為F16。
• 所有其他層量化為Q8_0。

Qwen3-4B-q4_k.gguf

• 輸出和嵌入層量化為Q8_0。
• 所有其他層量化為Q4_K。
• 適合內存有限的CPU推理。

Qwen3-4B-q4_k_s.gguf

• 最小的Q4_K變體，以犧牲準確性為代價減少內存使用。
• 最適合極低內存設置。

Qwen3-4B-q6_k.gguf

• 輸出和嵌入層量化為Q8_0。
• 所有其他層量化為Q6_K。

Qwen3-4B-q8_0.gguf

• 完全Q8量化的模型，以獲得更好的準確性。
• 需要更多內存，但提供更高的精度。

Qwen3-4B-iq3_xs.gguf

• IQ3_XS量化，針對極致內存效率進行了優化。
• 最適合超低內存設備。

Qwen3-4B-iq3_m.gguf

• IQ3_M量化，提供中等塊大小以提高準確性。
• 適用於低內存設備。

Qwen3-4B-q4_0.gguf

• 純Q4_0量化，針對ARM設備進行了優化。
• 最適合低內存環境。
• 若追求更高準確性，建議使用IQ4_NL。

測試模型

如果你覺得這些模型有用：

• 請點擊“點贊”，如果你覺得這很有用！
• 幫助測試我的由AI驅動的網絡監控助手，進行量子就緒安全檢查： 免費網絡監控器

測試方法：

1. 點擊聊天圖標（任何頁面的右下角）
2. 選擇一個AI助手類型：
   • TurboLLM（GPT - 4 - mini）
   • FreeLLM（開源）
   • TestLLM（僅支持CPU的實驗性模型）

測試內容

正在探索用於AI網絡監控的小型開源模型的極限，具體包括：

• 針對即時網絡服務的函數調用
• 模型可以多小，同時仍能處理：
  • 自動化Nmap掃描
  • 量子就緒檢查
  • Metasploit集成

TestLLM - 當前實驗性模型（llama.cpp在6個CPU線程上）

• 零配置設置
• 加載時間約30秒（推理速度慢，但無API成本）
• 尋求幫助！ 如果你對邊緣設備AI感興趣，讓我們一起合作！

其他助手

• TurboLLM - 使用gpt - 4 - mini進行：

  • 即時網絡診斷
  • 自動化滲透測試（Nmap/Metasploit）
  • 通過 下載免費網絡監控代理 獲得更多令牌

• HugLLM - 開源模型（約80億參數）：

  • 令牌數量是TurboLLM的2倍
  • 由AI驅動的日誌分析
  • 在Hugging Face推理API上運行

示例AI命令測試

1. "Give me info on my websites SSL certificate"
2. "Check if my server is using quantum safe encyption for communication"
3. "Run a quick Nmap vulnerability test"

🔧 技術細節

此模型使用 llama.cpp 在提交版本 19e899c 下生成。

📄 許可證

本項目採用 Apache 2.0 許可證。

最佳實踐

為了實現最佳性能，建議遵循以下設置：

1. 採樣參數：
   • 對於思考模式（enable_thinking=True），使用 Temperature=0.6、TopP=0.95、TopK=20 和 MinP=0。請勿使用貪心解碼，因為這可能導致性能下降和無限重複。
   • 對於非思考模式（enable_thinking=False），建議使用 Temperature=0.7、TopP=0.8、TopK=20 和 MinP=0。
   • 對於支持的框架，可以在0到2之間調整 presence_penalty 參數以減少無限重複。然而，使用較高的值可能偶爾會導致語言混合和模型性能略有下降。
2. 足夠的輸出長度：對於大多數查詢，建議使用32,768個標記的輸出長度。對於高度複雜問題的基準測試，如數學和編程競賽中的問題，建議將最大輸出長度設置為38,912個標記。這為模型提供了足夠的空間來生成詳細和全面的響應，從而提高其整體性能。
3. 標準化輸出格式：在進行基準測試時，建議使用提示來標準化模型輸出。
   • 數學問題：在提示中包含 “Please reason step by step, and put your final answer within \boxed{}.”。
   • 多項選擇題：在提示中添加以下JSON結構以標準化響應：“Please show your choice in the answer field with only the choice letter, e.g., "answer": "C".”
4. 歷史記錄中不包含思考內容：在多輪對話中，歷史模型輸出應僅包括最終輸出部分，不需要包括思考內容。這在Jinja2提供的聊天模板中已經實現。然而，對於不直接使用Jinja2聊天模板的框架，開發者需要確保遵循此最佳實踐。

引用

如果你覺得我們的工作有幫助，請引用：

@misc{qwen3,
    title  = {Qwen3},
    url    = {https://qwenlm.github.io/blog/qwen3/},
    author = {Qwen Team},
    month  = {April},
    year   = {2025}
}