ERNIE 5.5 Flash Base Requirements

ERNIE 5.5 Flash Base is an open-weight base model that Baidu released on November 5, 2026, built as a sparse MoE with about 280B total and 14B active parameters. Memory needs depend on precision: roughly 280-290GB for the official FP8 weights and 560-570GB for BF16 (weights only, estimates), which rules out a single consumer GPU. Four H100 80GB cards (320GB total) are about the practical floor for FP8 (estimate). Although speed is closer to a 14B model, all 280B parameters must sit in memory.

Parameter counts, architecture, benchmarks and launch commands below come from the official announcement and model card. Memory needs, GPU configurations, and Apple Silicon or CPU-offload feasibility are our own estimates computed from the parameter count; Baidu has not published a required GPU count. This is also a Base model, a checkpoint from the end of pre-training, so it is not suited to chat as-is.

If you want to check quickly whether your own GPU or Mac can run a model, the free VRAM calculator (no sign-up) estimates required VRAM from the model, quantization, and context length you select. ERNIE 5.5 Flash Base is also available in the model list.

The table covers weights only. KV cache, the CUDA context, activations and communication buffers come on top, so plan for an extra 10-20% of the weight size (estimate).

The official page is https://ernie.baidu.com/release/ernie-5-5-flash-base/. Weights are on Hugging Face as baidu/ERNIE-5.5-Flash-Base (FP8, F8_E4M3) and baidu/ERNIE-5.5-Flash-Base-BF16 (BF16). The FP8 build is the standard form, and training itself used FP8 mixed precision.

For each token, an MoE activates only the top-10 of 512 experts plus the shared expert. Per-token compute and decode speed therefore resemble a 14B-active model. But which experts get picked changes with every input, so all 280B parameters must stay in fast memory at all times.

In short, it is light on compute and heavy on memory. The same structure shows up in the Kimi K3.1 Pro requirements analysis. Expert parallelism spreads experts across GPUs and lifts throughput, but inter-GPU bandwidth then decides performance.

Weight size is roughly total parameters x bits / 8. At 280B, FP8 is about 280GB and BF16 about 560GB; using the HF figure of 286B gives about 286GB and 572GB. All of the following are estimates.

- FP8: ~280-290GB. The official standard form, and the one the 4-GPU example commands assume
- BF16: ~560-570GB. For fine-tuning where precision matters, or hardware without FP8 support
- 4-bit (Q4-class): ~150-170GB. A 4.8-bit format gives 280B x 4.8 / 8 = ~168GB. No official build; waiting on community releases
- 2-3 bit: ~90-120GB. Covers 280B x 2.6-3.4 bits / 8. Expect quality loss and instability from uneven expert usage

