LoRA

تُعد LoRA واحدة من أكثر طرق PEFT شيوعًا، وهي نقطة انطلاق جيدة إذا كنت تبدأ للتو في استخدام PEFT. تم تطويرها في الأصل للنماذج اللغوية الكبيرة، لكنها أصبحت طريقة تدريب شائعة للغاية لنماذج الانتشار (diffusion models) نظرًا لكفاءتها وفعاليتها.

التكيّف منخفض الرتبة (LoRA) هو أسلوب PEFT يقوم بتفكيك مصفوفة كبيرة إلى مصفوفتين أصغر منخفضتي الرتبة. وهذا يقلل بشكل كبير عدد المعلمات التي تحتاج إلى ضبط دقيق.

ملخص الورقة البحثية هو:

يتألف نموذج مهم في معالجة اللغة الطبيعية من التدريب المسبق على نطاق واسع على بيانات عامة، ثم التكيّف مع مهام أو مجالات محددة. ومع تدريب نماذج أكبر حجمًا، يصبح الضبط الدقيق الكامل، الذي يعيد تدريب جميع معاملات النموذج، أقل قابلية للتطبيق. فباستخدام GPT-3 175B كمثال، يُعد نشر نسخ مستقلة من النماذج المضبوطة بدقة، حيث تحتوي كل نسخة على 175 مليار معامل، مكلفًا بشكل غير مقبول. نقترح هنا التكيف منخفض الرتبة، أو LoRA، الذي يجمّد أوزان النموذج المدرَّب مسبقًا ويحقن مصفوفات تحليل رتبة قابلة للتدريب في كل طبقة من بنية Transformer، مما يقلل بشكل كبير عدد المعاملات القابلة للتدريب للمهام اللاحقة. مقارنةً بضبط GPT-3 175B بدقة باستخدام Adam، يمكن لـ LoRA تقليل عدد المعاملات القابلة للتدريب بمقدار 10,000 مرة، وتقليل متطلبات ذاكرة GPU بمقدار 3 مرات. يؤدي LoRA إلى جودة نموذج مماثلة أو أفضل من الضبط الدقيق على RoBERTa وDeBERTa وGPT-2 وGPT-3، على الرغم من امتلاكه عددًا أقل من المعاملات القابلة للتدريب، ومعدل إنتاجية تدريب أعلى، وبدون أي تأخير إضافي في الاستدلال، على عكس المحوِّلات (adapters). كما نقدم دراسة تجريبية حول نقص الرتبة في تكيّف نماذج اللغة، مما يسلّط الضوء على فعالية LoRA. نُصدر حزمة تسهّل دمج LoRA مع نماذج PyTorch، ونوفر تطبيقاتنا ونقاط فحص النماذج لـ RoBERTa وDeBERTa وGPT-2 في هذا الرابط.

تمثّل LoRA تحديثات الأوزان $\Delta W$ بمصفوفتين أصغر (تُسمى مصفوفات التحديث) عبر التحليل منخفض الرتبة. يمكن تدريب هذه المصفوفات الجديدة للتكيّف مع البيانات الجديدة مع الحفاظ على العدد الإجمالي للمعاملات منخفضًا. تبقى مصفوفة الأوزان الأصلية مجمّدة ولا تتلقى أي تحديثات إضافية. لإنتاج النتائج النهائية، يتم دمج الأوزان الأصلية مع الأوزان المُكيَّفة الإضافية. كما يمكنك دمج أوزان المُكيّف مع النموذج الأساسي للقضاء على زمن استجابة الاستدلال.

تتميز هذه الطريقة بعدد من المزايا:

• يجعل LoRA الضبط الدقيق أكثر كفاءة من خلال تقليل عدد المعاملات القابلة للتدريب بشكل كبير.
• تُحافظ الأوزان المُسبقة التدريب الأصلية على حالة التجميد، مما يعني أنه يمكنك امتلاك عدة نماذج LoRA خفيفة الوزن وقابلة للنقل لمهام مختلفة في المراحل اللاحقة، مبنية على أساسها.
• تُعد LoRA مستقلة عن الأساليب الأخرى الفعّالة من حيث المعاملات، ويمكن دمجها مع العديد منها.
• أداء النماذج المُحسَّنة باستخدام LoRA مماثل لأداء النماذج المُحسَّنة بالكامل.

مبدئيًا، يمكن تطبيق LoRA على أي مجموعة فرعية من مصفوفات الأوزان في الشبكة العصبية لتقليل عدد المعلمات القابلة للتدريب. ومع ذلك، من أجل البساطة وكفاءة أكبر في المعلمات، يُطبَّق LoRA عادةً على كتل الانتباه في نماذج Transformer فقط - وقد يستهدف طبقات أخرى أيضًا. يعتمد عدد المعلمات القابلة للتدريب الناتج في نموذج LoRA على حجم مصفوفات التحديث، والذي يحدده بشكل رئيسي الرتبة r وشكل مصفوفة الأوزان الأصلية.

يمكنك تهيئة المصفوفات منخفضة الرتبة مع وضع استخدامات مختلفة في الاعتبار - مثل الوعي بالمهمة (CorDA، EVA، Astra)، والتقارب الأسرع (PiSSA)، والتخفيف من آثار التكميم (LoftQ) - وذلك على سبيل المثال لا الحصر. اقرأ عن التهيئات المختلفة فيما يلي. التهيئة الافتراضية هي أن يكون LoRA عملية لا شيء (no-op)، ليتعلم سلوكًا جديدًا تدريجيًا دون التدخل كثيرًا في النموذج الموجود.

الاستخدام

يُحدَّد حجم مصفوفات التحديث منخفضة الرتبة بواسطة الرتبة أو r. كلما زادت الرتبة، زادت عدد المعاملات التي يتعيّن تدريبها في النموذج، لكن ذلك يعني أيضًا أن النموذج يتمتع بسعة تعلّم أكبر. في المثال التالي، ستستهدف مصفوفات الاستعلام والقيمة في كتل الانتباه. من بين المعاملات المهمة الأخرى التي يجب ضبطها: lora_alpha (عامل التوسيع)، وbias (ما إذا كان ينبغي تدريب none أو all أو معاملات انحياز LoRA فقط)، وmodules_to_save (الوحدات التي يجب تدريبها وحفظها بخلاف طبقات LoRA). جميع هذه المعاملات - وغيرها - موجودة في LoraConfig.

from peft import LoraConfig, get_peft_model

config = LoraConfig(
    r=16,
    lora_alpha=16,
    target_modules=["query", "value"],
    lora_dropout=0.1,
    bias="none",
    modules_to_save=["classifier"],
)
model = get_peft_model(model, config)
model.print_healthcheck()

نظرة عامة على الاختبارات

التهيئة

يتم التحكم في تهيئة أوزان LoRA عبر المعامل init_lora_weights في LoraConfig. افتراضياً، يهيّئ PEFT أوزان LoRA باستخدام Kaiming-uniform للوزن A وقيم صفرية للوزن B، مما يؤدي إلى تحويل هوية (identity transform) (نفس التنفيذ المرجعي).

بالنسبة لطبقات transformers.Conv1D، مثل الإسقاطات في GPT-2، استخدم fan_in_fan_out=True لأن أوزانها مخزنة على شكل (in_features, out_features) بدلاً من تخطيط nn.Linear. تستخدم مبادئات التهيئة القائمة على الأوزان المدعومة تخطيط Linear للتحليل، ثم تستعيد تخطيط التخزين عند تحديث الأوزان الأساسية. كما يستخدم تحجيم "stable" في LoRA-GA بُعد الإخراج بغض النظر عن تخطيط التخزين.

كما يمكن تمرير init_lora_weights="gaussian". وكما يوحي الاسم، يقوم هذا بتبديل الأوزان A باستخدام توزيع غاوسي والأصفار للوزن B (وهو الطريقة التي يستخدم بها Diffusers تهيئة أوزان LoRA).

from peft import LoraConfig

config = LoraConfig(init_lora_weights="gaussian", ...)

يوجد أيضًا خيار لتعيين init_lora_weights=False وهو مفيد لأغراض التصحيح واختبار الأخطاء. ينبغي أن يكون هذا هو الوقت الوحيد الذي تستخدم فيه هذا الخيار. عند اختيار هذا الخيار، يتم تهيئة أوزان LoRA بحيث لا تؤدي إلى تحويل هوية.

from peft import LoraConfig

config = LoraConfig(init_lora_weights=False, ...)

from torch import nn

from peft import LoraConfig, get_peft_model

model = nn.Sequential(
    nn.Linear(32, 32),
    nn.ReLU(),
    nn.Linear(32, 16),
)

config = LoraConfig(
    r=8,
    lora_alpha=8,
    target_modules=["0", "2"],
    init_lora_weights="nora",
    bias="none",
    lora_bias=False,
    use_rslora=False,
)
model = get_peft_model(model, config)
model.print_healthcheck()

from peft import LoraConfig
config = LoraConfig(init_lora_weights="pissa", ...)

