KINGSING Deploys DeepSeek-V4.1-Flash-1017 and Shares Benchmark Results

KINGSING has completed a local deployment of DeepSeek-V4.1-Flash-1017 and a structured series of performance and application tests. The project establishes an on-premises AI inference service for internal workflows and documents the practical choices needed to run a large model on a four-GPU server.

Rather than report a single best-case speed, we are sharing the tested configuration, repeated short-input measurements, a near-one-million-token context test, and a paired comparison between the official model and a community-modified variant. The results below were recorded on November 5, 2026. They describe this server and these workloads, not a guaranteed performance level for other deployments.

A four-GPU foundation for local AI

The deployment uses four NVIDIA RTX PRO 6000 Blackwell Server Edition GPUs. Docker packages the inference software, while tensor parallelism distributes the model across the GPUs. An OpenAI-compatible API connects the service to existing applications.

Storage and runtime memory serve different purposes. NVMe keeps the downloaded model files; the Engram component is retained in CPU RAM during inference. The host CUDA Toolkit was 13.1, while the tested container used PyTorch built for CUDA 13.0. The CUDA compatibility version shown by the driver is a separate value and should not be treated as the container runtime version.

What improved generation performance

We first verified the GPU topology and actual peer-to-peer transfers. On this server, changing the IOMMU configuration to passthrough mode enabled all 12 directed GPU peer paths in the test. This was a hardware-specific fix, not a recommendation to change IOMMU settings on every system.

The selected configuration combines Moet's GEMV path, GPU peer-to-peer communication, and DSpark speculative decoding with three draft tokens. CPU placement follows the measured NUMA topology. FP8 KV cache makes room for the long context. These are the settings used for the final model comparison; the testing does not establish that FP8 KV is quality-identical to a higher-precision KV cache.

During the earlier optimization stage, one short Chinese workload progressed from 180.64 tokens/s on the Moet baseline to 192.76 with GEMV and a five-run median of 209.37 with GEMV plus P2P. A subsequent production check on that workload measured 202.26 tokens/s. These historical results used a different workload from the paired measurements below and should not be combined into one improvement percentage.

We also rejected a faster activation-reuse candidate after an answer-completeness check failed. Other tested draft lengths did not provide a better overall result for the selected short Chinese workload. The final configuration uses no GPU overclocking, no activation reuse, and no additional LM-head quantization. Kernel and communication changes can still affect numerical behavior; this is not a claim of bit-for-bit equivalence.

Official model and community variant: measured side by side

We compared the official DeepSeek-V4.1-Flash-1017 model with the community DeepSeek-V4.1-Flash-1017-abliterated variant, using the same container image and inference parameters except for model identity and weights. The community model is a third-party modification, not an official DeepSeek release.

Each speed figure is the median of three runs for one prompt, with 1,024 generated tokens per run, temperature 0, and seed 731. The reported rate is output-token throughput after the first token, calculated from streamed responses. It excludes time to first token; streaming chunk size and speculative decoding can influence this measurement.

The community variant did not show a uniform speed or accuracy advantage. It matched the official model on the selected math questions with thinking disabled, but scored three fewer correct answers with low reasoning effort. One of those runs reached the 4,096-token output limit. These limited samples do not prove equal general capability. The name “abliterated” also does not guarantee that the model will never refuse a request; refusal rates were not evaluated here.

Application checks covered structured JSON output, tool arguments and a tool round trip, multi-turn updates, repeated-prefix requests, cancellation and recovery, and service stability. Both variants passed the ten checks.

Near-one-million-token context: capacity and cost

The server is configured for a maximum of 1,048,576 tokens across input and output. To validate a near-one-million-token workload, each model received 999,906 input tokens and generated 1,024 output tokens. Both retrieved the designated facts placed near the beginning, middle, and end of the input.

The community variant generated approximately 6.45% more slowly in this long-context test. Prefill dominated the waiting time: the first token arrived after about 217 seconds for both models. A context limit alone therefore says little about interactive latency.

GPU power values are sampled peaks during these requests, not configured power limits or evidence that the cards are capped at roughly 300 W. Host-memory usage and container memory including file cache are different accounting views and must not be added together.

This was one long-context run per model. It validates that specific request and retrieval task, not every possible million-token task, sustained tail latency, or four simultaneous million-token requests. The configured maximum of four active sequences does not establish that those four requests can each fill the entire context.

A deployment process that can be checked

The work progressed from operating-system and driver preparation through model download, topology verification, a pinned container build, and a small compatibility patch for a FlashInfer scratch-buffer allocation. We then validated model loading, context capacity, API integration, and performance before selecting the serving configuration.

The final comparison fixes model revisions, runtime versions, prompts, sampling settings, and scoring inputs. It uses a seeded selection of 200 questions from the public GSM8K test set, plus 30 authored mixed tasks. Models were run sequentially rather than in randomized alternating order, so thermal state and external load remain possible sources of variation. Small benchmark differences should be interpreted with those limits in mind.

We are making the configuration snapshot, sanitized measurements, model revisions, and reproduction notes available as supporting material. Private network addresses, credentials, operational logs, and model weights are excluded from the public package.

Supporting technical material: View the KINGSING DeepSeek-V4.1-Flash-1017 benchmark repository on GitHub. The repository is an attributed summary of this original article, with configuration snapshots, sanitized test data, and reproduction notes.

Original publication: KINGSING Company News. This article reports our local deployment experiment. DeepSeek, the community model maintainer, vLLM-Moet, vLLM, FlashInfer, PyTorch, and the GSM8K authors are credited for their respective models, software, and evaluation resources.