---
title: AF_Cache in Networks & AlphaFold
url: https://www.emergentmind.com/topics/af_cache
type: topic
---

# AF_Cache in Networks & AlphaFold

AF_Cache is a name attached to two distinct cache-oriented systems in the arXiv literature. In network measurement, it denotes an aggregate-flow cache that moves application identification from the usual per-connection basis to a server-endpoint basis in order to preserve the accuracy of payload-based classification while reducing repeated invocation of an expensive backend identification engine [1105.5684]. In computational structural biology, it denotes a high-throughput Nextflow pipeline for AlphaFold2 and AlphaFold3 protein-protein interaction prediction that combines GPU-accelerated multiple sequence alignment generation, monomer feature caching, and sequence-length bucketing to reduce redundant preprocessing and repeated JAX compilations [2606.04566].

## 1. Terminological scope

The two usages share a common systems intuition—reuse prior work when the same expensive subproblem recurs—but they operate at different abstraction levels and in different scientific domains. One caches application labels indexed by network server endpoints; the other caches monomer-derived AlphaFold features and reuses compiled inference shapes across similar targets.

| Usage of AF_Cache | Domain | Cached object |
|---|---|---|
| Aggregate-flow cache | Network application identification | Application label indexed by \((\text{server IP}, \text{server port}, \text{transport-layer protocol})\) |
| AF_Cache pipeline | AlphaFold-based PPI screening | MSAs and template features for each unique monomer; AF2 pickle files and symlinks; AF3 JSON inputs with MSA content |

A plausible implication is that AF_Cache is best interpreted contextually rather than as a single method family. In the networking paper, the cache sits inside an on-line traffic classifier. In the AlphaFold paper, it is an orchestration and preprocessing layer wrapped around existing inference engines.

## 2. Aggregate-flow AF_Cache in network application identification

In the networking usage, an **aggregate-flow** is defined as the set of connections that share a common **server endpoint**, where a server endpoint is the triple
\[
(\text{server IP address}, \text{server port}, \text{transport-layer protocol}).
\]
This differs from the standard connection-level view in which every TCP or UDP connection is classified independently. The central observation is that many connections to the same server endpoint are usually generated by the same application, so once one connection has been identified, that result can often be reused for later connections with the same server endpoint [1105.5684].

The framework places AF_Cache between the packet or connection processing front end and the backend identification engine. Incoming packets first go through connection lookup. If a packet belongs to an existing classified connection, the normal connection table handles it. Otherwise the system performs a lookup in AF_Cache using the server-endpoint triple as key. If a matching entry exists and contains a valid application label, that cached aggregate-flow heuristic is reused instead of sending the traffic directly to the expensive backend classifier. If there is no cache entry, or if the entry’s label is invalid, the packet is sent to the backend identification engine. The component between cache and engine is the **aggregate-flow adapter**, which determines which packets, and with what heuristics, are sent to the identification engine, and what outputs are captured back into the cache.

In the throughput-oriented design, the backend engine is the payload-based classifier **L7-filter**, and the primary cached heuristic is the **application label** associated with the aggregate-flow. This effectively changes classification from per-connection to **per-aggregate-flow**. To cope with staleness when the application behind a server endpoint changes, the design uses probabilistic validation: each connection that matches an existing AF_Cache entry is sampled with probability \(p\), and sampled connections are still sent to the backend engine for validation and possible cache update.

The cache is selective rather than universal. The output filter excludes at least two categories from caching: **data connections of applications that use dynamic port negotiation**, such as FTP and SIP, and **incoming connections to a proxy server**. The first category is excluded because such endpoints may be generated randomly and may be used only once. The second is excluded because a proxy server listens on a fixed endpoint while carrying traffic for multiple applications, violating the aggregate-flow consistency assumption.

## 3. Locality analysis, replacement policy, and measured effects in the network system

A major part of the aggregate-flow AF_Cache design is an analysis of temporal locality. The paper states that locality arises from two distinct phenomena: **long-term popularity** of aggregate-flows and **short-term temporal correlations** among references. Long-term popularity is reported to follow a **Zipf-like distribution**
\[
P(O_n) \propto n^{-\alpha},
\]
with fitted \(\alpha\) values of \(0.90\) and \(0.98\) on THU1 and THU2, \(1.26\) and \(1.19\) on LBL1 and LBL2, and \(0.69\) and \(0.73\) on CAIDA1 and CAIDA2. The authors conclude that **long-term popularity is the predominant and reliable contributor to temporal locality**, while temporal correlation exists only in some traces and with less consistent intensity [1105.5684].

