AF_Cache in Networks & AlphaFold

• AF_Cache is a dual-purpose caching system that reuses costly computations in both network application identification and high-throughput protein screening.
• In network applications, it aggregates flows by server endpoints and employs a multistage, frequency-based replacement policy to cut backend load by up to 95% and boost throughput by over 4×.
• For AlphaFold pipelines, AF_Cache caches monomer features and streamlines MSA generation, achieving dramatic speedups (up to 1343-fold for AF2) by eliminating redundant preprocessing.

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 (He et al., 2011). 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 (Narrowe et al., 3 Jun 2026).

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 (He et al., 2011).

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 $$(\text{server IP address}, \text{server port}, \text{transport-layer protocol}).$$0 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 (He et al., 2011).

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 $$(\text{server IP address}, \text{server port}, \text{transport-layer protocol}).$$1 parallel stages, each a hash table of counters, and an aggregate-flow is admitted only if all hashed counters exceed threshold $$(\text{server IP address}, \text{server port}, \text{transport-layer protocol}).$$2. The cited false-positive bound for an item with frequency $$(\text{server IP address}, \text{server port}, \text{transport-layer protocol}).$$3 is

$$(\text{server IP address}, \text{server port}, \text{transport-layer protocol}).$$4

Once admitted, entries are stored in a hash table for $$(\text{server IP address}, \text{server port}, \text{transport-layer protocol}).$$5 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 $$(\text{server IP address}, \text{server port}, \text{transport-layer protocol}).$$6 time for each cache lookup and $$(\text{server IP address}, \text{server port}, \text{transport-layer protocol}).$$7 time for each replacement, where $$(\text{server IP address}, \text{server port}, \text{transport-layer protocol}).$$8 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{server IP address}, \text{server port}, \text{transport-layer protocol}).$$9 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 (Narrowe et al., 3 Jun 2026).

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: $p$0 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 (Narrowe et al., 3 Jun 2026).

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$1-values less than $p$2. 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$3-values smaller than $p$4. 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 (He et al., 2011). 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 (Narrowe et al., 3 Jun 2026). 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.