Sunday, September 13, 2026

Merkle tree hashing technoques

 Yes, the original content or data blocks are hashed at the very bottom of a Merkle Tree to create the leaf nodes. [1, 2]


How Content is Hashed in a Merkle Tree
  • Leaf Nodes (Bottom Level): The actual content—such as files, data chunks, or blockchain transactions—is divided and run through a cryptographic hash function. The resulting outputs become the leaf nodes of the tree.
  • Parent Nodes (Upper Levels): Once the content is converted into hashes at the base, the actual content is no longer hashed higher up. Instead, adjacent pairs of these child hashes are combined (concatenated) and hashed together to form the parent nodes.
  • The Root Hash (Top Level): This pairing and hashing process repeats upward until a single top hash—the Merkle root—summarizes the entire set of underlying content. [1, 6]
Would you like to know how a Merkle proof uses these hashes to verify that a specific piece of content belongs in the tree without checking everything else?
AI responses may include mistakes.

Saturday, September 12, 2026

What is merkle tree

 A Merkle tree (or hash tree) is a hierarchical data structure in cryptography and computer science used to verify large datasets quickly and securely. [1]


How It Works
  • Leaf Nodes: The bottom layer of the tree contains data blocks (like individual transactions) that are run through a cryptographic hash function (like SHA-256) to produce unique text strings called hashes.
  • Branch Nodes: Pairs of adjacent leaf hashes are combined, concatenated, and hashed again to create parent nodes.
  • Merkle Root: This pairing and hashing process repeats upward until a single top hash remains, known as the Merkle root. [1, 2, 3, 4]
Why It Is Useful
  • Data Integrity: If a single piece of underlying data changes, its specific hash changes, which alters every parent hash all the way up to change the final Merkle root.
  • Efficiency: Systems can prove a specific transaction or piece of data belongs in the dataset using a tiny "Merkle proof" without downloading or processing the entire multi-gigabyte database.
  • Common Uses: They power the structural integrity of popular decentralized technologies like Bitcoin and other blockchain networks, version control systems like Git, and peer-to-peer file sharing. [7, 8, 10]
If you'd like, I can explain:How a Merkle proof works step-by-stepWhy Bitcoin specifically relies on this structureLet me know what you want to explore next!
AI responses may include mistakes.

What is turbopuffer vectorsb

 turbopuffer is a serverless vector and full-text search database built natively on object storage designed to cut costs at scale. [1, 2]


Core Architecture
  • Object Storage First: Data is stored primarily on cloud object storage (like
  • or
  • ), drastically lowering storage costs compared to traditional in-memory vector databases.
  • Smart Caching Layer: Uses RAM and NVMe SSD caching in front of object storage to keep hot data fast, achieving sub-10ms latencies for frequent queries.
  • Serverless Scaling: Automatically handles indexing, caching, and storage tiering without requiring cluster management or server bin packing. [2, 6]
Key Features
  • Hybrid Search: Supports vector search, BM25 full-text search, and hybrid queries combining both.
  • Native Metadata Filtering: Allows precise filtering alongside vector similarity matching.
  • High Throughput: Handles massive write volumes and scales namespaces independently past hundreds of millions of documents. [2, 4, 7]
Notable Use Cases
  • Notion: Powers production embeddings for Notion AI search, handling billions of text chunks while cutting millions from their database bill.
  • Cursor: Leverages the object-storage architecture for fast RAG operations across massive codebases, reducing costs significantly. [6, 8]
If you'd like, let me know:What is the scale of your vector data (number of vectors and dimensions)?Are you looking for hybrid search or pure vector similarity?I can help you evaluate if turbopuffer fits your infrastructure needs.
AI responses may include mistakes.

What is front matter in open knowledge format

 Front matter is a block of metadata placed at the very top of a plain text file (typically Markdown). Delimited by triple dashes (---), it acts as machine-readable data that allows AI agents, search indexes, and static site generators to index, filter, and traverse knowledge without having to parse the main document body.

