نموذج لغوي محلي في ⁨CI/CD⁩: مراجعة الكود المؤتمتة بدون سحابة

حقائق سريعة

• النموذج الموصى به: Qwen3-Coder 30B بتكميم Q4_K_M (~17 جيجابايت VRAM، ترخيص Apache 2.0).
• وقت التشغيل الموصى به: Ollama لبساطة الإعداد؛ vLLM إذا احتجت تزامناً أعلى على البطاقة ذاتها.
• الحد الأدنى من بطاقة GPU للفرق الجادة: RTX 4090 (24 جيجابايت). البطاقات الأصغر تُجبر على استخدام نموذج 7B بجودة مراجعة أدنى بشكل ملحوظ.
• التزامن على بطاقة GPU واحدة 24 جيجابايت: 1–3 مراجعات متزامنة بارتياح مع Qwen3-Coder 30B؛ قائمة انتظار بعد ذلك.
• هدف زمن الاستجابة: أقل من 30 ثانية لفرق من 200 سطر. بعد هذه النقطة يتغير سلوك مؤلف PR وتُتخطى المراجعات.
• موقف التدقيق: إثبات الصفر صادراً على خادم GPU أمر ممكن؛ المساحة الكاملة هي ollama serve + ملف سجل واحد.
• التقاطع مقابل GitHub Advanced Security (19 دولاراً للمطور شهرياً): تغطي 15–25 مقعداً مدفوعاً بناءً بـ RTX 4090 في 5–10 أشهر.
• التكافؤ مع GitLab CI: بنية متطابقة، استبدل GitHub Action بمهمة CI تستدعي نقطة نهاية HTTP ذاتها.

مقارنة البنى: ثلاثة خيارات حقيقية لمراجعة الكود في CI

المكدّس الموصى به: Ollama + Qwen3-Coder + إجراء GitHub Action خفيف

• خادم GPU مع Ollama (أو vLLM لتزامن أعلى). يكشف Ollama واجهة API HTTP متوافقة مع OpenAI على localhost:11434 افتراضياً؛ اربطها بواجهة خاصة أو وكيل عكسي مع مصادقة قبل كشفها للعدّائين.
• نموذج مُضبَّط على البرمجة: Qwen3-Coder 30B بتكميم Q4_K_M هو المعيار لمايو 2026 — أقوى نموذج مفتوح الأوزان للبرمجة، سياق 256K، ترخيص Apache 2.0، يناسب بطاقة GPU بسعة 24 جيجابايت. للبطاقات بسعة 8–16 جيجابايت، استخدم Qwen3-Coder 7B مع الأخذ بعين الاعتبار أن جودة المراجعة تنخفض بشكل ملحوظ.
• تكامل CI: عدّاء GitHub Actions مستضاف ذاتياً في الشبكة ذاتها مع خادم GPU، أو عدّائوك الحاليون المستضافون على GitHub وصولاً إلى خادم GPU عبر شبكة خاصة (Tailscale أو WireGuard أو VPC peering).
• إجراء GitHub Action مخصص (JavaScript أو composite) يجلب فرق PR عبر واجهة GitHub API، ويُرسله إلى نقطة نهاية Ollama مع موجّه مراجعة، ويُحلّل الاستجابة المنظمة وينشر تعليقات مضمّنة على PR.
• اختياري: ذاكرة تخزين مؤقت صغيرة Redis أو SQLite بمفتاح هاش الملف + هاش الفرق لتجنب إعادة مراجعة الملفات غير المتغيرة في تشغيلات CI اللاحقة.
• التكافؤ مع GitLab: البنية ذاتها مع مهمة GitLab CI تستبدل إجراء GitHub Action. استدعاء LLM متطابق.

سير عمل GitHub Actions قابل للتشغيل

