How does LearningCircuit’s LDR (Local Deep Research) perform with Qwen 27B on an NVIDIA Spark?

Europe’s push for data sovereignty (the principle that data is subject to the laws and governance structures of the nation where it is collected) has slowly transformed from a regulatory talking point into an operational strategy. Driven by concerns over foreign surveillance laws (like the US Cloud Act) and the potential legal instability of transatlantic data pacts, increasing numbers of European organizations are warming to the idea of migrating away from foreign tech.

While massive public-sector IT migrations like Munich’s infamous LiMux project stumbled over complex rollouts and bureaucratic friction, modern data sovereignty doesn’t have to require a total infrastructure overhaul.

Instead of all-in, high-risk, expensive migrations, companies have the option of leveraging localized hardware like an NVIDIA DGX Spark or DGX Station to understand and deploy new workflows individually, safely and cost effectively. These compact, powerful systems allow organizations to test how new, sovereign AI harnesses integrate with existing workflows in situ.

Of interest to both our company and customers is the topic of “Deep Research”, an advanced AI feature you’ve likely encountered or used yourself recently. It represents a shift from simple prompt-and-response search to an autonomous, multi-step analytical engine.

What follows is a fascinating/frustrating/technical rabbit hole I went down recently while evaluating LearningCircuit’s local-deep-research (LDR) harness.

TLDR; The obligatory commercial vs. open-source context

Dimension	LearningCircuit LDR	Perplexity Pro / OpenAI / Google (Commercial)
Data Processing & Privacy	Fully local execution option; zero telemetry/analytics; per-user AES-256 encrypted SQLite databases with zero-knowledge architecture. Independent security audits of Docker builds performed via Trivy and Grype.	Queries processed on proprietary cloud infrastructure; standard SaaS telemetry and data retention policies apply.
Search Sources & Retrieval	25+ integrated sources: arXiv, PubMed, Semantic Scholar, Wikipedia, SearXNG, GitHub, Wayback Machine, plus native RAG pipelines for private documents.	Focus on real-time web search with inline citations (Perplexity), multi-step reasoning chains (ChatGPT), or Gemini knowledge bases. No native private document ingestion at scale.
Model Flexibility & Cost	Hot-swappable local inference (Ollama, llama.cpp) and 10+ cloud LLM providers via environment variables. Free MIT license; costs only apply to optional cloud API tokens.	Locked to proprietary model families (GPT, Gemini, Claude/Perplexity models). Subscription-based pricing (~$20–$200/month) with bundled query limits.
Extensibility & Integration	Full REST API, LangChain-compatible vector store support (FAISS, Chroma, Pinecone, etc.), and MCP server for local AI assistants via STDIO transport.	Limited or proprietary APIs; no native LangChain/MCP integration; optimized for end-user web interfaces rather than developer pipelines.
Performance & Benchmarking	~95% SimpleQA accuracy with cloud models (GPT-4.1-mini) or capable local models (e.g., Qwen3.6-27B). Community-maintained Hugging Face leaderboards track strategy/model variability.	Commercial tools prioritize speed (Perplexity: 2–4 min/report), citation transparency, and structured reasoning depth. Consistent high-end accuracy without hardware dependency.

Installing Local Deep Research on the DGX Spark

Setting Local Deep Research up is non-trivial but also not excessive. If you want to go totally in-house and avoid calling commercial, third-party search APIs like Tavily, you are going to have to set up your own SearXNG instance. This will buy you a lot, but my docker logs still documented tonnes of timeouts, challenges, and scraping blockers that I assume would be mitigated to some degree with paid services.

SearXNG is a metasearch engine (which actually deserves its own article). It still has to query public endpoints like Google or Bing to fetch live web data. It absolutely sends the search queries themselves to those external services out of structural necessity. However, the architectural benefit is isolation: instead of a single third-party platform tracking your corporate API key, user profiles, and entire multi-step deep research intent, SearXNG aggregates and strips identifying trackers. You are still touching the public internet, but you can shift some control away from external profiling.

Outcomes

Since last week, I’ve run tens of deep searches through this Local Deep Research setup. Some runs were driven by genuine research curiosities, while others were explicitly designed to serve as performance baselines. To map out some boundaries when running a recursive research loop locally.

The results are mixed.

LDR is genuinely a great project with pretty profound implications if it can reach its potential. To be clear, I have already used the “quick summary” option several times at work (each run took anywhere from 1 to 4 hours on my DGX Station!) to get myself up to speed quickly on regulatory issues or evaluating technologies needing comprehensive citations. When it works well, it is very useful.

The wins I got from Local Deep Research (LDR)

From my perspective, the search felt exhaustive. What is even more valuable is that I am actively building local intelligence each time i use it.

When LDR discovers documents online germane to my search, it automatically caches and organizes them, building out an in-house knowledge library.

Conversely, if you already have an existing library of intellectual property, there is a great chance LDR can integrate with it directly, allowing you to use your proprietary files to inform and frame your research questions. There is also a “News”, and “Subscriptions” feature, which I haven’t touched yet, for maintaining more ephemeral/current source material.

The not-so-wins…

LDR does not appreciate me being a backseat driver.

When I tried giving it specific directions about the voice or framing of a research task, it either completely ignored me or produced documents with very little useful content.

Currently, many of my invocations using Qwen 3.8 27B have failed to produce any research at all, when 3.6 worked just fine. (A quick aside here: feeding Qwen 3.8 anything more than 0.5 of its context == really slow) This kind of friction is somewhat acceptable given that we are on the bleeding edge, but the real issue is that neither the UI nor the logs reported any useful debugging information when these failures occurred.

Lastly, (this could be user error) I have had much better luck with general, simple questions. When a highly specific query about the plugin architecture of a framework I use failed, I tried to clarify it by providing a simile.

The agent took it literally, returning three pages of research covering the technology mentioned in the simile instead of the actual framework.

Summary

When it works, and you get a multi-page data-rich document with no verifiable issues, it feels profound like my first interactions with ChatGPT. For now however, manage your expectations: expect a highly useful utility tool, not a service capable of extrapolating intent or reading nuance to the degree that frontier tools can.

Projects in this space move fast. It wasn’t too long ago that the UI paradigm for AI chat was contested; developer harnesses and agentic architectures are clearly on that continuum right now. Deep research as a local, self-contained paradigm is arguably still nascent. In the meantime, I’m going to dive into LangChain’s Open Deep Research repo to see how their LangGraph state machine approach handles the same workflows, and see what else I can learn from my next rabbit hole.

To see examples of the deliverables, check out my repository here: https://github.com/mwolf-pi3g/harness-ldr

This isn’t an exhaustive list, but demonstrative of the range of results you can expect.