TECHDRISHTI RESEARCH INFRA · PROVIDER EVALUATION

Sarvam vs DeepSeek, side by side

The research agent behind the RESEARCH stage (see the case study) can run on either model. 37 live calls per provider, 74 total, against the same fixed question set pulled from a real Stage 1 pipeline output: identity lookups (ambiguous and unambiguous entities) and context/gap questions, grouped by source article. This page is the evidence behind choosing Sarvam for that stage, not just an assertion of it.

Reproducibility. Every number on this page is read directly from two raw result files, one per provider, produced by running the same question set against both and merging the results, no number here was typed by hand. Token counts are estimates: the research agent doesn't return real prompt/completion usage, so the token figures are a tokenizer count over the returned answer text only, they exclude the agent's internal search/reasoning tokens and aren't a real cost figure.

Speed, iterations, length

AVG. LATENCY

sarvam

20.2s

deepseek

33.4s

lower is faster

AVG. SEARCH ITERATIONS

sarvam

4.5

deepseek

6.1

lower means fewer round-trips

AVG. ANSWER LENGTH (EST. TOKENS)

sarvam

263.7

deepseek

512

lower is more concise

AVG. SOURCES CITED

sarvam

8.6

deepseek

17.8

not scored either way, shown for context

Answer quality, judged independently

