Text Generation
Transformers
Safetensors
PyTorch
ONNX
English
qtensorformer
q-tensorformer
high-throughput-inference
tensor-train
tensor-networks
tensorrt-llm
vllm
continuous-batching
paged-attention
speculative-decoding
zero-svd
adaptive-computation
dynamic-neural-networks
kv-cache
kv-cache-quantization
attention-sinks
lyapunov-stability
control-theory
contextual-bandits
edge-ai
edge-inference
on-device-ai
model-compression
hopper-h100
blackwell-b200
jetson-orin
jetson-thor
grouped-query-attention
rotary-position-embeddings
custom_code
academic-paper
ieee
neurips
vit-ap-university
deepseek
deepseek-r1
reasoning
chain-of-thought
gsm8k
openai-compatible
fastapi
rest-api
sse-streaming
onnx-runtime
embedded-ai
hardware-telemetry
power-efficiency
green-ai
raspberry-pi
smollm2
qwen2.5
llama-3.2
apple-silicon
Premchandyadav369
feat(seo): maximize discoverability, Google Scholar metadata, interactive HF widget, LLM crawler schemas, zero em dashes, and one-click quickstart downloads
5175adb | <html lang="en"> | |
| <head> | |
| <meta charset="UTF-8"> | |
| <meta name="viewport" content="width=device-width, initial-scale=1.0"> | |
| <title>Limitations & Failure Modes - Q-TensorFormer</title> | |
| <meta name="description" content="Transparent technical disclosures on CPU contraction latency, hardware power sensor limitations, and verified boundaries for Q-TensorFormer."> | |
| <link rel="canonical" href="https://premchan369.github.io/Q-TensorFormer/limitations.html"> | |
| <meta property="og:type" content="article"> | |
| <meta property="og:site_name" content="Q-TensorFormer Research Project"> | |
| <meta property="og:title" content="Limitations & Failure Modes - Q-TensorFormer"> | |
| <meta property="og:description" content="Transparent disclosures of architectural trade-offs, CPU contraction overheads, and hardware limits."> | |
| <meta property="og:url" content="https://premchan369.github.io/Q-TensorFormer/limitations.html"> | |
| <script type="application/ld+json"> | |
| { | |
| "@context": "https://schema.org", | |
| "@type": "TechArticle", | |
| "headline": "Q-TensorFormer Known Technical Limitations and Failure Modes", | |
| "description": "Comprehensive disclosures regarding CPU einsum bottlenecks, FP16 emulation overhead, and boundary conditions.", | |
| "url": "https://premchan369.github.io/Q-TensorFormer/limitations.html", | |
| "author": { "@type": "Person", "name": "Premchand Yadav" }, | |
| "datePublished": "2026-10-13" | |
| } | |
| </script> | |
| <link rel="stylesheet" href="assets/style.css"> | |
| </head> | |
| <body> | |
| <header> | |
| <div class="header-container"> | |
| <div class="logo"> | |
| <a href="index.html"><span>Q-TensorFormer</span> Research</a> | |
| </div> | |
| <nav> | |
| <a href="index.html">Overview</a> | |
| <a href="architecture.html">Architecture</a> | |
| <a href="methodology.html">Methodology</a> | |
| <a href="benchmarks.html">Benchmarks</a> | |
| <a href="edge-inference.html">Edge Inference</a> | |
| <a href="training.html">Training</a> | |
| <a href="documentation.html">Docs & API</a> | |
| <a href="research.html">Research</a> | |
| <a href="limitations.html" class="active">Limitations</a> | |
| <a href="contributing.html">Contributing</a> | |
| </nav> | |
| </div> | |
| </header> | |
| <main class="container"> | |
| <h1>Limitations & Failure Modes</h1> | |
| <p class="lead"> | |
| Scientific credibility requires candidly stating where an architecture does not perform well. Below are the verified technical limitations, boundary conditions, and hardware constraints of Q-TensorFormer. | |
| </p> | |
| <section> | |
| <h2>1. Unfused CPU Contraction Overhead</h2> | |
| <p> | |
| While Tensor-Train decomposition achieves extraordinary parameter compression (up to <strong>56.96x parameter reduction</strong> at rank 1), contracting multi-core tensors sequentially via PyTorch <code>einsum</code> incurs wall-clock latency overhead on CPUs: | |
| </p> | |
| <ul> | |
| <li>On an x86 CPU where a dense <code>512 → 2048</code> matrix already fits in L3 cache, optimized MKL/BLAS dense GEMM takes <strong>0.20 ms</strong> per token.</li> | |
| <li>In contrast, contracting four Tensor-Train cores sequentially takes <strong>0.91 ms to 1.51 ms</strong> per token.</li> | |
| </ul> | |
| <div class="callout warning"> | |
| <p><strong>Conclusion:</strong> If your model weights comfortably fit in fast SRAM/VRAM and your system is purely compute-bound, dense matrix multiplication is faster in wall-clock time than unfused TT contraction. TT compression wins when models exceed memory capacity or when fused GPU kernels (Triton) eliminate intermediate memory round-trips.</p> | |
| </div> | |
| </section> | |
| <section> | |
| <h2>2. x86 CPU float16 Emulation Penalty</h2> | |
| <p> | |
| Serializing checkpoints in <code>float16</code> cuts disk storage by <strong>49.3%</strong> (from 22.35 MB to 11.19 MB). However, standard x86 CPU architectures lack native FP16 matrix execution instructions, forcing PyTorch to emulate FP16 math in software: | |
| </p> | |
| <ul> | |
| <li>FP32 Time-To-First-Token (TTFT) at L=16: <strong>25.82 ms</strong>.</li> | |
| <li>FP16 Time-To-First-Token (TTFT) at L=16: <strong>335.66 ms</strong> (13x slower on CPU due to software emulation).</li> | |
| </ul> | |
| <p> | |
| For CPU execution, we strongly advise using <strong>FP32</strong> or <strong>INT8 quantization</strong> rather than FP16. | |
| </p> | |
| </section> | |
| <section> | |
| <h2>3. Legacy Checkpoint Incompatibility (qtensorformer_small.pt)</h2> | |
| <p> | |
| The historical file <code>qtensorformer_small.pt</code> was produced by an external TensorLy container and has <strong>0/113 key overlap</strong> with repository model classes. | |
| </p> | |
| <p> | |
| In accordance with project guardrails, we refuse to load it with <code>strict=False</code> or alter its provenance. Instead, users must load the verified canonical checkpoint (<code>checkpoints/qtensorformer_canonical_trained.pt</code>). | |
| </p> | |
| </section> | |
| <section> | |
| <h2>4. Quantum Pathway Status & CPU Latency Overhead</h2> | |
| <p> | |
| Q-TensorFormer contains an experimental quantum pathway utilizing a classical Lie group surrogate (<code>ClassicalSurrogateUnitary</code>): | |
| </p> | |
| <ul> | |
| <li><strong>No physical quantum advantage:</strong> Zero physical QPU hardware was executed.</li> | |
| <li><strong>CPU Latency Penalty:</strong> Forcing quantum kernel attention on introduces a <strong>+6.75% CPU latency overhead</strong>.</li> | |
| <li>For edge deployment, presets <code>QTF_EDGE</code> and <code>QTF_CLASSICAL_ONLY</code> disable quantum execution by default.</li> | |
| </ul> | |
| </section> | |
| <section> | |
| <h2>5. Energy Measurement Disclosure</h2> | |
| <p> | |
| Because the benchmark host is a CPU-only workstation without physical inline power sensors or privileged RAPL wattmeter access, <strong>Level 4 direct sensor energy is explicitly unverified</strong>. All energy figures reported in <code>src/hardware_cost_model.py</code> are theoretical analytical estimates. | |
| </p> | |
| </section> | |
| <section> | |
| <h2>6. Training Corpus Scale</h2> | |
| <p> | |
| The canonical trained checkpoint was trained on a compact educational corpus (<code>data/qtensorformer_corpus.txt</code>, 2,905 tokens), reducing perplexity from 352.35 to 45.09. It is designed to demonstrate verifiable convergence and systems integration, not open-domain world knowledge. | |
| </p> | |
| </section> | |
| </main> | |
| <footer> | |
| <div class="footer-links"> | |
| <a href="index.html">Home</a> | |
| <a href="architecture.html">Architecture</a> | |
| <a href="methodology.html">Methodology</a> | |
| <a href="benchmarks.html">Benchmarks</a> | |
| <a href="documentation.html">Docs</a> | |
| <a href="limitations.html">Limitations</a> | |
| <a href="sitemap.xml">Sitemap</a> | |
| <a href="llms.txt">llms.txt</a> | |
| <a href="https://huggingface.co/Premchan369/Q-TensorFormer">Hugging Face</a> | |
| </div> | |
| <p>© 2026 Premchand Yadav. Licensed under Apache-2.0.</p> | |
| </footer> | |
| </body> | |
| </html> | |