DeepSeek V4 Flash 0731をRTX PRO 6000 Blackwell Max-Q 96GB 2枚に載せた。Runtimeはcustom vLLMのGilded Gnosis r24、Tensor Parallel 2、DSpark K5、FP8 compressed MLA KV、native CPU KV offloadという構成。

この構成でCoding-agent workloadを実行し、生成物を確認するまでの様子を動画にまとめた。

動画リンク: https://www.youtube.com/watch?v=E7JroDgE9no

MAX_MODEL_LEN=262144で起動し、GPU KV cacheは285,336 tokens確保できた。262,144 tokensのrequestを1本載せたときの理論concurrencyは1.09xになる。Coding-agent workloadではgeneration throughputが最大359.0 tok/s、single active requestの中央値が230.9 tok/sだった。

結果

項目実測値
Modeldeepseek-ai/DeepSeek-V4-Flash-0731
RuntimevLLM Gilded Gnosis r24
GPURTX PRO 6000 Blackwell Max-Q 96GB x2
Tensor Parallel / DCP2 / 1
Expert pathmodel-native FP4 / B12X W4A8
KV cacheFP8 DeepSeek compressed MLA
Configured context262,144
Maximum sequences2
GPU KV capacity285,336 tokens
262K request concurrency1.09x
Peak GPU KV usage79.4%
Peak generation throughput359.0 tok/s
Single-active-request median230.9 tok/s
Single-active-request IQR167.9-279.3 tok/s
Nonzero-window mean205.6 tok/s
Peak prompt throughput5,790.1 tok/s
DSpark acceptance lengthmedian 5.12 / best 5.90
DSpark draft acceptancemedian 82.4% / best 98.1%
CPU KV offload8 GiB total across TP ranks
Observed KV copy rateapproximately 50-55 GB/s
Captured access-log results101 / 101 HTTP 200

ThroughputとDSparkの統計値はCodexでvLLMのserver logを集計した。grafana telemetryから推定した値ではない。

既存のDeepSeek V4 Flash記事との違い

以前はDwarfStar 4の専用runtimeでQ2 GGUFを単一GPUに載せたり、2台のcompute nodeへ分散してorchestratorとして試した。

今回は新しく公開されたDeepSeek-V4-Flash-0731

  • RuntimeはDwarfStar 4ではなくcustom vLLM
  • CheckpointはDeepSeek-V4-Flash-0731
  • Expert weightsはmodel-native FP4
  • GPUは1台ではなく、1ホスト内のRTX PRO 6000 x2
  • DSpark K5 speculative decodingを使用
  • GPU KVにFP8 compressed MLAを使用
  • /dev/shm上のnative CPU KV offloadを使用

検証環境

項目内容
Host CPUAMD EPYC 9175F
Host RAM768GB DDR5 ECC
GPUNVIDIA RTX PRO 6000 Blackwell Max-Q Workstation Edition x2
VRAM96GB x2
GPU linkPCIe 5.0 x16
OSUbuntu 24.04
ContainerPodman / Quadlet
Modeldeepseek-ai/DeepSeek-V4-Flash-0731
Model snapshot7872f01b1d1fe23eabc4c98b48bffcef5a386062
Image usedregistry.home.arpa/vllm:deepseek-v4
Base releaseGilded Gnosis v20 r24
Runtime versionv0.11.2.dev280 custom build

実際に起動したvLLM versionは次の通り。

  Aug 04 01:45:09 compute-server grandpa[415455]: (APIServer pid=52) INFO 08-04 01:45:09 [api_utils.py:345]  ▄▄ ▄█ █     █     █ ▀▄▀ █  version 0.11.2.dev280+gilded.gnosis.v20.vllmf5981f1.si2b9bf2a.fi801d57a.cu132.20260803.r24
Aug 04 01:45:09 compute-server grandpa[415455]: (APIServer pid=52) INFO 08-04 01:45:09 [api_utils.py:345]   █▄█▀ █     █     █     █  model   /models/snapshots/7872f01b1d1fe23eabc4c98b48bffcef5a386062

Private mirrorの元になったrelease imageは次のbuild。

  voipmonitor/vllm:gilded-gnosis-v20-vllmf5981f1-si2b9bf2a-fi801d57a-cu132-20260803-r24