That conclusion motivates a replacement policy that is primarily frequency-based but recency-aware as a tie-break. The design rejects both idealized perfect LFU, which would require maintaining frequencies for all objects including evicted ones, and plain in-cache LFU, which loses history on eviction. Instead it introduces a **multistage filter** to detect frequently referenced aggregate-flows before admission to the main cache. The filter has \(d\) parallel stages, each a hash table of counters, and an aggregate-flow is admitted only if all hashed counters exceed threshold \(T\). The cited false-positive bound for an item with frequency \(f \le T(1 - 1/k)\) is
\[
P_f \le \left( \frac{T}{k(T-f)} \right)^d.
\]

Once admitted, entries are stored in a hash table for \(O(1)\) lookup. The implementation maintains only the subset of entries with the **lowest frequency** in a priority queue keyed by **last access time**. Eviction then removes, among the least frequently used entries, the **oldest** one. The paper characterizes this hybrid as **MS-Hybrid** (Multistage-Hybrid). It reports **\(O(1)\)** time for each cache lookup and **\(O(m \log m)\)** time for each replacement, where \(m\) is the average number of entries that currently share the lowest frequency.

Empirically, the system was evaluated on campus, enterprise, and backbone traces. The number of aggregate-flows was only about **4.7% to 20.4%** of the number of connections across the tested traces, which underlies the statement that the workload of the backend identification engine can be reduced by **up to 95%**. In replacement-policy experiments, **MS-Hybrid** outperformed **LRU** and **LFU-incache** on almost all traces and was close to **Optimal-LFU**; the explicit exception was **LBL2**, where LRU was slightly better, consistent with stronger short-term recency effects in that trace. The paper concludes that the replacement algorithm **“achieves 90% of the optimal performance using only 15% of memory.”** With L7-filter as backend, throughput increased by up to **5.1×** on THU1 and **4.5×** on THU2, and even with cache size limited to **15%** of total aggregate-flows, throughput still improved by **4.5×** on THU1 and **4.1×** on THU2.

## 4. AF_Cache as a high-throughput AlphaFold pipeline

In structural biology, AF_Cache is a **Nextflow** workflow for large-scale **protein-protein interaction** screening with **AlphaFold2** and **AlphaFold3**. Its stated bottlenecks are **repeated MSA generation** and, for AF2, **repeated JAX compilation** when input sequence lengths vary. The core observation is that pairwise multimer screening reuses the same monomer sequences many times. The paper states:
\[
\text{For } N \text{ proteins screened as all unique dimers including homodimers, default per-chain MSA generation requires } N(N+1) \text{ chain-level MSA generations, whereas only } N \text{ unique monomer MSAs are needed.}
\]
AF_Cache addresses this redundancy by combining **GPU-accelerated MSA generation with MMseqs2**, **feature caching** for unique monomers, and **sequence-length bucketing and padding** to reduce repeated **JAX compilations** in AF2 [2606.04566].

The workflow is explicit. AF_Cache reads protein inputs from a directory containing FASTA files, generates MSAs for all proteins simultaneously using **MMseqs2-GPU**, caches features for each unique monomer, constructs protein pairs, buckets pairs by total sequence length, pads pairs within each bucket to a common length, runs prediction sequentially within a bucket so that the first item triggers compilation and the remaining items reuse the compiled shape in AF2, and then writes AlphaFold outputs. For AF2, cached features are stored as **pickle files**, with symbolic links connecting cached monomer data into pair-specific directories. For AF3, features are represented in **JSON input files**, and AF_Cache automatically handles JSON generation.

The MSA stage follows the same search and alignment protocol as **ColabFold**, with one additional optimization: when performing alignments on both UniRef and the environmental databases, CPU and GPU steps are run in parallel across the two databases. The default AlphaFold pipelines use **JackHMMer** and **HHblits** with **full BFD**, **small BFD**, **UniRef30**, **mgnify**, **UniProt**, and **UniRef90**; AF_Cache instead uses **ColabFold databases**. The paper also compares AF_Cache with **AlphaFast**, highlighting dataset-wide monomer MSA generation at the start, parallel CPU and GPU task overlap, a different database choice, and support for both AF2 and AF3 on local systems or multiple HPC nodes via Nextflow.