lora_config = LoraConfig(init_lora_weights="pissa_niter_[number of iters]", ...)

from peft import LoraConfig
config = LoraConfig(init_lora_weights="mica", r=16, target_modules=["q_proj", "v_proj"], ...)

@torch.no_grad()
def run_model():
    # Assume `model` and `dataset` is in context...
    model.eval()
    for batch in dataset:
        model(**batch)


corda_config = CordaConfig(
    corda_method="kpm",
)
lora_config = LoraConfig(
    init_lora_weights="corda",
    corda_config=corda_config,
)
preprocess_corda(model, lora_config, run_model=run_model)
peft_model = get_peft_model(model, lora_config)

@torch.no_grad()
def run_model():
    # Assume `model` and `dataset` is in context...
    model.eval()
    for batch in dataset:
        model(**batch)


from peft.tuners.lora import AstraConfig, preprocess_astra

astra_config = AstraConfig()
lora_config = LoraConfig(
    init_lora_weights="astra",
    target_modules=["q_proj", "v_proj"],
    astra_config=astra_config,
)
preprocess_astra(model, lora_config, run_model=run_model)
peft_model = get_peft_model(model, lora_config)

from peft import LoraConfig
config = LoraConfig(init_lora_weights="olora", ...)

from peft import LoraConfig, EvaConfig
peft_config = LoraConfig(
    init_lora_weights = "eva",
    eva_config = EvaConfig(rho = 2.0),
    ...
)

peft_model = get_peft_model(model, peft_config, low_cpu_mem_usage=True)

initialize_lora_eva_weights(peft_model, dataloader)

from peft import LoraConfig

config = LoraConfig(use_rslora=True, ...)

from peft.tuners.lora import preprocess_loraga

def train_step():
    """Run forward and backward passes for gradient estimation."""
    dataloader_iter = iter(grad_dataloader)
    for _ in range(N):
        batch = next(dataloader_iter)
        batch = {k: v.to(device) for k, v in batch.items()}
        outputs = model(**batch)
        loss = outputs.loss
        loss.backward()

preprocess_loraga(model, lora_config, train_step)

التدريب

تُظهر هذه القسم كيفية التعامل مع سيناريوهات تدريب أكثر تعقيدًا، بدلاً من مجرد تطبيق مُكيّف منخفض الرتبة على النموذج وإمداده بالبيانات.

التدريب بأسلوب QLoRA

تضيف إعدادات LoRA الافتراضية في PEFT أوزانًا قابلة للتدريب إلى طبقات الاستعلام والقيمة في كل كتلة انتباه. لكن QLoRA، الذي يضيف أوزانًا قابلة للتدريب إلى جميع الطبقات الخطية في نموذج الترانسفورمر، يمكن أن يوفر أداءً مساويًا لنموذج مُعاد تدريبه بالكامل. لتطبيق LoRA على جميع الطبقات الخطية، كما في QLoRA، اضبط target_modules="all-linear" (وهو أسهل من تحديد الوحدات الفردية بالاسم، والتي قد تختلف اعتمادًا على البنية).

config = LoraConfig(target_modules="all-linear", ...)

لمزيد من المعلومات حول كيفية تطبيق التكميم على محولات PEFT، يُرجى الرجوع إلى دليل التكميم.

نسخ الطبقات بكفاءة في الذاكرة باستخدام LoRA

من الأساليب المستخدمة لتحسين أداء النماذج توسيع نموذج عن طريق تكرار طبقاته لبناء نموذج أكبر انطلاقًا من نموذج مُدرَّب مسبقًا بحجم محدد. على سبيل المثال، زيادة نموذج بحجم 7B ليصبح 10B كما هو موصوف في ورقة SOLAR. يدعم PEFT LoRA هذا النوع من التوسيع بطريقة فعّالة من حيث الذاكرة، وتتيح إمكانية إجراء ضبط دقيق إضافي باستخدام محولات LoRA المربوطة بالطبقات بعد تكرارها. لا تستهلك الطبقات المكررة ذاكرة إضافية لأنها تتشارك الأوزان الأساسية، لذا فإن الذاكرة الإضافية المطلوبة هي فقط ذاكرة أوزان المحولات. لاستخدام هذه الميزة، أنشئ إعدادًا يحتوي على الحجة layer_replication.

config = LoraConfig(layer_replication=[[0,4], [2,5]], ...)

بافتراض أن النموذج الأصلي كان يحتوي على 5 طبقات [0, 1, 2 ,3, 4]، فإن هذا سيؤدي إلى إنشاء نموذج يحتوي على 7 طبقات مرتبة على النحو التالي [0, 1, 2, 3, 2, 3, 4]. يتبع هذا أسلوب الدمج المار عبر mergekit حيث تُرصّ تسلسلات الطبقات المحددة كسلاسل تبدأ من قيمة شاملة وتنتهي بقيمة حصرية لبناء النموذج النهائي. تحصل كل طبقة في النموذج النهائي على مجموعة مميزة من محولات LoRA.

Fewshot-Metamath-OrcaVicuna-Mistral-10B هو مثال على نموذج تم تدريبه باستخدام هذه الطريقة على Mistral-7B الموسّع إلى 10B. يُظهر adapter_config.json إعدادًا نموذجيًا لمُكيّف LoRA يطبّق هذه الطريقة للضبط الدقيق.

تحكم دقيق في الرتب وألفا (المقياس)

بشكل افتراضي، ستتمتع جميع الطبقات المستهدفة بواسطة LoRA بنفس الرتبة r ونفس قيمة lora_alpha (والتي تحدد مقياس LoRA)، وذلك تبعاً لما تم تحديده في LoraConfig. ومع ذلك، قد ترغب في بعض الحالات في تحديد قيم مختلفة لطبقات مختلفة. وهذا ممكن عن طريق تمرير الحججين rank_pattern وalpha_pattern إلى LoraConfig. يجب أن تكون هذه الحجج قواميس يكون المفتاح فيها اسم الطبقة والقيمة فيها قيمة الرتبة/ألفا. يمكن أن تكون المفاتيح تعبيرات منتظمة (regex). وستتخذ جميع طبقات LoRA التي لم يتم ذكرها صراحةً في rank_pattern وalpha_pattern قيم r وlora_alpha الافتراضية.

لإعطاء مثال، لنفترض أن لدينا نموذجاً له البنية التالية:

>>> print(model)
Outer(
  (foo): Linear(...)
  (module): Middle(
    (foo): Linear(...)
    (foobar): Linear(...)
    (module): Inner(
      (foo): Linear(...)
      (barfoo): Linear(...)
    )
  )
)

• rank_pattern={"foo": 42} سيُطابق جميع طبقات foo الثلاث. ولا يُطابق أيٌّ من foobar أو barfoo.
• rank_pattern={"^foo": 42} سيُطابق طبقة foo في النموذج فقط، لكنه لن يطابق module.foo أو module.module.foo. والسبب في ذلك أن ^ تعني “بداية السلسلة” عند استخدام التعبيرات النمطية، ولا تبدأ سوى foo بـ "foo"، بينما تحمل أسماء الطبقات الأخرى بادئات.
• rank_pattern={"^module.foo": 42} يطابق module.foo فقط، لكنه لا يطابق module.module.foo، لنفس السبب.
• rank_pattern={"module.foo": 42} يطابق كلًا من module.foo وmodule.module.foo، لكنه لا يطابق foo.
• يطابق rank_pattern={"^foo": 42, "^module.module.foo": 55} foo وmodule.module.foo على التوالي، لكنه لا يطابق module.foo.
• لا حاجة إلى تحديد $ لتمييز نهاية التطابق، حيث يضيف PEFT ذلك تلقائيًا.

تنطبق المنطقية نفسها على alpha_pattern. إذا كنت متردداً، فلا تحاول استخدام تعبيرات منتظمة معقدة — بل مرر الاسم الكامل لكل وحدة ذات رتبة/ألفا مختلفة، مع وضع بادئة ^ قبله، وستكون النتيجة جيدة.

كشف الوحدات المستهدفة القابلة للتطبيق تلقائيًا

يُنفّذ peft.helpers.KappaTuneSelector استراتيجية اختيار الأهداف القائمة على عدد الشرط (condition number) الواردة في ورقة KappaTune. يقوم بفحص كل وحدة nn.Linear، وللموديلات التي تُخزَّن فيها أوزان خبراء MoE كمُتجهات nn.Parameter ثلاثية الأبعاد مدمجة (مثل Llama-4 وQwen3-MoE)، يفحص تلك المعاملات أيضاً، ويحسب عدد شرط المصفوفة κ = σ_max / σ_min لكل منها، ثم يختار الطبقات الأكثر أيزوتروبياً (أقل قيمة لـ κ). تعمل هذه الطبقات الأيزوتروبية كمرشحات مثالية للضبط الدقيق، لأن طبيعتها عالية الإنتروبيا تتيح لها امتصاص المعلومات الجديدة بسهولة أكبر، مع إبقاء الطبقات المتخصصة غير الأيزوتروبية كما هي للتخفيف من النسيان الكارثي أثناء التعلم المستمر.

