Perplexity Decider v1.1: Qwen Routing Setup and Deployment Checks

Perplexity Decider v1.1 is a Qwen-derived decision checkpoint for classification and routing. It returns probabilities over a defined set of answers instead of generating a chat response. That distinction matters when deploying it: a conventional language-model server can load related weights yet fail to preserve the behavior the publisher evaluated.

The official checkpoint card describes the model layout and its native inference path. The guidance below follows that revision and does not claim a routing benchmark or production saving of our own.

Perplexity Decider v1.1 checkpoint format

The model's exact repository name is perplexity-ai/pplx-decider-v1.1-27b; the spelling is pplx, even when a news summary abbreviates it differently. Its card identifies Qwen3.8-27B as the base model.

The artifact combines a backbone with a separate decision readout. The documented readout is a BF16 tensor with shape [255, 5120], rather than a full-vocabulary language-model output head. A server expecting ordinary generated text therefore needs an explicit compatibility layer.

A Transformers class name in the files is not a reliable substitute for the model's declared lineage. Keep the repository identifier, revision and model card together in the deployment record.

Preserve the supplied attention and calibration

The native implementation is the safest baseline because it preserves the configuration used for the released checkpoint. The card explains that full-attention layers use a saved noncausal mode while linear-attention layers retain their own behavior. Replacing that with a default causal configuration produces a different inference condition.

Calibration also belongs to the checkpoint's prediction contract. The supplied DecisionModel.predict applies the saved temperature. If your application consumes raw logits instead, it must use the correct temperature once and normalize over the valid candidates for that particular question.

This is why exporting the weights into a convenient serving format requires more than checking that tensor shapes load. You need to preserve the attention behavior, readout-to-answer mapping and calibration. Compare outputs from the native path and the proposed export on fixed inputs before using the export to control routes.

For an initial evaluation, keep everything native. Serving optimization can wait until you have a trusted reference result.

Load the native decision implementation

The card specifies Python 3.12 or later, the repository's pinned requirements and a CUDA GPU with room for roughly 49GiB of weights plus working memory. That weight estimate is not the complete peak-memory requirement.

Download the reviewed snapshot, inspect its requirements and source, then use the documented implementation. This example changes the question and state while retaining its API:

import sys
from pathlib import Path
from huggingface_hub import snapshot_download

checkpoint = Path(snapshot_download(
    "perplexity-ai/pplx-decider-v1.1-27b",
    revision="6195aa55a72ae21e503c8a60198f7b390d42adb5",
))
sys.path.insert(0, str(checkpoint / "source" / "src"))
from autojev.model import DecisionModel, answer

model = DecisionModel(checkpoint, device="cuda")
question = {
    "type": "choice",
    "instructions": "Select the appropriate support queue.",
    "criteria": {
        "integration": "API configuration and software failures",
        "billing": "Invoices, balances and payment questions",
    },
}
row = {
    "state": "The API returns an authentication error after I changed clients.",
    "question": question,
}
probabilities = model.predict([row])[0]
print(answer(question, probabilities))

Importing the downloaded implementation executes repository code, so review that code in the environment where it will run. The example is not an HTTP endpoint and does not define an application-wide response schema.

The card contains an authenticated-access instruction, while the public repository metadata was ungated when checked. Verify access for the exact snapshot rather than treating either a visible card or older wording as proof about your account.

Prepare a labeled routing evaluation

Start with routes that your application can actually serve. Give each a clear description and add cases that are ambiguous, incomplete or unsupported. A classifier forced to pick among inadequate options can return a confident answer that still sends the request to the wrong destination.

Use human labels or another reliable acceptance process. Separate the development examples used to edit criteria from the held-out evaluation set. Measure the errors that matter: a billing request sent to a coding assistant, a repository task routed to a simple summarizer, or an unsupported question accepted as routine.

The publisher reports a higher overall Decision Index score for v1.1 than v1. Those results are useful release context, but the overall suite uses its own weighting. They do not establish accuracy for your labels, input languages or routing costs.

Choose confidence thresholds and fallback behavior from your own evaluation. Record abstentions and retries as well as correct top choices. An application that handles uncertainty explicitly can be more useful than one that always dispatches an answer.

Budget images, memory and integration work

The documented image processor preserves aspect ratio, rounds dimensions to multiples of 32 and limits total image area. Its default maximum is 2048 × 2048 pixels, corresponding to at most about 4,096 visual tokens per image under the card's patch calculation.

Use realistic image sizes in the memory and latency test. A text-only benchmark does not describe a workflow that adds several screenshots. Keep preprocessing settings fixed when comparing requests, and log when large images are resized.

For a smaller self-hosted comparison, our Decision 2.0 guide covers a separate family and interface. A hosted option is described in the Cloudflare Clef guide. Compare them using the same application labels while preserving each model's own contract.

Conclusion: preserve behavior before optimizing serving

Perplexity Decider v1.1 is a candidate for a well-defined routing job when its native checkpoint and memory requirement fit your infrastructure. Establish reference outputs, evaluate routing errors and only then consider an export or gateway adapter. The reviewed artifact lists Apache-2.0; retain the relevant notices and check the deployment's additional dependencies.

Frequently asked questions

Can I serve this as an ordinary chat model?

Its native layout has a separate decision readout. Ordinary chat serving does not automatically preserve the evaluated behavior.

Is 49GiB the complete GPU requirement?

The card describes roughly that amount for weights plus additional working memory. Measure the complete peak for your request size and concurrency.

Does the benchmark improvement prove better routes for my product?

No. Evaluate the checkpoint on your own labels and traffic, including the cost of incorrect routes and fallback calls.