Docker manifest: sha256:64b94299abdd3bcf5bb5050ca91b378f9ee4e0b0eff4748375b95352371d7cb2
Local image ID: sha256:dc0bc459b8c1d59f84e945a4b77f65ea474778b58f4a95d3e3d1c97632daeb1d

Model-native FP4 expertとB12X W4A8

Expert weightsがmodel-native FP4で、一般的なpost-training Q4 conversionを作成ではない。 起動ログでもFP4 expert、W4A8、compressed MLA KV、FP8 Lightning Indexerが確認できた。

  (Worker_TP0 pid=496) INFO [quant_config.py:75] DeepSeek V4 expert_dtype resolved to 'fp4'
(Worker_TP0 pid=496) INFO [attention.py:98] Using DeepSeek's fp8_ds_mla KV cache format.
(Worker_TP0 pid=496) INFO [mxfp4.py:426] Using 'B12X' Mxfp4 MoE backend.
(Worker_TP0 pid=496) INFO [attention.py:1023] Using FP8 indexer cache for Lightning Indexer.
(Worker_TP0 pid=496) WARNING [b12x_moe.py:810] B12X MoE force-A8 enabled: using quant_mode=w4a8_mx for E8M0 FP4 weights.

Model loadingはInstantTensorのBUFFERED backendを使った。Model weightsは各GPUで81.01 GiBを占める。

DSpark K5

DSparkが1回のverificationで5個のdraft tokenを提案するfixed-depth profileを指す。

  Environment=MODE=dspark
Environment=DSPARK_DEPTH_MODE=fixed
Environment=DSPARK_TOKENS=5

この構成ではMAX_NUM_BATCHED_TOKENS=8192に対して、speculative decoding用のslotを差し引いた実効scheduled tokensが8,184になった。

  Aug 04 02:44:37 compute-server grandpa[572062]: (EngineCore pid=179) WARNING 08-04 02:44:37 [vllm.py:1758] max_num_scheduled_tokens is set to 8184 based on the speculative decoding settings. This may lead to suboptimal performance. Consider increasing max_num_batched_tokens to accommodate the additional draft token slots, or decrease num_speculative_tokens or max_num_seqs.

このrunではCurrent speculative depth: 5に対してacceptance lengthが最大5.90まで伸びた。これは5個のdraft tokenとは別に、通常のtarget tokenを含めて数えるmetricsであるため。Draft acceptanceはprompt依存で、常に高いわけではなかった。

Quadlet

このimageは標準のvllm-openai entrypointへ引数を直接並べる構成ではない。Image内のserve-ds4-flash.shが環境変数からDeepSeek V4専用のvLLM引数、SparkInfer backend、DSpark設定を組み立てる。

そのためQuadletのExecは次の1行になる。

  Exec=/usr/local/bin/serve-ds4-flash.sh

実際に使ったQuadletは次の通り。

  [Unit]
Description=DeepSeek V4 Flash 0731 / DSpark r24
After=network-online.target
Wants=network-online.target

[Container]
ContainerName=grandpa
Image=registry.home.arpa/vllm:deepseek-v4
Pull=always

Network=host
AddDevice=nvidia.com/gpu=0
AddDevice=nvidia.com/gpu=1
PodmanArgs=--ipc=host --privileged
RunInit=true

Volume=/mnt/data/hf/hub/models--deepseek-ai--DeepSeek-V4-Flash-0731:/models:ro
Volume=/mnt/data/hf/jit/ds4-v20-r24:/cache
Volume=/mnt/data/hf/tmp/ds4-v20-r24:/container-tmp

Environment=BACKEND=b12x-a8
Environment=CUDA_VISIBLE_DEVICES=0,1
Environment=DCP_SIZE=1
Environment=DSPARK_DEPTH_MODE=fixed
Environment=DSPARK_TOKENS=5
Environment=GPU_MEMORY_UTILIZATION=0.975
Environment=INSTANTTENSOR_BACKEND=BUFFERED
Environment=KV_OFFLOADING_SIZE=8
Environment=LOAD_FORMAT=instanttensor
Environment=MAX_MODEL_LEN=262144
Environment=MAX_NUM_BATCHED_TOKENS=8192
Environment=MAX_NUM_SEQS=2
Environment=MODE=dspark
Environment=MODEL_PATH=/models/snapshots/7872f01b1d1fe23eabc4c98b48bffcef5a386062
Environment=PORT=8000
Environment=SERVED_MODEL_NAME=grandpa
Environment=TP_SIZE=2

