Blame for site/limitations.html

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Limitations &amp; 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 &amp; 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 &amp; 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 &rarr; 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 &amp; 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>&copy; 2026 Premchand Yadav. Licensed under Apache-2.0.</p>
  </footer>
</body>
</html>