• يحتاج العدّاء إلى الوصول إلى OLLAMA_HOST عبر الشبكة — مستضاف ذاتياً في VPC ذاتها، أو عبر Tailscale / WireGuard إذا كان خادم GPU في مكان آخر.
• يفرض موجّه النظام استجابة JSON منظمة لتتفرع الإجراء بوضوح حسب الحكم. بدون format: "json" ومخطط صارم في الموجّه ستُنفق وقتاً تشغيلياً في تحليل مخرجات نص حر.
• الفحص مع fetch-depth: 0 ضروري لحساب فرق حقيقي مقابل الفرع الأساسي — تشكّل الفحوصات الضحلة فروقاً مشوّهة.
• للمستودعات التي تتجاوز ~50 ألف سطر كود مُعدَّل لكل PR، اقطع الفرق أو قسّمه قبل إرساله. سياق 256K في Qwen3-Coder 30B سخيّ لكن السياق العملي أقرب إلى 64K–128K (انظر أفضل نماذج البرمجة المحلية 2026).
• لعمق تصميم الموجّه — موجّهات النظام مقابل المستخدم والأمثلة والمخرجات المنظمة — انظر موجّه النظام مقابل موجّه المستخدم: ما الفرق؟.

# .github/workflows/local-llm-review.yml
name: Local LLM Code Review

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  review:
    runs-on: self-hosted   # or any runner that can reach OLLAMA_HOST
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Generate diff
        id: diff
        run: |
          git diff origin/${{ github.base_ref }}...HEAD > /tmp/pr.diff
          echo "size=$(wc -c < /tmp/pr.diff)" >> "$GITHUB_OUTPUT"

      - name: Call local LLM for review
        id: review
        env:
          OLLAMA_HOST: ${{ secrets.OLLAMA_HOST }}   # e.g. http://gpu-server.internal:11434
        run: |
          DIFF=$(jq -Rs . < /tmp/pr.diff)
          curl -sS "$OLLAMA_HOST/api/chat" \
            -H 'Content-Type: application/json' \
            -d "{
              \"model\": \"qwen3-coder:30b\",
              \"stream\": false,
              \"format\": \"json\",
              \"messages\": [
                {\"role\": \"system\", \"content\": \"You are a senior code reviewer. Return JSON: {verdict: 'approve'|'comment'|'block', summary: string, comments: [{path, line, severity, message}]}\"},
                {\"role\": \"user\", \"content\": $DIFF}
              ]
            }" > /tmp/review.json
          echo "verdict=$(jq -r '.message.content | fromjson | .verdict' < /tmp/review.json)" >> "$GITHUB_OUTPUT"

      - name: Post review comment
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require('fs');
            const review = JSON.parse(JSON.parse(fs.readFileSync('/tmp/review.json')).message.content);
            const body = `### Local LLM Review: \`${review.verdict}\`\n\n${review.summary}`;
            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.issue.number,
              body
            });

      - name: Block on critical verdict
        if: steps.review.outputs.verdict == 'block'
        run: exit 1

تحجيم الأجهزة حسب حجم الفريق

مشاركة GPU بين عمليات البناء والأعمال الأخرى

• GPU مخصصة للمراجعة فقط: النموذج الأبسط. زمن الاستجابة قابل للتنبؤ؛ وتخطيط الطاقة مباشر؛ وأوضاع الفشل معزولة. الموصى به لأي فريق لا يُشغّل بنية تحتية GPU بعد.
• GPU مشتركة مع استنتاج التعلم الآلي: قابل للتطبيق إذا كانت عبء استنتاج التعلم الآلي ذات غلاف مستقر (مثل خدمة embeddings صغيرة تناسب 4–6 جيجابايت). يشغل نموذج المراجعة بقية VRAM. تصادمات الجدولة نادرة مع هذا النمط.
• GPU مشتركة مع تدريب التعلم الآلي: غير موصى به بشدة. تُشبع مهام التدريب استخدام VRAM وتحرم نموذج المراجعة من الموارد، مما يسبب فترات استجابة مراجعة تتراوح بين 30 و120 ثانية تُضعف ثقة المطورين في النظام.
• vLLM مع الانتباه المُقسَّم: مُصمَّم خصيصاً لتخديم LLM بتزامن عالٍ. بطاقة RTX 4090 ذاتها التي تُعالج 1–3 مراجعات متزامنة تحت Ollama يمكنها معالجة 4–8 تحت vLLM، على حساب إعداد أكثر تعقيداً. يستحق الأمر ابتداءً من 25 مطوراً.
• تعدد المستأجرين على H100: على نطاق أكثر من 100 مطور، قسّم H100 إلى شرائح MIG أو شغّل vLLM مع حصص لكل مستأجر. هذا مجال هندسة المنصات؛ لا تُبادر به.

