Skip to main content
A coding agent may spend a few seconds writing a patch and then wait while its tests run. If you rent a GPU server for that agent, you pay for the waiting time too. A model that is cheap to use through an API can still be expensive to keep on your own hardware. With DeepSeek V4.1 Flash, the useful question is how much it costs to finish your coding tasks. Start with one request that you can run in both places. Once that works, add your agent’s tools and conversation history, measure the completed work, and compare the bills. The same process also helps if you need the model to run inside your own cloud account. You can see which parts of the setup are required to get an answer and which become necessary as you add more agents.

​
How do you get a first result before renting GPUs?

Your application can run on AWS or Azure and send requests to DeepSeek’s API. DeepSeek runs the model in this arrangement. Keeping the model itself inside your account requires the GPU setup later in this guide. Store a DeepSeek API key in your secret manager and make it available as DEEPSEEK_API_KEY. This Python 3 example makes one paid request for a small function:
The request asks the model to add two integers, turns reasoning off, and limits the output to 128 tokens. It prints the answer and the usage counts so you can see both what the model produced and what you were charged for. Keep the usage counts when you move on to real tasks. deepseek-flash is the current API name for V4.1. The code above gives you a first response without setting up a GPU server. API request reference
The older names deepseek-v4-flash and deepseek-v4-flash-vision-exp already send requests to V4.1 Flash. DeepSeek says deepseek-v4-pro will also use it from September 14, 2026 at 04:00 UTC. Record the version behind an API name when comparing results over time, because an old name can point to a newer model. Official release log
To serve the same request from your own account, the next step is to find a machine that can hold and run the model.

​
Why does a cheap model still need a large server?

The amount of computation used for a token can make V4.1 Flash look smaller than it is. It uses about 8 billion parameters when reading each input token and 16 billion when generating an output token. But different tokens use different parts of the model, and those parts all need to be available. The full model has 552 billion parameters in its main network and 196 billion in Engram lookup memory. It also includes components for reading images and drafting output tokens. The downloaded weight files take about 510.30 GB. This is why the starting point is a server with several large GPUs. Official model card First, allow enough disk space to download the files. Use at least 1 TiB for this guide’s setup, and more if you keep other model copies. Two full copies of the weights would already take about 1.02 TB. Then check memory separately. The GPUs need room for their share of the model, the conversation history, and the temporary work needed to serve requests. System RAM needs to cover loading, the operating system, and any model data or saved conversation state moved off the GPUs. Adding up the memory printed on the GPU specifications does not tell you whether each GPU has enough room after the model is divided between them.
The 48 weight files at revision dba1be0a40aa45a94ad051997016db3960a90277 total 510,296,708,312 bytes, or 475.25 GiB in binary units. This is the size on disk. Memory use while serving also depends on how the software loads and runs the model. Pinned model filesSome expert weights use four-bit floating point, called FP4. Other parts use eight-bit floating point, called FP8, or higher precision. Compressed values also need scaling information. The different formats are why multiplying every parameter by the same number of bits gives the wrong size. Quantization settings
A published working configuration is a better starting point than a memory estimate alone. You can then measure how much space your requests need on that configuration.

​
Which AWS or Azure server can you start with?

SGLang is the software that will load the model and serve requests. Its V4.1 preview has been verified on some of the GPU configurations below, with others still being checked. AWS offers an instance with eight B300 GPUs from which this setup uses four. Azure offers one with four GB300 GPUs. These are supported starting points, rather than a claim about the smallest possible server. The status is current as of September 10, 2026. SGLang lists these statuses in its hardware table. The cloud server details come from AWS, Azure’s GB300 documentation, and Azure’s H200 documentation. Matching the GPU configuration gives you a place to start. You still need to check the cloud image and run your application on it. The setup below follows the published documentation. We have not run V4.1 on these cloud servers, so the first run is for checking the setup before you test a real workload. On AWS, request a p6-b300.48xlarge instance in a region with available capacity. Use an AWS Deep Learning AMI that supports P6-B300 and provide at least 1 TiB of usable disk space. AWS requires CUDA 13.0, an R580 NVIDIA driver, and the kernel and networking components listed in its P6 documentation. A matching AMI gives you these components without having to assemble the system yourself. AWS P6 requirements On Azure, request quota and capacity for Standard_ND128isr_GB300_v6. This server has four GPUs with 288 GB each, 864 GiB of system RAM, and NVIDIA Grace CPUs. The CPUs use the ARM architecture, so choose a supported ARM64 Linux image with the GPU driver and NVIDIA Container Toolkit installed. The preview container is available for both ARM64 and AMD64. Check that Azure can provide the server in your subscription and region, and add enough usable disk space before downloading the model. A server appearing in the documentation does not mean capacity is immediately available. Keep port 30000 closed in the cloud firewall. The commands below make the model available only on the server’s local address. You will connect from your laptop through an SSH tunnel.