The effect of bucketing differs across model generations. AF2 benefits from both MSA optimization and reduced recompilation, whereas AF3 already employs padding of different bucket sizes for both monomers and multimers, so AF_Cache does **not** provide additional AF3 inference speedup. The paper states this difference directly: AF2 gains from **13x** faster MSA generation and about **2x** inference or prediction speedup, whereas AF3 gains from **5x** faster MSA generation but **no speedup** in inference because the same inference code is used as in default AF3. It also notes that **AF3 version 3.0.1 is notably faster than 3.0.0**, and the pipeline automatically uses **3.0.1**.

## 5. Benchmarking and predictive consistency in the AlphaFold system

The benchmark uses **100 human mitochondrial proteins** selected from the Human Protein Atlas and UniProt, with all-against-all screening including homodimers. The paper gives the pair count explicitly:
\[
100 \times 99 / 2 = 4{,}950
\]
heterodimers, plus 100 homodimers, for **5,050 unique pairs**. The hardware setup uses **NVIDIA A100** GPUs with **40 GB memory** for inference, and default MSA-generation jobs were run with **8, 16, or 32 Intel Xeon Gold 6130 CPU cores**, later rescaled to an assumption of **128 CPU cores with perfect parallelization** for more realistic comparison [2606.04566].

Under that rescaling, the reported MSA speedups are **13-fold** for the **full BFD** setting and **5-fold** for the **small database** setting. When compared against the fully repeated chain-by-chain vanilla pipelines, the rescaled speedups become **1343-fold** for **AF2** and **542-fold** for **AF3**, because AF_Cache combines faster MSA generation with elimination of repeated monomer preprocessing. The `parse_features` step takes **20 seconds per protein on average** for AF2 and **10 seconds per protein on average** for AF3. For AF2 inference and compilation, the paper reports a reduction from **253 GPU hours** in the default implementation to **125 GPU hours** with AF_Cache, describes this as **more than 50%** reduction, and states that AF_Cache is on average **90 seconds faster per protein pair** than default AF2.

The paper evaluates predictive consistency primarily with **ipTM** correlations rather than a full structural benchmarking campaign. Across all **5,050 pairs**, Pearson correlations between cache and default runs are **r = 0.64** for **AF3** and **r = 0.70** for **AF2**, with \(P\)-values less than \(10^{-300}\). For pairs with shared PDB-entry support, the correlations are much higher: **0.98** for AF2, **0.94** for AF3, and **0.92–0.94** between AF2 and AF3, with \(P\)-values smaller than \(10^{-30}\). The paper also reports AF2-versus-AF3 ipTM correlations of **0.42** for **AF_Cache** and **0.41** for the **default implementation**. These results are presented as evidence that acceleration does **not** substantially degrade predictions, especially on structurally supported cases.

## 6. Limitations and comparative interpretation

The aggregate-flow AF_Cache and the AlphaFold AF_Cache both rely on stability assumptions, but the relevant failure modes differ. In the network classifier, the central assumption is that a server endpoint usually corresponds to a stable application over at least short timescales. The paper explicitly identifies failure cases: **dynamic-port applications like FTP and SIP data channels**, **proxy servers**, stale entries caused by the absence of per-entry timeouts, and workloads with weak endpoint reuse, low popularity skew, or strong short-term recency effects inconsistent with the frequency-based design; **LBL2** is the empirical illustration of the last case [1105.5684]. The mechanism for mitigating staleness is sampling-based validation rather than full correctness analysis under rapid application changes.

In the AlphaFold pipeline, the main caveats are benchmarking and biological validation rather than cache consistency. The paper states that **AF3 inference is not accelerated**, that default AlphaFold CPU and GPU components had to be run separately because of HPC restrictions, that the shared-PDB subset is only a proxy because proteins mapping to the same PDB entry do not necessarily directly interact, and that the study does **not** perform a full experimental PPI truth benchmark or a large DockQ-based structural accuracy benchmark in the main text [2606.04566]. Across all pairs, ipTM agreement is only moderate, even though shared-PDB subsets show high concordance.

The two systems are therefore different in both purpose and mechanism. One is a **server-endpoint label cache** designed to reduce the cost of payload-based traffic identification; the other is a **monomer-centric feature cache and bucketing pipeline** designed to reduce redundant AlphaFold preprocessing and AF2 recompilation. What they share is the same systems principle: exploit repeated structure so that an expensive backend stage is invoked only when cached knowledge is absent, invalid, or no longer trustworthy.

Source: https://www.emergentmind.com/topics/af_cache