Deploy DeepSeek-V4.1-Flash on GPU Cloud for 1M-Context Inference

DeepSeek-V4.1-Flash-1017 is an updated release of DeepSeek-V4.1-Flash, a multimodal mixture-of-experts model with 552 billion backbone parameters that reads text and images, writes text and holds up to 1,048,576 tokens of context. Only 8 billion parameters are active for each prompt token and 16 billion for each generated token. The whole checkpoint is 510 GB, and once its Engram memory moves to host RAM, a DeepSeek-V4.1-Flash deployment fits on one node of eight 80 GB GPUs.

This guide deploys it on a single Hyperstack virtual machine with 8x NVIDIA H100-80G-PCIe-NVLink GPUs, using vLLM 0.31.0 and the NVIDIA H100 configuration from the vLLM recipe for DeepSeek-V4.1-Flash: tensor parallel 8, the Engram tables in pinned host memory, a 4,096-token batch budget and the full one-million-token context. The result is a private, OpenAI-compatible endpoint with thinking, a reasoning effort setting from 1 to 100, tool calling and image input, ready for an agent harness such as Claude Code.

Most of what lets the model fit on one machine comes from its design rather than from tuning. DeepSeek puts its global KV cache at 890 bytes per token, about a quarter of DeepSeek-V4-Flash's, and 196 billion of its parameters are Engram lookup tables that are read rather than computed, so they can sit in host memory. If you have followed our DeepSeek-V4-Pro multi-node Kubernetes guide, this is the opposite shape: one virtual machine, no cluster and no orchestration layer.

Inside DeepSeek-V4.1-Flash: 552B Parameters, 8B Active in Prefill

DeepSeek titles the release Pushing the Limits of KV Cache Compression, and almost every component serves that aim.

The 1017 Weights: Same Architecture, Stronger Scores

DeepSeek describes DeepSeek-V4.1-Flash-1017 as a minor update to the launch release. The vLLM recipe records that its config.json, tokenizer files and prompt encoding match the launch repository byte for byte, and that the index holds the same 96,085 tensors, so only the weights change and one command serves either checkpoint.

The gains are broad. Terminal-Bench 4.0 rises from 31.2 to 42.3 and HLE without tools from 36.8 to 42.6, and DeepSeek reports shorter outputs and task execution times.

A Causal Encoder-Decoder That Nearly Halves Prefill

The 40 transformer layers are split into a 20-layer causal encoder and a 20-layer decoder. In a decoder-only model, every layer derives its keys and values from its own hidden states, so every prompt token must run through all 40 layers. Here the decoder global KV cache is projected from the final encoder hidden state instead, which lets most prompt tokens stop at the end of the encoder.

According to the technical report, this nearly halves prefill computation, and it is where the 8 billion and 16 billion figures come from: a prompt token runs the encoder, a generated token runs both halves. DeepSeek designed the split for agentic work, which the report describes as increasingly input-heavy, with frequent tool calls generating long prefills.

Compressed Sparse Attention 2: Forty Layers, Four Global Caches

From layer 2 onwards, every layer combines a 128-token sliding window with a sparse view of the global context further back; layers 0 and 1 use the sliding window alone. Compressed Sparse Attention 2, or CSA2, decides where that global context comes from by giving each of those 38 layers one of three static modes:

• Full layers compute their own global KV, score it with a lightweight indexer and keep the top 512 entries for each query.
• Reindex layers reuse the global KV of the latest Full layer, but score it with their own indexer query and pick a fresh top 512.
• Reuse layers take both the KV and the top 512 selection from an earlier layer and run attention directly.

Only four of the 40 layers compute a global cache at all: layers 2, 8, 14 and 20. The encoder stores one global entry for every two tokens, while the decoder keeps one per token. In the decoder, layer 20 also builds a candidate pool of 2,048 blocks of eight positions, and the four Reindex layers search only those 16,384 candidates, so their cost per query stays constant however long the context grows.

890 Bytes of Global KV per Token

The saving has two sources. One is sharing caches across layers; the other is precision: DeepSeek trains the main KV cache to be stored in FP4, as E2M1 values with one E4M3 scale per 16 channels, while the sliding-window cache stays in FP8. Together they put the global KV footprint at 890 bytes per token, 3.9 times smaller than DeepSeek-V4-Flash, the model in our DeepSeek-V4 deployment guide, and 437 times smaller than DeepSeek-V1.

