Overseas Blogger Tests DeepSeek's New Flash Model: KV Cache Efficiency Up 337x

A tech blogger recently published an in-depth video testing DeepSeek's newly released Flash model. The headline finding is striking: the new model achieves a 337x improvement in KV cache efficiency compared to V1, with notable upgrades in visual generation, ML automation, and native object detection. This article summarizes the model's key features and real-world performance based on that hands-on evaluation.

Architecture Overhaul and Efficiency Leap

The blogger makes clear that this is not a simple iteration on the previous Flash model — it's a complete architectural redesign. The new model is nearly twice the size of its predecessor, yet more efficient. DeepSeek^Ad's optimization focus this time was squarely on the KV cache.

The most striking number: a 337x improvement in KV cache efficiency compared to V1. This matters enormously for users running long agentic tasks, since higher cache hit rates mean billing closer to the cached price rather than the full input price.

In one real-world test case, the blogger demonstrated a 99.7% cache hit rate: out of roughly 40 million tokens generated, nearly 39 million hit the cache. That means users are billed at the cache rate, dramatically cutting costs. API calls also delivered around 300 tokens per second output speed.

KV Cache Explained: KV cache (Key-Value Cache) is a core optimization mechanism in LLM inference. When processing input text, the model computes key-value pairs for each token. If those intermediate results can be stored and reused in subsequent requests, redundant computation is eliminated — reducing both cost and latency. For agentic tasks, a single session often contains large amounts of repeated system prompts, context, and tool definitions. If those hit the cache, the effective billing can be a fraction (often an order of magnitude lower) of the full input price. A 337x efficiency gain means the model can identify and reuse cached segments across a much larger and more granular scope, driving the actual cost of long conversations and complex multi-step tasks close to the theoretical minimum — especially critical for high-concurrency production environments.

Harness Choice Determines Performance Ceiling

A recurring theme in the video is that the harness (execution framework) used to run the model has an enormous impact on final performance. The blogger ran tests locally on two DGX machines using DeepSeek's official "DeepSeek Harness."

He cited comparative experiment data: on benchmarks like Terminal Bench 2.1 and DeepSuite V1.1, the same model's performance varied dramatically across different harnesses — DeepSuite V1.1 scores ranged from 69.8% all the way up to 74.2%.

"If you pick the wrong harness, you'll get suboptimal results from this model," he warned. He highlighted the DeepSeek Harness's work loop as a standout feature: plan → implement → verify, repeating continuously. Since the model can now use visual input, it can "see" its own output in a browser during implementation and iterate accordingly.

What Is a Harness? In AI evaluation and agentic deployment, a harness refers to the scaffolding code that wraps model calls — defining prompt structure, tool-calling conventions, output parsing logic, error retry mechanisms, and multi-step loop control. The same underlying model can exhibit dramatically different capabilities under different harnesses, because the harness determines how the model is used, not the model's parameters themselves. DeepSeek's official Harness's "plan → implement → verify" loop is a variant of the ReAct (Reasoning + Acting) paradigm. By introducing a visual verification step, it allows the model to review its own output in a browser and iterate — rather than blindly producing a one-shot result. Benchmarks like Terminal Bench and DeepSuite also embed their own harness assumptions, so cross-framework score comparisons require extra caution.

Significant Improvements in Visual Generation

The blogger's first test asked the model to fetch the real-time location of the International Space Station (ISS) and render it on a 3D globe. The result not only tracked the ISS position accurately but also correctly rendered the day/night distribution — North America in darkness and Asia in daylight at the time of testing — with impressive visual quality.

The full workflow under DeepSeek Harness follows an implement → visual check → iterate loop. The blogger also showed several other high-quality outputs, including scenes that toggle between different times of day with dynamic cloud layers, and a sea turtle swimming underwater — all faithfully following the prompt requirements, with noticeably better visual taste than previous generations.

First Open-Weight Model That Truly Excels at Training ML Models

The capability the blogger found most exciting is that this is the first open-weight model that genuinely excels at training machine learning models — effectively functioning as an AutoML agent. He provided a dataset with only a brief description and let the model decide how to approach the problem.

The model performed like a real ML engineer: it independently devised a strategy, performed feature selection, ran multiple experiments with different hyperparameter combinations, and converged on an optimal model. Even more noteworthy — the blogger deliberately left a data leakage issue in the dataset without mentioning it, and the model discovered it on its own, proactively dropping the affected feature. The blogger mentioned he'll produce a dedicated video on using LLMs for AutoML.

AutoML and Data Leakage Explained: AutoML (Automated Machine Learning) refers to algorithmically automating ML workflows that traditionally require human experts — including feature engineering, model selection, hyperparameter search, and result evaluation. Using LLMs for AutoML is an emerging direction: unlike traditional AutoML tools (e.g., Auto-sklearn, H2O AutoML), LLMs can interpret unstructured problem descriptions, generate interpretable decision rationale, and proactively intervene when data quality issues arise — as demonstrated here when the model independently detected and handled data leakage. Data leakage occurs when training data contains future information that wouldn't be available at real prediction time, causing inflated test-set performance and poor real-world deployment. The model's ability to autonomously identify and discard leaking features — without any prompt — signals a deep understanding of ML principles beyond mere code generation.

Native Visual Detection and Reasoning: No External CV Pipeline Required

Another major highlight is the model's native object detection capability — it can directly detect objects in images, reason about them, and count them, all without any external computer vision pipeline.

The blogger built a visual analysis benchmark: asking the model to extract component dimensions directly from technical drawings, or to classify and count objects in images. Results showed the model accurately detecting different car components and correctly classifying and counting various types of watercraft. In an advanced case, the blogger asked "How many boats are not sailboats? Answer with a single integer" — and the model correctly reasoned to "4."

The blogger also noted an honest limitation: bounding boxes generated by the model often have offsets. For example, one box didn't precisely frame the number "20," even though the extracted value itself was correct. He cautioned that for automated analysis pipelines, bounding box precision may not be fully reliable. These tests were run as single direct API calls, not within a harness.

Why Native Detection Matters: Traditional computer vision (CV) pipelines typically chain multiple independent modules: a detection model (e.g., YOLO, Detectron2) localizes objects and outputs bounding boxes, a classification model identifies categories, and additional logic handles counting and reasoning. This pipeline is engineering-heavy, maintenance-intensive, and prone to compounding errors across stages. Multimodal LLMs unify these capabilities in a single model, letting users describe requirements in natural language and receive end-to-end results. Bounding box offset is a common limitation of current multimodal LLMs: these models encode spatial information primarily through language tokens, making precise localization naturally weaker than purpose-built detection models. In scenarios requiring pixel-level precision (e.g., auto-labeling, industrial inspection), caution is warranted — but for semantic understanding and counting tasks, they are fully capable.

Positioning and Use Cases

The blogger openly acknowledges the video doesn't cover traditional benchmark scores — because he believes this model's absolute capability falls short of top-tier models like Opus 5. But he emphasizes: "Not every application needs state-of-the-art capability."

Thanks to its very low pricing, the model is highly competitive in two specific scenarios: first, visual analysis tasks where it's cheap and accurate enough to use directly via API; and second, as a sub-agent within long-running agentic systems, where it shines under an appropriate framework like DeepSeek Harness. Considering its pricing and capabilities together, it's a compelling choice whether deployed locally or as a sub-agent in orchestrated workflows.