​
How do you launch the model?

As of September 10, SGLang’s V4.1 support was available in a preview container, lmsysorg/sglang:dev-dsv41. It had not yet shipped in a regular release. Use this preview for the NVIDIA setup below; installing an ordinary SGLang release with pip does not give you the required V4.1 support. The vLLM integration was also still in progress. SGLang installation instructions Run these commands on the GPU server:
The first three commands show the GPUs, system RAM, and free disk space. Docker then downloads the preview container, and the final command records its image digest. The digest identifies the exact version you downloaded. Save it with your deployment settings so you can reproduce the run after the preview receives updates.
The multi-platform image index we checked for this article was sha256:3dbc313030a6ef2c5d7de8ecf48e9aece722694a82182cb618cc82b588816349. The preview tag can point to a different image when fixes arrive. The commands record the digest of the image you actually download.
Next, download a fixed revision of the model. This transfers roughly 510 GB. The example stores it under your home directory; if your large disk is mounted elsewhere, change MODEL_DIR to a directory on that disk first.
Start one copy of the model across four GPUs:
The GPU settings and draft-model settings follow SGLang’s verified B300 command. We also set a 32,768-token context limit and allow four requests to run at once, using SGLang’s server settings. These limits give you a manageable first test. They do not tell us the server’s maximum capacity. The --cuda-graph-max-bs-decode 64 setting limits the size of the CUDA graphs, which let the GPU replay a prepared sequence of operations. SGLang uses this limit because capturing larger graphs ran out of memory in its B300 setup. The GB300 configuration also uses four GPUs, and this example keeps the same lower graph limit there. On AWS, this command uses four GPUs, but you still pay for all eight GPUs in the instance. Before running another copy on the other four, check whether the server has enough system RAM and whether both copies can serve requests fast enough. Keep the two auto parser settings in the command. V4.1 uses its own format for prompts, reasoning, and tool calls, and it does not include a Jinja chat template. The new SGLang implementation understands that format. An older V4 parser or a generic chat template does not provide the same support. Official prompt format, SGLang parser instructions

​
Can your agent use the server you just started?

Once the logs say the server is ready, open a second terminal on the same machine. Ask it to generate the same function you requested from the API:
The first two commands check server health and the model name. The third sends the request for the Python function. It turns reasoning off so the model can finish within the small output limit. For tasks that need reasoning, SGLang accepts settings such as high and max. Its cookbook explains the different request format for numeric reasoning budgets. Set your agent’s context and output limits explicitly so it stays within this server’s 32,768-token limit. To connect from your laptop, replace your-user@your-vm with your server’s SSH login and address:
Configure your OpenAI-compatible agent to use http://127.0.0.1:30000/v1 and the model name deepseek-v41-local. If the client requires an API key, a placeholder works for this private local connection because this server has no authentication configured. Add authentication and TLS at a gateway before making it a shared service outside the SSH tunnel. A successful text response is the first check. A coding agent also needs to call tools and read their results correctly. Test structured tool calls, returned tool results, streamed reasoning, cancelled requests, and image inputs separately. Run the agent’s tools in an isolated environment, especially when those tools can execute code.

​
What changes when the agent reads a whole repository?