For a broader view of where KV cache memory goes and how serving engines manage it, our guide to optimising the KV cache covers the techniques this design builds on.

Engram: 196B Parameters That Are Looked Up, Not Computed

Engram is the module that makes the memory plan work. At layers 1 and 14, the last two, three and four tokens at each position are hashed into two tables of roughly 384 million rows each, and the retrieved rows are gated into the residual stream. A mixture of experts adds capacity through conditional computation; Engram adds it through conditional memory, which the vLLM documentation describes as parameters that are never computed over, only looked up. The two tables hold 196.6 billion parameters, 183.1 GiB in FP8 or about 189 GiB with their block scales, more than a third of the checkpoint.

Because the lookup indices depend only on the input tokens, they are known before the forward pass reaches the layer. vLLM uses that to keep the tables in pinned host memory and read them over unified virtual addressing (UVA), prefetching on a side CUDA stream so the transfer overlaps the computation of the earlier layers. The GPU memory this frees goes to the KV cache.

DSpark: Five Draft Tokens per Round

DeepSeek-V4.1-Flash drops the multi-token prediction module of earlier DeepSeek models in favour of DSpark, a speculative decoding module trained after pre-training. Three transformer blocks, each with 128 routed experts and 3 active, attend over a 128-token window and compute draft logits for five positions in one pass. A Markov head models the dependencies between those drafts, and a confidence head predicts how likely each position is to be accepted.

The recipe keeps DSpark opt-in, behind one speculative decoding flag, and counts the drafter's experts, roughly 14B parameters, as an addition to the load when it is on. On NVIDIA GPUs, the same flag turns on adaptive verification, which vLLM leaves off by default. It uses the confidence head's predictions to decide how many drafts to check for each request, within a compute budget profiled at start-up.

What the Published Scores Say

On the 1017 model card, DeepSeek-V4.1-Flash-1017 leads the other open models listed on every benchmark except HLE without tools, where Kimi K3 is 0.9 points ahead; our Kimi K3 deployment guide serves that model on 32 NVIDIA H100 GPUs. Against the closed models the picture is mixed: Opus 5 leads on six benchmarks and GPT-5.6 Sol on ZeroBench, while DeepSeek-V4.1-Flash-1017 leads on DeepSWE v1.1, Automation-Bench, Agents' Last Exam and Apex Bench.

The DeepSeek-V4.1-Flash Deployment Architecture on 8 NVIDIA H100 GPUs

The checkpoint is 510.3 GB across 48 safetensors shards, and each NVIDIA H100 PCIe card reports 81,559 MiB of memory. The vLLM recipe calls eight 80 GB cards the smallest NVIDIA node that serves this checkpoint, and only with a set of memory settings. Those settings define the DeepSeek-V4.1-Flash deployment architecture, and the largest of them moves the Engram tables off the GPUs.

Host memory takes the two Engram tables together with their block scales, which the recipe puts at 189 GiB. Tensor parallelism splits the remaining weights across the eight cards, with small parts such as the vision encoder and the norms copied to every card instead, and the recipe's NVIDIA H100 notes put the result at about 36 GiB of resident weights per card. vLLM manages 92 per cent of each card:

Why the Batch Budget Is 4,096 Tokens

The sparse-attention indexer allocates a logits buffer at start-up, sized by the number of tokens batched in one scheduler step and by the maximum context length, at two bytes per entry. At the full 1,048,576-token context, a budget of 8,192 tokens would make that buffer 16 GiB on every card. The recipe's NVIDIA H100 profile caps the budget at 4,096 tokens instead, which halves the buffer and keeps the whole context available for long agentic traces.

The profile adds two environment variables that keep the KV pool from fragmenting around that buffer: VLLM_USE_V2_MODEL_RUNNER=1 and PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True.

Inside the Node: Four NVLink Pairs Over PCIe

The 8x NVIDIA H100-80G-PCIe-NVLink flavour bridges each card to one neighbour with NVLink, which Hyperstack rates at 600 GB/s bidirectional on its NVIDIA H100 PCIe page, and reaches the other six cards over PCIe Gen5 through the host bridge. Tensor parallel 8 spans all eight cards, so every all-reduce uses both kinds of link. Our guide to distributed inference with vLLM explains how tensor parallelism splits each layer across GPUs.

