DeepSeek V4 Flash inference optimization for realistic Agent workloads on 2× NVIDIA GB10 is now open source. In the final Fair-Prefill V6 results, four concurrent 32K requests reached 1,842.04 aggregate Prefill tok/s, with TTFT P95 of 71.49 s and E2E P95 of 81.72 s. The release publishes the service configuration, benchmark definitions, result tables, and machine-readable evidence.
32K concurrency results
The first table covers the 32K cache-off concurrency sweep from C1 to C4. It reports Prefill, TTFT, E2E latency, Decode, and Goodput for every concurrency level, while the main release callout stays on Prefill and latency.
<!-- local-source=spoke/queue/assets/003/exports/fair-prefill-v6-concurrency.png --> 
At 32K/C4, aggregate Prefill reached 1,842.04 tok/s. TTFT P95 was 71.49 s, and E2E P95 was 81.72 s. This scenario represents four context-heavy requests running concurrently on the dual-GB10 service.
Prefill measures how quickly the service processes input tokens before generation. TTFT measures the wait for the first output token, while E2E follows the request through its natural stop. Long-context Agent work places pressure on prompt ingestion and request scheduling at the same time, so the concurrency table keeps both throughput and latency in view. Decode and Goodput remain in the table as supporting measurements.
C1 length sweep through 128K
The second table holds concurrency at C1 and increases input length from 8K through 128K. It uses the same Fair-Prefill V6 result set and reports Aggregate Prefill, Common-window Decode, TTFT, and E2E at each context length.
<!-- local-source=spoke/queue/assets/003/exports/fair-prefill-v6-length.png --> 
At 128K/C1, aggregate Prefill was 1,686.06 tok/s. TTFT P95 was 81.92 s, and E2E P95 was 85.91 s. Holding concurrency at C1 isolates input length from the concurrency axis. This sweep shows how the service handles a single request as its input approaches the longest measured window, while the 32K table covers concurrency.
What the formal benchmark covers
The formal v0.1.1 benchmark ran with `max_model_len=262144` and measured input lengths through 128K. Prefix Cache was off for every formal measurement, although the service supports Prefix Cache. Each scenario used 12 formal waves drawn from four realistic Agent task classes. Responses stopped naturally, with a limit of 512 output tokens.
Natural stopping is part of the workload definition. Requests could finish when their task response was complete instead of being forced to generate an identical output length. This keeps the latency measurements tied to completed Agent tasks while the 512-token limit provides a clear upper boundary.
Each complete source run finished 168 of 168 requests correctly across 96 measured waves. No request reached the length cap, and each run logged zero Prefix Cache queries or hits. The hardware and runtime configuration used TP=2, PP=1, one RoCE/IB rail, DSpark depth 5, `max_num_seqs=6`, batch 12288, and GPU memory utilization of 0.80.
The [pinned source repository](https://github.com/Approaching-AI/deepseek-v4-flash-2x-gb10/tree/6af1ff01fd4c476a53139f8249bd4ef8c2118113) contains the full tables and the [machine-readable Fair-Prefill V6 benchmark artifact](https://github.com/Approaching-AI/deepseek-v4-flash-2x-gb10/blob/6af1ff01fd4c476a53139f8249bd4ef8c2118113/artifacts/cacheoff-agent-v6-v0.1.1.json).
A separate 1M-context acceptance check
The service also has a verified near-limit 1M-context acceptance result. With `max_model_len=1048576`, it accepted one streaming request containing 1,048,038 prompt tokens. The request returned HTTP 200, retrieved the exact sentinel placed at the beginning of the input, and reported zero cached tokens. It completed without an OOM or service restart.
This check records single-request acceptance close to the configured limit. The formal throughput benchmark ends at 128K. Its evidence is limited to one accepted 1M request, so concurrent full-1M behavior remains outside the test. The [machine-readable 1M acceptance record](https://github.com/Approaching-AI/deepseek-v4-flash-2x-gb10/blob/6af1ff01fd4c476a53139f8249bd4ef8c2118113/artifacts/context-1m-acceptance-2026-08-10.json) preserves the request and response evidence.
Harbor Town AI Progress
Harbor Town AI Progress is Ethan Mollick's visual AI coding capability test. Different models receive the same open-ended prompt: create an interactive, procedurally generated 3D harbor town that evolves from 3000 BCE to 3000 AD. The generated web code then runs in a browser so the result can be inspected.
The prompt asks for the complete experience as one self-contained `index.html` file. The model chooses the visual style, historical stages, controls, camera behavior, and procedural systems. The town and its surroundings must change meaningfully across the timeline instead of switching between static sets of buildings. The prompt also requires failure handling and a final review for syntax or interaction problems.
OpenCode used a locally served DeepSeek V4 Flash service. Over about 29 minutes of cumulative execution, it completed Harbor Town, repaired issues, and passed final verification. The accelerated recording shows the workflow and the rendered town.
<!-- local-source=spoke/queue/assets/003/exports/harbor-town-accelerated.mp4 --> [Watch the accelerated Harbor Town AI Progress recording](/blog-images/deepseek-v4-flash-2x-gb10/harbor-town-accelerated.mp4)
Harbor Town is a visual coding capability test and a recorded workload on the local service. The Fair-Prefill V6 tables remain the formal performance evidence.
Code and evidence
The [v0.1.1 personal repository](https://github.com/rjckkkkk/deepseek-v4-flash-2x-gb10) remains available as a direct release source. The canonical project, current evidence, configurations, and releases are in the [Approaching-AI repository](https://github.com/Approaching-AI/deepseek-v4-flash-2x-gb10). [Follow Approaching AI on GitHub](https://github.com/Approaching-AI) for related open-source inference work.