The small function checks that the server can answer. A real coding agent will send source files, tool results, and earlier messages, often while other agents are also using the server. Increase the context length and the number of simultaneous requests gradually so you can see where memory use or response time becomes a problem. The following table gives examples to test. We have not measured these as server capacities. For the group of agents, also check whether the server reuses work from shared prompt prefixes. That can affect both memory use and response time when several agents read the same repository. DeepSeek’s published coding evaluations used a 1-million-token context window and maximum reasoning effort. The small test above uses different settings, so it will not reproduce those benchmark results. Increasing the reasoning budget also makes the model generate more tokens and keeps each request running longer. Evaluation settings DeepSeek reports that its compressed global key-value cache needs 890 bytes per token. This cache holds attention state that lets the model refer back to earlier tokens. At that size, one million tokens use about 0.89 GB for the global cache, and four conversations of that length use about 3.56 GB. The server needs memory for other things too. These include attention state for nearby tokens, memory pages used for the cache, copies of that state across GPUs, the draft model, temporary calculation results, and working buffers. How the software divides these across GPUs also affects memory use. Measure the actual memory used by the server before deciding how many long conversations it can handle. The launch command enables DSpark, a smaller model that proposes tokens for the main model to check. Try the same tasks with and without it. SGLang says the number of accepted draft tokens depends on the workload, and its throughput example turns drafting off because the extra work can become less useful when many requests run together. SGLang tuning instructions Keep the first comparison simple. Leave Engram tables on the GPUs and leave the optional sliding-window replay feature off. That feature rebuilds some saved attention state by processing a short section of the prompt again. Once the basic setup works, try each memory-saving option separately so you can see its effect. If GPU memory becomes the constraint, the Engram option is worth testing next. If you want to compare another GPU vendor, use the separate AMD setup. Both change the serving configuration, so compare them with the working setup you already have.
Engram stores large lookup tables that the model reads as it works. SGLang can keep these tables in the server’s system RAM by setting SGLANG_ENABLE_DSV41_ENGRAM_HOST_TABLE=1. This frees GPU memory. It also removes two all-reduce operations, which are steps where GPUs exchange and combine data. SGLang’s Engram instructionsMoving the tables to system RAM has a cost. The server needs more RAM, the model takes longer to load, and SGLang requires huge pages for efficient reads. Huge pages are larger blocks of memory managed by the operating system.The two tables contain about 196.61 GB of FP8 values and 6.14 GB of scaling information, or 202.76 GB combined. We calculated those sizes from the tensor shapes and file offsets in the two Engram weight files. The total excludes other Engram projections, memory needed during loading, and the rest of the model. You therefore need substantial system RAM before leaving any room for a conversation cache. Engram file 47, Engram file 48The GPUs still run the attention and expert layers in this setup. We could not verify a released way to run this exact V4.1 model entirely on CPUs, through MLX, or on Ascend chips. The llama.cpp conversion work was still an open pull request when we checked. Software that supports the older V4 Flash model still needs specific support for V4.1.
SGLang has verified four MI350X GPUs with its dedicated ROCm preview. ROCm is AMD’s software stack for running workloads on its GPUs. This is a concrete alternative to the NVIDIA configurations in this guide.The AMD setup has its own environment settings, and its published command disables radix caching, which normally lets requests reuse saved work from a shared prompt. Follow the AMD command panel for that exact hardware. The NVIDIA command used earlier in this guide needs different settings and cannot be copied directly to an arbitrary AMD server. SGLang’s AMD instructions

​
How do you turn those requests into an API bill?

Once the agent can complete a task, add up what it sent and received across every request. Some input will have been served from cache, some will need fresh processing, and all generated output has a cost. DeepSeek’s September 10, 2026 prices below are in US dollars per million tokens. Official pricing Peak hours are Monday through Friday, from 01:00 to 04:00 and from 06:00 to 10:00 UTC. All other times use off-peak pricing. Input read from the cache costs 98% less than input that needs fresh processing. That saving applies only to the input tokens that actually come from the cache. Use the usage counts returned by each request, including the ones printed by the first Python example, to calculate the cost:
completion_tokens already includes the tokens used for reasoning. Adding completion_tokens_details.reasoning_tokens again would count them twice. Reasoning is enabled at high effort by default, so the final answer a user sees may be only part of the output you pay for. API usage fields, reasoning settings Set an output limit and check for finish_reason="length" in the response. It means the model reached the limit before finishing normally. A very small output budget can save tokens on one request but lead to more retries if the model cannot complete the task. Images also count as input tokens. DeepSeek resizes each image and uses at most 1,024 tokens to represent it. That makes the image input alone cost at most $0.0001536 at the off-peak uncached rate. Text sent with the image and the model’s output add to that bill. Use the returned usage counts for the actual charge. Image token rules

​
What happens to the bill over ten agent turns?

