DS4-F Under Three Lights: Tool Discipline, Throughput, and Hermes Fit

June 25, 2026 — by Milo H

I ran DeepSeek V4 Flash through three different tests: live Hermes operational probes, tool-eval-bench, and llama-benchy. The answer is not a single magic score. The answer is a shape: useful local agent backend, strong tool behavior, acceptable decode speed, and clear cracks under strict protocols and adversarial state.

Contents
  1. The endpoint
  2. Scorecard
  3. Hermes probes
  4. tool-eval-bench
  5. llama-benchy
  6. What it means

The endpoint

The tested endpoint is the live DS4-F route:

Served modeldeepseek-v4-flash
EnginevLLM API
Context profile393,216

This was the endpoint as Hermes sees it: OpenAI-compatible chat, streaming, tool-calling, long context, and multiple overlapping agent requests.

Scorecard

TestWhat it measuresResultMy read
Hermes/Aiden operational probesLive endpoint behavior for Hermes: chat, tool call, long context, short concurrency, streamingTool calls work; 60K sentinel recall works; c6 short smoke 6/6 OK; c6 streaming aggregate 105.09 tok/sHealthy as a Hermes backend.
tool-eval-benchTool choice, arguments, state, schemas, refusals, adversarial tool contexts87 / 100Strong general tool-user; weaker under precision, crowded tools, state, and adversarial cases.
llama-benchyOpenAI-compatible endpoint throughput across prompt depths and concurrency25–34 tok/s single-stream decode; 1.4–2.15k tok/s prefill; 69.1 tok/s total at c4Usable, not a per-stream speed demon. Better as concurrent local workers.

1. Hermes/Aiden operational probes

The first test is the boring operational one: does the endpoint behave correctly when used as a Hermes backend? It does.

ProbeResultLatencyNotes
Plain chatOK0.188sThinking disabled; no reasoning field.
Native tool calladd({"a":19,"b":23})1.629sReturned real OpenAI tool_calls[], not prose.
Long-context sentinelCorrect recall0.609s60,030 prompt tokens; prefix cache likely helped this repeat run.
c6 short smoke6/6 OKmedian 0.365sSix simultaneous exact-response requests.
Streaming workloadPrompt tokensOutput tokensTTFTElapsedDecode after TTFTWall tok/s
Short c1312561.214s7.074s43.68 tok/s36.19
23K prompt c123,41911411.082s14.066s38.2 tok/s8.1
94K prompt c193,6196436.048s37.712s38.46 tok/s1.7
c3 concurrent short decode21 each426 totalmedian 1.953s7.62smixed55.91 aggregate
c6 concurrent short decode21 each864 totalmedian 0.237s8.222smixed105.09 aggregate
Terminal-Bench caveat: the Hermes/Aiden profile did not produce a valid Terminal-Bench 2 score. The endpoint was healthy, but Terminus-2 requires strict JSON-only task_complete: true; the Hermes-tuned profile did useful shell work without obeying that completion protocol. Diagnostic, not leaderboard.

2. tool-eval-bench

tool-eval-bench tests whether the model can behave like a tool-using agent rather than a plausible chatbot.

Final score87 / 100
Points120 / 138
Pass / partial / fail57 / 6 / 6
CategoryScoreWhat it says
Tool Selection100%Strong at choosing the obvious right tool.
Multi-Step Chains100%Can chain normal tool workflows.
Structured Output100%Very good schema compliance in this harness.
Parameter Precision67%Argument extraction is a real weakness.
Toolset Scale75%Crowded namespaces make it worse.
Safety & Boundaries77%Good enough for normal use, not enough for unattended adversarial work.
Context & State80%Long turn accumulation still needs supervision.

The failure pattern matters: multi-value extraction, scope limitation, contradictory parameters, crowded namespaces, deep multi-turn research, notification workflow, search-result injection, cross-turn sleeper injection. Translation: DS4-F is a strong normal tool-user, but it still needs guardrails around precision, long-lived state, and adversarial context.

Caveat: the monolithic 69-scenario benchmark process wedged just after TC-46 while writing/emitting progress. The vLLM server stayed healthy. The final score is reconstructed from completed TC-01..TC-60 events plus a clean TC-61..TC-69 continuation.

3. llama-benchy

llama-benchy measures the endpoint as an OpenAI-compatible chat server. The story is simple: single-stream decode is acceptable, prefill is decent, and concurrency improves aggregate throughput while slowing each individual request.

DepthPromptOutputPrefill tok/sDecode tok/sTTFR
0512321437.7 ± 24.028.0 ± 6.8586 ms
020481281970.4 ± 21.229.6 ± 1.41269 ms
40965121282154.9 ± 21.431.7 ± 2.92369 ms
40962048322127.5 ± 5.434.3 ± 1.33118 ms
163845121282104.9 ± 7.524.7 ± 1.58257 ms
1638420481282091.5 ± 3.526.4 ± 4.39043 ms
ConcurrencyTotal gen tok/sPer-request gen tok/sPeak totalTTFR
130.9 ± 2.030.937.0591 ms
248.8 ± 3.324.862.0813 ms
469.1 ± 2.517.998.01254 ms

What the three tests say together

The three views line up:

  1. Hermes operational probes: the server is healthy and practical. Tool calls work. Long context works. Short concurrency works.
  2. tool-eval-bench: the model has real tool discipline and strong structured-output behavior, but still needs guardrails around adversarial context, precision, and long state.
  3. llama-benchy: the serving stack is usable, with concurrency helping more than single-stream speed.
DS4-F is a capable local workhorse. Let it handle normal tool-using agent work, coding subagent drafts, structured transformations, and long-context local tasks. Keep strict benchmark protocols, high-stakes autonomy, and adversarial workflows behind stronger guardrails or different routes.

Decisions I would make from this

Artifact provenance

Bottom line: DS4-F passes the smell test. It is not flawless, and it is not magically fast, but it can call tools, obey schemas, carry context, and run without renting every token from a frontier API. That is enough to matter.