مقارنة التكاليف مقابل GitHub Advanced Security

• GitHub Advanced Security (Code Security): 19 دولاراً/مطور/شهر بسعر القائمة (تحقق من صفحة أسعار GitHub؛ تتوفر خصومات الحجم لعملاء المؤسسات).
• واجهة API لنموذج LLM سحابي (مثل OpenAI وAnthropic): نحو 50–200 دولار/شهر لكل مطور نشط بحجم PR النموذجي؛ يتفاوت بشكل كبير حسب حجم قاعدة الكود وتصميم موجّه المراجعة.
• نموذج LLM محلي مستضاف ذاتياً، بناء RTX 4090: نحو 2500 دولار في أجهزة مرة واحدة (GPU + هيكل خادم أساسي). الطاقة: ~50 واط في الخمول، ~350 واط تحت الحمل — احسب نحو 20–30 دولار/شهر في الكهرباء مع الاستخدام النموذجي. بدون رسوم مقاعد.
• التقاطع عند 10 مطورين: GHAS 190 دولار/شهر مقابل 25 دولار/شهر تشغيلياً + 2500 دولار رأسمالي. يُستهلَك الرأسمالي في ~14 شهراً.
• التقاطع عند 25 مطوراً: GHAS 475 دولار/شهر مقابل 25 دولار/شهر تشغيلياً + 2500 دولار رأسمالي. يُستهلَك في ~5–6 أشهر.
• التقاطع عند 50 مطوراً: GHAS 950 دولار/شهر مقابل 40 دولار/شهر تشغيلياً + 7500 دولار رأسمالي (GPU بسعة 48 جيجابايت). يُستهلَك في ~8 أشهر.
• الرقم الرأسمالي هو ما يهيمن على الحساب. إذا اشتريت GPU خصيصاً لهذا الغرض فالاسترداد حقيقي. إذا كانت لديك طاقة GPU قائمة، فالتكلفة الهامشية أقرب إلى الصفر وتفوز الاستضافة الذاتية فوراً.

نموذج الأمان وموقف التدقيق