Ulimit=memlock=-1:-1
Ulimit=nofile=1048576:1048576
Ulimit=stack=67108864:67108864

Exec=/usr/local/bin/serve-ds4-flash.sh

[Service]
ExecStartPre=/usr/bin/mkdir -p /mnt/data/hf/jit/ds4-v20-r24 /mnt/data/hf/tmp/ds4-v20-r24
TimeoutStartSec=3600
TimeoutStopSec=120
Restart=on-failure
RestartSec=30
LimitMEMLOCK=infinity
LimitNOFILE=1048576
LimitSTACK=67108864

--ipc=hostを使っているため、ShmSize=は指定できない。Podmanではhost IPCとcontainer固有のshm sizeを同時指定すると起動時に拒否されるのでどちらかにする必要がある。

また、この構成の--privilegedは最小権限設定ではない。今回の検証では起動を優先した実設定として残している。

GPU memoryとKV capacity

Graph capture後の内訳は各GPUで次のようになった。

項目1 GPUあたり
Model weights81.01 GiB
Peak activation2.45 GiB
Non-torch memory0.20 GiB
CUDA graph0.14 GiB
GPU KV cache8.59 GiB

生ログではmemory内訳とKV capacityが同じstartup sequenceに出ている。

  Aug 04 02:44:21 compute-server grandpa[572062]: (Worker_TP0 pid=264) INFO 08-04 02:44:21 [gpu_worker.py:617] Available KV cache memory: 8.59 GiB
Aug 04 02:44:21 compute-server grandpa[572062]: (EngineCore pid=179) INFO 08-04 02:44:21 [kv_cache_utils.py:2428] GPU KV cache size: 285,336 tokens
Aug 04 02:44:21 compute-server grandpa[572062]: (EngineCore pid=179) INFO 08-04 02:44:21 [kv_cache_utils.py:2429] Maximum concurrency for 262,144 tokens per request: 1.09x
Aug 04 02:44:27 compute-server grandpa[572062]: (Worker_TP0 pid=264) INFO 08-04 02:44:27 [gpu_worker.py:918] Free memory on device (93.73/94.97 GiB) on startup. Desired GPU memory utilization is (0.975, 92.59 GiB). Actual usage is 81.01 GiB for weight, 2.45 GiB for peak activation, 0.2 GiB for non-torch memory, and 0.14 GiB for CUDAGraph memory. Replace gpu_memory_utilization config with `--kv-cache-memory-bytes=9288604570` (8.65 GiB) to fit into requested memory, or `--kv-cache-memory-bytes=10511114752` (9.79 GiB) to fully utilize gpu memory. Current kv cache memory in use is 8.59 GiB.
Aug 04 02:44:36 compute-server grandpa[572062]: (EngineCore pid=179) INFO 08-04 02:44:36 [core.py:345] init engine (profile, create kv cache, warmup model) took 47.53 s (compilation: 12.64 s)

Active sequenceの割り振り

現在のGPU KV capacityを安全側に約256Kのactive working setとして扱うと、運用イメージは次のようになる。

Active sequences1 sequenceあたりの総token目安
1256K
2128K
464K

ここでいう総tokenはinputだけではなく、現在のpromptと生成済みoutputの合計。64K inputからさらに32K生成すれば、そのsequenceは96Kを使う。

柔軟に使うならMAX_MODEL_LEN=262144を維持し、MAX_NUM_SEQSを4へ増やしたうえで、agent-loop, orchestrator側でactive sequenceのtoken総量を制限する方法が考えられる。

  sum(active prompt tokens + generated tokens + output headroom) <= approximately 256K

Native CPU KV offload