In the Open Knowledge Format (OKF)—the specification published by Google Cloud to package markdown knowledge bases into traversable graphs for AI agents—front matter is written in YAML format.

OKF Front Matter Structure

An OKF concept document requires a structured YAML block at the head of the file, followed by the Markdown body:

---
type: metric
title: Active Monthly Users
description: Count of unique authenticated users who performed at least one action in the last 30 days.
resource: bigquery://analytics_db.tables.user_events
tags:
  - analytics
  - user-growth
timestamp: 2026-06-12T00:00:00Z
status: active
---

Front Matter Fields Breakdown

The specification keeps front matter minimal and extensible. It makes a clear distinction between required, standard optional, and custom keys:

FieldRequirementPurposeExample
typeRequiredDefines the category of the knowledge node (e.g., metric, table, runbook, policy, api).type: metric
titleRecommendedHuman-readable title of the concept node.title: Revenue Definition
descriptionRecommendedConcise summary used by retrieval systems to gauge relevance.description: Core calculation method...
resourceOptionalExternal URI mapping to an underlying dataset, API, or DB table.resource: postgres://db/orders
tagsOptionalCategorization keywords for filtering.tags: [finance, quarter-1]
timestampOptionalProvenance date for tracking currency and staleness.timestamp: 2026-06-12
statusOptionalIndicates context validity (e.g., active, deprecated, draft).status: active

Key Properties

  • Extensibility: You can add custom key-value pairs (e.g., owner: "@data-team") without breaking OKF parsers; compliant tooling must tolerate unknown keys.
  • Decoupled Relationships: While general metadata lives in the front matter, links to other concepts are expressed directly in the Markdown body using standard Markdown links ([Orders Table](/entities/orders.md)), forming a traversable knowledge graph.

Open knowledge format link data tpes

 Open Knowledge (and Open Data) standards do not prescribe a single, rigid "typed link" syntax. Instead, typed links in open knowledge systems are implemented using Linked Data principles, specifically RDF (Resource Description Framework) triplets and established Web Ontologies.

Core Structure: RDF Triplets

In an open knowledge format, connections between data points are expressed as typed relationships using a Subject-Predicate-Object model:

  • Subject: The resource being described (e.g., Entity_A)
  • Predicate (Typed Link): The specific, defined relationship type (e.g., schema:knows or dcterms:creator)
  • Object: The target resource or literal value (e.g., Entity_B)

How Links Are Formally Typed

Rather than using generic hypertext links (<a href="...">), open knowledge frameworks map typed links to standardized Uniform Resource Identifiers (URIs).