• النموذج يرى فقط الفرق الذي يُرسله إجراؤك. لا قياسات عن بُعد، ولا استدعاءات شبكة خفية. قابل للتأكيد بـ tcpdump أو nft monitor على واجهة الإخراج لخادم GPU — تحت التشغيل المستقر، يجب أن ترى صفر حزمة صادرة نحو مضيفين غير داخليين.
• مساحة التدقيق الكاملة هي عملية واحدة وملف سجل واحد. ollama serve هو مكدّس LLM بأكمله. سجلاته (أجسام الطلبات وزمن الاستجابة وأحداث تحميل النموذج) هي سجل التدقيق. لا لوحة SaaS للاستعلام، ولا سياسة احتفاظ خارجية للقراءة.
• العزل الشبكي مباشر. اربط ollama serve بواجهة خاصة؛ ضع وكيلاً عكسياً مع mTLS أو مصادقة الرمز المشترك أمامه؛ أنكر حركة البيانات الصادرة في فضاء أسماء شبكة خادم GPU باستثناء شبكة الفرع الفرعية لعدّاء CI. نمط zero-trust قياسي، بدون سحر خاص بـ LLM.
• أوزان النموذج عبارة عن مصنوعات ثابتة موقَّعة من المورّد. نزّلها مرة واحدة مع Ollama، وثبّت الملخص ولن يتغير النموذج دون تدخل المشغّل. هذه قصة سلسلة توريد أكثر صلابة من واجهة API لـ SaaS حيث يمكن استبدال النموذج الأصلي بصمت.
• موقف الامتثال: عدم تدفق البيانات صادراً سهل التوثيق لـ SOC 2 وISO 27001 وGDPR وتصنيف المخاطر المحدودة لقانون الذكاء الاصطناعي الأوروبي. الجزء الأصعب في امتثال الاستضافة الذاتية عادةً هو توثيق خادم الاستنتاج نفسه؛ كل من Ollama وvLLM موثّق جيداً.
• النموذج لا يزال يرى كودك. الاستضافة الذاتية لا تعني خصوصية من النموذج — بل تعني خصوصية من الأطراف الثالثة. سيناريوهات التهديد الداخلي (مهندس لديه وصول لخادم GPU يقرأ سجلات تحتوي على فروق PR تاريخية) لا تزال في النطاق؛ دوّر السجلات وقيّد الوصول وفقاً لذلك.

تصميم الموجّه لمراجعة الكود

• المخرجات المنظمة غير قابلة للتفاوض. أجبر JSON بمخطط صارم (verdict وsummary وcomments[]). بدونه تُنفق الإجراء 30% من كودها في تحليل مخرجات نص حر وأوضاع الفشل دقيقة.
• للدليل الكامل حول فرض المخرجات المنظمة في النماذج، انظر المخرجات المنظمة ووضع JSON.
• عتبات الخطورة تنتمي إلى الموجّه لا إلى الإجراء. أخبر النموذج بما يُعدّ حرجاً ومرتفعاً ومتوسطاً ومنخفضاً؛ اطلب منه تصفية النتائج ذات الخطورة المنخفضة إلا إذا طُلبت صراحةً. هذا أكثر موثوقية بكثير من التصفية اللاحقة على حقل خطورة بنص حر.
• أرسِ الموجّه بأمثلة. موجّه بطلقة واحدة أو اثنتين مع فرق حقيقي وJSON مراجعة مثالي يتفوق بفارق كبير على zero-shot للنموذج ذاته وحجم الفرق ذاته.
• ميّز بين نية "المراجعة" و"التعليق". تعليق المراجع ("فكّر في استخراج هذا لـ helper") وعنصر الحظر ("هذا يُدخل حقن SQL") يحتاجان إجراءات مختلفة في CI. ضعهما في المخرجات المنظمة واجعل الإجراء يحظر فقط عند عناصر الحظر.
• تنويعات الموجّه حسب اللغة البرمجية تُساعد ابتداءً من حجم معين. قاعدة كود متعددة اللغات تستفيد من موجّه يستشهد باصطلاحات اللغة ذات الصلة (Python الاصطلاحي مقابل Rust الاصطلاحي). اختياري دون ~25 مطوراً؛ ذو قيمة فوقه.
• لأساسيات أعمق لهندسة الموجّهات — موجّهات النظام مقابل المستخدم والمخرجات المنظمة وfew-shot prompting — انظر موجّه النظام مقابل موجّه المستخدم: ما الفرق؟.

إدارة الإيجابيات الكاذبة دون تآكل ثقة المطورين

