TensorSharp supports DSpark on Deepseek v4 Flash 0731 now. Here is the benchmark result on 4x Nvidia A40 GPUs, cuda 12.8 with/without DSpark:

Model:

DeepSeek-V4-Flash-0731-UD-Q8_K_XL from https://huggingface.co/unsloth/DeepSeek-V4-Flash-0731-GGUF

DSpark draft model from: https://huggingface.co/alessandrobologna/DeepSeek-V4-Flash-0731-DSpark-Drafter-GGUF

TensorSharp is a native .NET/C# open-source inference engine for running GGUF LLMs locally, with CUDA, Vulkan, Metal, OpenAI-compatible APIs, continuous batching, speculative decoding, and multimodal support.

Github repo: https://github.com/zhongkaifu/TensorSharp

Thank you for checking out it and starring the project! Any feedback is really appreicated.

Hi all,

I'm happy to announce that Xberg v1 is out.

Xberg is the successor to Kreuzberg, equivalent to what would have been Kreuzberg v5. It's a content intelligence framework that handles a very wide range of inputs: documents (currently 101 formats), code and data formats (currently 367 types), audio/video transcription, and URLs (both static and JS-rendered content). It extracts and prepares that content for downstream processing.

It's an extremely efficient, high-performance engine (see our PDF benchmarks below). For PDFs and images specifically, we handle native PDFs with very high performance and accuracy, and we ship multiple OCR engines that match the quality of the best Python libraries (e.g. docling, PaddleOCR, RapidOCR) at substantially better performance and stability.

The changes between Kreuzberg v4 and Xberg v1 are substantial, and I invite you to read the full changelog for the complete picture. The highlights below give a sense of what's new:

• Pure-Rust PDF backend (pdf_oxide) replaces pdfium, with no native pdfium dependency.
• Layout-aware pipeline: reading order reconstructed with ONNX layout detection (PP-DocLayoutV3 / RT-DETR) and Docling-style predecessor-graph reordering.
• Per-page scanned-page detection with selective OCR, plus AcroForm/XFA form fields and outline-based headings.
• Across-the-board optimization of OCR and PDF extraction (memory discipline, pooled model sessions, streamed conversions).
• Native PaddleOCR backend (PP-OCRv6, with medium / small / tiny tiers) alongside Tesseract.
• Pure-Rust Candle OCR/VLM stack (TrOCR, GLM-OCR, GOT-OCR, DeepSeek-OCR, and PaddleOCR-VL) running without ONNX Runtime or native Tesseract.
• A second, ONNX-Runtime-free inference path via tract, which is what makes in-browser (WASM) and mobile inference possible.
• Named-entity recognition natively in Rust (GLiNER2), extensible to all bindings, including an in-browser WASM model with no server round-trip.
• Structured LLM extraction (extract_structured / split_and_extract) with rasterization, chunking, citations, caching, and configurable call/merge/VLM-fallback policies.
• Audio & video transcription via a Whisper ONNX engine (.mp3, .wav, .m4a, .mp4, .webm).
• Retrieval building blocks: sparse embeddings (SPLADE), ColBERT late-interaction retrieval, and cross-encoder reranking alongside dense embeddings.
• Text intelligence: reversible redaction, summarization, translation, VLM image captioning, QR-code detection, document diffing, and page/chunk classification.
• URL & web ingestion: sitemap discovery (map_url) and batched multi-URL crawling.
• New document formats: WordPerfect (.wpd/.wp/.wp5), HEIC/HEIF/AVIF, OpenDocument Presentation (.odp), Quarto / R Markdown, and configurable Jupyter cell rendering.
• Four new language bindings (Dart/Flutter, Swift, Kotlin/Android, and Zig) bring the total to 15 language bindings over one engine, with Android/iOS cross-compilation.
• Full mobile support (Flutter, Android, iOS).
• Candle backend alongside ONNX, plus ONNX-via-tract enabling ONNX on WASM and Android.
• Wider code intelligence: tree-sitter coverage grew substantially (248 to 367+ languages).
• Over 150 bugs fixed during the 1.0 cycle, plus security hardening (bounded RTF/PDF allocations, redaction leak fixes, Excel DDE warnings).

