> For the complete documentation index, see [llms.txt](https://docs.quantaria.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.quantaria.xyz/architecture/tensor-network-weights.md).

# Tensor-Network Weights

Every layer in a Quantaria model is stored and trained as a tensor network: a chain of small tensors ("cores") whose product represents a much larger weight. This page explains the terms used across these docs.

## MPS and MPO

* A **matrix product state (MPS)** represents a large vector as a chain of three-index cores. Each core has one physical index and two bond indices that connect it to its neighbours.
* A **matrix product operator (MPO)** is the same idea for a matrix. Each core has two physical indices (input and output) and two bond indices.

A Quantaria layer is an MPO. Instead of storing every entry of a dense weight matrix, the model stores the cores and contracts them with the input.

For an MPO with N cores, input and output dimensions mₖ and nₖ per core and bond dimension χ, the parameter count is roughly Σₖ mₖ·nₖ·χ², rather than the full size of the dense matrix. For example, a 4096×4096 layer (16,777,216 dense parameters) split into 4 cores with mₖ = nₖ = 8 and χ = 64 needs 532,480 parameters, about 31.5× fewer. The bond dimension is therefore the main knob for trading capacity against size.

## Bond dimension χ

The **bond dimension χ** is the width of the connection between two neighbouring cores. A larger χ lets the layer represent more correlations between its input and output positions and costs more parameters and compute. A smaller χ is cheaper and more compressed.

In quantum terms, a bond of dimension χ carries at most log₂χ bits of entanglement entropy across its cut. This is what links tensor-network layers to quantum circuits (see [Quantum Path](/architecture/quantum-path.md)).

## Schmidt truncation

Cutting a tensor network at a bond splits it into a left part and a right part. The **Schmidt decomposition** writes the connection between them as a sum of terms weighted by Schmidt coefficients. **Schmidt-rank truncation** keeps only the dominant coefficients at each bond and discards the rest. This is the same operation used in physics to bound entanglement in a quantum state, and in Quantaria it controls how much of each bond is retained.

## Canonical-form gauging

A tensor network can be rewritten with different but equivalent cores. Quantaria keeps cores in **canonical form**: cores to the left of a chosen position are left isometries, and cores to the right are right isometries. This gives numerically stable contraction, and at the bond where the left and right forms meet, the Schmidt coefficients can be read off directly. Moving that position along the chain lets each bond be truncated in turn.

## Rank-adaptive training

Quantaria does not fix χ in advance. **Rank-adaptive training** lets bond dimensions shrink where a bond carries little information and grow where it needs more capacity, during training. The approach builds on CoMERA ([arXiv:2405.14377](https://arxiv.org/abs/2405.14377)), which reports 9x more memory-efficient training than GaLore with 2-3x faster epochs. That figure is from the published paper, not from a Quantaria model.

## Native, not compressed

Many compression methods start from a trained dense model and factorize it afterwards. Quantaria trains in tensor-network form from the first step, so the model never has a dense version to compress.

## Where the library lives

The tensor-train and MPO layers, rank-adaptive training, canonical gauging and fused contraction kernels are packaged in **Bond**, a PyTorch library planned for open-source release. See [Models](https://github.com/bhavy2908/dataai_docs/tree/main/overview/models.md#bond).

## Related

* [Shared Multimodal Backbone](/architecture/multimodal-backbone.md)
* [Research Foundations](/architecture/research-foundations.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.quantaria.xyz/architecture/tensor-network-weights.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.