模型概述
模型特點
模型能力
使用案例
🚀 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驅動的網絡監控助手,進行量子就緒安全檢查: 免費網絡監控器
測試方法:
- 點擊聊天圖標(任何頁面的右下角)
- 選擇一個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命令測試
"Give me info on my websites SSL certificate"
"Check if my server is using quantum safe encyption for communication"
"Run a quick Nmap vulnerability test"
🔧 技術細節
此模型使用 llama.cpp 在提交版本 19e899c
下生成。
📄 許可證
本項目採用 Apache 2.0 許可證。
最佳實踐
為了實現最佳性能,建議遵循以下設置:
- 採樣參數:
- 對於思考模式(
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
參數以減少無限重複。然而,使用較高的值可能偶爾會導致語言混合和模型性能略有下降。
- 對於思考模式(
- 足夠的輸出長度:對於大多數查詢,建議使用32,768個標記的輸出長度。對於高度複雜問題的基準測試,如數學和編程競賽中的問題,建議將最大輸出長度設置為38,912個標記。這為模型提供了足夠的空間來生成詳細和全面的響應,從而提高其整體性能。
- 標準化輸出格式:在進行基準測試時,建議使用提示來標準化模型輸出。
- 數學問題:在提示中包含 “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"
.”
- 歷史記錄中不包含思考內容:在多輪對話中,歷史模型輸出應僅包括最終輸出部分,不需要包括思考內容。這在Jinja2提供的聊天模板中已經實現。然而,對於不直接使用Jinja2聊天模板的框架,開發者需要確保遵循此最佳實踐。
引用
如果你覺得我們的工作有幫助,請引用:
@misc{qwen3,
title = {Qwen3},
url = {https://qwenlm.github.io/blog/qwen3/},
author = {Qwen Team},
month = {April},
year = {2025}
}



