Update README.md

README.md

@@ -60,22 +60,21 @@ pipeline_tag: text-to-image
     - OneTrainer: 910 steps, 1.12 s/it (`Local Batch Size: 3, LR: 0.0003`) → ~0.37s/img (17m 43s)
     - Fizgig(Batch-Size: Not Supported): 2730 steps, 1.25 it/s (`Gradient Accumulation: 3, LR: 0.0001`) → ~0.83s/img (36m 17s)
     - Fizgig-Advanced(Batch-Size: Supported): 2730 steps, 1.25 it/s (`Batch Size: 3, LR: 0.0003`) → ~0.83s/img (36m 17s)
-    - *Note on Speed & Formats: OneTrainer used the official sharded Diffusers format (bfloat16), while Fizgig used the ComfyUI single-file format (int8).*
+    - *(Note on Speed & Formats: OneTrainer used the official sharded Diffusers format (bfloat16), while Fizgig used the ComfyUI single-file format (int8). Although int8/fp8 usually compute faster on modern GPUs, the benchmark shows Fizgig is slower here—likely due to software-level framework overheads. Fizgig also supports the original bf16 Diffusers shards.)*
   - Showcase & Card Image Parameters:
     - Model: - 
     - LoRA Weight: 0.8 ~ 1
   
-  > **💡 Quick Note: LR / Batch Size / Gradient Accumulation**
-  > 
-  > - **Effective Batch Size** = `Batch Size × Gradient Accumulation`. Gradient accumulation saves VRAM but is slower; a larger Batch Size is faster but uses more VRAM.
-  > - **LR Scaling**: Don't blindly apply the linear rule to LoRA. Validate with loss curves. (My baseline: `Batch 3` + `LR 0.0003`). *Note: The vanilla Fizgig benchmark used the default `LR 0.0001`, which is technically under-scaled for an effective batch of 3; however, it was sufficient for this speed test.*
-  > 
-  > **Paper TL;DR:**
-  > - [*Accurate, Large Minibatch SGD* (2017)](https://arxiv.org/abs/1706.02677): The "Linear Scaling Rule" — if you multiply batch size by k, multiply LR by k. This was designed for full fine-tuning on ImageNet, not LoRA.
-  > - [*One weird trick for parallelizing CNNs* (2014)](https://arxiv.org/abs/1404.5997): The "Square Root Scaling Rule" — to keep gradient variance stable, scale LR by √k instead. More conservative when batch gets very large.
-  > - [*Beware of the Batch Size* (2026)](https://arxiv.org/abs/2602.09492): For LoRA specifically, batch size is not just a multiplier for LR — it's a **first-order design parameter**. Optimal batch depends on dataset size (most sensitive), rank, and model capacity. Vanilla LoRA matches fancy variants when batch is tuned properly.
-
-  
+    > #### LR / Batch Size / Gradient Accumulation
+    > 
+    > - **Effective Batch Size** = `Batch Size × Gradient Accumulation`. Gradient accumulation saves VRAM but is slower; a larger Batch Size is faster but uses more VRAM.
+    > - **LR Scaling**: Don't blindly apply the linear rule to LoRA. Validate with loss curves. (My baseline: `Batch 3` + `LR 0.0003`). *Note: The vanilla Fizgig benchmark used the default `LR 0.0001`, which is technically under-scaled for an effective batch of 3; however, it was sufficient for this speed test.*
+    > 
+    > #### Paper TL;DR:
+    > - [*Accurate, Large Minibatch SGD* (2017)](https://arxiv.org/abs/1706.02677): The "Linear Scaling Rule" — if you multiply batch size by k, multiply LR by k. This was designed for full fine-tuning on ImageNet, not LoRA.
+    > - [*One weird trick for parallelizing CNNs* (2014)](https://arxiv.org/abs/1404.5997): The "Square Root Scaling Rule" — to keep gradient variance stable, scale LR by √k instead. More conservative when batch gets very large.
+    > - [*Beware of the Batch Size* (2026)](https://arxiv.org/abs/2602.09492): For LoRA specifically, batch size is not just a multiplier for LR — it's a **first-order design parameter**. Optimal batch depends on dataset size (most sensitive), rank, and model capacity. Vanilla LoRA matches fancy variants when batch is tuned properly.
+      
 - **Krea2**
   - Training Tools: [Onetrainer](https://github.com/nerogar/OneTrainer)
   - Dataset: Mostly 50+ images (averaging 100+)