{
  "schema_version": "1.0.0",
  "rubric_version": "1.0",
  "license": "CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)",
  "record": {
    "id": "K-0023",
    "slug": "flop-accounting",
    "title": "FLOP accounting",
    "aliases": [
      "training compute accounting",
      "compute thresholds"
    ],
    "status": "draft",
    "last_reviewed": "2026-09-23",
    "review_interval_days": 90,
    "steward": null,
    "provenance": {
      "drafted_by": "ai",
      "reviewed_by": []
    },
    "risk_flags": [],
    "flags": [],
    "one_liner": "Estimating or verifying how many floating-point operations a training run or other workload used, often to compare against a threshold in a rule.",
    "sources": [
      {
        "source": "S-0029",
        "supports": "total training compute as a rule and an indicator of capabilities; a threshold of H FLOPs converted to chip-days using each chip's FLOPs per day at full, perfectly parallel use",
        "locator": "§2.1; §3.2, Table 1"
      },
      {
        "source": "S-0053",
        "supports": "EO 14110 reporting threshold of 10^26 operations; compute as a high-level proxy for capabilities; thresholds may need updating",
        "locator": "thresholds; limitations"
      },
      {
        "source": "S-0063",
        "supports": "Strict Threshold 10^24 FLOP and Monitored Threshold 10^22 FLOP",
        "locator": "§4"
      },
      {
        "source": "S-0062",
        "supports": "energy estimates converted into an approximation of FLOPs",
        "locator": "Energy monitoring"
      },
      {
        "source": "S-0002",
        "supports": "estimating MFU and physical signature (e.g. power) as a research problem",
        "locator": "Table 2, Appendix A.6"
      },
      {
        "source": "S-0057",
        "supports": "offline licensing with a renewable licence carrying a compute budget",
        "locator": "p. viii"
      },
      {
        "source": "S-0018",
        "supports": "coarse metrics like total FLOPs insufficient; per-workload evidence sought",
        "locator": "verification goals"
      },
      {
        "source": "S-0069",
        "supports": "revocation of EO 14110 on 20 January 2025",
        "locator": "Sec. 2(ggg)"
      }
    ],
    "related": [
      "K-0025",
      "K-0016"
    ],
    "type": "concept",
    "url": "https://trustbutveri.fyi/concepts/flop-accounting/",
    "source_file": "content/concepts/flop-accounting.md",
    "flags_all": [
      "ai-drafted"
    ],
    "body_markdown": "FLOP accounting estimates or verifies the total number of floating-point operations (FLOP) that a training run or other workload performs, usually to compare it with a threshold set by a rule [[S-0029]] [[S-0053]].\n\nShavit lists total training compute among the rules a verifier might enforce, noting that it has proven to be an indicator of model capabilities [[S-0029]]. US Executive Order 14110 required reporting for models trained with more than 10^26 operations [[S-0053]] until its revocation in January 2025 [[S-0069]], and a proposed international agreement sets a prohibited threshold of 10^24 FLOP and a monitored threshold of 10^22 FLOP [[S-0063]]. Proposed ways to count or cap FLOP include:\n- **Hardware time.** Shavit converts a FLOP threshold into accelerator-days by assuming that every accelerator runs at its full rate with perfect parallelization, a conservative assumption that gives the fewest accelerator-days a run of that size could occupy [[S-0029]].\n- **Energy.** Energy use can be converted into an approximate FLOP count [[S-0062]].\n- **Telemetry.** RAND lists estimating a workload's model FLOPs utilization (MFU) and physical signature, such as power, as a research problem [[S-0002]], the aim of [[M-0010|on-chip telemetry]].\n- **On-chip budgets.** Offline licensing ties chip use to a renewable licence carrying a compute budget [[S-0057]], as in [[M-0011|hardware performance throttling and licensing]].\n\nTraining compute is only a high-level proxy for capability, and algorithmic progress means thresholds may need to change [[S-0053]]; one system overview argues that coarse totals such as FLOP counts are not enough and seeks evidence about individual workloads [[S-0018]].",
    "body_text": "FLOP accounting estimates or verifies the total number of floating-point operations (FLOP) that a training run or other workload performs, usually to compare it with a threshold set by a rule [S-0029] [S-0053]. Shavit lists total training compute among the rules a verifier might enforce, noting that it has proven to be an indicator of model capabilities [S-0029]. US Executive Order 14110 required reporting for models trained with more than 10^26 operations [S-0053] until its revocation in January 2025 [S-0069], and a proposed international agreement sets a prohibited threshold of 10^24 FLOP and a monitored threshold of 10^22 FLOP [S-0063]. Proposed ways to count or cap FLOP include: - Hardware time. Shavit converts a FLOP threshold into accelerator-days by assuming that every accelerator runs at its full rate with perfect parallelization, a conservative assumption that gives the fewest accelerator-days a run of that size could occupy [S-0029]. - Energy. Energy use can be converted into an approximate FLOP count [S-0062]. - Telemetry. RAND lists estimating a workload's model FLOPs utilization (MFU) and physical signature, such as power, as a research problem [S-0002], the aim of on-chip telemetry. - On-chip budgets. Offline licensing ties chip use to a renewable licence carrying a compute budget [S-0057], as in hardware performance throttling and licensing. Training compute is only a high-level proxy for capability, and algorithmic progress means thresholds may need to change [S-0053]; one system overview argues that coarse totals such as FLOP counts are not enough and seeks evidence about individual workloads [S-0018].",
    "referenced_by": [
      {
        "id": "M-0009",
        "title": "Hardware-enabled guarantees (flexHEG) and guarantee processors",
        "url": "https://trustbutveri.fyi/mechanisms/flexheg-guarantee-processors/"
      },
      {
        "id": "M-0011",
        "title": "Hardware performance throttling and licensing",
        "url": "https://trustbutveri.fyi/mechanisms/hardware-performance-throttling/"
      },
      {
        "id": "M-0010",
        "title": "On-chip telemetry from timing, memory and performance counters",
        "url": "https://trustbutveri.fyi/mechanisms/on-chip-telemetry/"
      },
      {
        "id": "M-0006",
        "title": "Proof-of-learning and training-transcript verification",
        "url": "https://trustbutveri.fyi/mechanisms/proof-of-learning/"
      },
      {
        "id": "M-0007",
        "title": "Proofs of useful work and resource exhaustion",
        "url": "https://trustbutveri.fyi/mechanisms/proofs-of-useful-work/"
      },
      {
        "id": "M-0005",
        "title": "Zero-knowledge proofs of training constraints",
        "url": "https://trustbutveri.fyi/mechanisms/zk-proofs-of-training-constraints/"
      },
      {
        "id": "C-0001",
        "title": "Compute stock is at most a declared amount",
        "url": "https://trustbutveri.fyi/claims/compute-stock-is-bounded/"
      },
      {
        "id": "C-0010",
        "title": "There is no undeclared relevant compute",
        "url": "https://trustbutveri.fyi/claims/no-undeclared-compute/"
      },
      {
        "id": "C-0007",
        "title": "A training run stayed within declared limits",
        "url": "https://trustbutveri.fyi/claims/training-within-declared-limits/"
      },
      {
        "id": "K-0025",
        "title": "Inference and training workloads",
        "url": "https://trustbutveri.fyi/concepts/inference-and-training-workloads/"
      },
      {
        "id": "K-0016",
        "title": "Undeclared compute",
        "url": "https://trustbutveri.fyi/concepts/undeclared-compute/"
      }
    ]
  }
}