GLM-5.3 is live. Run Z.ai's latest model on Friendli Model APIs. Try it today ➜
raoashish10
Available on FriendliAI
Run this model inference on single tenant GPU with unmatched speed and reliability at scale.
Run this model inference with full control and performance in your environment.
Model Details
Model Provider
raoashish10
Model Tree
Qwen/Qwen3-8B
Input Modalities
Output Modalities
Supported Functionality
0.46.0, examples/hf_ptq/hf_ptq.py, --qformat nvfp4 --kv_cache_qformat none.
W4A4: every linear layer's weights and input activations packed
to 4-bit with per-16-element FP8 block scale factors (group_size=16);
activation quantization uses a real, statically-calibrated input_scale
per quantized layer (amax-derived from the calibration set below), not a
dynamic/runtime estimate. Attention KV cache is left at native precision
(--kv_cache_qformat none); lm_head and model.embed_tokens are
excluded from quantization (kept BF16).cnn_dailymail, 512 samples (calibrates both the weight
and the activation quantizers — this is what populates the input_scale
tensors above). A mixed calibration set combining cnn_dailymail with
nvidia/Nemotron-Post-Training-Dataset-v2 was also considered, but the
latter is gated and no HF_TOKEN with access to it was available on the
instance used for quantization, so cnn_dailymail alone was used.1.2.1, PyTorch backend
specifically (trtllm-serve serve --backend pytorch or
tensorrt_llm.llmapi.LLM with the default backend). The classic
_TrtLLM backend is confirmed broken for this checkpoint (real
repetition/degenerate-output bug under exact-greedy decoding) — do not
serve this checkpoint on the classic backend.TensorRT-LLM, PyTorch backend, not the classic _TrtLLM backend (see above):
bash
trtllm-serve serve raoashish10/Qwen3-8B-NVFP4 \--backend pytorch \--max_seq_len 4096 \--max_batch_size 8 \--free_gpu_memory_fraction 0.2
--max_seq_len 4096 and --free_gpu_memory_fraction 0.2 are example
short-context, GPU-sharing deployment values, not general
defaults — raise --max_seq_len toward this model's real
32768/131072-with-YaRN capability for longer context, and raise
--free_gpu_memory_fraction if you're not sharing the GPU with other
processes.
vLLM and SGLang both auto-detect this checkpoint's
hf_quant_config.json (quant_algo: NVFP4, real W4A4, per-16-
element block scales) via --quantization modelopt_fp4, per their own
docs (vLLM,
SGLang) —
neither has actually been run against this checkpoint
(only the TensorRT-LLM path above has); the command below is the
documented, expected-correct invocation, not a verified one.
bash
# SGLang (>=0.4.10)python3 -m sglang.launch_server \--model-path raoashish10/Qwen3-8B-NVFP4 \--quantization modelopt_fp4
[!WARNING] vLLM will currently fail to load this checkpoint on consumer Blackwell (SM120, e.g. RTX 50-series) GPUs. vLLM's
modelopt_fp4loader routes a realNVFP4(W4A4) checkpoint like this one through a cutlass kernel (via FlashInfer), and FlashInfer does not yet ship an SM120 build of that kernel — it fails at load time with(confirmed directly against this checkpoint on an RTX 5070 Ti, vLLM 0.28.0). This is a real hardware/kernel-support gap, not something fixable by changing this repo's metadata — this checkpoint's activations are genuinely quantized, and a W4A4 kernel is required to serve that correctly. If you need vLLM on such a GPU, use the weight-only sibling repo instead: raoashish10/Qwen3-8B-NVFP4-W4A16, which loads via vLLM's Marlin kernel with no such requirement (verified working on the same RTX 5070 Ti). On datacenter Blackwell (B200/GB200) or other GPUs with a supported cutlass/FlashInfer NVFP4 build, this repo should load in vLLM as-is viamarkdown
RuntimeError: No supported CUDA architectures found for major versions [12]— not independently verified either way.markdown
vllm serve raoashish10/Qwen3-8B-NVFP4 --quantization modelopt_fp4
SGLang exposes an OpenAI-compatible endpoint on port 8000 by default. This
checkpoint ships with Qwen3's "thinking mode" on by default — see the
important note right below before calling either — pass
chat_template_kwargs={"enable_thinking": false} in the request body for
low-latency use, the same as the TensorRT-LLM path.
Measured on an RTX 5070 Ti (15.47GiB usable VRAM), including a test of running alongside other models concurrently on a memory-constrained GPU — not just static benchmarks:
| Checkpoint size on disk | 6.0GB |
| Standalone VRAM footprint (PyTorch backend, loaded) | 8.7GB |
MMLU (mmlu_generative, 57 subjects × 20 samples, n=1140) | 72.9% |
| IFEval (n=100 of 541) | 79.0% prompt-strict / 85.3% inst-strict |
Short-response fitness (20 representative prompts, enable_thinking: false + a short system prompt) | 100% clean-stop rate, median 23 completion tokens |
| Standalone latency (streaming, unbatched) | TTFT p50 0.029s, 131.6 tokens/s |
| Concurrent GPU-sharing test: fits alongside ~3-4.5GB of other concurrently-running models with (3.4-4.9GB free); latency degradation of those other models while this one generates concurrently measured at . |
Important — this model ships with "thinking mode" enabled by default
(inherited from base Qwen3). Naive deployment can reproduce a
token-cap-hit/rambling failure mode: a small token budget can be entirely
consumed by an unclosed <think>...</think> block with zero actual answer
produced. For low-latency use, pass
chat_template_kwargs={"enable_thinking": false} (or the equivalent
enable_thinking=False in apply_chat_template) plus a short system
prompt constraining response style — with both, the model did not
reproduce the failure mode at all in the sample above (0% token-cap-hit).
Apache-2.0, inherited from the base Qwen/Qwen3-8B model. Quantization does not change the license terms.
The remainder of this card is the original Qwen3-8B model card, kept for reference — it describes the base model's general capabilities, not this checkpoint's quantization or the results above.
Qwen3 is the latest generation of large language models in Qwen series, offering a comprehensive suite of dense and mixture-of-experts (MoE) models. Built upon extensive training, Qwen3 delivers groundbreaking advancements in reasoning, instruction-following, agent capabilities, and multilingual support, with the following key features:
Qwen3-8B has the following features:
For more details, including benchmark evaluation, hardware requirements, and inference performance, please refer to our blog, GitHub, and Documentation.
[!NOTE] The "Quickstart" and general usage sections below describe the original BF16 Qwen3-8B model, loaded via plain
transformers. This repository contains the NVFP4-quantized checkpoint, which should be loaded via TensorRT-LLM (see "Quantization" above), not viaAutoModelForCausalLM.from_pretrainedas shown below.
The code of Qwen3 has been in the latest Hugging Face transformers and we advise you to use the latest version of transformers.
With transformers<4.51.0, you will encounter the following error:
markdown
KeyError: 'qwen3'
The following contains a code snippet illustrating how to use the model generate content based on given inputs.
python
from transformers import AutoModelForCausalLM, AutoTokenizermodel_name = "Qwen/Qwen3-8B"# load the tokenizer and the modeltokenizer = AutoTokenizer.from_pretrained(model_name)model = AutoModelForCausalLM.from_pretrained(model_name,torch_dtype="auto",device_map="auto")# prepare the model inputprompt = "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 # Switches between thinking and non-thinking modes. Default is True.)model_inputs = tokenizer([text], return_tensors="pt").to(model.device)# conduct text completiongenerated_ids = model.generate(**model_inputs,max_new_tokens=32768)output_ids = generated_ids[0][len(model_inputs.input_ids[0]):].tolist()# parsing thinking contenttry:# rindex finding 151668 (</think>)index = len(output_ids) - output_ids[::-1].index(151668)except ValueError:index = 0thinking_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)
For deployment, you can use sglang>=0.4.6.post1 or vllm>=0.8.5 or to create an OpenAI-compatible API endpoint:
shell
python -m sglang.launch_server --model-path Qwen/Qwen3-8B --reasoning-parser qwen3
shell
vllm serve Qwen/Qwen3-8B --enable-reasoning --reasoning-parser deepseek_r1
For local use, applications such as Ollama, LMStudio, MLX-LM, llama.cpp, and KTransformers have also supported Qwen3.
[!TIP] The
enable_thinkingswitch is also available in APIs created by SGLang and vLLM. Please refer to our documentation for SGLang and vLLM users.
enable_thinking=TrueBy default, Qwen3 has thinking capabilities enabled, similar to QwQ-32B. This means the model will use its reasoning abilities to enhance the quality of generated responses. For example, when explicitly setting enable_thinking=True or leaving it as the default value in tokenizer.apply_chat_template, the model will engage its thinking mode.
python
text = tokenizer.apply_chat_template(messages,tokenize=False,add_generation_prompt=True,enable_thinking=True # True is the default value for enable_thinking)
In this mode, the model will generate think content wrapped in a <think>...</think> block, followed by the final response.
[!NOTE] For thinking mode, use
Temperature=0.6,TopP=0.95,TopK=20, andMinP=0(the default setting ingeneration_config.json). DO NOT use greedy decoding, as it can lead to performance degradation and endless repetitions. For more detailed guidance, please refer to the Best Practices section.
enable_thinking=FalseWe provide a hard switch to strictly disable the model's thinking behavior, aligning its functionality with the previous Qwen2.5-Instruct models. This mode is particularly useful in scenarios where disabling thinking is essential for enhancing efficiency.
python
text = tokenizer.apply_chat_template(messages,tokenize=False,add_generation_prompt=True,enable_thinking=False # Setting enable_thinking=False disables thinking mode)
In this mode, the model will not generate any think content and will not include a <think>...</think> block.
[!NOTE] For non-thinking mode, we suggest using
Temperature=0.7,TopP=0.8,TopK=20, andMinP=0. For more detailed guidance, please refer to the Best Practices section.
We provide a soft switch mechanism that allows users to dynamically control the model's behavior when enable_thinking=True. Specifically, you can add /think and /no_think to user prompts or system messages to switch the model's thinking mode from turn to turn. The model will follow the most recent instruction in multi-turn conversations.
Here is an example of a multi-turn conversation:
python
from transformers import AutoModelForCausalLM, AutoTokenizerclass QwenChatbot:def __init__(self, model_name="Qwen/Qwen3-8B"):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)# Update historyself.history.append({"role": "user", "content": user_input})self.history.append({"role": "assistant", "content": response})return response# Example Usageif __name__ == "__main__":chatbot = QwenChatbot()# First input (without /think or /no_think tags, thinking mode is enabled by default)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("----------------------")# Second input with /no_thinkuser_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("----------------------")# Third input with /thinkuser_input_3 = "Really? /think"print(f"User: {user_input_3}")response_3 = chatbot.generate_response(user_input_3)print(f"Bot: {response_3}")
[!NOTE] For API compatibility, when
enable_thinking=True, regardless of whether the user uses/thinkor/no_think, the model will always output a block wrapped in<think>...</think>. However, the content inside this block may be empty if thinking is disabled. Whenenable_thinking=False, the soft switches are not valid. Regardless of any/thinkor/no_thinktags input by the user, the model will not generate think content and will not include a<think>...</think>block.
Qwen3 excels in tool calling capabilities. We recommend using Qwen-Agent to make the best use of agentic ability of Qwen3. Qwen-Agent encapsulates tool-calling templates and tool-calling parsers internally, greatly reducing coding complexity.
To define the available tools, you can use the MCP configuration file, use the integrated tool of Qwen-Agent, or integrate other tools by yourself.
python
from qwen_agent.agents import Assistant# Define LLMllm_cfg = {'model': 'Qwen3-8B',# Use the endpoint provided by Alibaba Model Studio:# 'model_type': 'qwen_dashscope',# 'api_key': os.getenv('DASHSCOPE_API_KEY'),# Use a custom endpoint compatible with OpenAI API:'model_server': 'http://localhost:8000/v1', # api_base'api_key': 'EMPTY',# Other parameters:# 'generate_cfg': {# # Add: When the response content is `<think>this is the thought</think>this is the answer;# # Do not add: When the response has been separated by reasoning_content and content.# 'thought_in_content': True,# },}# Define Toolstools = [{'mcpServers': { # You can specify the MCP configuration file'time': {'command': 'uvx','args': ['mcp-server-time', '--local-timezone=Asia/Shanghai']},"fetch": {"command": "uvx","args": ["mcp-server-fetch"]}}},'code_interpreter', # Built-in tools]# Define Agentbot = Assistant(llm=llm_cfg, function_list=tools)# Streaming generationmessages = [{'role': 'user', 'content': 'https://qwenlm.github.io/blog/ Introduce the latest developments of Qwen'}]for responses in bot.run(messages=messages):passprint(responses)
Qwen3 natively supports context lengths of up to 32,768 tokens. For conversations where the total length (including both input and output) significantly exceeds this limit, we recommend using RoPE scaling techniques to handle long texts effectively. We have validated the model's performance on context lengths of up to 131,072 tokens using the YaRN method.
YaRN is currently supported by several inference frameworks, e.g., transformers and llama.cpp for local use, vllm and sglang for deployment. In general, there are two approaches to enabling YaRN for supported frameworks:
Modifying the model files:
In the config.json file, add the rope_scaling fields:
json
{...,"rope_scaling": {"rope_type": "yarn","factor": 4.0,"original_max_position_embeddings": 32768}}
For llama.cpp, you need to regenerate the GGUF file after the modification.
Passing command line arguments:
For vllm, you can use
shell
vllm serve ... --rope-scaling '{"rope_type":"yarn","factor":4.0,"original_max_position_embeddings":32768}' --max-model-len 131072
For sglang, you can use
shell
python -m sglang.launch_server ... --json-model-override-args '{"rope_scaling":{"rope_type":"yarn","factor":4.0,"original_max_position_embeddings":32768}}'
For llama-server from llama.cpp, you can use
shell
llama-server ... --rope-scaling yarn --rope-scale 4 --yarn-orig-ctx 32768
[!IMPORTANT] If you encounter the following warning
markdown
Unrecognized keys in `rope_scaling` for 'rope_type'='yarn': {'original_max_position_embeddings'}please upgrade
transformers>=4.51.0.
[!NOTE] All the notable open-source frameworks implement static YaRN, which means the scaling factor remains constant regardless of input length, potentially impacting performance on shorter texts. We advise adding the
rope_scalingconfiguration only when processing long contexts is required. It is also recommended to modify thefactoras needed. For example, if the typical context length for your application is 65,536 tokens, it would be better to setfactoras 2.0.
[!NOTE] The default
max_position_embeddingsinconfig.jsonis set to 40,960. This allocation includes reserving 32,768 tokens for outputs and 8,192 tokens for typical prompts, which is sufficient for most scenarios involving short text processing. If the average context length does not exceed 32,768 tokens, we do not recommend enabling YaRN in this scenario, as it may potentially degrade model performance.
[!TIP] The endpoint provided by Alibaba Model Studio supports dynamic YaRN by default and no extra configuration is needed.
To achieve optimal performance, we recommend the following settings:
Sampling Parameters:
enable_thinking=True), use Temperature=0.6, TopP=0.95, TopK=20, and MinP=0. DO NOT use greedy decoding, as it can lead to performance degradation and endless repetitions.enable_thinking=False), we suggest using Temperature=0.7, TopP=0.8, TopK=20, and MinP=0.presence_penalty parameter between 0 and 2 to reduce endless repetitions. However, using a higher value may occasionally result in language mixing and a slight decrease in model performance.If you find our work helpful, feel free to give us a cite.
markdown
@misc{qwen3technicalreport,title={Qwen3 Technical Report},author={Qwen Team},year={2025},eprint={2505.09388},archivePrefix={arXiv},primaryClass={cs.CL},url={https://arxiv.org/abs/2505.09388},}
| Passed |
Adequate Output Length: We recommend using an output length of 32,768 tokens for most queries. For benchmarking on highly complex problems, such as those found in math and programming competitions, we suggest setting the max output length to 38,912 tokens. This provides the model with sufficient space to generate detailed and comprehensive responses, thereby enhancing its overall performance.
Standardize Output Format: We recommend using prompts to standardize model outputs when benchmarking.
answer field with only the choice letter, e.g., "answer": "C"."No Thinking Content in History: In multi-turn conversations, the historical model output should only include the final output part and does not need to include the thinking content. It is implemented in the provided chat template in Jinja2. However, for frameworks that do not directly use the Jinja2 chat template, it is up to the developers to ensure that the best practice is followed.