📚 Auto-publish: Add/update 7 blog posts
All checks were successful
Hugo Publish CI / build-and-deploy (push) Successful in 33s
All checks were successful
Hugo Publish CI / build-and-deploy (push) Successful in 33s
Generated on: Wed Aug 20 06:04:36 UTC 2025 Source: md-personal repository
This commit is contained in:
1
.image_mappings/ppo-for-language-models.txt
Normal file
1
.image_mappings/ppo-for-language-models.txt
Normal file
@@ -0,0 +1 @@
|
||||
Pasted image 20250816140700.png|.png
|
1
.image_mappings/transformer-s-core-mechanics.txt
Normal file
1
.image_mappings/transformer-s-core-mechanics.txt
Normal file
@@ -0,0 +1 @@
|
||||
Pasted image 20250819211718.png|.png
|
94
content/posts/breville-barista-pro-maintenance.md
Normal file
94
content/posts/breville-barista-pro-maintenance.md
Normal file
@@ -0,0 +1,94 @@
|
||||
---
|
||||
title: "Breville Barista Pro Maintenance"
|
||||
date: 2025-08-16
|
||||
draft: false
|
||||
---
|
||||
|
||||
|
||||
Proper maintenance is critical for the longevity and performance of a Breville Barista Pro espresso machine. Consistent cleaning not only ensures the machine functions correctly but also directly impacts the quality of the espresso produced. This guide provides a detailed, technical breakdown of the essential maintenance routines, from automated cycles to daily upkeep.
|
||||
|
||||
#### **Understanding the Two Primary Maintenance Cycles**
|
||||
|
||||
The Breville Barista Pro has two distinct, automated maintenance procedures: the **Cleaning (Flush) Cycle** and the **Descale Cycle**. It is important to understand that these are not interchangeable, as they address different types of buildup within the machine.
|
||||
|
||||
* **Cleaning Cycle (Flush):** This process is designed to remove coffee oils and granulated residue from the group head, shower screen, and portafilter system.
|
||||
* **Descale Cycle:** This process targets the internal components of the machine, such as the thermocoil and water lines, to remove mineral and limescale deposits from water.
|
||||
|
||||
#### **Procedure 1: The Cleaning (Flush) Cycle**
|
||||
|
||||
The machine will indicate when a cleaning cycle is needed by displaying a "FLUSH" alert on the LCD screen. This typically occurs after approximately 200 extractions.
|
||||
|
||||
**Required Materials:**
|
||||
* 1-Cup filter basket
|
||||
* Grey silicone cleaning disc (provided with the machine)
|
||||
* One cleaning tablet
|
||||
|
||||
**Step-by-Step Instructions:**
|
||||
1. Insert the 1-cup filter basket into the portafilter.
|
||||
2. Place the grey silicone cleaning disc inside the basket.
|
||||
3. Position one cleaning tablet in the center of the disc.
|
||||
4. Lock the portafilter firmly into the group head.
|
||||
5. Ensure the drip tray is empty and the water tank is filled.
|
||||
6. Press the 'MENU' button and use the 'Grind Amount' dial to navigate to the 'FLUSH' option. Press the dial to select it.
|
||||
7. The '1 CUP' button will illuminate. Press it to initiate the cycle.
|
||||
8. The cleaning process will last approximately five minutes, with the machine backflushing water under pressure. The remaining time will be displayed on the screen.
|
||||
9. Upon completion, the machine will beep and return to its ready state.
|
||||
10. Remove the portafilter and discard the water and dissolved tablet residue. Thoroughly rinse the portafilter, cleaning disc, and filter basket.
|
||||
11. Re-insert the portafilter (without the disc or tablet) and run a shot of hot water through the group head to rinse any remaining cleaning solution.
|
||||
|
||||
#### **Procedure 2: The Descale Cycle**
|
||||
|
||||
The machine will alert you when descaling is required. The frequency depends on water hardness and usage but is generally recommended every 2-3 months.
|
||||
|
||||
**Required Materials:**
|
||||
* Breville-recommended descaling solution
|
||||
* A large container (minimum 2-liter capacity)
|
||||
|
||||
**Step-by-Step Instructions:**
|
||||
|
||||
**Part A: Preparation**
|
||||
1. Empty the drip tray and re-insert it.
|
||||
2. Remove the water filter from the water tank.
|
||||
3. Pour the descaling solution into the empty water tank and add fresh water up to the indicated "DESCALE" line.
|
||||
4. Place a large container under the group head, hot water outlet, and steam wand.
|
||||
|
||||
**Part B: The Descaling Process**
|
||||
1. Turn the machine on and press the 'MENU' button. Navigate to the 'DESCALE' option and select it by pressing the dial.
|
||||
2. Press the illuminated '1 CUP' button to begin.
|
||||
3. The cycle proceeds in three stages. You must manually advance through them using the steam dial based on the LCD prompts:
|
||||
* **Group Head (d3):** The machine descales the coffee brewing components.
|
||||
* **Hot Water (d2):** After a beep, the LCD shows "d2". Turn the steam dial to the hot water position.
|
||||
* **Steam (d1):** After another beep, the display reads "d1". Turn the dial to the steam position.
|
||||
|
||||
**Part C: The Rinse Cycle**
|
||||
1. Once the descaling solution is expended, the machine will beep and prompt for a rinse cycle ("r").
|
||||
2. Empty the large container and rinse the water tank thoroughly.
|
||||
3. Fill the water tank with fresh, cold water to the MAX line and re-insert it.
|
||||
4. Place the empty container back under the outlets and press the '1 CUP' button.
|
||||
5. The rinse cycle will mirror the descaling process, prompting you to engage the group head ("r3"), hot water ("r2"), and steam wand ("r1") in sequence.
|
||||
6. After the rinse is complete, the machine will exit the maintenance mode and return to its ready state.
|
||||
|
||||
#### **Routine and Preventative Maintenance Schedule**
|
||||
|
||||
In addition to the automated cycles, regular manual cleaning is essential for machine health.
|
||||
|
||||
**Daily Tasks:**
|
||||
* **Purge Group Head:** After the final use of the day, run hot water through the group head (without the portafilter) to clear grounds.
|
||||
* **Clean Portafilter & Baskets:** Do not let used coffee grounds sit in the portafilter. Rinse with hot water after every use.
|
||||
* **Clean Steam Wand:** Immediately after texturing milk, wipe the wand with a damp cloth and purge steam for 2-3 seconds to clear internal passages.
|
||||
* **Empty Drip Tray:** Empty and rinse the drip tray regularly.
|
||||
|
||||
**Weekly Tasks:**
|
||||
* **Soak Components:** Remove the filter basket from the portafilter. Soak both components in a solution of hot water and a cleaning tablet (or specific espresso cleaner) for 20-30 minutes to dissolve accumulated coffee oils. Rinse thoroughly.
|
||||
* **Clean Grinder:** Empty the bean hopper. Run the grinder to clear any remaining beans, then use a brush and/or vacuum to clean out fines and oil residue from the burrs and chute.
|
||||
|
||||
**Periodic Tasks (Every 2-3 Months):**
|
||||
* **Replace Water Filter:** The water filter located inside the water tank should be replaced every 3 months. This reduces the rate of scale buildup.
|
||||
* **Inspect Shower Screen:** Use a brush to gently scrub the shower screen inside the group head to remove any stubborn coffee grounds.
|
||||
|
||||
By adhering to this comprehensive maintenance schedule, you can ensure your Breville Barista Pro operates at peak performance and consistently produces high-quality espresso.
|
||||
|
||||
***
|
||||
|
||||
**Reference:**
|
||||
* Breville Barista Pro Instruction Manual and official manufacturer guidelines.
|
108
content/posts/ppo-for-language-models.md
Normal file
108
content/posts/ppo-for-language-models.md
Normal file
@@ -0,0 +1,108 @@
|
||||
---
|
||||
title: "A Deep Dive into PPO for Language Models"
|
||||
date: 2025-08-02
|
||||
draft: false
|
||||
---
|
||||
|
||||
|
||||
Large Language Models (LLMs) have demonstrated astonishing capabilities, but out-of-the-box, they are simply powerful text predictors. They don't inherently understand what makes a response helpful, harmless, or aligned with human values. The technique that has proven most effective at bridging this gap is Reinforcement Learning from Human Feedback (RLHF), and at its heart lies a powerful algorithm: Proximal Policy Optimization (PPO).
|
||||
|
||||
You may have seen diagrams like the one below, which outlines the RLHF training process. It can look intimidating, with a web of interconnected models, losses, and data flows.
|
||||
|
||||

