More Rank Is Not Always More Capacity
Fine-tuning teams love a simple knob.
If the model underperforms, increase rank. If the adapter looks too small, increase rank. If the downstream task is hard, increase rank again and call it strategy. This is comforting because rank is measurable, budgetable, and easy to explain in a meeting. Unfortunately, reality has its usual habit of being less cooperative.
The paper behind this article, CeRA: Overcoming the Linear Ceiling of Low-Rank Adaptation via Capacity Expansion, makes a sharper argument: LoRA’s bottleneck is not only that its rank may be too low. The deeper issue is that the adapter update is structurally linear.1 Increasing rank inside the same linear form can add parameters without adding much usable expressivity. That is the “linear ceiling.”
This matters because LoRA became popular for good reasons. It is parameter-efficient, easy to train, and mergeable into the base model for zero-latency inference. In production environments, those are not decorative virtues. They are the difference between a model that can be deployed and a model that remains a very elegant research folder.
But mergeability has a price. A mergeable LoRA update must remain a linear weight update. CeRA asks whether this convenience has become a hidden architectural constraint, especially for reasoning-heavy tasks where the model needs more than a small linear correction.
The answer offered by the paper is not “use more parameters.” It is more annoying, and therefore more useful: change the shape of the adapter.
LoRA’s Hidden Contract: Stay Linear, Stay Mergeable
LoRA starts with a simple idea. Instead of updating the full weight matrix $W_0$, it learns a low-rank update:
The adapted layer behaves like:
This is efficient because $A$ and $B$ are small relative to the full weight matrix. After training, $\Delta W$ can be merged into $W_0$. Inference remains clean. No extra adapter computation has to sit beside the model at serving time.
That is the bargain: LoRA gives you cheap adaptation in exchange for accepting that the learned update lives inside a linear low-rank subspace.
For many tasks, this bargain is perfectly reasonable. Classification, style adaptation, format imitation, and many instruction-following improvements may not require deep changes to the model’s internal geometry. A linear update can be enough.
Reasoning tasks are less polite. Multi-step math and logic require intermediate state tracking, conditional branching, and transformations that are not easily captured by a narrow linear correction. The paper’s core claim is that when these tasks become complex, LoRA can allocate more rank without using that rank effectively. The adapter may have 512 available dimensions, but its learned update can still collapse into a much smaller effective subspace.
In other words, the invoice says “rank 512.” The model may be using something much closer to a small fraction of that. Delightful, if you enjoy paying for dormant capacity.
CeRA Changes the Adapter’s Functional Class
CeRA, or Capacity-enhanced Rank Adaptation, keeps the broad parameter-efficient adapter idea but changes the update from a purely linear mapping into a non-linear weight-level adapter.
Its forward path can be summarized as:
The important shift is not just the presence of an activation function. It is the combination of three design choices.
First, CeRA operates at weight-level granularity. It injects the adapter into internal projections, especially query and value projections, rather than only applying a coarse adapter around the output of a whole module. That means the adapter can influence the internal dynamics of attention, not merely patch the final block output.
Second, CeRA uses SiLU gating. SiLU is smooth and input-dependent, which allows the adapter to amplify or suppress latent directions rather than applying the same linear correction everywhere. This gives the adapter a richer functional shape.
Third, CeRA uses structural dropout inside the latent adapter pathway. The paper interprets this not merely as regularization but as a capacity-expansion mechanism: by stochastically blocking paths, dropout discourages the adapter from collapsing into a few dominant directions and forces information to spread across more of the rank spectrum.
This is the mechanism-first reading of the paper:
| Mechanism | What it changes | Why it matters |
|---|---|---|
| Weight-level insertion | Touches internal attention projections | The adapter can alter internal feature dynamics, not only block-level outputs |
| SiLU gating | Adds smooth non-linearity | The update can become input-dependent rather than a fixed linear correction |
| Structural dropout | Forces distributed latent use | The adapter is less likely to collapse into a narrow spectral band |
| Unmerged inference | Gives up LoRA’s clean mergeability | Acceptable in some multi-tenant serving setups, costly in edge or strict zero-latency settings |
The last row is not a footnote. It is the trade-off. CeRA does not preserve LoRA’s most operationally convenient feature: exact mergeability. The paper’s defense is that in multi-tenant adapter serving, adapters are often already kept unmerged because different users or tasks require different adapters. In that setting, the practical penalty of non-linearity may be modest.
That is a credible argument for some deployments. It is not a universal pardon.
The Main Evidence: CeRA Wins Where the Task Needs More Geometry
The paper uses Llama-3-8B as the frozen backbone and compares CeRA with LoRA and DoRA. It evaluates on SlimOrca and MathInstruct, with downstream exact-match results on GSM8K and MATH.
The most business-relevant result is the MATH benchmark.
| Method | Rank | Trainable parameters | MATH pass@1 | MATH pass@10 | GSM8K pass@1 |
|---|---|---|---|---|---|
| LoRA | 64 | 27.3M | 14.36% | 50.20% | 48.38% |
| LoRA | 128 | 54.5M | 14.20% | 49.60% | 50.43% |
| LoRA | 512 | 218.1M | 15.72% | 55.20% | 49.64% |
| DoRA | 64 | 27.3M | 14.44% | 48.80% | 45.46% |
| DoRA | 128 | 54.5M | 15.18% | 53.20% | 47.97% |
| CeRA | 64 | 27.3M | 16.36% | 53.60% | 50.27% |
The clean headline is that CeRA at rank 64 reaches 16.36% pass@1 on MATH, outperforming LoRA at rank 512, which reaches 15.72%. CeRA does this with 27.3M trainable parameters compared with LoRA-512’s 218.1M. That is one-eighth of the trainable parameter budget.
This is not a huge absolute accuracy number. Nobody should read 16.36% on MATH and declare victory over mathematics. Please do not put that on a pitch deck unless you enjoy being asked follow-up questions.
The point is comparative. Under the same backbone and paper-defined setup, increasing LoRA rank to 512 does not beat the smaller non-linear CeRA adapter. The implication is that for complex reasoning, the marginal value of more linear rank can be lower than the marginal value of changing the adapter’s functional class.
The GSM8K result is also important because it prevents overinterpretation. On GSM8K, LoRA-128 reaches 50.43%, CeRA-64 reaches 50.27%, and LoRA-512 reaches 49.64%. CeRA is competitive, but not dramatically superior. That fits the paper’s argument: simpler arithmetic may not require the same expanded spectral capacity as more complex MATH problems.
This distinction is useful. It says CeRA is not magic adapter seasoning to sprinkle over every fine-tuning job. It appears more relevant when the downstream task demands richer internal transformations.
The Spectral Story: Rank Budget Is Not Rank Usage
The paper’s strongest explanatory evidence is spectral, not just benchmark-based.
The authors analyze singular value distributions and effective rank. Effective rank estimates how many dimensions are actually being used after considering how energy is distributed across singular values. A model can have a large nominal rank but a much smaller effective rank if most of the energy concentrates in only a few directions.
The paper uses the entropy-based effective rank formulation:
where $p_i$ is the normalized singular value distribution.
The interpretation is simple: if energy spreads across many singular directions, effective rank is higher. If energy collapses into a few dominant directions, effective rank is lower.
On SlimOrca, the paper reports that LoRA shows rank collapse: singular values decay rapidly, and performance plateaus even as rank increases. CeRA maintains a heavier spectral tail and, at high rank, achieves an effective rank exceeding 330 while LoRA saturates far lower.
This matters because it connects the engineering result to a mechanism. CeRA is not merely “a little better in a table.” It appears to make more of the allocated adapter dimensions usable.
| Evidence type | Likely purpose | What it supports | What it does not prove |
|---|---|---|---|
| SlimOrca perplexity scaling | Main evidence | LoRA performance saturates while CeRA continues improving at lower rank | That all tasks need non-linear adapters |
| MATH/GSM8K exact match | Main evidence | CeRA helps more on complex reasoning than basic arithmetic | That CeRA is universally superior across domains |
| Singular spectrum and effective rank | Mechanistic evidence | CeRA distributes information across more dimensions | That spectral spread alone causes all downstream gains |
| Logistic-map case study | Qualitative illustration | Linear adapters can suffer state collapse in iterative reasoning | General performance across all recursive tasks |
| Ablation table | Ablation | SiLU, dropout, and weight-level granularity each contribute | Perfect isolation of every possible design interaction |
| Latency and memory discussion | Implementation analysis | Non-mergeability may be acceptable in some unmerged serving contexts | That CeRA is costless in all production environments |
This table is worth spelling out because papers often mix main results, ablations, robustness checks, and illustrative examples into one narrative. For business readers, that can blur the signal. The MATH result supports the practical performance claim. The spectral analysis supports the mechanism. The ablation supports the design choices. The latency section supports deployment plausibility. They are connected, but they are not the same kind of evidence.
Why the Ablation Matters More Than It Looks
The ablation study is easy to skim. That would be a mistake.
At rank 128 on SlimOrca, the full CeRA architecture achieves a test perplexity of 3.81. Moving from weight-level to module-level application worsens perplexity to 3.90. Removing the activation and reverting to an identity mapping worsens perplexity to 3.97. Replacing SiLU with ReLU gives 3.84. Removing dropout gives 3.85.
| Variant | Change | Test PPL |
|---|---|---|
| CeRA | Full architecture | 3.81 |
| Module-level adapter | Coarser granularity | 3.90 |
| Identity activation | Removes non-linearity | 3.97 |
| ReLU activation | Less smooth activation | 3.84 |
| No dropout | Removes structural dropout | 3.85 |
The most important line is the identity activation result. Once the adapter becomes linear again, performance drops meaningfully. That supports the paper’s main thesis: the gain is not merely from having another adapter path. The non-linear form is doing work.
The granularity result also matters. A module-level adapter is still non-linear, but it performs worse than weight-level CeRA. That suggests placement is not cosmetic. If the adapter acts only after the broader module computation, it may arrive too late to reshape the internal attention dynamics that reasoning tasks depend on.
The dropout result is smaller but still relevant. Removing dropout worsens performance from 3.81 to 3.85. That supports the authors’ interpretation of dropout as structural expansion, though the magnitude is not as dramatic as the identity-activation comparison. A cautious reading is that dropout helps, but the main architectural rupture is the move away from a purely linear update.
Hyperparameter Robustness Is a Business Result, Not Just a Training Detail
One underappreciated part of the paper is the claim about optimization robustness.
The authors argue that linear adapters such as LoRA can be sensitive to learning-rate choices, and that DoRA’s magnitude-direction decomposition may introduce its own optimization fragility. In the appendix, they say LoRA and DoRA were tuned separately, with DoRA receiving an independent learning-rate search. CeRA, by contrast, uses the same optimal learning rate found for vanilla LoRA.
For practitioners, this matters because hyperparameter search is not free. It consumes GPU hours, engineer attention, and calendar time. Fine-tuning cost is not only the final number of trainable parameters; it is the number of failed runs required before a team finds a stable configuration.
This is where CeRA’s business relevance becomes more concrete. If a CeRA-like adapter can provide stronger reasoning performance while also reducing the need for extensive tuning, then the ROI is not merely “fewer trainable parameters.” It is cheaper diagnosis.
A team fine-tuning models for financial analysis, legal reasoning, scientific question answering, or technical support does not only need a higher score. It needs to know whether poor performance comes from data quality, task ambiguity, model scale, hyperparameters, or adapter capacity. If LoRA rank increases but effective rank remains low, that is a diagnostic clue: the adapter may be structurally underusing its own budget.
That kind of clue can save teams from the classic enterprise AI ritual: trying three more expensive configurations, then concluding vaguely that “the model needs more data.” Sometimes it does. Sometimes the adapter is just geometrically asleep.
The Deployment Question: Losing Mergeability Is Not Always Fatal
CeRA gives up LoRA’s exact mergeability because the non-linear adapter path cannot be folded into the base weight matrix as a single static update.
This is the most obvious objection. It is also the least interesting if treated as a yes-or-no debate.
The better question is: what serving regime are we talking about?
For single-task deployments that require zero-latency merged inference, LoRA still has a strong operational advantage. Edge devices, latency-sensitive embedded systems, or tightly optimized batch-serving environments may not want an unmerged non-linear adapter path.
For multi-tenant cloud serving, the situation is different. If a platform already serves many adapters dynamically, it may keep adapters unmerged anyway. In that context, CeRA’s paper reports that its additional latency over an unmerged linear baseline is around 6% on Llama-3-8B, with throughput remaining stable across ranks. The authors argue that the extra SiLU operation is small relative to the matrix multiplications, and that the overhead is mostly memory-bound kernel-launch cost.
This is a reasonable deployment argument, but it has boundaries.
CeRA is not “free.” It is potentially affordable in systems where unmerged adapter execution is already normal. That is a narrower and more useful claim than saying non-linear adapters have no cost.
| Deployment setting | CeRA fit | Reason |
|---|---|---|
| Multi-tenant adapter serving | Stronger fit | Adapters may already be unmerged, reducing the relative penalty |
| Reasoning-heavy vertical workflows | Stronger fit | The paper’s gains are clearest on complex MATH-style reasoning |
| Edge inference | Weaker fit | Non-mergeability may be costly where memory bandwidth and latency are tight |
| Simple format/style adaptation | Unclear fit | LoRA may already be sufficient |
| Strict zero-latency merged deployment | Weak fit | CeRA cannot be merged like standard LoRA |
This is the practical replacement for the reader misconception. The choice is not “linear adapters are obsolete” or “non-mergeable adapters are impractical.” The real distinction is between deployment regimes where mergeability is essential and regimes where adapter flexibility is already part of the architecture.
What Cognaptus Would Infer for Business Teams
The paper directly shows three things: CeRA outperforms high-rank LoRA and DoRA on MATH pass@1 under the reported setup; CeRA’s spectral profile uses rank more broadly; and its non-linear design choices contribute to the result.
From that, we can infer several business-relevant lessons.
First, adapter selection should depend on task complexity. If the task is mostly formatting, classification, or simple domain adaptation, LoRA may remain the sensible default. It is proven, mergeable, and operationally simple. If the task requires multi-step reasoning, structured calculation, planning, or internal state tracking, adapter expressivity deserves more attention.
Second, teams should stop treating nominal rank as a sufficient capacity measure. Rank is budget. Effective rank is utilization. A high-rank adapter with a collapsed spectrum is not a high-capacity adapter in practice; it is a larger container with most of the shelves unused.
Third, spectral diagnostics can become part of fine-tuning evaluation. This is especially relevant for companies building repeatable model customization workflows. Instead of comparing only final validation loss or downstream accuracy, teams can inspect whether the adapter is actually using its allocated dimensions. If not, increasing rank may be the wrong intervention.
Fourth, infrastructure decisions should be made before adapter decisions. A company that insists on merged inference has different choices from a company building a multi-tenant adapter-serving platform. CeRA-like methods become more attractive when unmerged adapters are already operationally acceptable.
Here is the short business translation:
| Paper result | Business interpretation | Boundary |
|---|---|---|
| CeRA-64 beats LoRA-512 on MATH pass@1 | More rank is not always the best path to better reasoning | Shown on the paper’s selected model and datasets |
| CeRA has higher spectral utilization | Effective capacity matters more than nominal adapter size | Effective rank is diagnostic, not a complete success metric |
| Ablations support SiLU, dropout, and weight-level placement | The architectural details are not arbitrary | Exact best design may vary by model family |
| CeRA cannot be merged | Deployment architecture determines usefulness | Edge and strict low-latency systems may prefer mergeable adapters |
| CeRA uses LoRA-like hyperparameters | Potentially lower tuning burden | Needs broader validation across architectures and domains |
This is not a call to replace every LoRA pipeline tomorrow morning. That would be the kind of overreaction the AI industry produces when left unsupervised near a benchmark table.
It is a call to update the evaluation checklist.
The Boundaries: One Backbone, Selected Reasoning Tasks, One Architectural Bet
The paper is strongest when read as evidence for a mechanism, not as a universal product verdict.
The experiments focus on Llama-3-8B. That is a serious model, but it is still one model family and one scale point. The authors themselves note that future work should validate the capacity-expansion hypothesis across other architectures, including Mixture-of-Experts models.
The task evidence is also concentrated. SlimOrca, MathInstruct, GSM8K, and MATH are appropriate for studying instruction following and mathematical reasoning, but they do not cover every enterprise workload. A legal review model, a customer support model, a biomedical assistant, and a code repair system may stress different parts of the representation space.
The latency result is also context-specific. A 6% overhead compared with an unmerged linear baseline is useful evidence for multi-tenant serving, but it should not be casually transferred to every inference stack. Kernel fusion, batching, hardware, sequence length, adapter rank, and traffic patterns all matter.
Finally, the qualitative logistic-map example is illustrative. It helps explain state collapse, but it should not be treated as a benchmark by itself. Its value is pedagogical: it shows how a linear adapter can fail to update an internal trajectory even when a non-linear adapter keeps changing state. The quantitative evidence still carries the main weight.
The Real Shift: From Parameter Efficiency to Capacity Efficiency
PEFT began as a parameter-efficiency story. Train fewer weights. Store smaller adapters. Move faster.
CeRA pushes the conversation toward capacity efficiency: not only how many parameters are trained, but whether those parameters can express the transformations the task requires.
That distinction is important. A low-rank linear adapter can be parameter-efficient and capacity-limited at the same time. A high-rank LoRA adapter can be larger but still spectrally collapsed. A non-linear adapter can be less mergeable but more useful for reasoning-heavy tasks.
The trade-off is no longer simple:
- LoRA optimizes operational simplicity and mergeability.
- DoRA improves the linear adapter family through weight decomposition, but remains within a linear update paradigm.
- CeRA changes the functional class by adding non-linear capacity at the weight level.
The practical question is not “Which method is best?” That question is too broad to be useful. The better question is:
What kind of capacity does the downstream task actually require, and what serving constraints can the business tolerate?
For simple adaptation under strict latency constraints, LoRA remains hard to beat. For complex reasoning under flexible adapter-serving infrastructure, CeRA points to a more interesting frontier.
The linear ceiling is not the end of PEFT. It is the end of pretending that rank alone is a strategy.
And honestly, it had a good run.
Cognaptus: Automate the Present, Incubate the Future.
-
Hung-Hsuan Chen, “CeRA: Overcoming the Linear Ceiling of Low-Rank Adaptation via Capacity Expansion,” arXiv:2602.22911, version 5, April 3, 2026. https://arxiv.org/abs/2602.22911 ↩︎