MechanismDescriptionExample
Schema.orgStandard vocabulary for web-based structured data[http://schema.org/contributor](http://schema.org/contributor)
Dublin Core (DCTERMS)Common metadata standards for resources[http://purl.org/dc/terms/references](http://purl.org/dc/terms/references)
FOAF (Friend of a Friend)Links connecting people, organizations, and groups[http://xmlns.com/foaf/0.1/knows](http://xmlns.com/foaf/0.1/knows)
OWL / RDFSFormal ontology definitions expressing subclass and equivalency linksowl:sameAs, rdfs:subClassOf

Common Serializations

Open knowledge formats express these typed links using several common file types:

  • JSON-LD: Embeds structured, typed links inside standard JSON objects.
  • Turtle / N-Triples: Human-readable text formats designed specifically for RDF graphs.
  • Wikidata Statements: Open graph property links (e.g., P31 for "instance of", P279 for "subclass of").

Thursday, September 10, 2026

LLM-d infrastructure using Kubernetes

 Here is one of the best video tutorials for this

https://www.youtube.com/watch?v=hBzUokVYQkI

Wednesday, September 9, 2026

What is Perplexity Lily inference engine?

 


Perplexity Open Sources Lily: A Rust + Metal Inference Engine for Qwen3.6-35B-A3B on Apple Silicon

By Asif Razzaq -September 2, 2026

Perplexity has open sourced Lily, the local inference engine behind Hybrid Compute in Perplexity Computer. It is a single-process runtime: a Rust layer loads the checkpoint and drives the generation loop, an OpenAI-compatible chat-completions API streams tokens, and hand-written Metal kernels execute the model. Neither PyTorch nor MLX sits in the execution path. Lily is deliberately narrow with one model, Qwen3.6-35B-A3B, on one hardware family and that narrowness is the performance argument.


Is it deployable? Yes. A standalone demo is public in the pplx-garden repository. A Rust and Metal inference server offering greedy text generation through a minimal OpenAI-compatible HTTP API. The 4-bit checkpoint is 19.4 GB, so an Apple silicon Mac with 32 GB or more of unified memory is the realistic floor; Perplexity’s shipping Hybrid Compute product lists macOS 15+, 24 GB minimum and 32 GB for best results.



Why specialize at all?

The default Mac stack is MLX plus MLX-LM, which already ships a Qwen implementation with grouped expert work, a fused recurrent Metal kernel, and GQA-aware attention. But its operations must stay reusable across architectures. Lily gives that up and puts model structure, execution plans, and kernel selection in one runtime.


Three workload shapes

Qwen3.6-35B-A3B stores 35B parameters and activates roughly 3B per token. A router scores 256 experts and picks eight, alongside one shared expert that sees every token. It also mixes 10 full-attention layers using grouped-query attention (16 query heads, two KV heads) with 30 Gated DeltaNet layers. That yields three patterns: uneven expert groups, attention over a growing KV cache, and a fixed-size recurrence.


Prefill: keep weights packed, keep routing on the GPU

The checkpoint uses groupwise affine 4-bit quantization, every group of 64 weights sharing a bfloat16 scale and bias, about 70 GB of bfloat16 weights compressed to 19.4 GB. Metal 4 tensor operations consume bfloat16, so weights must be reconstructed first. Lily does that one tile at a time inside the grouped GEMM, holding results in threadgroup memory and accumulating in FP32, so the expanded array never reaches unified memory. In Perplexity’s ablation that fusion raised end-to-end prefill 77.4% at a 512-token prompt.


Keeping the routing histogram, prefix scan, scatter and block map inside a single GPU command buffer added 89% at 512 tokens by removing CPU synchronization inside each MoE layer. Moving from 16-row to 32-row tiles with four simdgroups added 13.2% at 2K; a register-resident Gated DeltaNet scan added 5.6%. Expert GEMMs are roughly 90% of prefill time. Long prompts run in bounded chunks so temporary activations do not compete with weights and cache for memory.


Decode: minimize bytes moved per token

Batch-1 decode has almost no weight reuse, so bandwidth sets the ceiling. One recorded step launched 795 kernels forming 555 sequential stages; Lily records real dependencies in a concurrent Metal pass so independent kernels overlap. The selected token is written straight into the next step’s GPU-resident input slot, removing a per-token CPU round trip, and four kernel chains are fused to keep intermediates in registers.


Coalesced cache reads lifted key bandwidth from 33.8 to 47.9 GB/s and value bandwidth from 42.0 to 61.8 GB/s. GQA packing, four query heads sharing one threadgroup so each KV row loads once, improved decode 23.8% at 32K. A fixed-block attention layout at 32K and above improved decode 7.7% at 32K, 27.4% at 64K, and 40.2% at 128K.


Results

On one 40-core, 128 GB M5 Max at batch 1, loading identical 4-bit checkpoint bytes against MLX-LM’s fastest direct-generation path across ten lengths from 256 to 128K tokens, Lily averaged 4,156 prefill tokens/s versus 3,388 (1.23x) and 170.0 decode tokens/s versus 126.4 (1.35x). At a 4K prompt and 4K context it reached 5,749.9 and 186.6 tokens/s against 4,737.5 and 140.9, and was faster at every recorded point: 1.12–1.42x prefill, 1.31–1.37x decode. A teacher-forced check across 192 positions put Lily’s perplexity 0.04% higher, with the same top-ranked token 96.35% of the time.