Scored by an external GPT judge, not by this pipeline and not by me, on the 4 context/gap questions where quality is genuinely hard to call by eye (the 33 identity lookups weren't scored this way, most of them are plain factual overviews with an obvious right answer). Included as a transparent second opinion the quantitative metrics above can't give on their own.

AVG. JUDGE SCORE (/10)

sarvam

8.5

deepseek

9.2

4 of 37 cases judged

WINS (4 JUDGED)

sarvam

deepseek

DeepSeek wins every judged case outright, by margin.

Click a question to see the actual answers and what the judge flagged.

SARVAM · WHAT THE JUDGE SAID

Hits every sub-topic asked (compilation pipeline, memory, ISAs, compute units, overheads) and is the best-organized of the two. But oversimplifies backend targets (claims ROCm compiles to HSAIL, understates Intel Arc's real pipeline) and overstates portability (“single binary runs on any accelerator”).

ZML achieves cross-chip compatibility by compiling a single, language-level model graph into native binaries for each accelerator family, using a stack of open-source compiler technologies (Zig + MLIR + OpenXLA) and a thin platform-abstraction layer that hides hardware-specific details. Compilation flow and IR: the model is expressed in Zig and lowered to MLIR, a multi-level intermediate representation that can be progressively refined. OpenXLA consumes the MLIR dialect and emits target-specific HLO IR, which is then lowered to the backend's native code generators (PTX for CUDA, HSAIL for ROCm, TPU XLA, Metal shaders, and SPIR-V for Intel Arc). Because the lowering is performed by the compiler rather than hand-written kernels, ZML does not need separate kernel libraries for each vendor. Memory-architecture abstraction: ZML's platform API presents a unified buffer allocation interface. At compile time, XLA performs buffer-allocation analysis and inserts device-specific memory allocation calls. This lets a single binary run on any supported accelerator without manual memory-layout tuning, but it also means ZML cannot exploit vendor-specific memory-hierarchy optimizations that hand-tuned kernels might achieve. Performance overheads and limitations: cross-compilation adds build-time overhead; benchmarks on AMD GPUs show inference throughput roughly 80-90% of an RTX 4090 for comparable model sizes; current releases are limited to single-GPU execution with no multi-GPU sharding; the LLMD server caps batch size at 16 with no prefix-caching; only Llama-3.1/3.2, Qwen-3.5, and LFM-2.5 families are officially supported; the stack is still in alpha.

DEEPSEEK · WHAT THE JUDGE SAID

Goes to implementation depth Sarvam never reaches: StableHLO, the zml.Platform abstraction, PJRT plugin layer, DMA allocator, zero-copy transfers. Explains the actual lowering chain (StableHLO -> MLIR dialects -> vendor dialects -> native kernels) instead of naming ISAs. Self-flags one claim as [UNVERIFIED], good practice. Slightly verbose, ~25% could be trimmed.

ZML is a production inference stack built primarily in Zig (92.7% of its codebase), developed by a Paris-based startup, that achieves cross-chip compatibility through a multi-layered compilation pipeline rather than a runtime abstraction layer that wraps individual vendor APIs. At its core, ZML uses MLIR and OpenXLA as its compilation backend, expressing tensor operations in StableHLO and progressively lowering those operations through MLIR's dialect hierarchy into hardware-native code for each target: CUDA for NVIDIA, ROCm for AMD, XLA for Google TPU, oneAPI for Intel Arc, Metal for Apple GPUs, and Neuron for AWS Trainium. The central abstraction governing cross-chip compatibility is the zml.Platform construct, introduced in the ZML/v2 rewrite (March 24, 2026). A Platform encapsulates an accelerator runtime, owning compilation, memory management, device placement, and I/O for that hardware target, selectable at compile time via Bazel build flags, at runtime via automatic detection, or manually. On memory-architecture differences: ZML/v2 exposes explicit pinned memory management through zml.mem.DmaAllocator, combined with Zig's explicit allocator model, giving precise control over memory transfers. Data transfers are channeled through zml.io.MemoryWriter for zero-copy, overlapped data movement. On instruction-set and compute-unit differences: ZML relies on the MLIR/OpenXLA compiler pipeline rather than hand-tuned kernel libraries per architecture, wrapping the PJRT C API from OpenXLA, a uniform Device API where each hardware vendor implements an opaque plugin. Limitations: the compilation-based approach adds an ahead-of-time compilation step eager-execution frameworks don't require; cross-vendor tensor parallel sharding (splitting a model across an NVIDIA and an AMD card simultaneously) is not documented and likely unsupported; the 92.7%-Zig codebase limits the contributor pool versus Python-first projects [UNVERIFIED: this specific claim not found in retrieved sources]; the LLMD server is still in alpha with model support currently limited to specific families.

SARVAM · WHAT THE JUDGE SAID

Covers all three asked angles (business risk, performance-parity risk, competitive strategy) in a focused, readable executive-summary style. Stays fairly high-level; a few claims asserted without much nuance (e.g. “changing a flag recompiles the model”).

ZML's ambition to break vendor lock-in introduces both business and technical risks. Technically, the company must keep its inference stack in lock-step with a rapidly moving hardware landscape; new GPU, TPU, and NPU generations each bring changes to driver APIs and instruction sets. ZML mitigates this by building on open, compiler-centric technologies (Zig, MLIR, OpenXLA) and bundling the required runtime inside the container image. However, supporting five distinct back-ends creates a real maintenance burden, and ZML still lacks expert-parallelism support, a gap that could become a bottleneck as mixture-of-experts models dominate. Business-wise, ZML competes against deeply integrated proprietary solutions from NVIDIA (TensorRT-LLM), Google, Amazon, and Microsoft, all of which benefit from tight silicon-compiler-cloud coupling and ecosystem trust. ZML's lean 20-person team and $20M funding give it agility, but the same small size can limit support depth and long-term sustainability versus the major cloud providers. Strategically, ZML centers on hardware-agnostic openness and performance-first engineering: compiling directly to each accelerator via MLIR/OpenXLA, claiming up to 2x faster inference than TensorRT-LLM on an H100 and up to 10x with DFlash speculative decoding, and targeting European chip makers (Axelera, Fractile, Kalray) to broaden the ecosystem and reduce single-vendor dependence.

DEEPSEEK · WHAT THE JUDGE SAID

Surfaces business risks Sarvam omits or only hints at: unclear monetization, contributor-pool limits, dependency on OpenXLA, the CUDA ecosystem moat. Explains why each risk matters rather than just listing it. More verbose, with some repetition around ecosystem advantages.

Business risks: the most immediate is the absence of a proven monetization model, LLMD was released free with no articulated revenue model beyond speculation about enterprise support or managed services. The inference-serving market already has well-funded competitors (Baseten at a $13B valuation, vLLM and SGLang with their own commercial backers). ZML's Zig-based codebase (92.7% Zig) significantly limits its contributor pool versus Python-first projects. There's also a dependency risk: ZML relies on OpenXLA and MLIR, both originating from Google's AI infrastructure group, and any shift in Google's priorities there could affect ZML's roadmap. If NVIDIA restricted CUDA-level access or accelerated its own higher-level software layer to bypass abstraction layers, ZML's compilation path to NVIDIA hardware could be impaired. Technical risk on performance parity: ZML relies on MLIR/OpenXLA rather than hand-tuned kernels, the same approach Google uses internally with JAX. The compiler's ability to generate performant code depends on lowering-rule quality, which for rapidly evolving architectures may lag vendor hand-tuned libraries; NVIDIA's CUDA ecosystem includes 19 years of accumulated, deeply tuned kernel libraries. Community benchmarks show ZML on AMD hardware at roughly 80-90% of RTX 4090 throughput, real but incomplete parity, and ZML is still alpha with significant feature gaps: single-GPU-only, no multi-GPU sharding, batch size capped at 16, no prefix caching, no expert-parallelism/MoE support. Competitive strategy: targets the vendor-lock-in pain point directly, positions itself as an enabler for alternative and emerging chipmakers (naming several European AI chip startups as potential partners), competes on technical claims (2x over TensorRT-LLM on H100), and uses its free pricing to pressure commercial managed services, though that free strategy itself carries the business-model risk noted above. The core tension: NVIDIA's moat isn't CUDA alone but a 19-year ecosystem of libraries, tools, and community knowledge.

SARVAM · WHAT THE JUDGE SAID

Cleanly separates terms / implications / differences and covers every key fact (investment, ownership %, co-selling, Xeon integration). The equity percentages (8.2%, 9%, 6.8%) are oddly specific without adding analytical value, and it explains what happened more than why it matters.

Intel's latest deal with SambaNova Systems goes far beyond the modest equity stakes the two companies held in earlier years and creates a joint go-to-market and product-development engine aimed at the fast-growing AI-inference market. Key terms: Intel plans an additional $15 million investment raising its ownership to roughly 9% of SambaNova, up from 8.2% after a $35 million round in February 2026 and 6.8% in 2025. Intel also participated in SambaNova's $350 million Series E round. The two firms signed a multi-year strategic collaboration to deliver AI inference solutions built on Intel Xeon-based infrastructure. Intel will leverage its enterprise, cloud, and partner channels to co-sell SambaNova's SN50 Reconfigurable Dataflow Unit. Strategic implications: for Intel, the deal deepens its foothold in AI inference with a differentiated offering versus NVIDIA's GPU-centric solutions. For SambaNova, the partnership provides scale, distribution, and credibility through Intel's global sales network, plus capital to accelerate chip production. How this differs from the earlier collaboration: the earlier involvement was a $15 million investment in 2019 and a $35 million round in early 2026, purely financial stakes. The new agreement adds a formal, multi-year product-development and go-to-market partnership at a much larger equity position. The partnership emerged after failed acquisition talks that reportedly valued SambaNova at around $1.6 billion; instead of buying the company, Intel opted for a deeper collaborative relationship.

DEEPSEEK · WHAT THE JUDGE SAID

Frames the relationship as an evolution: investor relationship -> board representation -> acquisition talks -> failed acquisition -> strategic alliance, which directly answers the “how does it differ from before” half of the question. Adds useful context (a boardroom recusal, a SoftBank deployment, a later funding round), though the later Series F detail runs past what was asked.

The SambaNova-Intel relationship has two distinct phases, and the partnership announced on February 24, 2026 is fundamentally different from what came before. The previous phase (2017-2025) was an investor relationship, not a go-to-market partnership. Intel CEO Lip-Bu Tan became chairman of SambaNova's board when the company was founded in 2017, through his venture firm Walden International. Intel Capital first invested in SambaNova in 2019 during its Series B round, then again in the Series C round. The relationship consisted of venture capital investment and board representation, with no product integration or co-selling arrangement. In late 2025, Intel explored acquiring SambaNova outright for approximately $1.6 billion, but those talks stalled by January 2026. The new partnership is a multiyear strategic collaboration going far deeper: co-development of AI inference systems combining SambaNova's SN50 RDU accelerators with Intel Xeon processors and Intel GPUs; Intel tapping its enterprise, cloud, and partner channels to co-market and co-sell the resulting platforms; Intel Capital participating in the $350 million Series E round led by Vista Equity Partners and Cambium Capital; Intel CEO Lip-Bu Tan recusing himself from partnership discussions due to his dual role as SambaNova board chairman. SoftBank committed to deploying the new SN50 chip as an existing SambaNova customer. The key difference is structural: the earlier relationship was purely financial (VC investment plus board representation) with no product-level integration, while the new collaboration involves co-developed products, joint sales through Intel's enterprise channels, and a strategic funding round rather than a conventional VC investment. The failed acquisition attempt was the catalyst that transformed a passive investor relationship into an active strategic alliance. Notably, just months later, on July 8, 2026, SambaNova raised a further $1 billion at an $11 billion valuation in a Series F first close.

SARVAM · WHAT THE JUDGE SAID

Correctly summarizes the acquisition-status chronology (talks stalled, partnership replaced acquisition). Its IPO/independence discussion leans on generic corporate-finance factors (interest rates, antitrust, timing) rather than SambaNova-specific evidence, and honestly flags this with [UNVERIFIED: IPO not found in retrieved sources].

Intel's reported $1.6 billion acquisition of SambaNova Systems collapsed by the end of 2025, leaving SambaNova independent. In early February 2026, SambaNova secured a $350 million Series E round led by Vista Equity Partners, with Intel taking roughly a 9% strategic stake and signing a multi-year collaboration agreement rather than completing a full purchase. Earlier reports (Reuters, EE Times, SiliconANGLE, Heise, October-December 2025) had suggested the deal was near completion at a reported $1.6 billion price. Key factors that will determine whether SambaNova stays independent or pursues an IPO: financial performance and cash-flow trajectory; the valuation gap between private and public markets; the strategic value of Intel's partnership and access to its manufacturing/distribution channels, which may reduce urgency to go public; regulatory considerations such as antitrust scrutiny; the competitive landscape, particularly the pace of innovation by NVIDIA, AMD, and emerging AI-chip startups; and broader macroeconomic conditions including interest rates and investor appetite for high-growth tech IPOs. In summary, the rumored acquisition has stalled, resulting in a strategic partnership and minority investment that keeps SambaNova independent for now. [UNVERIFIED: IPO not found in retrieved sources]

DEEPSEEK · WHAT THE JUDGE SAID

Same acquisition-status chronology, sourced with a clearer timeline (a rumor, a wire-service report, the funding round, the strategic collaboration). Grounds the independence/IPO analysis in company-specific signals: Series E runway, record bookings, manufacturing expansion, customer traction, not just generic IPO theory. Also appropriately flags the unverified parts.

The rumored acquisition of SambaNova by Intel, first reported by Bloomberg in October 2025, is no longer active; both companies have publicly stated the deal is not under discussion. SambaNova sought up to $500 million in funding after talks stalled (Reuters, January 22, 2026); by February 6, Vista Equity Partners and Intel were reported leading a new round of over $350 million; on February 24, SambaNova formally announced the $350 million Series E led by Vista Equity Partners and Cambium Capital, alongside its next-generation SN50 chip and a multiyear strategic collaboration with Intel. A SambaNova spokesperson told CRN the acquisition deal is “not in discussion at this stage.” Factors that will determine independence versus going public: the company just raised $350 million in Series E funding, giving it runway to scale manufacturing and cloud capacity independently; the same announcement references record bookings and revenue closing out 2025; customer concentration and commercial traction, SoftBank Corp. as the first SN50 deployment customer, alongside Hugging Face, Meta, and major AI labs; competitive position relative to NVIDIA, SambaNova claims the SN50 is up to 5x faster and 3x lower cost than GPUs for agentic workloads; valuation trajectory, SambaNova was valued at $5 billion in 2021, though BlackRock reportedly marked down its stake implying a valuation near $2.4 billion, well above the $1.6 billion Intel had considered; the structure of the Intel partnership as a strategic collaboration rather than an acquisition, which keeps SambaNova independent while giving it distribution access; and the intertwined governance relationship from Intel CEO Lip-Bu Tan's dual role as SambaNova board chairman, though he recused himself from the partnership discussions. [UNVERIFIED: specific IPO timeline not found in retrieved sources] No definitive IPO timeline has been announced; the immediate focus is shipping the SN50 chip later in 2026.

Why Sarvam anyway

DeepSeek is genuinely better on the questions that need real depth, an independent judge scored it higher on all 4 judged cases, and it goes further into implementation detail (one answer, on ZML's compiler stack, named the exact lowering chain from StableHLO through vendor dialects to native kernels; Sarvam's equivalent answer stayed a level higher, correct but less deep). That's a real, honest edge, not explained away here.

But it takes about 65% longer per call (33.4s vs 20.2s), needs more search iterations to get there (6.1 vs 4.5), and returns roughly double the answer length (512 vs 264 tokens) for that gain, on a stage that fires several times per article, every day, unattended. Combined with Sarvam running 5–9× cheaper per raw token (see the pricing table in the case study), the tradeoff didn't clear the bar for this pipeline specifically: DeepSeek's extra depth is real, but it's not the kind of gap this stage's job actually needs to close, and Sarvam is, in the external judge's own words, “the stronger choice if the goal is a tight executive summary,” which is exactly what feeds the writer downstream.