For a single request, the formula is straightforward. An agent makes several requests, and each one usually includes more conversation history than the last. Let’s use an assumed ten-round coding task to see how that changes the bill. The output counts include reasoning and tool calls. The agent starts with 50,000 tokens of repository context. In each round, it adds 500 new input tokens and generates 2,000 output tokens. We assume the next request includes all earlier output, including any reasoning kept during this tool-calling turn. The first prompt therefore contains 50,500 tokens. The tenth contains 73,000. Although the repository itself started at 50,000 tokens, sending the growing conversation ten times brings the total input to 617,500 tokens. The cheaper case assumes that every call after the first can read the complete previous conversation from the cache. Only the first 50,500 tokens and the 500 new tokens in each later round need to be processed at the uncached rate. DeepSeek documents that it can save prefixes at both input and output boundaries, which makes this kind of reuse possible. Cache behavior Across the ten rounds, that gives us 55,000 uncached input tokens, 562,500 cached input tokens, and 20,000 output tokens. At off-peak prices, the total comes to about $0.02194. If none of the input hits the cache, the same requests cost about $0.10463. The table puts those two cases beside examples of a single patch and a larger repository request. All four use assumed token counts to illustrate the calculation, rather than measured task results. You still need to check the actual cache-hit counts. DeepSeek’s cache is best-effort and works with saved units of a prompt prefix. Repeating text alone does not guarantee a hit. At 1,000 sessions like this, the model bill would be about $21.94 with the assumed cache hits or $104.63 without them. Running everything during peak hours doubles both amounts. Tools, test containers, network charges, and human review cost extra. Compare cost per successfully completed task, including failed attempts. Suppose 100 tasks need 120 equal-cost attempts, and 90 tasks pass your checks. Using the cheaper example, the cost becomes 120 × 0.0219375 / 90 = 0.02925 USD for each accepted task, before tools and review.

​
When would your own server cost less than the API?

You now have a price for the agent’s work through the API. Compare it with the server you selected earlier, including the time that server spends waiting for work. AWS lists the eight-GPU p6-b300.48xlarge at $112.32 for each reserved instance-hour in Oregon and Northern Virginia. This comes from its September 10 Capacity Blocks price table, where you reserve capacity and pay upfront. It is not an on-demand price. The table adds no operating-system fee for Linux. AWS Capacity Blocks pricing You pay for the full instance even when the model uses four of its eight GPUs. You also need to cover storage, network use, operations, and reserved hours when the server sits idle. At the off-peak API rate, $112.32 pays for 5,120 of the ten-round sessions with cache hits described above. Your own server would need to complete that much work during every paid hour, at comparable quality and response time, just to match the GPU reservation cost. We can express the same comparison in output tokens per second. The calculation includes the input tokens that go with each output token in this example:
The result says the server would need to produce about 28,444 output tokens per second across the whole instance, averaged over all paid time. We have not measured that throughput. It is the rate the server would need to reach to break even under these assumptions. If the server is active for only half of its paid time, it would need about 56,889 output tokens per second while working. Other operating costs raise the required rate. Peak API prices lower it because the API becomes more expensive. Changing the balance of input, output, and cache hits changes the calculation too. For Azure’s Standard_ND128isr_GB300_v6, we found no matching entry in the public Retail Prices API when we checked on September 10. Ask Azure for the hourly price of the whole server in your region and use that figure in the calculation. The missing public price does not establish whether the server is available. Azure retail-price API

​
How should you decide whether to keep running it?

Choose a set of real repository tasks and define what a successful result looks like before testing. Count the tasks that pass your checks and finish within an acceptable time. Include failed attempts, retries, startup time, idle time, storage, and the infrastructure that runs the agent’s tools in the total cost. For each test, record the model revision, container digest, input and output lengths, number of simultaneous requests, cache state, and reasoning settings. These details help explain why one run costs more or finishes faster than another. Use the cost-per-successful-request method to compare your results with the hosted API. The architecture explainer covers the changes that make V4.1 cheaper to serve. Whether those changes make your own server economical depends on how much useful work you can keep it doing. When you finish testing, stop the container:
Then stop or terminate the cloud server according to its billing rules. Stopping Docker does not stop charges for the GPU instance. If you bought a prepaid Capacity Block, you remain committed to paying for its reservation period. The hardware support and prices in this guide were checked against official sources on September 10, 2026. The cost examples use the assumptions stated above; we have not measured V4.1 performance on the listed servers.