• ضع عتبة "حظر" مرتفعة. حكم حظر يُطلَق على أي مشكلة lint بسيطة يُدرّب المطورين على تخطي الفحص. احتفظ بـ حظر لمشاكل الأمان والاختبارات الفاشلة وأخطاء الصحة الواضحة.
• اجعل التعليقات غير الحاجبة رخيصة. التعليقات المضمّنة التي النموذج غير متأكد منها يجب أن تُوسَم ("مبدئي" / "فكّر في") حتى يتمكن المؤلفون من رفضها بسرعة دون تكاليف.
• ابنِ حلقة ملاحظات في الشهر الأول. أضف تفاعلاً (👍 / 👎) لكل تعليق مراجعة. دورياً (أسبوعياً يعمل بشكل جيد) راجع 👎 وحدّث موجّه النظام بتعليمات صريحة "لا تُعلّم على X" لأكثر فئات الإيجابيات الكاذبة شيوعاً.
• قيّد حجم التعليقات لكل PR. PR واحدة يجب ألا تتلقى أكثر من 5–10 تعليقات من نموذج LLM؛ بعدها تنهار نسبة الإشارة إلى الضوضاء. قيّد الإجراء على مستوى الموجّه ("أعد ما يصل إلى N من التعليقات").
• تتبع ارتباط الحكم بالدمج أسبوعياً. إذا دُمج 80% من أحكام حظر على أي حال، فعتبتك عدوانية. إذا لم تحظَ 0% من أحكام تعليق بأي تفاعل بشري، فموجّهك يُولّد ضوضاء.

المزالق التشغيلية التي تظهر في الشهر الثاني

• تحديثات النموذج تكسر الموجّهات. إصدار جديد من Qwen3-Coder يُغيّر تنسيق المخرجات بدقة؛ يفشل تحليل JSON المنظم في CI؛ تتوقف المراجعات عن النشر. ثبّت ملخص النموذج مع ollama show <model> --modelfile؛ حدّثه في فرع staging قبل الترقية.
• تجزئة ذاكرة GPU في وقت تشغيل ممتد. خادم GPU يعمل على مدار الساعة قد يُجزّئ VRAM ويرفض التخصيصات الجديدة بعد أسابيع من التشغيل. أعد تشغيل ollama serve أسبوعياً عبر cron job؛ هذا رخيص ويتجنب وضع الفشل هذا كلياً.
• تزاحم عدّاء CI. عدّاء مستضاف ذاتياً يستضيف خادم LLM ومهام CI أخرى سيرى ارتفاعاً في زمن استجابة المراجعة تحت حمل البناء. افصل العدّاء وخادم GPU عندما يتجاوز حجم الفريق ~25 مطوراً.
• نمو حجم الفرق. أحجام PR تتزايد تدريجياً؛ في النهاية تتجاوز PR الحد العملي لسياق النموذج وتتدهور المراجعات بصمت. أضف حارساً في الإجراء يقطع أو يقسّم الفروق التي تتجاوز ~30 ألف رمز وينبّه المؤلف.
• الطاقة والتبريد. بطاقة RTX 4090 تحت حمل مستمر تستهلك ~350 واط في الاستنتاج وتُولّد حرارة كبيرة. غرفة خوادم بحجم خزانة بدون تبريد نشط ستحدّ من البطاقة؛ والتحديد يُكلّف زمن استجابة والمطورون يلاحظون ذلك.
• تدوير السجلات المنسي. Ollama يُسجّل كل جسم طلب افتراضياً. بعد ثلاثة أشهر من مراجعات PR، ملف السجل كبير ويحتوي على فروق PR تاريخية بنص عادي. دوّر السجلات أسبوعياً؛ أرشف أو احذف وفق سياسة الاحتفاظ بالبيانات.

الأخطاء الشائعة في إعداد مراجعة الكود بنموذج LLM المحلي