The Launch Settings, Flag by Flag

Every engine flag below comes from the command the vLLM recipe generates for NVIDIA H100, apart from the served name and the API key, which turn the server into a private endpoint.

How to Deploy DeepSeek-V4.1-Flash on Hyperstack, Step by Step

The whole DeepSeek-V4.1-Flash deployment runs on one machine in eight steps. Start the 510 GB download as soon as the machine is active, and pull the container image while it runs.

Step 1: Access Hyperstack

• Go to the Hyperstack console and sign in.
• If you are new, create an account, activate billing and add credit. The getting started guide walks through a first deployment from start to finish.

Step 2: Deploy a New Virtual Machine

On the Virtual Machines page, click Deploy New Virtual Machine.

The Deploy New Virtual Machine button.

Then make six choices in the deployment form.

The flavour card for 8x NVIDIA H100-80G-PCIe-NVLink.

The OS image list. Choose Ubuntu Server 24.04 LTS R570 CUDA 12.8 with Docker.

Click Deploy. The machine is ready once its status shows ACTIVE, and billing starts from that state.

Step 3: Open Port 8000 for the Endpoint

Apart from the SSH rule from Step 2, a new virtual machine accepts no inbound traffic until a firewall rule allows it. Open the machine's details page, go to the Firewall tab and add one inbound rule:

• Ether type: IPv4
• Protocol: TCP
• Port range: 8000
• Remote IP prefix: your own public address followed by /32

The inbound rule on the Firewall tab. In the remote IP field, enter your own address followed by /32 rather than 0.0.0.0/0.

Step 4: Connect and Check the GPUs

# From your workstation, once the virtual machine shows ACTIVE
chmod 600 ~/.ssh/[YOUR KEY]
ssh -i ~/.ssh/[YOUR KEY] ubuntu@[VM PUBLIC IP]

Once the Ubuntu welcome banner appears, confirm what the machine holds before installing anything.

# Eight cards and their memory, before anything is installed
nvidia-smi --query-gpu=index,name,memory.total --format=csv

# How the eight cards are wired to one another
nvidia-smi topo -m

index, name, memory.total [MiB]
0, NVIDIA H100 PCIe, 81559 MiB
1, NVIDIA H100 PCIe, 81559 MiB
2, NVIDIA H100 PCIe, 81559 MiB
3, NVIDIA H100 PCIe, 81559 MiB
4, NVIDIA H100 PCIe, 81559 MiB
5, NVIDIA H100 PCIe, 81559 MiB
6, NVIDIA H100 PCIe, 81559 MiB
7, NVIDIA H100 PCIe, 81559 MiB

      GPU0  GPU1  GPU2  GPU3  GPU4  GPU5  GPU6  GPU7  NIC0
GPU0   X    NV12  PHB   PHB   PHB   PHB   PHB   PHB   PHB
GPU1  NV12   X    PHB   PHB   PHB   PHB   PHB   PHB   PHB
GPU2  PHB   PHB    X    NV12  PHB   PHB   PHB   PHB   PHB
GPU3  PHB   PHB   NV12   X    PHB   PHB   PHB   PHB   PHB
GPU4  PHB   PHB   PHB   PHB    X    NV12  PHB   PHB   PHB
GPU5  PHB   PHB   PHB   PHB   NV12   X    PHB   PHB   PHB
GPU6  PHB   PHB   PHB   PHB   PHB   PHB    X    NV12  PHB
GPU7  PHB   PHB   PHB   PHB   PHB   PHB   NV12   X    PHB
NIC0  PHB   PHB   PHB   PHB   PHB   PHB   PHB   PHB    X

Eight NVIDIA H100 PCIe cards at 81,559 MiB each, with NV12 between GPU0 and GPU1, GPU2 and GPU3, GPU4 and GPU5, and GPU6 and GPU7. Every other pair shows PHB, a path through the PCIe host bridge.

Step 5: Download the Weights to the Ephemeral Disk

The root disk is 100 GB, so the Hugging Face cache goes on the 6,500 GB ephemeral disk mounted at /ephemeral.

# The root disk is 100 GB and the checkpoint is 510 GB, so
# the Hugging Face cache lives on the ephemeral disk
sudo mkdir -p /ephemeral/hf
sudo chown -R ubuntu:ubuntu /ephemeral/hf