|
||||
|
||||
This post will decode that diagram, piece by piece. We'll explore the "why" behind each component, moving from high-level concepts to the deep technical reasoning that makes this process work.
|
||||
|
||||
### Translating RL to a Conversation
|
||||
|
||||
The first step is to understand how the traditional language of reinforcement learning maps to the world of text generation.
|
||||
|
||||
* **State (`s_t`)**: In a chat setting, the "state" is the context of the conversation so far. It's the initial prompt (`x`) plus all the text the model has generated up to the current moment (`y₁, ..., y_{t-1}`).
|
||||
* **Action (`a_t`)**: The "action" is the model's decision at each step. For an LLM, this means generating the very next token (`y_t`). A full response is a sequence of these actions.blob:https://aistudio.google.com/872e746f-88c1-40ec-8e45-fa0efce97299
|
||||
* **Reward (`r`)**: The "reward" is a numeric score that tells the model how good its full response (`y`) was. This score comes from a separate **Reward Model**, which has been trained on a large dataset of human preference comparisons (e.g., humans rating which of two responses is better). This reward is often only awarded at the end of the entire generated sequence.
|
||||
|
||||
Let's make this concrete. If a user provides the prompt **(x)**: *"The best thing about AI is"*, and the model generates the response **(y)**: *"its potential to solve problems."*, here is how it's broken down for training:
|
||||
|
||||
* **State 1**: "The best thing about AI is"
|
||||
* **Action 1**: "its"
|
||||
* **State 2**: "The best thing about AI is its"
|
||||
* **Action 2**: " potential"
|
||||
* **State 3**: "The best thing about AI is its potential"
|
||||
* **Action 3**: " to"
|
||||
* ...and so on for every generated token.
|
||||
|
||||
This breakdown transforms a single prompt-response pair into a rich trajectory of state-action pairs, which becomes the raw data for our learning algorithm.
|
||||
|
||||
### The Cast of Models: An Actor-Critic Ensemble
|
||||
|
||||
The PPO process doesn't rely on a single model but an ensemble where each member has a distinct role.
|
||||
|
||||
1. **The Actor (Policy LM)**: This is the star of the show—the LLM we are actively fine-tuning. Its role is to take a state (the current text) and decide on an action (the next token). We refer to its decision-making process as its "policy" (`π`).
|
||||
2. **The Critic (Value Model)**: This is the Actor's coach. The Critic doesn't generate text. Instead, it observes a state and estimates the *potential future reward* the Actor is likely to receive from that point onward. This estimate is called the "value" (`V(s_t)`). The Critic's feedback helps the Actor understand whether it's in a promising or a dead-end situation, which is a much more immediate learning signal than waiting for the final reward.
|
||||
3. **The Reward Model**: This is the ultimate judge. As mentioned, it's a separate model trained on human preference data that provides the final score for a complete generation. Its judgment is treated as the ground truth for training both the Actor and the Critic.
|
||||
|
||||
### The Challenge of Credit Assignment: Generalized Advantage Estimation (GAE)
|
||||
|
||||
A key problem in RL is assigning credit. If a 20-token response gets a high reward, was it because of the first token, the last one, or all of them? The Critic helps solve this. By comparing the reward at each step with the Critic's value estimate, we can calculate the **Advantage (`Â`)**.
|
||||
|
||||
A simple advantage calculation might be: `Advantage = reward + Value_of_next_state - Value_of_current_state`.
|
||||
|
||||
However, this can be noisy. PPO uses a more sophisticated technique called **Generalized Advantage Estimation (GAE)**. The formula looks complex, but the idea is intuitive:
|
||||
|
||||
`Â(s_t, a_t) = Σ(γλ)^l * δ_{t+l}`
|
||||
where `δ_t = r_t + γV(s_{t+1}) - V(s_t)`
|
||||
|
||||
* **γ (gamma)** is a discount factor (e.g., 0.99), which values immediate rewards slightly more than distant ones.
|
||||
* **λ (lambda)** is a smoothing parameter that balances the trade-off between bias and variance. It creates a weighted average of advantages over multiple future time steps.
|
||||
|
||||
In essence, GAE provides a more stable and accurate estimate of how much better a specific action was compared to the policy's average behavior in that state.
|
||||
|
||||
### The Heart of PPO: The Quest for Stable Updates
|
||||
|
||||
Now we arrive at the core innovation of PPO. We want to update our Actor model to take actions with higher advantages. The naive way to do this is to re-weight our training objective by an **importance sampling ratio**: `(π_new / π_old)`. This corrects for the fact that the data we are learning from was generated by a slightly older version of our policy.
|
||||
|
||||
However, this ratio is incredibly dangerous. If the new policy becomes very different from the old one, the ratio can explode, leading to massive, unstable gradient updates that destroy the model.
|
||||
|
||||
PPO solves this with its signature **Clipped Surrogate Objective**. The PPO loss function is:
|
||||
|
||||
`L_CLIP(θ) = Ê_t [ min( r_t(θ)Â_t, clip(r_t(θ), 1 - ε, 1 + ε)Â_t ) ]`
|
||||
|
||||
Let's translate this from math to English:
|
||||
* `r_t(θ)` is the probability ratio `π_new(a_t|s_t) / π_old(a_t|s_t)`.
|
||||
* The goal is to increase the objective by an amount proportional to the advantage `Â_t`.
|
||||
* **The `clip` function is the crucial safeguard.** It forbids the probability ratio from moving outside a small window (e.g., `[0.8, 1.2]`).
|
||||
|
||||
This means the algorithm says: "Let's update our policy to favor this good action. But if the required update would change the policy too drastically from the old one, we'll 'clip' the update to a more modest size." This creates a "trust region," ensuring stable, incremental improvements.
|
||||
|
||||
### Avoiding Amnesia: The Pretraining Loss
|
||||
|
||||
There's one final problem. If we only optimize for the PPO loss, the model might learn to "hack" the reward model by generating repetitive or nonsensical text that gets a high score. In doing so, it could suffer from **catastrophic forgetting**, losing its fundamental grasp of grammar and facts.
|
||||
|
||||
To prevent this, we introduce a second loss term. As seen in the diagram, we mix in data from the original **Pretraining Data** (or the dataset used for Supervised Fine-Tuning). We calculate a standard next-token prediction loss (`LM Loss`) on this high-quality data.
|
||||
|
||||
The final loss for the Actor is a combination of both objectives:
|
||||
|
||||
**Total Loss = Loss_PPO + `λ_ptx` * Loss_LM**
|
||||
|
||||
This brilliantly balances two goals:
|
||||
1. The `Loss_PPO` pushes the model towards behaviors that align with human preferences.
|
||||
2. The `Loss_LM` acts as a regularizer, pulling the model back towards its core language capabilities and preventing it from drifting into gibberish.
|
||||
|
||||
### The Full Training Loop
|
||||
|
||||
Now, we can assemble the entire process into a clear, iterative loop:
|
||||
|
||||
1. **Collect**: The current Actor policy `π_k` generates responses to a batch of prompts. These experiences—`(state, action, probability, reward, value)`—are stored in an **Experience Buffer**.
|
||||
2. **Calculate**: Once the buffer is full, we use the collected data to compute the advantage estimates `Â_t` for every single token-generation step.
|
||||
3. **Optimize**: For a few epochs, we repeatedly sample mini-batches from the buffer and update the Actor and Critic models. The Actor is updated using the combined `PPO-clip Loss` and `LM Loss`. The Critic is updated to improve its value predictions.
|
||||
4. **Flush and Repeat**: After the optimization phase, the entire experience buffer is discarded. The data is now "stale" because our policy has changed. The newly updated policy `π_{k+1}` becomes the new Actor, and we return to step 1 to collect fresh data.
|
||||
|
||||
This cycle of collection and optimization allows the language model to gradually and safely steer its behavior towards human-defined goals, creating the helpful and aligned AI assistants we interact with today.
|
||||
|
||||
***
|
||||
|
||||
**References:**
|
||||
|
||||
1. Schulman, J., Wolski, F., Dhariwal, P., Radford, A., & Klimov, O. (2017). *Proximal Policy Optimization Algorithms*. arXiv preprint arXiv:1707.06347.
|
||||
2. Schulman, J., Moritz, P., Levine, S., Jordan, M., & Abbeel, P. (2015). *High-Dimensional Continuous Control Using Generalized Advantage Estimation*. arXiv preprint arXiv:1506.02438.
|
||||
3. Ouyang, L., et al. (2022). *Training language models to follow instructions with human feedback*. Advances in Neural Information Processing Systems 35.
|
93
content/posts/transformer-s-core-mechanics.md
Normal file
93
content/posts/transformer-s-core-mechanics.md
Normal file
@@ -0,0 +1,93 @@
|
||||
---
|
||||
title: "Transformer's Core Mechanics"
|
||||
date: 2025-08-19
|
||||
draft: false
|
||||
---
|
||||
|
||||
The Transformer architecture is the bedrock of modern Large Language Models (LLMs). While its high-level success is widely known, a deeper understanding requires dissecting its core components. This article provides a detailed, technical breakdown of the fundamental concepts within a Transformer block, from the notion of "channels" to the intricate workings of the attention mechanism and its relationship with other advanced architectures like Mixture of Experts.
|
||||
|
||||
### 1. The "Channel": A Foundational View of `d_model`
|
||||
|
||||
In deep learning, a "channel" can be thought of as a feature dimension. While this term is common in Convolutional Neural Networks for images (e.g., Red, Green, Blue channels), in LLMs, the analogous concept is the model's primary embedding dimension, commonly referred to as `d_model`.
|
||||
|
||||
An input text is first tokenized, and each token is mapped to a vector of size `d_model` (e.g., 4096). Each of the 4096 dimensions in this vector can be considered a "channel," representing a different semantic or syntactic feature of the token.
|
||||
|
||||
As this data, represented by a tensor of shape `[batch_size, sequence_length, d_model]`, progresses through the layers of the Transformer, these channels are continuously transformed. However, a critical design choice is that the output dimension of every main sub-layer (like the attention block or the FFN block) is also `d_model`. This consistency is essential for enabling **residual connections**, where the input to a block is added to its output (`output = input + SubLayer(input)`). This technique is vital for training the extremely deep networks common today.
|
||||
|
||||
### 2. The Building Blocks: Dimensions of Key Layers
|
||||
|
||||
A Transformer layer is primarily composed of two sub-layers: a Multi-Head Attention block and a position-wise Feed-Forward Network (FFN). The parameters for these are stored in several key weight matrices. Understanding their dimensions is crucial.
|
||||
|
||||
Let's define our variables:
|
||||
* `d_model`: The core embedding dimension.
|
||||
* `d_ff`: The inner dimension of the FFN, typically `4 * d_model`.
|
||||
* `h`: The number of attention heads.
|
||||
* `d_head`: The dimension of each attention head, where `d_model = h * d_head`.
|
||||
|
||||
The dimensions of the weight matrices are as follows:
|
||||
|
||||
| Layer | Weight Matrix | Input Vector Shape | Output Vector Shape | **Weight Matrix Dimension** |
|
||||
| ----------------------------- | ------------- | ------------------ | ------------------- | ------------------------- |
|
||||
| **Attention Projections** | | | | |
|
||||
| Query | `W_Q` | `d_model` | `d_model` | **`[d_model, d_model]`** |
|
||||
| Key | `W_K` | `d_model` | `d_model` | **`[d_model, d_model]`** |
|
||||
| Value | `W_V` | `d_model` | `d_model` | **`[d_model, d_model]`** |
|
||||
| Output | `W_O` | `d_model` | `d_model` | **`[d_model, d_model]`** |
|
||||
| **Feed-Forward Network** | | | | |
|
||||
| Layer 1 (Up-projection) | `W_ff1` | `d_model` | `d_ff` | **`[d_model, d_ff]`** |
|
||||
| Layer 2 (Down-projection) | `W_ff2` | `d_ff` | `d_model` | **`[d_ff, d_model]`** |
|
||||
|
||||
### 3. Deconstructing Multi-Head Attention (MHA)
|
||||
|
||||
The core innovation of the Transformer is Multi-Head Attention. It allows the model to weigh the importance of different tokens in the sequence from multiple perspectives simultaneously.
|
||||

