GLM-5.2 is live. #1 throughput on OpenRouter, pay-per-token on FriendliAI. Try it today ➜
Kritpawit
Available on FriendliAI
Run this model inference on single tenant GPU with unmatched speed and reliability at scale.
Model Details
Model Provider
Kritpawit
Model Tree
huginnfork/Qwen3.8-27B-NVFP4A16
Input Modalities
Output Modalities
Supported Functionality
The original repo's tokenizer.json ships with truncation hardcoded into the Rust tokenizer's persistent state:
json
"truncation": {"direction": "Right", "max_length": 2048, "strategy": "LongestFirst", "stride": 0}
This contradicts the model_max_length: 262144 declared elsewhere in the same checkpoint (likely baked in by llm-compressor calibration, which commonly tokenizes calibration data at max_length: 2048, with the tokenizer saved after that config was applied).
Consequences for every downstream user of the original checkpoint:
<|image_pad|> placeholders (images needing > ~2048 combined tokens, e.g. anything above ~1500×1500 px), transformers' _check_special_mm_tokens raises a token-count mismatch that vLLM re-wraps as an opaque "Failed to apply Qwen3VLProcessor..." error.Exactly one file differs from the original:
| File | Change |
|---|---|
tokenizer.json | "truncation": null (was max_length: 2048) |
Everything else — weights, configs, chat template, preprocessor configs — is untouched.
With truncation disabled, over-length prompts are rejected explicitly by the serving stack (e.g. vLLM's --max-model-len check) instead of being silently truncated, which is the correct failure mode.
python
from transformers import AutoTokenizertok = AutoTokenizer.from_pretrained("Kritpawit/Qwen3.8-27B-NVFP4A16")print(tok.init_kwargs.get("max_length")) # -> None (original: 2048)print(tok.model_max_length) # -> 262144ids = tok("x " * 5000)["input_ids"]print(len(ids)) # -> full length, not capped at 2048