# tmux outlives a dropped session; jq reads JSON responses
sudo apt-get update -q && sudo apt-get install -y -q tmux jq
python3 -m pip install -q --break-system-packages \
  -U "huggingface_hub[hf_xet]"
export PATH="$HOME/.local/bin:$PATH"

# Start a named tmux session, then run the download inside it
tmux new -s weights

export HF_HOME=/ephemeral/hf
hf download deepseek-ai/DeepSeek-V4.1-Flash-1017 --max-workers 16

Detach from tmux with Ctrl+b then d, and reattach with tmux attach -t weights. The repository is public under the MIT licence, so the download needs no Hugging Face token. When the command returns, confirm that all 48 shards are present and none is partial:

# Count the shards and any partial files once the download returns
REPO=/ephemeral/hf/hub/models--deepseek-ai--DeepSeek-V4.1-Flash-1017
SHARDS=$(ls $REPO/snapshots/*/model-*-of-00048.safetensors | wc -l)
PARTIAL=$(find $REPO -name '*.incomplete' | wc -l)
echo "$SHARDS shards, $PARTIAL incomplete"

48 shards, 0 incomplete

Step 6: Pull the vLLM Image

In a second SSH session, pull the image while the weights download. DeepSeek-V4.1-Flash support arrived in vLLM 0.30.0, and the recipe sets vLLM 0.31.0 as its minimum, so pin that release rather than latest.

# In a second SSH session, while the weights download
docker pull vllm/vllm-openai:v0.31.0

Step 7: Launch vLLM

Create a key for the endpoint first. Clients send it as a bearer token.

# A random key for the endpoint, readable by your user only
openssl rand -hex 32 > ~/.vllm_key && chmod 600 ~/.vllm_key
export VLLM_KEY=$(cat ~/.vllm_key)

Then start the container. The engine flags are the recipe's NVIDIA H100 command, with the served name, the API key and CUDA compatibility added.

docker run -d --name deepseek-v41-flash \
  --gpus all --ipc=host -p 8000:8000 \
  -v /ephemeral/hf:/root/.cache/huggingface \
  -e HF_HUB_OFFLINE=1 \
  -e VLLM_ENABLE_CUDA_COMPATIBILITY=1 \
  -e VLLM_ENGINE_READY_TIMEOUT_S=3600 \
  -e VLLM_USE_V2_MODEL_RUNNER=1 \
  -e PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True \
  vllm/vllm-openai:v0.31.0 \
  deepseek-ai/DeepSeek-V4.1-Flash-1017 \
  --served-model-name deepseek-v4.1-flash \
  --api-key "$VLLM_KEY" \
  --tokenizer-mode deepseek_v41 \
  --tensor-parallel-size 8 \
  --engram-config '{"cpu_offload":true}' \
  --max-num-batched-tokens 4096 \
  --gpu-memory-utilization 0.92 \
  --reasoning-parser deepseek_v41 \
  --tool-call-parser deepseek_v41 \
  --enable-auto-tool-choice \
  --mm-encoder-tp-mode data

The first start reads 510 GB of weights from the ephemeral disk and pins about 189 GiB of Engram tables and scales in host memory before the API opens; VLLM_ENGINE_READY_TIMEOUT_S=3600, set by the recipe, gives that first load up to an hour.

# Stream the engine's start-up in one terminal
docker logs -f deepseek-v41-flash

# In another, poll the health route until it answers
until curl -sf http://localhost:8000/health; do sleep 30; done
echo "vLLM is ready"

vLLM is ready

Step 8: Send the First Request

List the served model, then send the question the recipe uses as its own check, with thinking off. The correct answer is 323.

curl -s http://localhost:8000/v1/models \
  -H "Authorization: Bearer $VLLM_KEY" \
  | jq -r '.data[] | "\(.id)  max_model_len=\(.max_model_len)"'

deepseek-v4.1-flash  max_model_len=1048576

curl -s http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $VLLM_KEY" \
  -d '{"model": "deepseek-v4.1-flash",
       "chat_template_kwargs": {"thinking": false},
       "messages": [{"role": "user", "content":
           "What is 17*19? Return only the integer."}]}' \
  | jq -r '.choices[0].message.content'

323

Setting thinking to false in chat_template_kwargs asks for a direct answer. Without it, the server renders the prompt in thinking mode at effort 75. From your workstation, the same request works against http://[VM PUBLIC IP]:8000 once the Step 3 rule is in place.

DeepSeek-V4.1-Flash Inference: Thinking, Effort, Tools and Images

Every DeepSeek-V4.1-Flash inference request follows the same path. The API server checks the key, vLLM's deepseek_v41 prompt encoder writes the conversation in DeepSeek's V4.1 format, the engine runs it across the eight GPUs, and the reasoning and tool-call parsers turn the raw output back into OpenAI fields.

Connect a Python Client

The server speaks the OpenAI Chat Completions API, so the official OpenAI SDK works unchanged. DeepSeek recommends a temperature of 1.0 and a top_p of 1.0 for the 1017 checkpoint, as its model card lists.

# pip install openai, then export VLLM_KEY with the Step 7 key
import os
from openai import OpenAI

client = OpenAI(
    base_url="http://[VM PUBLIC IP]:8000/v1",
    api_key=os.environ["VLLM_KEY"],
)
MODEL = "deepseek-v4.1-flash"

Chat Mode for Direct Answers

With thinking off, the encoder closes the reasoning block before generation starts, so the reply is the answer and nothing else.

ask = "Write 1,048,576 as a power of two. Expression only."

reply = client.chat.completions.create(
    model=MODEL,
    messages=[{"role": "user", "content": ask}],
    max_tokens=16,
    extra_body={"chat_template_kwargs": {"thinking": False}},
)
print(reply.choices[0].message.content)

2^20

Thinking Mode and the 1 to 100 Effort Dial

DeepSeek-V4.1-Flash exposes reasoning as a number rather than a handful of tiers. During reinforcement learning, DeepSeek trained the model at a set of effort levels on a scale from 1 to 100, penalising long reasoning less as the level rises, and the report notes that values between the trained levels give interpolated behaviour. In thinking mode, the encoder writes the value into the prompt as a Reasoning Effort line at the start of the conversation. DeepSeek's own API maps its low, high and max tiers to 50, 75 and 100, as section 5.1.4 of the technical report sets out.

On this server, a request that sets neither thinking key runs in thinking mode at effort 75, the default in DeepSeek's encoder and in vLLM 0.31.0. Set thinking explicitly on every request, and add reasoning_effort whenever thinking is on. Give thinking requests room in max_tokens, since the reasoning trace and the answer share one budget and the answer begins only once the trace closes.

question = ("A 475 GiB checkpoint is served by 8 GPUs after "
            "189 GiB of it moves to host memory. How many GiB "
            "does each GPU hold? Answer with the number only.")

reply = client.chat.completions.create(
    model=MODEL,
    messages=[{"role": "user", "content": question}],
    temperature=1.0, top_p=1.0, max_tokens=8192,
    extra_body={"chat_template_kwargs": {
        "thinking": True, "reasoning_effort": 60}},
)
msg = reply.choices[0].message
print("reasoning:", msg.reasoning)
print("answer:", msg.content)

reasoning: Of the 475 GiB, 189 GiB sits in host memory.
That leaves 475 - 189 = 286 GiB for the GPUs, and split
evenly across 8 GPUs that is 286 / 8 = 35.75 GiB each.
answer: 35.75

The reasoning arrives in the reasoning field and the answer in content. The deepseek_v41 reasoning parser makes that split, and the vLLM documentation notes that the field was called reasoning_content in older releases.

Efforts of 60 to 80 recover most of effort 100's accuracy at less than half its tokens, while the last step to 100 lengthens agent trajectories by 1.6 to 1.8 times for marginal gains. Effort therefore sets how many tokens each request spends, and so how much of the machine's capacity it uses, with no change to the server.

Tool Calling Through the DSML Parser

DeepSeek-V4.1-Flash writes tool calls as DSML tag blocks rather than JSON. vLLM handles both directions: the encoder wraps your tool messages in tool_result tags, and the deepseek_v41 parser turns DSML blocks into standard OpenAI tool_calls. With --enable-auto-tool-choice, the model decides for itself when to call a tool.

<｜DSML｜ calls>
<｜DSML｜ invoke name="get_flavour">
<｜DSML｜ parameter name="name" string="true">n3-H100x8-NVLink</｜DSML｜ parameter>
</｜DSML｜ invoke>
</｜DSML｜ calls>

"tool_calls": [{
  "type": "function",
  "function": {
    "name": "get_flavour",
    "arguments": "{\"name\": \"n3-H100x8-NVLink\"}"
  }
}]

The example below gives the model one tool that returns the hardware of a Hyperstack flavour, then asks a question it can only answer after calling it.

import json

FLAVOURS = {"n3-H100x8-NVLink": {
    "gpus": 8, "vcpus": 252, "ram_gb": 1440,
    "root_disk_gb": 100, "ephemeral_gb": 6500}}
tools = [{"type": "function", "function": {
    "name": "get_flavour",
    "description": "Hardware of a Hyperstack flavour, by API name.",
    "parameters": {"type": "object", "required": ["name"],
                   "properties": {"name": {"type": "string"}}}}}]
effort = {"chat_template_kwargs": {"thinking": True,
                                   "reasoning_effort": 40}}

messages = [{"role": "user", "content":
             "Will a 510 GB checkpoint fit on the ephemeral disk "
             "of n3-H100x8-NVLink? Look the flavour up first."}]
reply = client.chat.completions.create(
    model=MODEL, messages=messages, tools=tools, extra_body=effort)
call = reply.choices[0].message.tool_calls[0]
print(call.function.name, call.function.arguments)

get_flavour {"name": "n3-H100x8-NVLink"}

msg = reply.choices[0].message
messages.append({"role": "assistant", "content": msg.content,
                 "reasoning": msg.reasoning,
                 "tool_calls": [call.model_dump()]})

result = FLAVOURS[json.loads(call.function.arguments)["name"]]
messages.append({"role": "tool", "tool_call_id": call.id,
                 "content": json.dumps(result)})

final = client.chat.completions.create(
    model=MODEL, messages=messages, tools=tools, extra_body=effort)
print(final.choices[0].message.content)

Yes. n3-H100x8-NVLink has 6,500 GB of ephemeral storage,
so a 510 GB checkpoint fits with about 5,990 GB to spare.

Passing the assistant turn back with its reasoning keeps the model's plan intact across the call. When a conversation declares tools, DeepSeek's encoder keeps the reasoning from every turn rather than dropping earlier traces, so the model can follow one plan through several calls.

Image Input

Images go in as image_url content parts, the format vLLM's multimodal input guide documents. vLLM fetches each image, runs the 32-layer vision encoder and places the visual tokens where the image sits in the prompt. Each image costs up to 1,024 tokens, as the vLLM recipe notes, and the 3 by 3 pixel-unshuffle supports inputs up to about 1,344 by 1,344 pixels. The request below asks the model to read DeepSeek's own KV cache chart from the DeepSeek-V4.1-Flash model card.

chart = ("https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash/"
         "resolve/main/assets/dsv41_kv_cache.png")
question = ("Which model on this chart has the smallest KV cache "
            "per token, and how much smaller is it than the next?")

reply = client.chat.completions.create(
    model=MODEL,
    messages=[{"role": "user", "content": [
        {"type": "image_url", "image_url": {"url": chart}},
        {"type": "text", "text": question},
    ]}],
    max_tokens=512,
    extra_body={"chat_template_kwargs": {"thinking": False}},
)
print(reply.choices[0].message.content)

DeepSeek-V4.1-Flash has the smallest global KV cache per
token, at 890 bytes. The next smallest is DeepSeek-V4-Flash
at 3,514 bytes, so V4.1-Flash is about 3.9 times smaller.

Keep one text request and one image request in your deployment checks, since the vision encoder is a separate path through the model.

Connect an Agent Harness to DeepSeek-V4.1-Flash

DeepSeek scored DeepSeek-V4.1-Flash in eight harness configurations from six families, with the checkpoint and decoding settings held fixed, and reports that its agentic behaviour carries across them. You can therefore pick the harness that fits your own workflow.

vLLM serves the Anthropic Messages API beside the OpenAI one, so Claude Code can use this endpoint directly. Point it at the server and map every model tier to the served name:

# On your workstation, with Claude Code installed
export ANTHROPIC_BASE_URL="http://[VM PUBLIC IP]:8000"
export ANTHROPIC_AUTH_TOKEN="[YOUR VLLM KEY]"
export ANTHROPIC_API_KEY="[YOUR VLLM KEY]"
export ANTHROPIC_DEFAULT_OPUS_MODEL="deepseek-v4.1-flash"
export ANTHROPIC_DEFAULT_SONNET_MODEL="deepseek-v4.1-flash"
export ANTHROPIC_DEFAULT_HAIKU_MODEL="deepseek-v4.1-flash"
claude

As its environment variable reference states, Claude Code sends ANTHROPIC_AUTH_TOKEN as a bearer token, which the server's API key check accepts. Harnesses that speak the OpenAI API take http://[VM PUBLIC IP]:8000/v1 as the base URL and the same key.

Tuning DeepSeek-V4.1-Flash on vLLM

Turn On DSpark Drafting

To enable DSpark, add the recipe's speculative decoding flag as the last line of the launch command, with a backslash at the end of the line before it:

# Append to the end of the Step 7 launch command
  --speculative-config '{"method": "dspark",
    "num_speculative_tokens": 5,
    "draft_sample_method": "probabilistic",
    "rejection_sample_method": "block",
    "enable_adaptive_verification": true}'

It drafts five tokens per round, the block size DSpark was trained on, and turns on adaptive verification on NVIDIA GPUs. How many drafts are accepted depends on how predictable your traffic is, so measure the acceptance rate on your own prompts before adopting it.

Serve Text Only

For text-only traffic, replace --mm-encoder-tp-mode data with the flag below. It skips the vision encoder and its aligner and frees that memory for the KV cache; the two flags cannot be used together.

# In place of --mm-encoder-tp-mode data, for text-only traffic
  --language-model-only

Size the Context to the Workload

The indexer buffer grows with the context limit as well as the batch budget. A workload that never needs a million tokens can set --max-model-len lower, and the memory the buffer gives up goes to the KV cache.

DeepSeek-V4.1-Flash Deployment Cost

A DeepSeek-V4.1-Flash deployment on one machine comes down to one hourly GPU rate. Hyperstack lists NVIDIA H100 NVLink at $2.60 per GPU hour on demand and from $1.82 per GPU hour reserved on its GPU pricing page, and this machine carries eight cards. The public IP the endpoint needs is listed separately on the same page, at $0.00672043 per hour. Billing runs per minute, as the billing policies set out, and starts once the machine is ACTIVE, as the getting started guide notes.

Three Levers on the Bill

Run DeepSeek-V4.1-Flash on your own GPUs

Deploy DeepSeek-V4.1-Flash on 8x NVIDIA H100

One virtual machine, the vLLM recipe's NVIDIA H100 configuration and a private endpoint with thinking, tool calls, image input and the full one-million-token context, from $20.80 per hour on demand.

8x NVIDIA H100 80 GB1,048,576-token contextvLLM 0.31.0$20.80 per hour

Launch an NVIDIA H100 virtual machine on Hyperstack today.

FAQs

What is DeepSeek-V4.1-Flash-1017?

DeepSeek-V4.1-Flash-1017 is an updated release of DeepSeek-V4.1-Flash, a multimodal mixture-of-experts model with 552B backbone parameters. It activates 8B parameters per prompt token and 16B per generated token, holds 1,048,576 tokens of context and ships under the MIT licence.

What hardware do you need to deploy DeepSeek-V4.1-Flash?

DeepSeek-V4.1-Flash needs one node of eight 80 GB GPUs, the smallest NVIDIA configuration the vLLM recipe serves. Its 475 GiB checkpoint fits once the Engram tables and their scales, about 189 GiB, move to host memory, leaving about 36 GiB of resident weights on each NVIDIA H100.

How much does a DeepSeek-V4.1-Flash deployment cost on Hyperstack?

An 8x NVIDIA H100-80G-PCIe-NVLink machine costs $20.80 per hour on demand, or from $14.56 per hour reserved, billed per minute. The whole deployment runs on that one machine, so one hourly rate covers every GPU.

How do you control thinking on DeepSeek-V4.1-Flash?

Send chat_template_kwargs with thinking set to true or false and, when thinking is on, a reasoning_effort integer from 1 to 100 in the same object. With neither key set, vLLM 0.31.0 runs thinking mode at effort 75.

Does DeepSeek-V4.1-Flash support tool calling and images on vLLM?

Yes. With the deepseek_v41 tool parser and auto tool choice, the tag blocks the model writes for tool calls arrive as OpenAI tool_calls, and image_url content parts run through its 32-layer vision encoder at up to 1,024 tokens per image.