KV_OFFLOADING_SIZE=8はTP0とTP1で共有するhost RAM poolの合計が8 GiBになる。

  Aug 04 02:44:22 compute-server grandpa[572062]: (Worker_TP0 pid=264) INFO 08-04 02:44:22 [shared_offload_region.py:85] Created mmap file /dev/shm/vllm_offload_f5388900-1119-46b2-b2eb-178e4b7e21c5.mmap (8.59 GB)
Aug 04 02:44:22 compute-server grandpa[572062]: (Worker_TP1 pid=265) INFO 08-04 02:44:22 [shared_offload_region.py:93] Opened existing mmap file /dev/shm/vllm_offload_f5388900-1119-46b2-b2eb-178e4b7e21c5.mmap
Aug 04 02:44:22 compute-server grandpa[572062]: (Worker_TP0 pid=264) INFO 08-04 02:44:22 [shared_offload_region.py:176] Unlinked mmap file /dev/shm/vllm_offload_f5388900-1119-46b2-b2eb-178e4b7e21c5.mmap after 2 workers mapped it

mmap fileという名前でもSSDへ書いているわけではない。/dev/shmは通常tmpfsで、実体はhost DRAMになる。GPUとの転送はPCIe 5.0 x16を通る。

今回のtransfer metricsをbytes / recorded copy timeで計算すると、storeはweighted 54.38 GB/s、loadはweighted 51.46 GB/sだった。

DirectionWeighted rateObserved range
GPU to host RAM (store)54.38 GB/s52.09-55.56 GB/s
Host RAM to GPU (load)51.46 GB/s48.02-54.91 GB/s

最大のstore intervalは1.415 GBを27.17 ms、最大のload intervalは185.3 MBを3.37 msで転送している。

  Aug 04 02:49:49 compute-server grandpa[572062]: (APIServer pid=53) INFO 08-04 02:49:49 [metrics.py:103] KV Transfer metrics: vllm:kv_offload_store_bytes=1415335680, vllm:kv_offload_store_time=0.027173248052597042, vllm:kv_offload_store_size_count=18, vllm:kv_offload_store_size_sum=1415335680, vllm:kv_offload_cpu_cache_usage_perc=0.0, vllm:kv_offload_cpu_allocation_size_count=7, vllm:kv_offload_cpu_allocation_size_sum=503, vllm:kv_offload_cpu_cache_write_usage_perc=0.0, vllm:kv_offload_cpu_cache_read_usage_perc=0.0
Aug 04 02:49:59 compute-server grandpa[572062]: (APIServer pid=53) INFO 08-04 02:49:59 [metrics.py:103] KV Transfer metrics: vllm:kv_offload_cpu_cache_usage_perc=0.0, vllm:kv_offload_cpu_cache_write_usage_perc=0.0, vllm:kv_offload_cpu_cache_read_usage_perc=0.0, vllm:kv_offload_lookup_sync_delay_seconds_count=5, vllm:kv_offload_lookup_sync_delay_seconds_sum=9.603999751561787e-05, vllm:kv_offload_load_bytes=185264640, vllm:kv_offload_load_time=0.0033739200830459597, vllm:kv_offload_load_size_count=2, vllm:kv_offload_load_size_sum=185264640, vllm:kv_offload_cpu_allocation_size_count=5, vllm:kv_offload_cpu_allocation_size_sum=139, vllm:kv_offload_store_bytes=299439360, vllm:kv_offload_store_time=0.005468831906095147, vllm:kv_offload_store_size_count=10, vllm:kv_offload_store_size_sum=299439360

PCIe 5.0x16のraw片方向bandwidthは約64 GB/sなので、50-55 GB/sは不自然な値ではない。

今回のworkloadでkv_offload_cpu_cache_usage_percの観測最大は約3.86%だった。8 GiB poolを使い切る負荷ではない。Offload pathが動いたことは確認できたが、巨大なCPU tierの容量評価にはなっていない。

768GB RAMで増えるのはKVの保管量

このhostの768GB RAMをCPU KV offloadに使っても、1 requestの最大contextや、GPU上で同時に処理できるKV量は増えない。増えるのは、一度計算したprefix KVをCPU側へ残し、後続requestで再利用できる量になる。

今回の構成では、TP2全体のGPU KV 17.18 GiBが285,336 logical tokensに相当した。同じKV block layoutがCPU側でも保たれると仮定すると、512 GiBのCPU poolは次の保存容量に相当する。

  285,336 tokens x (512 GiB / 17.18 GiB)
  = approximately 8.5 million token-block equivalents