• الخطأ 1: البدء بنموذج 7B على بطاقة GPU بسعة 16 جيجابايت. مراجعات Qwen3-Coder 7B أدنى بشكل ملحوظ من نموذج 30B؛ يفقد المطورون الثقة بسرعة ويُهجر المشروع. إذا لم تتمكن من استضافة 30B فحسّن البطاقة أو استخدم واجهة API سحابية في الأشهر الستة الأولى بينما تضمن الميزانية.
• **الخطأ 2: حظر PR بأحكام حظر من اليوم الأول.** الشهر الأول معايرة؛ عامل كل المخرجات باعتبارها استشارية حتى تقيس معدل الإيجابيات الكاذبة. رقّها إلى حاجب فقط حين ينخفض المعدل دون ~5%.
• **الخطأ 3: كشف ollama serve على 0.0.0.0:11434 بدون مصادقة.** هذا مكافئ حقبة LLM لترك Redis مرتبطاً بواجهة عامة. اربط بواجهة خاصة وضع المصادقة أمامه قبل أي كشف بين المضيفين.
• الخطأ 4: إغفال ذاكرة التخزين المؤقت. إعادة مراجعة الملفات غير المتغيرة في كل تشغيل CI يُهدر ~80% من ميزانية الاستنتاج في PR نموذجية. ذاكرة تخزين مؤقت صغيرة بهاش الملف + هاش الفرق (Redis أو SQLite) تُقلّص زمن استجابة المراجعة وحمل GPU بشكل كبير.
• الخطأ 5: تشغيل مهام التدريب على البطاقة ذاتها. التدريب يُشبع استخدام VRAM ويحرم نموذج المراجعة من الموارد. استخدم بطاقات منفصلة أو، إذا اضطررت للمشاركة، شغّل التدريب وفق جدول زمني صارم لا يتداخل مع ساعات ذروة PR.
• الخطأ 6: بناء إجراء GitHub Action بدون حلقة ملاحظات. نظام مراجعة بدون تفاعلات 👍/👎 لا يمكنه التحسين. ابنِ الحلقة في الأسبوع الأول؛ اجمع البيانات؛ كرّر الموجّه شهرياً.

المصادر

• توثيق Ollama — المرجع الرسمي لـ HTTP API لـ /api/chat و/api/generate والمخرجات المنظمة وإدارة النماذج.
• توثيق vLLM — توثيق خادم الاستنتاج عالي الأداء؛ مسار الترقية بعد Ollama للفرق ذات التزامن العالي.
• توثيق GitHub Actions — المرجع الرسمي للعدّائين المستضافين ذاتياً والأسرار وسكريبت JavaScript لـ Actions المستخدم في سير العمل أعلاه.
• أسعار GitHub Advanced Security — مرجع أسعار القائمة لمقارنة التكاليف؛ تحقق من شروطك التفاوضية الفعلية.
• بطاقة نموذج Qwen3-Coder — البنية ونافذة السياق وشروط الترخيص لنموذج المراجعة الموصى به.
• مرجع GitLab CI/CD — المرجع المكافئ لفرق GitLab؛ جزء استدعاء LLM من سير العمل متطابق.

الأسئلة الشائعة

قراءات ذات صلة

• استبدال GitHub Copilot بنموذج LLM محلي — سياق استبدال أوسع للتكاليف للفرق التي تدرس أدوات AI مستضافة ذاتياً.
• Continue.dev مقابل Cline مقابل Aider: أفضل وكيل برمجة محلي 2026 — ما يعمل في خطوط الأنابيب مقابل العمل التفاعلي في المحرر؛ طبقة harness تحت النموذج.
• أفضل نماذج البرمجة المحلية 2026 — جانب النموذج في المعادلة: Qwen3-Coder وDeepSeek وCodestral ومشهد التراخيص.
• موجّه النظام مقابل موجّه المستخدم: ما الفرق؟ — أساسيات هندسة الموجّهات لموجّه نظام المراجعة.
• llama.cpp مقابل Ollama مقابل vLLM — مقارنة محركات الاستنتاج؛ vLLM هو مسار الترقية بعد Ollama للفرق ذات التزامن العالي.
• مركز Power Local LLM — مكتبة الأدلة الكاملة.