MLA keeps the KV cache smaller than standard attention. Assuming roughly 50KB per token (a rough guess using a DeepSeek-style latent size, not ERNIE's actual value), 131,072 tokens take about 6-7GB and 1M tokens around 50GB. The HCA part is not included, so measure before relying on long contexts. For background on quantization, see the LFM3 requirements guide.

Baidu does not state a required GPU count or model. The example commands use four GPUs (SGLang with TP4 and attn-dp-size 4; vLLM with DP4 and expert parallelism), and the SGLang cookbook references B300. On 4x H100, FP8 weights alone take about 90% of memory, leaving little room for KV cache and runtime overhead, so context length stays small (estimate). For headroom, four H200 or B200/B300 cards are more realistic.

Native FP8 compute requires H100-class or newer hardware. On older GPUs such as the A100 you would fall back to BF16, which doubles the memory requirement.

Unified memory lets Apple Silicon hold very large models without a separate VRAM limit. However, there is currently no official quantized or MLX build, so you would need to convert it yourself or wait for community releases. The figures below assume a 4-bit build appears (estimates).

- 512GB class (M3 Ultra, or an M4 Ultra if released): ~150-170GB at 4-bit fits and is a strong candidate. Memory bandwidth is below that of GPU servers, so prompt processing tends to be slow
- 192GB class: 4-bit fits, but with KV cache and the OS you are limited to short contexts
- 128GB or less: even 2-3 bit is tight; not practical
- 24GB-class M-series: not possible

To get a feel for reading memory capacity on a Mac, the Raon-1 Mini requirements guide is a useful companion.

A workstation with 256GB or more of RAM could in theory hold a quantized build on the CPU side and put only some layers on a GPU. With 14B active parameters, a usable speed is possible if memory bandwidth allows. This is an estimate, and it is unconfirmed whether engines such as llama.cpp implement this architecture (hybrid MLA + HCA, Multi-Router Latent MoE). The official examples cover only SGLang and vLLM, so at launch it is not something to try casually on a home PC.

Baidu documents two inference paths, SGLang and vLLM. Both examples assume four GPUs and set the context length to 131,072. The commands below are the official examples reorganized; check the official page for driver, CUDA, and image versions before running them.

SGLang uses the dedicated image lmsysorg/sglang:dev-ernie-55-flash. Inside the container, start it like this.

vLLM uses vllm==0.32.0 together with the vLLM-ERNIE plugin. It enables an FP8 KV cache and expert parallelism, and selects the humming MoE backend.

The public config enables a 1M-token context, while the samples stop at 131,072. At 1M the KV cache grows, so use the estimates above to add GPUs or lower the context length.

ERNIE 5.5 Flash Base is the checkpoint at the end of pre-training, with no mid-training or post-training. Baidu says a post-trained chat version will follow later. It is therefore not suited to following instructions in a conversation as-is; given a prompt, it mainly continues the text.

- Base for fine-tuning: a starting point for supervised training or instruction tuning on your data
- Continued pre-training: further training on domain-specific text
- Evaluation and research: Base-to-Base benchmarks and studying the architecture (MLA + HCA, Hyper-Connections, and so on)
- Distillation source: a teacher model for transferring knowledge to smaller models
- For chat, it is safer to wait for the post-trained release

Fine-tuning needs gradients and optimizer state on top of the weights, which takes far more memory than inference. Even with LoRA-style methods, the BF16 weights of roughly 570GB are the baseline, so multi-node GPU capacity is effectively required (estimate).

Baidu's page compares against the Base models DeepSeek-V4-Flash-Base, Hy3-preview-Base and MiMo-V2.5-Base. The values below are ERNIE 5.5 Flash Base results as published by Baidu, so they are self-reported.

In Baidu's table ERNIE 5.5 Flash Base leads on many rows, but DeepSeek-V4-Flash-Base is ahead on others such as ChineseSimpleQA and InfiniteBench. These compare Base models and say little about chat quality or day-to-day usability. Test on data close to your own use case before deciding.

The license is the ERNIE 5.5 Flash Base Model License Agreement v1.0, with details in the LICENSE file of the repository. The model card gives no summary of commercial terms, redistribution, or derivative models. Do not assume it matches a common license such as Apache 2.0 or MIT; read the full LICENSE before any commercial use.

- CUDA out of memory at startup: the weights do not fit. Add GPUs or lower --context-length (SGLang) or --max-model-len (vLLM). Most likely on 4x H100 (estimate)
- OOM after startup: not enough room for KV cache or activations. Lower the context length, concurrent requests, or batch size
- vLLM does not recognize the model: check that vllm==0.32.0 and the vLLM-ERNIE plugin are installed together. Version mismatches are the typical cause
- SGLang will not run: use lmsysorg/sglang:dev-ernie-55-flash rather than the standard image
- Replies continue the text instead of answering: this is how a Base model behaves. Wait for the post-trained version or train it yourself
- Slow or failed download: the FP8 build is about 290GB. Check free disk space and bandwidth, and use resumable downloads
- No GGUF available: there is no official quantized build as of 2026-11-06; wait for community releases