262,144-tokenの履歴なら単純換算で約32本分の保存量になる。ただし、これは32本を同時実行できるという意味ではない。CPU側にあるKVを再利用するときはPCIe経由でGPUへ戻す必要があり、実際の保存量もblock rounding、metadata、eviction、shared prefixによって変わる。

今回のnative offloadは、使われていないprefix KVをCPUに退避して再利用するcacheで、実行中requestをCPU上だけで継続するものではない。KV_OFFLOADING_SIZEを512 GiBへ増やしただけでは、次の値は変わらない。

  • MAX_MODEL_LEN
  • GPU KV cacheの285,336 tokens
  • GPU上のactive working set
  • 設定済みのMAX_NUM_SEQS

また、512 GiBのshared mmapには、十分な/dev/shm、実際の空きRAM、memlock、CUDA host registrationが必要になる。

  df -h /dev/shm

これは8 GiB runから計算した上限換算であり、512 GiBでの起動、latency、実効capacityは未検証になる。

Generation throughputとDSpark acceptance

10秒ごとのvLLM metrics windowを集計した。

  • Running: 1の22 windowsからmedianとTukey IQRを算出
  • Generation throughputがnonzeroの34 windowsからmeanを算出
  • DSpark metricsがある34 windowsからacceptance統計を算出
  • CPU KV bandwidthはsum(bytes) / sum(recorded transfer time)で算出
MetricValue
Peak generation throughput359.0 tok/s
Single-active-request median230.9 tok/s
Single-active-request IQR167.9-279.3 tok/s
Mean across nonzero windows205.6 tok/s
Peak prompt throughput5,790.1 tok/s
Acceptance length median5.12
Acceptance length mean4.86
Acceptance length best5.90
Draft acceptance median82.4%
Draft acceptance mean77.2%
Draft acceptance best98.1%
Draft acceptance range41.9-98.1%
Accepted speculative throughput median161.2 tok/s
Accepted speculative throughput best298.2 tok/s

最もDSparkが効いたwindowではgeneration throughput 359.0 tok/s、draft acceptance 98.1%だった。

  Aug 04 02:46:09 compute-server grandpa[572062]: (APIServer pid=53) INFO 08-04 02:46:09 [loggers.py:314] Engine 000: Avg prompt throughput: 0.0 tokens/s, Avg generation throughput: 359.0 tokens/s, Running: 1 reqs, Waiting: 0 reqs, GPU KV cache usage: 1.9%, Prefix cache hit rate: 88.1%, External prefix cache hit rate: 0.8%
Aug 04 02:46:09 compute-server grandpa[572062]: (APIServer pid=53) INFO 08-04 02:46:09 [metrics.py:125] SpecDecoding metrics: Mean acceptance length: 5.90, Current speculative depth: 5, Accepted throughput: 298.18 tokens/s, Drafted throughput: 303.98 tokens/s, Accepted: 2982 tokens, Drafted: 3040 tokens, Per-position acceptance rate: 1.000, 0.998, 0.993, 0.972, 0.941, Avg Draft acceptance rate: 98.1%

一方でpromptによってはacceptanceが41.9%まで下がった。

  Aug 04 02:47:59 compute-server grandpa[572062]: (APIServer pid=53) INFO 08-04 02:47:59 [loggers.py:314] Engine 000: Avg prompt throughput: 0.0 tokens/s, Avg generation throughput: 193.9 tokens/s, Running: 1 reqs, Waiting: 0 reqs, GPU KV cache usage: 3.3%, Prefix cache hit rate: 95.2%, External prefix cache hit rate: 9.3%
Aug 04 02:47:59 compute-server grandpa[572062]: (APIServer pid=53) INFO 08-04 02:47:59 [metrics.py:125] SpecDecoding metrics: Mean acceptance length: 3.09, Current speculative depth: 5, Accepted throughput: 131.19 tokens/s, Drafted throughput: 313.47 tokens/s, Accepted: 1312 tokens, Drafted: 3135 tokens, Per-position acceptance rate: 0.789, 0.542, 0.362, 0.247, 0.152, Avg Draft acceptance rate: 41.9%