|
||||
#### 3.1. The "Why": Beyond a Single Attention
|
||||
A single attention mechanism would force the model to average all types of linguistic relationships into one pattern. MHA avoids this by creating `h` parallel subspaces. Each "head" can specialize, with one head learning syntactic dependencies, another tracking semantic similarity, and so on. This creates a much richer representation.
|
||||
|
||||
#### 3.2. An Encoding/Decoding Analogy
|
||||
A powerful way to conceptualize the attention calculation is as a two-stage process:
|
||||
1. **Encoding Relationships:** The first part of the calculation, `softmax(Q @ K.T)`, can be seen as an encoding step. It does not use the actual "content" of the tokens (the `V` vectors). Instead, it uses the Queries and Keys to build a dynamic "relationship map" between tokens in the sequence. This map, a matrix of attention scores, answers the question: "For each token, how important is every other token right now?"
|
||||
2. **Decoding via Information Retrieval:** The second part, `scores @ V`, acts as a decoding step. It uses the relationship map to retrieve and synthesize information. For each token, it creates a new vector by taking a weighted sum of all the `V` vectors in the sequence, using the scores as the precise mixing recipe. It decodes the relational structure into a new, context-aware representation.
|
||||
|
||||
#### 3.3. The "How": A Step-by-Step Flow
|
||||
The MHA process is designed for maximum computational efficiency.
|
||||
1. **Initial Projections:** The input vectors (shape `[seq_len, d_model]`) are multiplied by `W_Q`, `W_K`, and `W_V`. These matrices are all `[d_model, d_model]` not to create one large query, but to **efficiently compute the vectors for all `h` heads at once**. The single large output vector is then reshaped into `h` separate vectors, each of size `d_head`.
|
||||
2. **Attention Score Calculation:** For each head `i`, a score matrix is calculated: `scores_i = softmax( (Q_i @ K_i.T) / sqrt(d_head) )`. Note that `Q_i` and `K_i` have dimensions `[seq_len, d_head]`, so the resulting `scores_i` matrix has a dimension of **`[seq_len, seq_len]`**.
|
||||
3. **Weighted Value Calculation:** The scores are used to create a weighted sum of the Value vectors for each head: `output_i = scores_i @ V_i`. Since `scores_i` is `[seq_len, seq_len]` and `V_i` is `[seq_len, d_head]`, the resulting `output_i` has a dimension of **`[seq_len, d_head]`**. This is the final output of a single head.
|
||||
4. **Concatenation and Final Projection:** The outputs of all `h` heads are concatenated along the last dimension. This produces a single large matrix of shape `[seq_len, h * d_head]`, which is equivalent to `[seq_len, d_model]`. This matrix is then passed through the final output projection layer, `W_O` (shape `[d_model, d_model]`), to produce the attention block's final output. The `W_O` matrix learns the optimal way to mix the information from all the specialized heads into a single, unified representation.
|
||||
|
||||
### 4. Optimizing Attention: GQA and MQA
|
||||
|
||||
During inference, storing the Key and Value vectors for all previous tokens (the KV Cache) is a major memory bottleneck. **Grouped-Query Attention (GQA)** and **Multi-Query Attention (MQA)** are architectural modifications that address this by allowing multiple Query heads to share the same Key and Value heads.
|
||||
|
||||
Let's use a concrete example, similar to Llama 2 7B:
|
||||
* `d_model` = 4096
|
||||
* `h` = 32 Q heads
|
||||
* `d_head` = 128
|
||||
* `g` = 8 KV head groups for GQA
|
||||
|
||||
The key insight is that only the dimensions of the `W_K` and `W_V` matrices change, which in turn reduces the size of the KV cache. The `W_Q` and `W_O` matrices remain `[4096, 4096]`.
|
||||
|
||||
| Attention Type | No. of Q Heads | No. of KV Heads | `W_K` & `W_V` Dimension | Relative KV Cache Size |
|
||||
| ------------------- | -------------- | --------------- | ----------------------- | ---------------------- |
|
||||
| **MHA** (Multi-Head)| 32 | 32 | `[4096, 32*128]` = `[4096, 4096]` | 1x (Baseline) |
|
||||
| **GQA** (Grouped) | 32 | 8 | `[4096, 8*128]` = `[4096, 1024]` | 1/4x |
|
||||
| **MQA** (Multi-Query)| 32 | 1 | `[4096, 1*128]` = `[4096, 128]` | 1/32x |
|
||||
|
||||
GQA provides a robust balance, significantly reducing the memory and bandwidth requirements for the KV cache with negligible impact on model performance, making it a popular choice in modern LLMs.
|
||||
|
||||
### 5. MHA vs. Mixture of Experts (MoE): A Clarification
|
||||
|
||||
While both MHA and MoE use the concept of "experts," they are functionally and architecturally distinct.
|
||||
|
||||
* **MHA:** The "experts" are the **attention heads**. All heads are active for every token to build a rich representation within the attention layer. This is akin to a board meeting where every member analyzes and contributes to every decision.
|
||||
* **MoE:** The "experts" are full **Feed-Forward Networks**. A routing network selects a small subset of these FFNs for each token. This is a scaling strategy to increase a model's parameter count for greater capacity while keeping the computational cost fixed. It replaces the standard FFN block, whereas MHA *is* the attention block.
|
||||
|
||||
By understanding these technical details, from the basic concept of a channel to the sophisticated interplay of heads and experts, one can build a more complete and accurate mental model of how LLMs truly operate.
|
||||
|
||||
---
|
||||
### References
|
||||
|
||||
1. Vaswani, A., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., Gomez, A. N., ... & Polosukhin, I. (2017). Attention is all you need. *Advances in neural information processing systems*, 30.
|
||||
2. Shazeer, N., Mirhoseini, A., Maziarz, K., Davis, A., Le, Q., Hinton, G., & Dean, J. (2017). Outrageously large neural networks: The sparsely-gated mixture-of-experts layer. *arXiv preprint arXiv:1701.06538*.
|
||||
3. Ainslie, J., Ontanon, J., Cakka, E., Dosovitskiy, A., & Le, Q. V. (2023). GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints. *arXiv preprint arXiv:2305.13245*.
|
BIN
static/images/ppo-for-language-models/.png
Normal file
BIN
static/images/ppo-for-language-models/.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 1.2 MiB |
BIN
static/images/transformer-s-core-mechanics/.png
Normal file
BIN
static/images/transformer-s-core-mechanics/.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 254 KiB |
Reference in New Issue
Block a user