استخدم peft.helpers.find_kappa_target_modules() كسطر واحد للحصول على target_modules المثالية لـ LoraConfig:

from peft import LoraConfig, get_peft_model
from peft.helpers import find_kappa_target_modules

model = AutoModelForCausalLM.from_pretrained("mistralai/Mixtral-8x7B-Instruct-v0.1")

targets = find_kappa_target_modules(model, top_p=0.2)
config = LoraConfig(
    target_modules=targets["target_modules"],
    target_parameters=targets["target_parameters"] if stable_modules_dic["target_parameters"] else None,
    r=64,
    lora_alpha=32,
    task_type="CAUSAL_LM",
)
peft_model = get_peft_model(model, config)

راجع مثالًا كاملًا هنا.

استهداف nn.Parameter مباشرة

بشكل عام، ينبغي استخدام target_modules لاستهداف الوحدة (مثل nn.Linear). ومع ذلك، في بعض الظروف، لا يكون ذلك ممكناً. على سبيل المثال، في العديد من طبقات خليط الخبراء (MoE) في HF Transformers، يتم استخدام nn.Parameter بدلاً من nn.Linear. عادةً ما يعيد PEFT كتابة طريقة forward الخاصة بـ LoRA، لكن في حالة nn.Parameter، لا توجد طريقة من هذا النوع. لذلك، لتطبيق LoRA على ذلك المعامل، يجب استهدافه باستخدام target_parameters. كمثال، بالنسبة إلى Llama4، يمكنك تمرير: target_parameters=['feed_forward.experts.gate_up_proj', 'feed_forward.experts.down_proj].

لاحظ أنه عند استهداف معاملات الخبراء، يمكن أن يضيف PEFT عبئًا تشغيليًا كبيرًا. والسبب في ذلك أن PEFT يُنشئ دائمًا مساهمة LoRA لكل خبير حتى لو كان عدد الخبراء المطلوب صغيرًا. أثناء التدريب، يكون هذا الأمر أقل أهمية، لأن نسبة كبيرة من الخبراء تُفعَّل عادةً مرة واحدة على الأقل على مدار التسلسل. ومع ذلك، أثناء الاستدلال، يُستخدم عادةً ذاكرة KV، وبالتالي نحتاج إلى حساب الرمز الأخير فقط، مما يعني أن عددًا صغيرًا من الخبراء فقط يُفعَّل. لذلك، يمكن أن يؤدي استخدام LoRA على طبقات MoE إلى تباطؤ كبير في وقت الاستدلال. لذا، يُوصى بدمج الأوزان (model.merge_adapter() أو model = model.merge_and_unload()). وهذا يُزيل عبء PEFT.

يمكن العثور على تحقيق أكثر تفصيلاً في هذه المسألة في طلب الدمج هذا الخاص بتحسين MoE.

ملاحظات

• حاليًا، يسمح هذا الحُجج باستهداف معاملات nn.Parameter ثنائية الأبعاد أو ثلاثية الأبعاد. ويُفترض أنه في حالة المعامل ثلاثي الأبعاد، فإن البُعد صفر هو بُعد الخبير.
• تُؤيَّد عدة محوِّلات LoRA (المُضافة عبر model.add_adapter أو model.load_adapter) التي تستخدم target_parameters، لكن يجب أن تستهدف جميعها نفس مجموعة المعاملات.

معاملات خبراء MoE وvLLM

تخزّن بعض نماذج MoE في Transformers أوزان الخبراء كمُتجهات nn.Parameter (غالبًا ثلاثية الأبعاد)، وليس كوحَدات nn.Linear. لتطبيق LoRA على تلك الخبراء، استخدم target_parameters واضبط رتبة لكل طبقة باستخدام rank_pattern:

num_experts = getattr(model.config, "num_local_experts", None) or model.config.num_experts
effective_r = max(1, r // num_experts)
config = LoraConfig(
    r=r,
    lora_alpha=32,
    target_modules=["q_proj", "v_proj"],
    target_parameters=[
        # Mixtral / Qwen3-MoE / GPT-OSS
        "mlp.experts.gate_up_proj",
        "mlp.experts.down_proj",
        # Llama4
        # "feed_forward.experts.gate_up_proj",
        # "feed_forward.experts.down_proj",
    ],
    rank_pattern={
        "experts.gate_up_proj": effective_r,
        "experts.down_proj": effective_r,
    },
)

يُبقي هذا الميزانية الإجمالية لمعاملات LoRA مماثلة لطبقات الكثافة (انظر LoRA Without Regret من Schulman وآخرون). وتستخدم وحدات غير الخبراء الترتيب الافتراضي r.

يمكن إجراء الاستدلال المُسرَّع باستخدام النموذج المُحسَّن، على سبيل المثال، عبر vLLM الذي يدعم طبقات خبراء MoE المدمجة منذ الإصدار v0.11.2.

تدريب الرموز بكفاءة إلى جانب LoRA

تدعم محولات PEFT LoRA إضافة رموز جديدة عبر المعامل trainable_token_indices. وهذا يتيح ضبط رموز أخرى بالتوازي مع ضبط طبقات محددة. يتم تدريب الرموز المحددة فقط بينما تبقى جميع الرموز الأخرى دون تغيير. يوفر هذا الأسلوب الذاكرة ولا يتخلص من السياق المكتسب من تمثيلات الرموز الموجودة، على عكس تدريب مصفوفة التمثيل بأكملها. يستخدم هذا الأسلوب داخليًا طبقة TrainableTokensModel.

# for layer 'embed_tokens'
config = LoraConfig(trainable_token_indices=[idx_1, idx_2, ...], ...)

# specific embedding layer
config = LoraConfig(trainable_token_indices={'emb_tokens': [idx_1, idx_2, ...]}, ...)

في المقطع أدناه، نُظهر كيفية إضافة رموز جديدة إلى النموذج وكيفية تدريبه جنبًا إلى جنب مع الطبقات الأخرى في النموذج.

from transformers import AutoTokenizer, AutoModelForCausalLM
from peft import get_peft_model, LoraConfig

base_model = AutoModelForCausalLM.from_pretrained("mistralai/Mistral-7B-v0.1")
tokenizer = AutoTokenizer.from_pretrained("mistralai/Mistral-7B-v0.1")

# we define our new tokens and add them to the tokenizer as special tokens
special_tokens = ['<|start_think|>', '<|stop_think|>']
tokenizer.add_special_tokens({'additional_special_tokens': special_tokens})

# make room for new tokens in the embedding matrix if it isn't big enough already
base_model.resize_token_embeddings(max(len(tokenizer), base_model.model.embed_tokens.num_embeddings))

# typical LoRA config with `trainable_token_indices` targeting embedding layer `embed_tokens`
# and specifically our new tokens we just added
lora_config = LoraConfig(
    target_modules='all-linear',
    trainable_token_indices={'embed_tokens': tokenizer.convert_tokens_to_ids(special_tokens)},
)
peft_model = get_peft_model(base_model, lora_config)

# proceed to train the model like normal
[...]

تُحفظ أوزان الرموز كجزء من حالة القاموس (state dict) الخاص بالمُكيّف (adapter) إلى جانب أوزان LoRA. كان التدريب الكامل (Full fine-tuning) وحفظ مصفوفة التضمين (embedding matrix) سيؤديان إلى تخزين ملف أكبر بكثير.

لإعطاء فكرة تقريبية عن مقدار ذاكرة VRAM التي يمكن توفيرها، أُجري مقارنة أولية على المثال أعلاه بين تدريب مصفوفة التضمين بالكامل (modules_to_save=["embed_tokens"])، واستخدام LoRA لمصفوفة التضمين (target_modules=[..., "embed_tokens"]، رتبة 32) والرموز القابلة للتدريب (trainable_token_indices=[...]، 6 رموز):

ربط الأوزان

تستخدم العديد من نماذج اللغة السببية ربط الأوزان، حيث تتشارك وزنتان أو أكثر في نفس المعلمات الأساسية. في الحالة الأكثر شيوعاً، تتشارك أوزان التضمين المدخل (embed_tokens) وأوزان الإسقاط المخرج (lm_head) في نفس المصفوفة. والسبب في ذلك هو أنه يقلل من عدد المعلمات ويحافظ عادةً على جودة النموذج.

ليس من الواضح دائمًا كيف يتعامل PEFT مع هذه الأوزان المرتبطة عندما تكون مستهدفة للضبط الدقيق. فيما يتعلق بـ LoRA، يتحكم ensure_weight_tying في LoraConfig فيما إذا كان ينبغي لـ PEFT الحفاظ صراحةً على ارتباط تحديثات جانب المُكيّف (adapter) لتلك الطبقات. عمليًا، يمكن أن يؤثر ذلك على modules_to_save وtarget_modules وtrainable_token_indices. لاحظ أن هذه المنطقية تعتمد جزئيًا على العرف فيما يتعلق بتسمية الطبقات ("embed_tokens"، "lm_head") ولا يمكن ضمان عمل صحيح إذا لم تُستخدم تلك الأعراف.

تلخص الجداول أدناه السلوك المتوقع.

modules_to_save

target_modules

trainable_token_indices

بالنسبة للرموز القابلة للتدريب، لدينا تعقيد إضافي يتمثل في أنه حتى لو كانت رأس النموذج اللغوي والتضمينات مرتبطة ببعضها، فقد أريد كمستخدم ضبط رموز مختلفة عليها. لذلك، في الجدول أدناه، نميّز بين ضبط الرموز نفسها وضبط رموز مختلفة.

بالنسبة للمستخدمين، يعني هذا:

• بشكل عام، إذا كنت ترغب في ضبط الأوزان المرتبطة مع الحفاظ على ارتباطها، فمرّر ensure_weight_tying=True.
• إذا كانت أوزان النموذج الأساسي غير مترابطة، فلا يمكن لـensure_weight_tying=True فرض الترابط، بل يُصدر تحذيرًا فقط.
• بالنسبة إلى trainable_token_indices، يجب أن تستخدم الطبقات المرتبطة نفس فهارس الرموز عندما يكون ensure_weight_tying=True.

المحسّنات

يمكن أن يتضمن تدريب LoRA اختيارياً محسّنات (Optimizers) مخصصة لأغراض خاصة. حالياً، يدعم PEFT كل من LoRA-FA وLoRA+ وLoRA المُسبَق الشرطية ريمانياً (Riemannian-preconditioned LoRA).

مُحسِّن LoRA-FA

يمكن أن يكون تدريب LoRA أكثر فعالية وكفاءة باستخدام LoRA-FA، كما هو موصوف في LoRA-FA. يقلل LoRA-FA من استهلاك ذاكرة التفعيل عن طريق تثبيت المصفوفة A وضبط المصفوفة B فقط. أثناء التدريب، يتم تحسين تدرج B لتقريب تدرج الضبط الدقيق الكامل للمعاملات. علاوة على ذلك، لا يتأثر استهلاك الذاكرة في LoRA-FA بالرتبة (بما أنه يمحو تفعيل $A$)، وبالتالي يمكنه تحسين الأداء عن طريق زيادة رتبة lora دون زيادة استهلاك الذاكرة.

from peft import LoraConfig, get_peft_model
from peft.optimizers import create_lorafa_optimizer
from transformers import Trainer, get_cosine_schedule_with_warmup

base_model = AutoModelForCausalLM.from_pretrained("meta-llama/Meta-Llama-3-8B-Instruct")

config = LoraConfig(...)
model = get_peft_model(base_model, config)

optimizer = create_lorafa_optimizer(
    model=model,
    r=128,
    lora_alpha=32,
    lr=7e-5,
)

scheduler = get_cosine_schedule_with_warmup(
    optimizer,
    num_warmup_steps=100,
    num_training_steps=1000,
)

trainer = Trainer(
    ...,
    optimizers=(optimizer, scheduler),
)

LoRA+ المحسّن لـ LoRA

يمكن تحسين تدريب LoRA باستخدام LoRA+، الذي يستخدم معدلات تعلم مختلفة لمصفوفات المحوّل A و B، وقد ثبت أنه يزيد سرعة الضبط الدقيق حتى مرتين والأداء بنسبة 1-2%.

from peft import LoraConfig, get_peft_model
from peft.optimizers import create_loraplus_optimizer
from transformers import Trainer
import bitsandbytes as bnb

base_model = ...
config = LoraConfig(...)
model = get_peft_model(base_model, config)

optimizer = create_loraplus_optimizer(
    model=model,
    optimizer_cls=bnb.optim.Adam8bit,
    lr=5e-5,
    loraplus_lr_ratio=16,
)
scheduler = None

...
trainer = Trainer(
    ...,
    optimizers=(optimizer, scheduler),
)

LoRA المُسبَق الشرط بطريقة ريمان

يمكن تحسين تدريب LoRA باستخدام مُهيِّئ ريمانّي، كما هو موصوف في LoRA المُهيَّأ ريمانّيًا. في كل خطوة مُحسِّن، تُضرب تدرّجات مصفوفات LoRA $A$ و $B$ بـ $r \times r$ مُهيِّئ يعيد مقياس التدرّج الإقليدي نحو الاتجاه الريمانّي (اتجاه التدرّج المُقيَّس) على متعدد الأشكال لمصفوفة الرتبة المنخفضة، مما يحسّن شروط التحديث ويمكن أن يحسّن التقارب. وبما أن المُهيِّئ بحجم $r \times r$، فإن تكاليفه في الذاكرة والوقت التشغيلي صغيرة بالنسبة لرتبة LoRA. create_riemannian_optimizer يغلّف أي فئة مُحسِّن أساسية (مثل torch.optim.AdamW أو torch.optim.SGD): تُحدَّث المعاملات غير LoRA بواسطة المُحسِّن الأساسي دون تغيير، ولا يُخضع للمُهيِّئة سوى nn.Linear-طبقات LoRA ذات شكلlora_A / lora_B) يُخضع للمُهيِّئة.

from peft import LoraConfig, get_peft_model
from peft.optimizers import create_riemannian_optimizer
from transformers import Trainer, get_cosine_schedule_with_warmup
import torch

base_model = AutoModelForCausalLM.from_pretrained("meta-llama/Meta-Llama-3-8B-Instruct")

config = LoraConfig(...)
model = get_peft_model(base_model, config)

optimizer = create_riemannian_optimizer(
    model=model,
    optimizer_cls=torch.optim.AdamW,
    lr=5e-5,
    reg=1e-2,
)

scheduler = get_cosine_schedule_with_warmup(
    optimizer,
    num_warmup_steps=100,
    num_training_steps=1000,
)

trainer = Trainer(
    ...,
    optimizers=(optimizer, scheduler),
)

reg هو حد تخميد يُضاف إلى $r \times r$ مصفوفة القطر قبل العكس؛ فهو يُثبّت المُسبِّق عندما يكون عامل LoRA (قريبًا من) النقص في الرتبة.

التدريب اللاحق

تُظهر هذه القسم طرق المعالجة اللاحقة المحتملة للمُكيِّفات المُدرَّبة.

دمج أوزان LoRA في النموذج الأساسي

While LoRA is significantly smaller and faster to train, you may encounter latency issues during inference due to separately loading the base model and the LoRA adapter. To eliminate latency, use the merge_and_unload() function to merge the adapter weights with the base model. This allows you to use the newly merged model as a standalone model. The merge_and_unload() function doesn’t keep the adapter weights in memory.

فيما يلي مخطط يوضح الحدس وراء دمج محوّل LoRA:

نُظهر في المقاطع أدناه كيفية تشغيل ذلك باستخدام PEFT.

from transformers import AutoModelForCausalLM
from peft import PeftModel

base_model = AutoModelForCausalLM.from_pretrained("mistralai/Mistral-7B-v0.1")
peft_model_id = "alignment-handbook/zephyr-7b-sft-lora"
model = PeftModel.from_pretrained(base_model, peft_model_id)
model = model.merge_and_unload()

من المهم تعيين النموذج المُعاد إلى متغير واستخدامه، إذ إن merge_and_unload() ليست عملية تتم في الموقع. إذا كنت بحاجة إلى الاحتفاظ بنسخة من الأوزان حتى تتمكن من إلغاء دمج المُكيّف لاحقًا أو حذفه وتحميل مُكيّفات أخرى، فيجب عليك استخدام دالة merge_adapter() بدلاً من ذلك. الآن لديك خيار استخدام unmerge_adapter() لإرجاع النموذج الأساسي.

from transformers import AutoModelForCausalLM
from peft import PeftModel

base_model = AutoModelForCausalLM.from_pretrained("mistralai/Mistral-7B-v0.1")
peft_model_id = "alignment-handbook/zephyr-7b-sft-lora"
model = PeftModel.from_pretrained(base_model, peft_model_id)
model.merge_adapter()

# unmerge the LoRA layers from the base model
model.unmerge_adapter()

في النموذج المُكمَّم، لا تكون عملية إلغاء الدمج دقيقة: فعملية الدمج تعيد تكميم الوزن الأساسي، وقد تتراكم أخطاء التقريب مع تكرار دورات الدمج وإلغاء الدمج. راجع دمج المُكيّفات في الأوزان المُكمَّمة.

إذا كانت عدة محوِّلات نشطة وتم دمج بعضها فقط، فإن المحوِّلات غير المدمجة لن تُطبَّق بصمت. سيتغير هذا السلوك في PEFT v1.0. راجع دمج بعض المحوِّلات النشطة فقط.

تُعدّ دالة add_weighted_adapter() مفيدة لدمج عدة LoRAs في مُكيّف جديد بناءً على مخطط أوزان يحدده المستخدم في معامل weights. أدناه مثال شامل من البداية إلى النهاية.

First load the base model:

from transformers import AutoModelForCausalLM
from peft import PeftModel
import torch

base_model = AutoModelForCausalLM.from_pretrained(
    "mistralai/Mistral-7B-v0.1", dtype=torch.float16, device_map="auto"
)

ثم نحمّل المُكيّف الأول:

peft_model_id = "alignment-handbook/zephyr-7b-sft-lora"
model = PeftModel.from_pretrained(base_model, peft_model_id, adapter_name="sft")

ثم حمّل مُكيّفًا مختلفًا وادمجه مع الأول:

weighted_adapter_name = "sft-dpo"
model.load_adapter("alignment-handbook/zephyr-7b-dpo-lora", adapter_name="dpo")
model.add_weighted_adapter(
    adapters=["sft", "dpo"],
    weights=[0.7, 0.3],
    adapter_name=weighted_adapter_name,
    combination_type="linear"
)
model.set_adapter(weighted_adapter_name)

توجد عدة طرق مدعومة لـcombination_type. راجع التوثيق لمزيد من التفاصيل. لاحظ أن استخدام “svd” كـcombination_type غير مدعوم عند استخدام torch.float16 أو torch.bfloat16 كنوع البيانات.

الآن، قم بتنفيذ الاستدلال:

device = torch.accelerator.current_accelerator().type if hasattr(torch, "accelerator") else "cuda"

tokenizer = AutoTokenizer.from_pretrained("mistralai/Mistral-7B-v0.1")

prompt = "Hey, are you conscious? Can you talk to me?"
inputs = tokenizer(prompt, return_tensors="pt")
inputs = {k: v.to(device) for k, v in inputs.items()}

with torch.no_grad():
    generate_ids = model.generate(**inputs, max_length=30)
outputs = tokenizer.batch_decode(generate_ids, skip_special_tokens=True, clean_up_tokenization_spaces=False)[0]
print(outputs)

استعادة أداء النموذج الأساسي عبر تقليل أبعاد المتسلل

تجادل الورقة LoRA vs Full Fine-tuning: An Illusion of Equivalence بأن تدريب LoRA يُدخل أبعادًا إضافية إلى الأوزان التي لا تشترك كثيرًا مع الأوزان المتعلمة مسبقًا، مما يؤدي إلى نسيان المعلومات المتعلمة بالفعل. تنفّذ PEFT الإجراء التخفيفي المقترح في peft.tuners.lora.intruders.reduce_intruder_dimension().

ستقوم آلية التخفيف بأخذ نموذج PEFT يحتوي على LoRA محمّل، وإنشاء مُكيّف جديد معدّل يُحمَّل إلى جانب المُكيّف الحالي ليصبح المُكيّف النشط.

مثال على الاستخدام:

from peft.tuners.lora.intruders import reduce_intruder_dimension

peft_model = AutoPeftModelForCausalLM.from_pretrained('hubnemo/llama-3.2b-metamathqa-lora64')

reduce_intruder_dimension(
    peft_model,
    mitigation_lambda=0.75,
)

peft_model.generate(...)

توجد بعض المعلمات الفائقة التي يمكن استخدامها لضبط فعالية التخفيف، ولكن، كما هو موضح في الشكل 8 من الورقة البحثية، سيكون هناك دائمًا تنازل بين دقة المهمة التي يتعلمها المُكيّف (adapter) ونسيان معرفة النموذج الأساسي. سيقوم التخفيف بإزالة المعلومات من المُكيّف لتقليل الأثر على نسيان المعرفة السابقة، لكن هذا يعني أيضًا أن بعض المعلومات المتعلقة بالمهمة التي تعلمها المُكيّف ستُفقد أيضًا.

في حين أن الإعدادات الافتراضية مُعدّة لتقديم توازن جيد بين العاملين، إلا أنه لا يُكفَل أن تبقى هذه الإعدادات مناسبة لمُكيّفك ونموذجك وبياناتك، لذا من الحكمة أن يكون لديك معيار مرجعي جاهز لقياس الأثر.

تحميل المُكيّفات

يمكن تحميل المُكيّفات (Adapters) على نموذج مُدرَّب مسبقًا باستخدام load_adapter()، وهو أمر مفيد لتجربة مُكيّفات مختلفة لم يتم دمج أوزانها. اضبط أوزان المُكيّف النشط باستخدام دالة set_adapter().

from transformers import AutoModelForCausalLM
from peft import PeftModel

base_model = AutoModelForCausalLM.from_pretrained("mistralai/Mistral-7B-v0.1")
peft_model_id = "alignment-handbook/zephyr-7b-sft-lora"
model = PeftModel.from_pretrained(base_model, peft_model_id)

# load different adapter
model.load_adapter("alignment-handbook/zephyr-7b-dpo-lora", adapter_name="dpo")

# set adapter as active
model.set_adapter("dpo")

لإرجاع النموذج الأساسي، يمكنك استخدام unload() لتفريغ جميع وحدات LoRA أو استخدام delete_adapter() لحذف المُكيّف بالكامل. لاحظ أن unload() ليست عملية تتم في الموقع (in-place)، لذا تذكّر بتعيين النموذج المُعاد إلى متغير واستخدامه.

# unload adapter
model = model.unload()

# delete adapter
model.delete_adapter("dpo")

توازي الموتر

يدعم LoRA توازي الموترات (TP) كما يوفره Transformers. عند تحميل نموذج أساسي مع tp_plan، يكتشف PEFT تلقائياً إعدادات توازي الموترات لكل وحدة مستهدفة ويضيف الخطافات المناسبة إلى أوزان محوّل LoRA حتى تشارك بشكل صحيح في حساب توازي الموترات.

يتطلب دعم التوازي في الموترات (Tensor Parallelism) لـ LoRA transformers >= 5.4.0. يتطلب واجهة برمجة التطبيقات (API) للتوازي في الموترات (Tensor Parallelism) القائمة على DTensor peft >= 0.21.1 وtransformers >= 5.17.0.

يكون الاستخدام مطابقًا تمامًا لتدفق عمل LoRA القياسي — ما عليك سوى تحميل النموذج الأساسي مع tp_plan قبل تغليفه بواسطة PEFT:

from transformers import AutoModelForCausalLM
from peft import get_peft_model, LoraConfig

model = AutoModelForCausalLM.from_pretrained("meta-llama/Llama-3.1-8B", tp_plan="auto")
lora_config = LoraConfig(r=16, target_modules=["q_proj", "v_proj"])
model = get_peft_model(model, lora_config)

تعمل عمليات الحفظ والتحميل بشكل اعتيادي عبر save_pretrained / from_pretrained. يقوم PEFT بجمع أوزان المُكيِّف المقسَّم مرة أخرى إلى متجهات كاملة قبل الحفظ، مما يجعل نقاط التفتيش قابلة للنقل ومستقلة عن عدد الأجهزة المستخدمة أثناء التدريب.

إذا طبّقت توازي الموترات دون خطة TP، على سبيل المثال باستخدام parallelize_module الخاص بـ PyTorch، فإن PEFT يحدّد حجم أوزان LoRA لطبقة nn.Linear المقسّمة إلى حجم شحنتها المحلية إذا كان لمشبك الجهاز الخاص بالوزن بُعد باسم "tp"، وإلا فسيكون الحجم مطابقًا لشكل الطبقة الكاملة (كما هو الحال مع FSDP2). لا يضيف PEFT خطافات TP إلى هذه أوزان LoRA ولا يجمعها عند الحفظ. إذا كان بُعد مشبك TP لديك يحمل اسمًا مختلفًا، أضِفه قبل إنشاء نموذج PEFT:

from peft.utils.integrations import TpMeshDimRegistry

TpMeshDimRegistry.register("tp_dim")

الاستدلال

تُبرز هذه القسم ما يمكنك القيام به أثناء وقت الاستدلال باستخدام LoRA، مثل فك ارتباط المُكيّف.

لورا المُفعَّلة (aLoRA)

LoRA المُفعَّل (aLoRA) هو معمارية مُكيِّف منخفض الرتبة لنماذج اللغة السببية يعيد استخدام ذاكرة KV الموجودة في النموذج الأساسي لتحقيق استدلال أكثر كفاءة. يناسب هذا النهج خطوط الأنابيب التي تعتمد على النموذج الأساسي لمعظم المهام/التوليدات، لكنها تستخدم مُكيِّف aLoRA أو أكثر لأداء مهام متخصصة ضمن السلسلة. على سبيل المثال، التحقق من مخرجات النموذج الأساسي المولَّدة أو تصحيحها. في هذه الإعدادات، يمكن تسريع أوقات الاستدلال بمقدار مرتبة أو أكثر. لمزيد من المعلومات حول aLoRA والعديد من حالات الاستخدام، راجع ورقة aLoRA.

تقوم هذه التقنية بمسح آخر ظهور لسلسلة الاستدعاء (alora_invocation_tokens) في كل مدخل (ويمكن أن تكون هذه السلسلة قصيرة حتى رمز واحد). وتفعّل أوزان المحوّل (adapter) على الرموز بدءًا من بداية سلسلة الاستدعاء. كما تخضع المدخلات اللاحقة لسلسلة الاستدعاء للتكييف، وستستخدم جميع الرموز المولّدة الأوزان المُكيَّفة. وتُترك الأوزان على الرموز السابقة دون تكييف، مما يجعل ذاكرة التخزين المؤقت (cache) لتلك الرموز قابلة للاستبدال مع ذاكرة التخزين المؤقت للنموذج الأساسي بسبب قناع الانتباه السببي في النماذج اللغوية السببية. طريقة الاستخدام مشابهة جدًا لـ LoRA القياسي. والفرق الجوهري هو أنه يجب تحديد سلسلة الاستدعاء عند إنشاء المحوّل:

from peft import LoraConfig

config = LoraConfig(alora_invocation_tokens=alora_invocation_tokens, task_type="CAUSAL_LM", ...)

alora_invocation_tokens هو قائمة من معرفات الرموز الصحيحة. بالنظر إلى سلسلة استدعاء مرغوبة، يمكن الحصول عليها على النحو التالي:

invocation_string = "placeholder"
alora_invocation_tokens = tokenizer.encode(invocation_string, add_special_tokens=False).

المُرمِّز هو مُرمِّز النموذج الأساسي. استخدم add_special_tokens=False لتجنّب إضافة رموز SOS/EOS في سلسلة البحث لدينا (وهو ما سيُسبّب على الأرجح فشل عملية البحث).

ملاحظات

• يُؤيَّد aLoRA فقط لمهام task_type=CAUSAL_LM بسبب تركيزه على إعادة استخدام ذاكرة التخزين المؤقت.
• بما أن الأوزان تُكيَّف على عدد أقل من الرموز، فإن aLoRA يتطلب غالبًا (وليس دائمًا) رتبة (r) أعلى من LoRA. يمكن أن يكون r=32 نقطة بداية جيدة.
• لا يمكن دمج أوزان aLoRA في النموذج الأساسي بحكم التعريف، حيث تُطبَّق أوزان المُكيِّف بشكل انتقائي على مجموعة فرعية من الرموز. ستُصدر محاولات الدمج أخطاء.
• لا يُدعم البحث الشعاعي بعد.
• لا يُنصح عمومًا بإضافة رموز جديدة إلى مُجزّئ الرموز (tokenizer) غير الموجودة في النموذج الأساسي. فقد يُعقّد ذلك حالة الاستخدام المستهدفة التي يعمل فيها كل من النموذج الأساسي ونموذج المُكيّف (adapter) على سياق متداخل. يمكنك تجاوز هذه المشكلة عن طريق إضافة رموز قابلة للتدريب إلى النموذج الأساسي قبل تدريب المُكيّف.

اختيار تسلسل الاستدعاء وتصميم SFT

يجب عليك إضافة تسلسل alora_invocation_tokens لأنه لا يُضاف تلقائيًا. نوصي بتفعيل أوزان المُكيّف مبكرًا (في بداية أي تلميح خاص بالمُكيّف)، ولكن بعد أي مدخلات طويلة، لتعظيم أداء النموذج دون المساس بإعادة استخدام ذاكرة التخزين المؤقت. وكما هو الحال مع أي نموذج، يجب أن يكون التنسيق متسقًا بين التدريب والاختبار.

فكّر في المثال التالي، حيث يحتوي النموذج الأساسي على قالب محادثة، والهدف هو تدريب المُكيّف (adapter) على توليد مخرجات مرغوبة.

• الخيار 1: إذا لم يكن هناك موجه محدد للمهمة، أي أن المدخل هو سجل محادثة مع موجه assistant، فإن موجه assistant في قالب المحادثة (مثل <|start_of_role|>assistant<|end_of_role|>) هو خيار طبيعي لسلسلة الاستدعاء. راجع قالب المحادثة الخاص بالنموذج للعثور على الموجه الخاص بالنموذج.
• الخيار 2: إذا كان هناك موجه محدد للمهمة للمكيّف يصف المهمة التي يتعلمها المكيّف، وتم وضع ذلك الموجه كدور user مباشرة قبل التوليد، فإن موجه user في قالب المحادثة (مثل <|start_of_role|>user<|end_of_role|>) هو خيار طبيعي لسلسلة الاستدعاء.

بعد تحديد سلسلة الاستدعاء، احصل على مُجزِّئ النموذج واحصل على alora_invocation_tokens على النحو التالي

alora_invocation_tokens = tokenizer.encode(invocation_string, add_special_tokens=False).

مثال على إعداد الاستدلال موجود في alora finetuning.

عند استخدام نصوص مخصصة لسلسلة الاستدعاء، تأكد من أن بداية ونهاية السلسلة هي رموز خاصة لتجنب المشكلات المتعلقة بالتجزئة عند الحدود.

للفهم، تخيّل أن الرموز ‘a’ و ‘b’ و ‘c’ و ‘ab’ هي توكنات في مُجزّئ النصوص الخاص بك (والأرقام 1 و 2 و 3 و 4 على التوالي). افترض أن alora_invocation_tokens = [2, 3]. الآن تخيّل أن نص الإدخال الخاص بك هو “abc”. بما أن “ab” هو توكن، فإن هذا النص سيُجزَّأ إلى [4,3]. وبالتالي، سيفشل العثور على alora_invocation_tokens على الرغم من وجود السلسلة “bc” ضمن النص. ومع ذلك، إذا كانت بداية ونهاية سلسلة الاستدعاء توكنات خاصة، فلن يحدث هذا الفشل أبدًا لأن التوكنات الخاصة لا تُدمج أبدًا مع أحرف أخرى في توكن واحد.

استخدام (وإعادة استخدام) ذاكرة التخزين المؤقت للتوليد

الغرض الرئيسي من aLoRA هو جعل ذاكرة KV قابلة للتبديل بين النموذج الأساسي ونماذج محوّل aLoRA قبل تسلسل الاستدعاء لأن قيم KV الأساسية والمحوّلة غير متوافقة. على وجه التحديد، يمكن استخدام المفاتيح والقيم المخزنة أثناء توليد نموذج واحد في عمليات التوليد اللاحقة لتجنب عمليات التعبئة المسبقة المكلفة لرموز السياق. عند مشاركة ذاكرة التخزين المؤقت بين النموذج الأساسي ومحوّلات aLoRA، هناك نمطان رئيسيان:

1. لقد أنتج النموذج الأساسي شيئًا ما، ثم يُستدعى مُكيّف aLoRA لإجراء توليد تالٍ. على سبيل المثال، يجيب النموذج الأساسي على سؤال، ثم يفحص مُكيّف aLoRA المُدرَّب على كشف الهلوسة (الوهم) ردّ النموذج الأساسي.
2. يكون مُكيّف aLoRA قد أنتج شيئًا ما، ثم يُستدعى النموذج الأساسي أو مُكيّف aLoRA مختلف لإجراء توليد تالٍ يتداخل جزئيًا مع سياق aLoRA الأصلي. على سبيل المثال، يقدّم المستخدم استعلامًا، فيعيد مُكيّف aLoRA صياغة الاستعلام ليكون أكثر استقلالية لتحسين الاسترجاع في نظام RAG. ثم تُسترجع المستندات وتُحمَّل في السياق، ويتحقق aLoRA من مدى صلة هذه المستندات بالسؤال، ثم يولّد النموذج الأساسي إجابة.

لإظهار السلوكيات المذكورة أعلاه عند استخدام التخزين المؤقت، نستخدم DynamicCache من transformers. انتبه إلى ضمان عدم خلط قيم التخزين المؤقت المُكيّفة بقيم التخزين المؤقت الأساسية. وبشكل خاص، يتطلب مشاركة التخزين المؤقت خطوة إضافية عندما يكون هناك تداخل جزئي في السياق (النمط 2).

النمط 1: النموذج الأساسي متبوعًا بـ aLoRA هنا، يُدخل كامل مدخلات النموذج الأساسي ومخرجاته إلى مُكيّف aLoRA، إلى جانب تسلسل الاستدعاء:

from transformers import DynamicCache
...
cache = DynamicCache()
inputs_base = tokenizer(prompt_base, return_tensors="pt")
# Generate from base model and save cache
with model_alora.disable_adapter():
    output = model_alora.generate(inputs_base["input_ids"].to(device),attention_mask=inputs_base["attention_mask"].to(device),past_key_values = cache,return_dict_in_generate=True)
output_text_base = tokenizer.decode(output.sequences[0])
cache = output.past_key_values

# Generate with aLoRA adapter from cache
prompt_alora = output_text + INVOCATION_STRING
inputs_alora = tokenizer(prompt_alora, return_tensors="pt").to(device)
output = model_alora.generate(**inputs_alora, past_key_values=cache)
output_text_alora = tokenizer.decode(output[0])

# Note: cache is now tainted with adapter values and cannot be used in base model from here on!

النمط 2: توليد aLoRA يليه النموذج الأساسي (أو aLoRA آخر) مع تداخل جزئي في السياق هنا، نملأ السياق المشترك مسبقًا باستخدام النموذج الأساسي، ثم ننتج النص.

from transformers import DynamicCache
import copy
...
cache = DynamicCache()
inputs_shared = tokenizer(prompt_shared, return_tensors="pt").to(device)

# Prefill from base model and save cache
with model_alora.disable_adapter():
    with torch.no_grad():
        model_alora(**inputs_shared, past_key_values=cache)
cache_copy = copy.deepcopy(cache)

# Generate from aLoRA using prefilled cache
prompt_alora = prompt_shared + INVOCATION_STRING
inputs_alora = tokenizer(prompt_alora, return_tensors="pt").to(device)
output = model_alora.generate(**inputs_alora, past_key_values=cache)
output_text_alora = tokenizer.decode(output[0])

# Generate from base model using saved cache not tainted by aLoRA KV values
prompt_base = prompt_shared
inputs_base = tokenizer(prompt_base, return_tensors="pt").to(device)
with model_alora.disable_adapter():
    output = model_alora.generate(**inputs_base, past_key_values=cache_copy)
output_text_base = tokenizer.decode(output[0])

الاستدلال باستخدام محولات LoRA مختلفة في نفس الدفعة

عادةً، يجب أن يستخدم كل دفعة استنتاج نفس المُكيِّف (أو المُكيِّفات) في PEFT. وقد يكون هذا مزعجًا أحيانًا، إذ قد تحتوي الدفعات على عينات مخصصة للاستخدام مع مُكيِّفات LoRA مختلفة. على سبيل المثال، قد يكون لدينا نموذج أساسي يعمل بشكل جيد باللغة الإنجليزية، بالإضافة إلى مُكيِّفَي LoRA آخرين، أحدهما للفرنسية والآخر للألمانية. وعادةً، سنضطر إلى تقسيم دفعاتنا بحيث تحتوي كل دفعة على عينات من لغة واحدة فقط، فلا يمكننا دمج لغات مختلفة في الدفعة نفسها.

لحسن الحظ، يمكن خلط محولات LoRA المختلفة في نفس الدفعة باستخدام الحجة adapter_name. أدناه، نوضح مثالاً على كيفية عمل ذلك عملياً. أولاً، دعونا نحمّل النموذج الأساسي، والإنجليزية، والمحولين، الفرنسية والألمانية، على النحو التالي:

from transformers import AutoTokenizer, AutoModelForCausalLM
from peft import PeftModel

model_id = ...
tokenizer = AutoTokenizer.from_pretrained(model_id)

model = AutoModelForCausalLM.from_pretrained(model_id)
# load the LoRA adapter for French
peft_model = PeftModel.from_pretrained(model, <path>, adapter_name="adapter_fr")
# next, load the LoRA adapter for German
peft_model.load_adapter(<path>, adapter_name="adapter_de")

الآن، نريد توليد نص على عينة تحتوي على اللغات الثلاث: العيّنات الثلاث الأولى بالإنجليزية، والتالية الثلاث بالفرنسية، والأخيرة الثلاث بالألمانية. يمكننا استخدام الحجة adapter_names لتحديد المُكيّف (adapter) الذي سنستخدمه لكل عينة. بما أن النموذج الأساسي لدينا يُستخدم للإنجليزية، نستخدم السلسلة الخاصة "__base__" لهذه العيّنات. بالنسبة للعيّنات الثلاث التالية، نحدد اسم المُكيّف الخاص بالتدريب الدقيق LoRA للفرنسية، وفي هذه الحالة "adapter_fr". وبالنسبة للعيّنات الثلاث الأخيرة، نحدد اسم المُكيّف الخاص بالتدريب الدقيق LoRA للألمانية، وفي هذه الحالة "adapter_de". بهذه الطريقة، يمكننا استخدام النموذج الأساسي والمُكيّفين في دفعة واحدة.

inputs = tokenizer(
    [
        "Hello, my dog is cute",
        "Hello, my cat is awesome",
        "Hello, my fish is great",
        "Salut, mon chien est mignon",
        "Salut, mon chat est génial",
        "Salut, mon poisson est super",
        "Hallo, mein Hund ist süß",
        "Hallo, meine Katze ist toll",
        "Hallo, mein Fisch ist großartig",
    ],
    return_tensors="pt",
    padding=True,
)

adapter_names = [
    "__base__", "__base__", "__base__",
    "adapter_fr", "adapter_fr", "adapter_fr",
    "adapter_de", "adapter_de", "adapter_de",
]
output = peft_model.generate(**inputs, adapter_names=adapter_names, max_new_tokens=20)

لاحظ أن الترتيب لا يهم هنا، أي أن العينات في الدفعة لا تحتاج إلى أن تكون مجمّعة حسب المُكيّف كما في المثال أعلاه. ما نحتاجه فقط هو التأكد من أن معامل adapter_names متوافق بشكل صحيح مع العينات.

علاوة على ذلك، يعمل النهج نفسه أيضًا مع ميزة modules_to_save، التي تتيح حفظ وإعادة استخدام طبقات محددة من الشبكة العصبية، مثل رؤوس مخصصة لمهام التصنيف، عبر محولات LoRA المختلفة.

ملاحظات

يوجد بعض العيوب لاستخدام هذه الميزة، وهي:

• يعمل للاستدلال فقط، وليس للتدريب.
• تتفوق عملية تعطيل المُكيّفات باستخدام سياق with model.disable_adapter() على adapter_names.
• لا يمكنك تمرير adapter_names إذا تم دمج بعض أوزان المحوّل مع الوزن الأساسي باستخدام طريقة merge_adapter. يرجى إلغاء دمج جميع المحوِّلات أولاً عن طريق استدعاء model.unmerge_adapter(). لاحظ أن دمج بعض المحوِّلات النشطة فقط يحمل تحذيراً مماثلاً خارج نطاق adapter_names.
• لأسباب واضحة، لا يمكن استخدام هذا بعد استدعاء merge_and_unload()، حيث سيتم دمج جميع محولات LoRA في الأوزان الأساسية في هذه الحالة.
• لا تعمل هذه الميزة حاليًا مع DoRA، لذا اضبط use_dora=False في LoraConfig الخاص بك إذا كنت ترغب في استخدامها.
• ميزة modules_to_save مدعومة حاليًا فقط لطبقات الأنواع Linear وEmbedding وConv2d وConv1d.
• يوجد عبء متوقع عند الاستدلال باستخدام adapter_names, خاصة إذا كان عدد المحوِّلات المختلفة في الدفعة كبيرًا. والسبب في ذلك هو أن حجم الدفعة يُقلَّص فعليًا إلى عدد العينات لكل محوِّل. إذا كانت أداء وقت التشغيل أولويتك القصوى، فحاول ما يلي:
  • زيادة حجم الدفعة.
  • حاول تجنّب تضمين عدد كبير من المحوِّلات المختلفة في الدفعة الواحدة، وفضِّل الدفعات المتجانسة. يمكن تحقيق ذلك عن طريق تخزين العينات التي تستخدم المحوِّل نفسه في منطقة مؤقتة، ثم تنفيذ الاستدلال بعدد صغير فقط من المحوِّلات المختلفة.
  • اطّلع على تطبيقات بديلة مثل LoRAX وpunica أو S-LoRA، وهي مصممة خصيصًا للعمل مع عدد كبير من المحوِّلات المختلفة.

تكوين مُكيّفات LoRA وإعادة استخدامها

Arrow

Arrow هي خوارزمية توجيه معيارية مصممة لدمج عدة محولات LoRA مسبقة التدريب ومخصصة لمهام محددة لحل مهمة معينة، على غرار Polytropon لكن دون الحاجة إلى ضبط دقيق. وبدلا من دمج جميع المحولات بشكل ساذج، يقدم آلية توجيه خالية من التدرجات على مستوى الرموز (token-wise) تعتمد على مزيج الخبراء (MoE). عند الاستدلال، يحسب أولاً نموذجًا أوليًا (prototype) لكل محول LoRA من خلال استخراج متجه القيمة المفردة اليمنى الأعلى من تحليله باستخدام SVD. ثم تُقارن تمثيلات كل رمز مع هذه النماذج الأولية عبر التشابه الجيب التمامي (cosine similarity) للحصول على معاملات التوجيه. تُسند الرموز إلى محولات LoRA الأكثر صلة (top-k)، مع تطبيع المعاملات عبر softmax، وتُدمج مخرجاتها خطيًا. وهذا يتيح إعادة استخدام وحدات LoRA الموجودة بفعالية لمهام جديدة، مما يؤدي إلى تعميم أفضل في سيناريوهات الصفرية (zero-shot).

في PEFT، يتم تفعيل Arrow من خلال andcreate_arrow_model. You can also configure parameters such astop_k(the number of LoRA adapters combined per token),router_temperature(the softmax temperature applied to the routing coefficients), andrng_seed` (for reproducibility).

from peft import create_arrow_model, ArrowConfig
from transformers import AutoModelForCausalLM

# Loading the model
base_model = AutoModelForCausalLM.from_pretrained("microsoft/Phi-3-mini-4k-instruct")

# Creating the Arrow config
arrow_config = ArrowConfig(
    top_k=3,
    router_temperature=1.0,
    rng_seed=42,
)

# The LoRA adapters below were trained on a clustered FLAN dataset.
# Task clustering was performed using the Model-Based Clustering (MBC) method,
# as described in the Arrow paper.
# While one could train a separate LoRA for each task and let Arrow route tokens among them,
# training LoRAs on clusters of tasks instead provides an indirect optimization for
# transfer across the multi-task dataset.
task_specific_adapter_paths = [
        f"TahaBa/phi3-mini-clustered-flan/ts_expert_{i}" for i in range(10)
    ]

# Creating the Arrow model
model = create_arrow_model(
        base_model=base_model,
        task_specific_adapter_paths=task_specific_adapter_paths,
        arrow_config=arrow_config,
    )

# Now the forward path could be called on this model, like a normal PeftModel.

علاوة على ذلك، يمكنك إضافة أو إزالة المُكيّفات (adapters) بعد استدعاء create_arrow_model—على سبيل المثال، لضبط مُكيّف جديد أو التخلّي عن مُكيّف غير ضروري. بمجرد وضع المُكيّفات في مكانها، يمكنك تفعيل "arrow_router" للاستدلال (inference) لاستخدام Arrow. لاحظ أنه إذا أضفت مُكيّف LoRA جديدًا بعد create_arrow_model وأردت ضبطه، فيجب عليك تعيين المُكيّف الجديد كفعّال بشكل صريح، لأن "arrow_router" يكون مفعّلًا افتراضيًا في create_arrow_model.

from trl import SFTTrainer, SFTConfig

# Adding a new adapter and activating it
model.add_adapter(adapter_name='new_adapter')
model.set_adapter('new_adapter')

# Now the model could be trained along the `new_adapter`.
trainer = SFTTrainer(
        model=model,
        args=SFTConfig(...),
        ...
    )

# Once the training is done, you can activate `arrow_router` and use it in inference
model.set_adapter('arrow_router')    # Model is ready to be used at inference time now

GenKnowSub

يعزز GenKnowSub تقنية Arrow من خلال تنقية محولات LoRA الخاصة بالمهام قبل التوجيه. الفكرة الأساسية هي طرح المعرفة العامة المُرمّزة في فضاء LoRA—بناءً على مبدأ النسيان عبر النفي—بحيث تصبح محولات المهام أكثر عزلاً وتركيزاً على الإشارات ذات الصلة بالمهمة. عملياً، يقدّر GenKnowSub فضاءً فرعيّاً منخفض الأبعاد “عامّاً” من مجموعة من محولات LoRA العامة (غير الخاصة بمهمة معينة) ثم يزيل هذا المكوّن من تحديث LoRA لكل محوّل مهام قبل التوجيه على مستوى الرموز في Arrow. وهذا يحسّن عادةً قابلية التركيب ويقلل من التداخل عند دمج العديد من محولات المهام.

في PEFT، فعّل GenKnowSub عن طريق تعيين use_gks=True في ArrowConfig، وتوفير general_adapter_paths في create_arrow_model:

from peft import create_arrow_model, ArrowConfig
from transformers import AutoModelForCausalLM

# Loading the model
base_model = AutoModelForCausalLM.from_pretrained("microsoft/Phi-3-mini-4k-instruct")

# Creating the Arrow config
arrow_config = ArrowConfig(
    top_k=3,
    router_temperature=1.0,
    use_gks=True,
    rng_seed=42,
)

# Path to task-specific, trained on flan clustered dataset (as we explained before.)
task_specific_adapter_paths = [
        f"TahaBa/phi3-mini-clustered-flan/ts_expert_{i}" for i in range(10)
    ]
# These general adapters are trained on English, German, and French Wikipedia dataset,
# with causal language modelling objective, each pair like: (507 token tsentence, 5 token completion), and the loss computed on the completion
general_adapter_paths = [
        "TahaBa/phi3-mini-general-adapters/cluster0_batch16_prop1.0_langen/checkpoint-17",
        "TahaBa/phi3-mini-general-adapters/cluster0_batch16_prop1.0_langfr/checkpoint-35",
        "TahaBa/phi3-mini-general-adapters/cluster0_batch16_prop1.0_langger/checkpoint-17"
    ]

# Creating the Arrow model
model = create_arrow_model(
        base_model=base_model,
        task_specific_adapter_paths=task_specific_adapter_paths,
        general_adapter_paths=general_adapter_paths,
        arrow_config=arrow_config,
    )

# Now the forward path could be called on this model, like a normal PeftModel.

لتشفير المعرفة العامة، يطرح GenKnowSub متوسط المُكيّفات العامة المُقدَّمة من كل مُكيّف خاص بالمهمة مرة واحدة، قبل بدء التوجيه. علاوة على ذلك، لا يزال يُدعم في هذه الحالة القدرة على إضافة أو إزالة المُكيّفات بعد استدعاء create_arrow_model (كما هو موصوف في قسم Arrow).

أشياء يجب وضعها في الاعتبار عند استخدام Arrow + GenKnowSub:

• يجب أن تتشارك جميع محولات LoRA (المخصصة للمهمة والعامة) نفس rank وtarget_modules.

• ستؤدي أي عدم اتساق في هذه الإعدادات إلى رفع خطأ في create_arrow_model.

• يُؤمَن استخدام عوامل توسيع مختلفة (lora_alpha) عبر مُكيّفات المهام — يتعامل Arrow معها تلقائيًا.

• لا يُدعم دمج "arrow_router" بسبب سلوكه الديناميكي في التوجيه.

• في create_arrow_model، تُحمَّل مُكيّفات المهام باسم task_i ومُكيّفات الاستخدام العام باسم gks_j (حيث i وj هما فهارس). تضمن الدالة اتساق target_modules وrank، وما إذا كانت المُكيّفات مطبّقة على طبقات Linear أو Linear4bit. ثم تضيف وحدة "arrow_router" وتفعّلها. أي تخصيص لهذه العملية يتطلب تجاوز create_arrow_model.

• يتوافق هذا التنفيذ مع التكميم بدقة 4 بت (عبر bitsandbytes):

  تم النسخ

  from transformers import AutoModelForCausalLM, BitsAndBytesConfig
  import torch
  
  # Quantisation config
  bnb_config = BitsAndBytesConfig(
          load_in_4bit=True,
          bnb_4bit_quant_type="nf4",
          bnb_4bit_compute_dtype=torch.bfloat16,
          bnb_4bit_use_double_quant=False,
      )
  
  # Loading the model
  base_model = AutoModelForCausalLM.from_pretrained(
      "microsoft/Phi-3-mini-4k-instruct",
      dtype=torch.bfloat16,
      device_map="auto",
      quantization_config=bnb_config,
  )
  
  # Now call create_arrow_model() as we explained before.

واجهة برمجة التطبيقات

LoraConfig

LoraModel

>>> from transformers import AutoModelForSeq2SeqLM
>>> from peft import LoraConfig, get_peft_model

>>> config = LoraConfig(
...     task_type="SEQ_2_SEQ_LM",
...     r=8,
...     lora_alpha=32,
...     target_modules=["q", "v"],
...     lora_dropout=0.01,
... )

>>> model = AutoModelForSeq2SeqLM.from_pretrained("t5-base")
>>> lora_model = get_peft_model(model, config)

>>> import torch
>>> import transformers
>>> from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training

>>> rank = ...
>>> target_modules = ["q_proj", "k_proj", "v_proj", "out_proj", "fc_in", "fc_out", "wte"]
>>> config = LoraConfig(
...     r=4, lora_alpha=16, target_modules=target_modules, lora_dropout=0.1, bias="none", task_type="CAUSAL_LM"
... )
>>> quantization_config = transformers.BitsAndBytesConfig(load_in_8bit=True)

>>> tokenizer = transformers.AutoTokenizer.from_pretrained(
...     "kakaobrain/kogpt",
...     revision="KoGPT6B-ryan1.5b-float16",  # or float32 version: revision=KoGPT6B-ryan1.5b
...     bos_token="[BOS]",
...     eos_token="[EOS]",
...     unk_token="[UNK]",
...     pad_token="[PAD]",
...     mask_token="[MASK]",
... )
>>> model = transformers.GPTJForCausalLM.from_pretrained(
...     "kakaobrain/kogpt",
...     revision="KoGPT6B-ryan1.5b-float16",  # or float32 version: revision=KoGPT6B-ryan1.5b
...     pad_token_id=tokenizer.eos_token_id,
...     use_cache=False,
...     device_map={"": rank},
...     torch_dtype=torch.float16,
...     quantization_config=quantization_config,
... )
>>> model = prepare_model_for_kbit_training(model)
>>> lora_model = get_peft_model(model, config)

أدوات مساعدة

ArrowConfig

LoftQ

replace_lora_weights_loftq

LoftQConfig

Eva

EvaConfig

initialize_lora_eva_weights

get_eva_state_dict

LoraGAConfig

أدوات

تقليل الأبعاد للغريب