Peakだけを見ると359 tok/sだが、このruntimeの実用値はacceptanceによって大きく動く。今回のworkloadではsingle-active-request medianの約231 tok/sを中心値として扱うほうがよい。

Prompt throughput 5,790.1 tok/sはmixed long-context workload中のwindow peakであり、独立した固定長prefill benchmarkではない。

  Aug 04 02:49:39 compute-server grandpa[572062]: (APIServer pid=53) INFO 08-04 02:49:39 [loggers.py:314] Engine 000: Avg prompt throughput: 2649.6 tokens/s, Avg generation throughput: 107.1 tokens/s, Running: 1 reqs, Waiting: 0 reqs, GPU KV cache usage: 79.4%, Prefix cache hit rate: 95.9%, External prefix cache hit rate: 3.7%
Aug 04 02:49:49 compute-server grandpa[572062]: (APIServer pid=53) INFO 08-04 02:49:49 [loggers.py:314] Engine 000: Avg prompt throughput: 5790.1 tokens/s, Avg generation throughput: 115.7 tokens/s, Running: 1 reqs, Waiting: 0 reqs, GPU KV cache usage: 4.2%, Prefix cache hit rate: 95.9%, External prefix cache hit rate: 3.7%

Peak GPU KV usageは79.4%。285,336 slotsの単純換算では約226K token slotsに相当する。ただし複数request、shared prefix、block allocationを含むruntime gaugeなので、単一prompt長そのものではない。

Prefix cache

Prefix cache hit rateは最大97.4%、external prefix cache hit rateは最大11.4%だった。

  Aug 04 02:49:29 compute-server grandpa[572062]: (APIServer pid=53) INFO 08-04 02:49:29 [loggers.py:314] Engine 000: Avg prompt throughput: 293.2 tokens/s, Avg generation throughput: 136.6 tokens/s, Running: 0 reqs, Waiting: 0 reqs, GPU KV cache usage: 0.0%, Prefix cache hit rate: 97.4%, External prefix cache hit rate: 6.7%
Aug 04 02:50:39 compute-server grandpa[572062]: (APIServer pid=53) INFO 08-04 02:50:39 [loggers.py:314] Engine 000: Avg prompt throughput: 250.6 tokens/s, Avg generation throughput: 166.5 tokens/s, Running: 1 reqs, Waiting: 0 reqs, GPU KV cache usage: 2.1%, Prefix cache hit rate: 95.5%, External prefix cache hit rate: 11.4%

External prefix cacheとnative CPU KV offloadは同じものではない。Gilded Gnosis r24のrunbookでは、native offloadはqualified host-cache path、LMCacheはDS4に対してexperimentalという位置づけだった。

Coding-agent workload

Client requestはvLLMへ直接送っていない。自作のagent-loop runtimeであるFamiliarを通し、tool-call correctionとtelemetryを適用している。

代表requestは44 messages、10 tools、41,230 prompt tokens、800 completion tokensだった。

  {"time":"2026-08-04T11:49:58.642929+09:00","level":"INFO","msg":"backend POST","url":"http://compute.home.arpa:8000/v1/chat/completions","model":"grandpa","stream":true,"req_stream_arg":true,"payload_bytes":180640,"total_content_chars":136124,"n_messages":44,"tools":10,"max_tokens":32768,"max_completion_tokens":32768,"reasoning_format":null,"reasoning_effort":null,"temperature":0.7}
{"time":"2026-08-04T11:50:02.952783+09:00","level":"INFO","msg":"http request","method":"POST","path":"/v1/chat/completions","status":200,"duration":4317612500,"model":"familiar","message_count":44,"prompt_tokens":41230,"completion_tokens":800}

Captured vLLM access logには101件のHTTP 200があり、同じ範囲でnon-200 response、CUDA OOM、fatal CUDA error、tracebackは0件だった。

  Aug 04 02:50:28 compute-server grandpa[572062]: (APIServer pid=53) INFO:     10.10.10.2:52922 - "POST /v1/chat/completions HTTP/1.1" 200 OK
