Open-Weight LLM · Private & Custom AI

Qwen3-30B-A3B-FP8

MoE reasoning engine for private ops automation—thinking and non-thinking modes in one model, deployable entirely on-premise with native 32K context and YaRN extension to 131K.

Qwen3-30B-A3B-FP8 is a 30.5B-parameter mixture-of-experts model with 3.3B activated per token, offering dual-mode reasoning (deep thinking for math/code, fast inference for dialogue). FP8 quantization makes it practical for on-premise deployment without sacrificing reasoning quality. Built for teams automating operational workflows—support ticket triage, compliance doc analysis, agent tasks—while keeping all data in their own environment.

30.5B
Parameters
apache-2.0
License (OSI/permissive)
Unknown
Context
450k
Downloads

Model facts

DeveloperQwen
Parameters30.5B
Context windowUnknown
Licenseapache-2.0 — OSI/permissive
Tasktext-generation
GatedNo
Downloads450k
Likes84
Updated2025-07-26
SourceQwen/Qwen3-30B-A3B-FP8

Private deployment

Run Qwen3-30B-A3B-FP8 in your own environment

Deploy via vLLM (>=0.8.5), SGLang (>=0.4.6.post1), or transformers on a single enterprise GPU (A100 40GB or H100; estimate ~28–32GB for FP8 inference). No external API calls; data never leaves your infrastructure. Fine-grained FP8 quantization (block size 128) trades minimal accuracy for ~25–30% memory savings vs. BF16. Known issue: distributed inference with fine-grained FP8 in transformers may require `CUDA_LAUNCH_BLOCKING=1`; vLLM/SGLang workaround this.

Operational AI use cases

01

Support ticket classification & auto-routing

Enable thinking mode (default) to parse incoming support tickets for intent, urgency, and knowledge-base relevance. Router agent selects non-thinking mode for speed. Runs entirely in-house; no customer data leaves your network. Routes complex tickets to specialists, canned responses to chatbot.

02

Compliance & contract document analysis

Use thinking mode to reason through policy alignment in uploaded contracts, SOWs, and regulatory docs. Non-thinking mode surfaces summary flags and risk tags for ops review. Embedded in your document pipeline; sensitive data remains private.

03

Agentic workflow orchestration

Leverage native agent capabilities to build multi-step ops workflows: sales qualification, HR onboarding automation, financial reconciliation tasks. Thinking mode for ambiguous decisions, non-thinking for high-throughput execution. Connects to Salesforce, Workday, SAP via standard APIs—all control in-house.

Custom AI

As a base for custom AI

Ideal base for building proprietary reasoning agents and automated decision systems. MoE architecture + thinking/non-thinking toggle means you can fine-tune on your domain (legal, finance, ops) without retraining everything. 128 experts with 8 active per token allow downstream task-specific expert selection and sparse adaptation. FP8 quantization keeps inference cost low for production custom AI.

In the operating system

Where it fits

Knowledge layer (document ingestion, fact retrieval), reasoning/agent layer (multi-step decision-making, tool use), workflow orchestration. Think of it as the 'brain' in an on-premise ops AI stack: ingests unstructured data (tickets, docs, emails), reasons through operational decisions (routing, compliance, automation), and triggers downstream actions (APIs, notifications, queues).

Data control & security

Self-hosted deployment means all prompt/completion data stays within your network boundary—no third-party API logging. Reduces exposure to external model vendors' data practices and fine-tuning pipelines. Note: you remain responsible for infrastructure hardening, access control, and audit logging. FP8 quantization does not change security posture; it's a memory optimization. Unknown: whether fine-tuning introduces additional privacy concerns—requires Qwen security review.

Hardware footprint

**Estimate (FP8).** Single GPU: ~28–32 GB VRAM (A100 40GB safe; H100 80GB overkill but flexible). Multi-GPU (vLLM/SGLang): splits across devices; 2×RTX4090 (48GB each) or 4×A6000 (48GB each) viable. BF16 baseline would be ~50–55 GB; FP8 saves ~25–30%. Thinking mode (longer generation) increases KV cache; non-thinking mode is 15–20% faster.

Integration

Standard HuggingFace transformers + `device_map='auto'` for multi-GPU. OpenAI-compatible API via vLLM (drop-in for LangChain, LlamaIndex). SGLang also provides reasoning-parser integration for thinking/non-thinking switching via API. Example: wrap in FastAPI, connect to Postgres for chat history, trigger via webhook from Zapier/n8n. Transformers supports chat template with `enable_thinking` parameter—switch per-request, no model reload.

When it's not the right fit

  • You need sub-100ms latency for every request. Thinking mode adds reasoning overhead; non-thinking mode is fast but still ~200–500ms end-to-end on typical ops prompts.
  • Your ops team cannot allocate DevOps resources to manage on-premise inference (containerization, monitoring, scaling). Fully managed API (Claude, GPT-4) is simpler operationally.
  • You require SOC2/FedRAMP/PCI compliance on *the LLM vendor* (Qwen's compliance posture is Unknown). Self-hosting shifts compliance burden to your infra team.
  • Your domain involves non-English-heavy reasoning (100+ languages supported, but reasoning benchmarks focus on math/code in English; multilingual reasoning capability Unknown).

Alternatives to consider

Llama 3.1 405B (Meta)

Larger, no MoE; denser reasoning. Requires more VRAM (~300GB BF16). Open license (Llama Community), but no thinking/non-thinking toggle. Better if you want a single model without mode switching.

Mixtral 8x22B (Mistral)

MoE, 8 active experts. Smaller params (~176B total), lower inference cost. No integrated reasoning mode; you control thinking via prompts. Proven in production ops workflows (routing, classification).

Deepseek-R1-70B (Deepseek)

Reasoning-specialized, open-weight, competitive on math/code. No official MoE variant at 30B scale. Larger memory footprint; heavy on thinking overhead. Better if pure reasoning performance > cost/speed balance.

FAQ

Can we fine-tune Qwen3-30B-A3B-FP8 on our internal ops data without losing privacy?

Yes. Download the FP8 checkpoint, run training on your hardware (vLLM/SGLang/transformers compatible). Fine-tuning data never leaves your environment. Caveat: FP8 quantization may complicate QLoRA fine-tuning—check transformers version and test on a small batch first.

Is Qwen3-30B-A3B-FP8 licensed for commercial use in our product?

Apache 2.0 license permits commercial use, redistribution, and modification without royalty. You can embed it in a commercial product as long as you include the Apache 2.0 notice. No Qwen trademark use without permission. Verify with your legal team if reselling model weights directly; LLM.co recommends API wrapper for customer isolation.

How do we switch between thinking and non-thinking modes in production?

Set `enable_thinking=True/False` in `tokenizer.apply_chat_template()` per request, or use `/think` / `/no_think` in the prompt. No model reload required. vLLM and SGLang expose this via API parameter. Useful: thinking mode for complex decisions (compliance review), non-thinking mode for high-volume ops (ticket tagging).

What's the performance trade-off of FP8 vs. full precision?

FP8 saves ~25–30% VRAM; inference latency is similar or slightly faster. Accuracy drop is typically <1% on reasoning tasks (Qwen benchmarks Unknown; requires internal eval). Known issue with distributed transformers inference; vLLM/SGLang are safer. For ops workflows (classification, routing), FP8 is production-grade.

Build your private ops AI stack on Qwen3.

Deploy Qwen3-30B-A3B-FP8 in your environment. LLM.co handles quantization, fine-tuning, and integration into your workflows. Keep data in-house. Start a proof-of-concept today.