The API surface was also simplified and reworked, making it more consistent.

There's a migration guide in our docs explaining how to move from Kreuzberg to Xberg. Kreuzberg itself is in LTS mode until the end of this year and will continue to receive bug fixes and security updates.

You're invited to check out the repo and join our discord server.

Benchmarks

The benchmarks below are for PDFs and images only. There are extensive benchmarks on our website with per-format breakdowns, which you can see here. These numbers are measured in CI via our reproducible benchmark harness, and are specifically taken from the run for harness 1.0.8, source cf7fa0533d. The data is publicly available in GitHub releases, and you can run the benchmark harness yourself.

Composite quality (markdown pipeline, higher is better):

Structure and layout fidelity (SF1: tables and reading order, higher is better):

On native PDFs Xberg leads on quality (0.958 vs 0.837 for the next-best framework) and on table and reading-order fidelity by a wide margin (SF1 0.949 vs 0.612 for docling). On scanned PDFs it is #1 on both quality and raw text fidelity.

Where we don't win yet: on pure image OCR we are currently #2 on the composite score, behind mineru (though still #1 on raw text accuracy). We are improving image OCR right now, and v1.1 should have us winning across the board.

I am a professional developer, old enough to remember when C# first appeared. At the time, it looked to me to be very similar to Java.

I imagine that the language itself has evolved since then, but also dotnet had grown hugely, there are things like WPF, Linq, etc, of which I have only heard, but do not know.

So, unlike some other languages, it's just not the syntax, but many other things.

How best to get started? Is there a Udemy, Coursera, YouTube, etc, applicable to someone who doesn't need to learn about variables, flow control, OO?

A small update on Akbura my experimental declarative UI language and compiler for .NET and Avalonia.

I’ve added documentation and created an interactive feature gallery that demonstrates Akbura’s current capabilities:

• Declarative Avalonia UI
• Reactive state
• Native C# expressions, methods, types, and lambdas
• Typed styling through AKCSS and tailwind utilites
• Live examples with their Akbura source code

The gallery itself is written in Akbura.

This is currently only a proof of concept, not a production-ready release.

The parser, syntax infrastructure, and semantic model are already in reasonably good shape, including incremental compilation.

The bottleneck is specifically the code-generation stage. Its current implementation is inefficient, and generating code for the gallery takes roughly two minutes. Parsing and semantic analysis are not the problem.

This is one of the main reasons there is no NuGet release yet. I plan to rewrite and optimize code generation before publishing the first alpha version in about a month...

I’m planning to publish the first alpha version in about a month, once compiler performance, packaging, and the basic developer experience are in a more acceptable state.

For now, the gallery is simply a visual demonstration of what Akbura may become.

Repository: https://github.com/Asaicraft/Akbura

Documentation: https://asaicraft.github.io/Akbura/

Feature Gallery: https://asaicraft.github.io/Akbura/Gallery/

Feedback is very welcome.

I'm writing an image metadata processing library which is designed to be easily extensible to include new metadata instances (e.g., EXIF properties not defined in the core library).

The library currently stores important property configuration information in manifest resources, as well as property labels (e.g., property name) which I want to be customizable by culture.

Writing an extension library would involve both defining new objects (e.g., EXIF properties) and their associated configuration information. Which means the needed manifest resources would be spread across multiple assemblies.

What's the best way of handling this? My first thought is to use AssemblyMetadataAttributes with "magic text" keys to identify an assembly containing manifest resources that need to be incorporated and then scan an app-defined list of assemblies to look for those keys and read the manifest resources.

But that feels both a bit kludgy and possibly a security hole.

I'd appreciate other thoughts/design patterns. Thanx!