A Feed-Forward Network (FFN) is a position-wise, fully connected network that applies an identical non-linear transformation to every token's representation independently within a Transformer block. It typically consists of two linear projections separated by an activation function, such as ReLU or GELU, enabling the model to introduce non-linearity and increase representational capacity.
Glossary
Feed-Forward Network (FFN)

What is Feed-Forward Network (FFN)?
A position-wise, fully connected sub-layer within a Transformer block that applies a non-linear transformation to each token's representation independently.
Unlike the self-attention mechanism, which mixes information between tokens, the FFN operates on each position in isolation. This component acts as a per-token feature processor, expanding the hidden dimension before projecting it back, and is essential for the model to learn complex, non-linear functions of the data.
Key Characteristics of the FFN
The Feed-Forward Network (FFN) is the primary locus of non-linear processing and memory storage within a Transformer block. It applies an identical transformation to every token independently, expanding and then contracting the model's hidden dimension.
Position-Wise Independence
Unlike the self-attention sub-layer, which mixes information across token positions, the FFN processes each token's representation in isolation. This means the exact same weights are applied to every vector in the sequence, treating each position identically. This design allows the attention mechanism to handle the routing of information between tokens, while the FFN focuses on refining what is stored within each token's hidden state.
The Two-Layer Sandwich
The standard FFN consists of two linear projections separated by a non-linear activation function:
- Up-Projection: The first layer expands the input from the model's hidden dimension
d_modelto a larger intermediate dimensiond_ff(often 4x larger). - Activation: A non-linear function like ReLU, GELU, or SwiGLU is applied.
- Down-Projection: The second layer projects the expanded representation back down to
d_model. This bottleneck structure forces the network to learn a compressed, expressive representation.
Key-Value Memory Analogy
A leading interpretation views the FFN as a massive, static key-value memory bank. The first linear layer acts as a set of keys, detecting specific patterns in the input. The activation function selectively fires for matching patterns, and the second linear layer retrieves the corresponding values—factual knowledge or linguistic rules—and adds them to the residual stream. This is why factual recall is often localized to FFN weights.
SwiGLU Activation Variant
Modern architectures like LLaMA and PaLM replace the simple ReLU with the SwiGLU activation function. This uses a gating mechanism:
- The input is projected into two separate matrices.
- One is passed through a Swish (SiLU) activation.
- The result is multiplied element-wise with the other matrix. This gated linear unit provides a smoother gradient flow and has been empirically shown to improve model quality, though it requires an additional weight matrix.
The Sparse Mixture-of-Experts (MoE) Extension
To scale model capacity without proportionally increasing compute, the single FFN can be replaced with a Mixture-of-Experts (MoE) layer. This contains multiple parallel FFN 'experts' and a trainable router network.
- Sparsity: For each token, the router selects only the top-k experts (e.g., 2 out of 8) to activate.
- Conditional Compute: This massively increases total parameters while keeping the FLOPs per token roughly constant, as inactive experts are not computed.
Computational Dominance
Despite its conceptual simplicity, the FFN dominates the parameter count and computational budget of a Transformer. In a standard architecture with d_ff = 4 * d_model, the two linear layers contain roughly two-thirds of the total model parameters. Optimizing these matrix multiplications is therefore the primary target for inference acceleration techniques like quantization and pruning.
FFN vs. Self-Attention: Complementary Roles
A functional comparison of the two primary sub-layers within a Transformer block, highlighting their distinct computational roles in token processing.
| Feature | Feed-Forward Network (FFN) | Self-Attention |
|---|---|---|
Primary Function | Position-wise non-linear transformation | Token mixing via pairwise interactions |
Interaction Scope | Per-token independently | Across all tokens in the sequence |
Core Operation | Two linear projections with activation | Scaled dot-product of Q, K, V vectors |
Information Flow | Vertical (depth-wise feature refinement) | Horizontal (contextual aggregation) |
Complexity Class | O(n * d_model^2) | O(n^2 * d_model) |
Parameter Count | ~67% of block parameters | ~33% of block parameters |
Role in Architecture | Knowledge storage and pattern memory | Dynamic routing of contextual information |
Activation Function |
Frequently Asked Questions
Clear answers to common questions about the position-wise feed-forward network, its role in the Transformer block, and its impact on model capacity.
A Feed-Forward Network (FFN) is a position-wise, fully connected sub-layer within a Transformer block that applies an identical non-linear transformation to every token's representation independently. Unlike the self-attention mechanism, which mixes information between tokens, the FFN processes each token's vector in isolation. It typically consists of two linear transformations with a non-linear activation function, such as ReLU, GELU, or SwiGLU, in between. The standard formulation is FFN(x) = W_2 * Activation(W_1 * x + b_1) + b_2, where the first layer expands the hidden dimension (e.g., by a factor of 4) and the second layer projects it back to the model's original dimension. This architecture acts as a per-token feature processor, introducing the non-linearity essential for the model to learn complex functions beyond simple weighted averages.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
The Feed-Forward Network is a critical component of the Transformer block. Explore the related mechanisms that work alongside the FFN to enable deep contextual processing.
Transformer Block
The fundamental building block of the Transformer architecture. Each block consists of two primary sub-layers: a multi-head self-attention mechanism for mixing information between tokens, and a position-wise Feed-Forward Network for transforming each token's representation independently. Both sub-layers are wrapped with residual connections and layer normalization to stabilize training and enable gradient flow in very deep networks.
Residual Connection
A pathway that adds the input of a sub-layer directly to its output before normalization. In the context of the FFN, the operation is LayerNorm(x + FFN(x)). This identity mapping prevents the vanishing gradient problem, ensuring that even if the FFN weights collapse to near-zero, the signal from the previous layer passes through unimpeded. This is the primary architectural enabler for training Transformers with hundreds of layers.
Layer Normalization
A normalization technique applied across the feature dimension of a single token's representation, rather than across the batch. It computes the mean and variance for each token independently, re-centering and re-scaling the activations. This reduces internal covariate shift during training and is typically applied before the FFN sub-layer in a Pre-LN architecture, which is the dominant configuration in modern models.
Gaussian Error Linear Unit (GELU)
The activation function most commonly used within the FFN of modern Transformer models like BERT and GPT. Unlike ReLU, GELU applies a smooth, stochastic regularization by multiplying the input by the cumulative distribution function of the standard Gaussian. This provides a non-monotonic 'bump' near zero, allowing for more nuanced gradient flow compared to the hard zeroing of ReLU.
SwiGLU Activation
A gated activation variant used in models like LLaMA and PaLM to replace the standard two-layer FFN. It uses a SwiGLU (Swish-Gated Linear Unit) where the output is Swish(xW_1) ⊗ (xW_2). This introduces a multiplicative gating mechanism that dynamically controls information flow, often requiring a three-weight-matrix projection to maintain the same parameter count while improving training stability and downstream performance.
Mixture of Experts (MoE)
An architecture that replaces the single, dense FFN with multiple parallel 'expert' FFNs and a learned routing network. For each token, the router selects a sparse subset (e.g., top-2) of experts to activate. This dramatically increases total model parameters without proportionally increasing compute, as only a fraction of the FFN weights are used per token. Used in Mixtral and GPT-4.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us