Aug 04 02:50:30 compute-server grandpa[572062]: (APIServer pid=53) INFO:     10.10.10.2:52922 - "POST /v1/chat/completions HTTP/1.1" 200 OK
Aug 04 02:50:34 compute-server grandpa[572062]: (APIServer pid=53) INFO:     10.10.10.2:52922 - "POST /v1/chat/completions HTTP/1.1" 200 OK
Aug 04 02:50:36 compute-server grandpa[572062]: (APIServer pid=53) INFO:     10.10.10.2:52922 - "POST /v1/chat/completions HTTP/1.1" 200 OK
Aug 04 02:50:38 compute-server grandpa[572062]: (APIServer pid=53) INFO:     10.10.10.2:52922 - "POST /v1/chat/completions HTTP/1.1" 200 OK

このworkloadではDjangoのrestaurant reservation systemを生成した。Artifactには25 domain models、9 public service methods、12 API endpoints、Django Admin、seed dataが含まれ、52 testsはすべて通った。

  uv run --frozen --offline python manage.py test --verbosity 2
  
  Ran 52 tests in 0.419s
OK

Seed dataを投入したDjango Adminでは、Lakeside Bistroに対するPrivate Event、Maintenance、Holidayの3件のexceptional closureを確認できた。

DeepSeek V4 Flash 0731で生成したrestaurant reservation systemのseed dataを表示するDjango Admin画面
生成物へseed dataを投入したDjango Admin。Lakeside Bistroのexceptional closureとしてPrivate Event、Maintenance、Holidayの3件が登録されている。

一方で別途reviewすると、timezone-aware availability calculation、waitlistとholdのexpiry enforcement、invalid foreign key handlingにprototype-levelの問題が残っていた。生成物は単純なscaffoldより大きいが、production-readyという評価ではない。

Tool callingについても、Familiarの補正を通した結果とvLLMへ直接requestした結果は分けて考える必要がある。

注意点

256K capacityと256K correctnessは別

今回確認したのは、262,144 context設定で起動し、285,336 GPU KV tokensを確保し、mixed long-context workloadが安定して完走したこと。

CPU offload APIはexperimental

Startup logにはCPUOffloadingSpec APIがexperimentalと出る。r24でnative offload pathのruntime testは通っているが、API contractが今後変わる可能性はある。

  Aug 04 02:44:21 compute-server grandpa[572062]: (Worker_TP0 pid=264) WARNING 08-04 02:44:21 [base.py:493] Initializing OffloadingSpec. This API is experimental and subject to change in the future as we iterate the design.

First-run JIT

First runではSparkInfer、TileLang、CUDA graph artifactのcompileが走る。今回のengine initializationは47.53秒、うちcompilationは12.64秒だった。JIT cache volumeは再利用したほうがよい。

Tool Call

Client requestはFamiliarを通している。Familiarはtool-call correctionとtelemetryを適用するため、direct vLLMのtool calling behaviorは少し違う可能性がある。とはいえ、エディタ経由で使う場合に透過的に行っているのはtoolcallのリカバリ処理、vectorへテレメトリの送出が主なのでそんなに変わらないと思う。

ThroughputとDSparkの数値自体はvLLM server-side metrics logから取得した。

まとめ

DeepSeek V4 Flash 0731のmodel-native FP4 expert checkpointは、RTX PRO 6000 Blackwell 96GB 2枚で262K contextの実用構成まで載った。 出力内容を見てもterminalが秀逸でstepfunで長く運用していたけど、ds4で再調整を試みるつもりだ。

  1. FP8 compressed MLAにより、各GPU 8.59 GiBのKV memoryから285,336 logical tokensを確保できた
  2. DSpark K5が高acceptance windowで大きく効き、single-active-request medianでも約231 tok/sだった
  3. Native CPU KV offloadがTP2共有mmapとして動き、PCIe 5.0 x16経由で約50-55 GB/sのKV copy rateを記録した

GPU KVのactive working setを約256Kとして管理し、host RAMを再利用可能なprefix KVの階層cacheとして使う構成は、自作agent基盤と相性が良い。1 x 256K、2 x 128K、4 x 64Kというadmission controlをagent-loop側へ持たせれば、単一の長いsessionと複数の中規模sessionを同じruntimeで扱える。

References