While deploying HPE Morpheus Manager from Windows, the installer reported:
Connection failed: SECURITY WARNING: Host key for 192.0.2.50:22 has changed!
This could indicate a man-in-the-middle attack. Connection refused.
This means the SSH client used by the installer had a previously saved host key
for 192.0.2.50:22, but the remote system now presented a different one. This
commonly happens after rebuilding a server, restoring a VM, changing an IP
assignment, or regenerating SSH host keys. It must always be treated as a
potential security issue until the new host fingerprint has been verified
independently.
I’ve been evaluating DFlash2 speculative decoding for Qwen3.8-27B
(NVFP4) on a single NVIDIA DGX Spark (GB10) in the homelab — the successor
to the Qwen3.6-27B DFlash setup that was my daily driver, kept behind the same
OpenAI-compatible contract the agents already use.
Before switching to DFlash2, I ran Qwen3.8-27B (NVFP4) on vLLM 0.27.2rc1
with MTP speculative decoding (3 tokens) on the DGX Spark (GB10). This is
the baseline the DFlash2 stack has to beat.
Config: 3 speculative tokens · 262,144 max context · 0.45 GPU-memory
utilisation · max 4 sequences.
Concurrency
Throughput
1
30.99 tok/s
2
57.76 tok/s aggregate
Near-linear scaling from 1 to 2 concurrent streams — the box has clear headroom
left at concurrency 2, which is why the follow-up DFlash2 runs are only the
floor, not the ceiling.
Before Qwen3.8 landed, Qwen3.6-27B (NVFP4) with DFlash speculative decoding
was my favourite local model on the DGX Spark (GB10) — the dense 27B quality
I wanted, finally at a speed I could live with. The earlier FP8 build of this
same model only managed ~8–16 tok/s; NVFP4 + DFlash changed the picture
completely.
The headline: ~6× over the FP8 baseline
Same workload (20 requests, concurrency 2, ~512 in / 128 out), FP8 baseline vs
NVFP4 + DFlash:
A small, fast model — Qwen2.5-3B (65k context) — served through Ollama,
benchmarked to decide whether it was worth moving to llama.cpp.
Metric
Median
Output throughput
71 tok/s
TTFT
1.75 s
Request latency
3.51 s
Failures
0
Results were excellent and extremely consistent across runs.
Bottom line: keep Ollama. There’s no performance reason to move to
llama.cpp for this workload — spend the effort testing alternative models for
quality instead, not swapping the runtime. The laziest stack that hits the
numbers wins.
Qwen3.6-27B-FP8, a dense 27B model on the DGX Spark (GB10) — every
token activates all 27B parameters, so it trades speed for per-token quality.
Metric
Value
Status
✅ up, no init errors
Generation throughput
~8.3 tok/s steady
Prompt throughput
51–381 tok/s bursts (prefill)
KV cache usage
2–3% (131k context configured)
Prefix cache hit rate
48% → 81%, climbing
Active requests
0–1, all 200 OK
The slower generation (8.3 vs the 15–25 tok/s of the MoE/smaller models) is
expected for a dense 27B — the payoff is noticeably higher quality per token,
especially for code and reasoning. Prefix caching climbing to 81% means
repeat conversations and code completion feel far snappier than the raw 8 tok/s
suggests.
Qwen3-VL-8B-FP8, the vision model, filling the fast auxiliary roles on the
DGX Spark (GB10) — titles, approvals, MCP routing, screenshot follow-ups.
Metric
Value
Status
✅ up, no errors
Generation throughput
11–25 tok/s (peaks 25)
Prompt throughput
~76 tok/s sustained
KV cache usage
2–3% (massive headroom)
MM (image) cache hit rate
60–75%
Prefix cache hit rate
12–60%
Warnings
2× Triton JIT first-touch (one-time, harmless)
Qwen is actually faster at generation than the 120B Nemotron (25 vs ~15
tok/s) — exactly what you want where latency matters. The multimodal cache
working well means repeated questions about the same image get a free speedup:
the vision encoder skips the re-encode.
Running NVIDIA Nemotron-3 Super 120B (A12B, NVFP4) — a Mixture-of-Experts
model with ~12B active parameters per token — on a single DGX Spark (GB10).
Snapshot from a healthy serving window:
Metric
Value
Status
✅ up, no errors
Generation throughput
~13–16 tok/s steady
Prompt throughput
bursts up to 2,400 tok/s (prefix-cached)
KV cache usage
7.9–9.6%
Prefix cache hit rate
62–63%
Active requests
0–1, all 200 OK
Bottom line: comfortable. KV under 10% means plenty of headroom for longer
prompts, and ~15 tok/s is right where you’d expect a 12B-active MoE to land on
this box. This is my heavy long-context reasoning engine.
