本地LLM在CI/CD中的代码审查：自托管设置2026

重要事实

• GPU内存需求： Qwen3-Coder 30B在q4_K_M量子化下最多需要22GB VRAM。24GB（RTX 4090）很紧但可行。如果想要余量，至少使用32GB（RTX 5090）。
• 推论延迟： 典型PR diff（50-500行）在24 GB卡上为10-30秒。H100级卡将其减少到5-10秒。将审查时间与CI工作的其他部分比较——测试套件和构建通常占主导。
• 并发性： 单个RTX 4090可通过GPU调度（时间共享）处理约1-3个并发审查。多个并发PR审查增加等待时间，第一个月也增加假阳性。
• 网络架构： 运行器必须通过专用VPC到达Ollama服务器，或通过Tailscale / WireGuard等私有隧道。不要暴露在互联网上。
• 模型选择： Qwen3-Coder 30B是2026年5月的代码生成默认值。与DeepSeek Coder V3相当。7B更快但审查质量降低，开发者很快失去信心。
• 存储： Ollama将模型权重存储在~/.ollama/models中。Qwen3-Coder 30B @ q4_K_M约14GB。对于多个模型，计划额外存储。
• 缓存重要性： 没有基于文件hash + diff hash的缓存，重新审查未更改的文件浪费约80%的推论预算。小缓存层（Redis、SQLite或内存中）大幅减少推论负载。
• 可审计性： Ollama记录请求体到日志。此日志包含PR diff，所以应用日志轮转（周为单位）和加密。可审计性是安全价值主张的大部分。

架构比较

• 自托管（推荐）： 初始设置（GPU购买、系统管理、安全设置）为中等复杂度。但成本固定，在15-25+开发者时变为主导。代码永不离开网络。完整的提示控制、模型选择和审计。大型团队（25+）的标准。
• 云API： 通过OpenAI、Anthropic或其他API服务。设置简单——API密钥和自定义GitHub Action。成本按请求单位（令牌/美元）扩展。5人以下团队便宜。大型团队从$2,000/月+开始扩展非常快。代码对第三方系统可见。
• 混合： 小团队（<25人）从云API开始，随着增长切换到自托管。但支付架构迭代复杂性——版本化提示、管理模型质量差异、计划故障转移。

推荐堆栈

• Ollama： 服务器推论框架。管理模型加载、量子化、批处理。设置简单、文档好、GPU内存效率好。https://github.com/ollama/ollama
• Qwen3-Coder 30B： Alibaba Qwen团队的编码专用模型。Apache 2.0（许可）。256K上下文长度。在一般代码质量、错误检测和安全性上与DeepSeek Coder V3相当。在HuggingFace上可得。
• 自定义GitHub Action（JavaScript）： 获取PR diff，POST到Ollama HTTP端点，解析JSON响应，发布内联评论。100-200行。无用户依赖。
• 自托管GitHub Actions运行器或私有CI执行器： 需要运行器或Ollama服务器可达性（同VPC、Tailscale或代理）。云运行器不起作用。
• 安全层（可选）： Ollama前的反向代理（nginx、Envoy），具有mTLS认证或共享密钥。默认Ollama绑定到localhost。
• 日志管理： Ollama记录请求体（包含PR diff）。应用syslog、文件轮转或systemd journalctl策略来轮转日志。

GitHub Actions工作流

• 运行器需要网络访问OLLAMA_HOST——自托管必须在同VPC内或通过Tailscale / WireGuard。
• 系统提示强制结构化JSON响应。没有format: "json"和严格的schema，action花费30%的代码解析自由形式输出。
• fetch-depth: 0对于计算相对于基础分支的真实diff是必需的——浅检查生成畸形diff。
• 对于超过约50K行代码更改的repo，在发送前截断或分割diff。256K上下文对Qwen3-Coder 30B很宽松，但实际工作上下文更接近64K-128K（见2026年最佳本地编码模型）。
• 对于提示深度工程——系统vs用户提示、示例、结构化结果——见系统提示vs用户提示：有什么区别。

name: Local LLM Code Review

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  review:
    runs-on: [self-hosted, linux]
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Get PR diff
        id: diff
        run: |
          git diff origin/${{ github.base_ref }}...HEAD > /tmp/pr.diff
          wc -l /tmp/pr.diff

      - name: Call local LLM review
        id: review
        env:
          OLLAMA_HOST: ${{ secrets.OLLAMA_HOST }}   # ex. 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基础设施团队的推荐。
• 与ML推论共享GPU： 可行如果推论负载有稳定的封装（例如，小集成服务适应4-6GB）。审查模型占用剩余VRAM。此模式下计划竞争少见。
• 与ML训练共享GPU： 强烈不推荐。训练作业将VRAM使用激增到限制，使审查模型饥饿，导致30-120秒审查延迟侵蚀开发者对系统的信心。
• vLLM与分页注意力： 为高并发LLM服务而生。同个RTX 4090在Ollama下处理1-3并发审查，在vLLM下处理4-8个，代价是更复杂的配置。25+开发者时值得。
• H100上多租户： 在100+开发者规模，将H100分割为MIG片或使用租户配额运行vLLM。这是平台工程领地；不要即兴。

与GitHub Advanced Security的成本比较

• GitHub Advanced Security（代码安全）： 价目表价格$19/开发者/月（检查GitHub定价页面；企业客户可得体积折扣）。
• 云LLM API（例OpenAI、Anthropic）： 典型PR体积下约$50-200/月/活跃开发者。极大地因代码库大小和审查提示设计而异。
• 自托管本地LLM、RTX 4090构建： 约$2,000硬件一次（GPU +基础服务器盒）。电力消耗：~50W空闲、~350W负载——在典型使用中约$25-35/月操作功耗。无按座位成本。
• 10开发者处平价： GHAS $190/月 vs 自托管约$25-35/月操作+约$2,000 capex。Capex在约14个月内回收。
• 25开发者处平价： GHAS $475/月 vs 自托管约$25-35/月操作+约$2,000 capex。Capex在约5-6个月内回收。
• 50开发者处平价： GHAS $950/月 vs 自托管约$35-45/月操作+约$7,500 capex（48 GB GPU）。Capex在约8个月内回收。
• Capex数字主导数学。 如果具体为此购买GPU，回收是真实的。如果有现有GPU容量，边际成本接近零，自托管立即获胜。

安全模型和审计态势

• 模型仅看到你的action发送的diff。 无遥测、无隐藏网络调用。可用tcpdump或GPU服务器发送接口上的nft monitor验证——在稳定操作中，你应该看到零个向非内部主机的发送数据包。
• 完整审计表面是一个进程和一个日志文件。 ollama serve就是整个LLM栈。它的日志（请求体、延迟、模型加载事件）是审计记录。无SaaS仪表板要查询、无第三方保留政策要读。
• 网络隔离简单。 将ollama serve绑定到私有接口。把认证反向代理（mTLS或shared-secret）放在它前面。拒绝GPU服务器namespace的发送，除了你的CI运行网络子网。标准零信任模式，无LLM特定魔法。
• 模型权重是供应商签署的静态工件。 通过Ollama拉一次、pin digest、模型不能在无操作者行动下改变。这是比可静默交换上游模型的SaaS API更强的供应链故事。
• 合规态势： 零数据外泄对SOC 2、ISO 27001、GDPR和EU AI法限制风险分类简单可记录。自托管合规最困难的部分通常是记录推论服务器本身。Ollama和vLLM都有好文档。
• 信息安全和全球数据主权： 对于在全球运营但在亚太地区存储数据的组织，自托管本地LLM满足区域数据驻留要求。代码评审从不离开你的服务器，符合许多亚太地区的监管框架。
• 模型看到你的代码。 自托管不意味着对模型私密——意味着对第三方私密。内部威胁情景（有服务器访问权的工程师读含有历史PR diff的日志）仍在范围内。轮转日志并相应限制访问。

代码审查提示设计

• 结构化输出不可商议。 用严格schema（verdict、summary、comments[]）强制JSON。没有这个，action花费30%的代码解析自由形式输出，故障模式是微妙的。
• 对于结构化输出和JSON模式应用的完整信息，见结构化输出和JSON模式。
• 严重程度阈值属于提示，不属于action。 告诉模型什么是critical、high、medium、low；告诉它过滤低严重程度结果除非明确要求。这比自由形式严重程度字段的事后过滤更可靠得多。
• 用示例anchor提示。 带有真实diff和理想审查JSON的1-2shot提示超过同样模型和diff大小的零shot。
• 区分"审查"意图和"评论"。 批评评论（"考虑提取到helper"）和blocker（"这引入SQL注入"）需要不同的CI行动。在结构化输出中标记它们，仅在blocker处块action。
• 按语言的提示变体在某个规模以上很有用。 多语言代码库从引用相关语言习语的提示受益（Pythonic vs Rust习语）。这在约25开发者以下是可选的；以上是有价值的。
• 对于更深的提示工程anchor——系统vs用户提示、结构化结果、few-shot prompting——见系统提示vs用户提示：有什么区别。

处理假阳性而不侵蚀开发者信心

• 设置高"block"阈值。 每个小lint问题都触发block判决会训练开发者绕过检查。为安全问题、破损测试和明确的正确性失败预留block。
• 使非阻止评论便宜。 模型不确定的内联评论标记为"tentative"/"consider"，以便作者可以快速无仪式地驳回。
• 第一个月建立反馈循环。 向每条审查评论添加反应（👍 / 👎）。定期（周基础工作）检查👎s，用明确的"不报告X"指令更新系统提示以处理最常见的假阳性类别。
• 按PR的评论体积速率限制。 单个PR不应从LLM收到超过5-10条评论；超过此信号对噪声比崩溃。在提示级实现action功能（"最多返回N条评论"）。
• 周追踪判决对合并相关性。 如果80%的block判决无论如何都合并，你的阈值太激进。如果0%的comment判决获得任何人类行动，你的提示生成噪声。

第二个月的运营陷阱

• 模型更新破坏提示。 新Qwen3-Coder版本略微改变结构化输出格式；JSON解析在CI中破坏；评论停止发布。用ollama show <model> --modelfilepin模型digest。在升级到生产前在staging上升级新版本。
• 长期运行下的GPU内存碎片化。 GPU服务器运行24/7可碎片化VRAM，在数周后拒绝新分配。每周用cron作业重启ollama serve。便宜且完全避免此故障模式。
• CI运行器竞争。 自托管运行器同时承载LLM服务器和其他CI作业在构建负荷下会看到审查延迟尖峰。当团队规模超过~25开发者时分离运行器和GPU服务器。
• Diff大小漂移。 PR大小向上漂移；最终PR超过模型的实际上下文并无声地降级。添加guard来分割或截断超过约30K令牌的diff并警告作者。
• 电力和冷却。 持续加载的RTX 4090在推论下抽取约350W并产生大量热。没有主动冷却的小壁橱服务器房间会饥饿GPU；饥饿导致延迟而开发者注意。
• 遗忘日志轮转。 Ollama默认记录每个请求体。三个月后PR审查的日志文件含有纯文本的历史PR diff。按周轮转日志；按你的数据保留政策存档或清除。

设置本地LLM代码审查时的常见错误

• 错误1：在16 GB GPU上从7B模型开始。 Qwen3-Coder 7B审查显著比7B差。开发者快速失去信心，项目被搁置。如果不能容纳30B，在6个月内使用云API同时保障GPU预算。
• **错误2：第一天从block判决阻止PR。** 第一个月是校准；将所有输出视为建议直到假阳性率低于约5%时升级阻止。
• **错误3：在没有认证的0.0.0.0:11434上公开暴露ollama serve。** 这是LLM时代相当于将Redis绑定到公共接口。绑定到私有接口；在任何跨主机暴露前放置认证。
• 错误4：忽视缓存。 在每次CI运行重新审查未改变的文件浪费约80%的推论预算在典型PR上。小文件hash + diff hash缓存（Redis或SQLite）大幅减少审查延迟和GPU负荷。
• 错误5：在同个GPU上运行训练作业。 训练将VRAM使用激增到限制；使审查模型饥饿；导致30-120秒审查延迟侵蚀开发者系统信心。使用分离GPU或计划训练在不与PR峰值时段重叠的严格日程上。
• 错误6：没有反馈循环构建GitHub Action。 没有👍/👎反应的审查系统无法改进。第一周构建循环。收集数据；每月迭代提示。

资源

• Ollama Documentation — /api/chat、/api/generate、结构化输出和模型管理的官方API HTTP参考。
• vLLM Documentation — 高吞吐量推论服务器文档；对高并发团队的超越Ollama升级路径。
• GitHub Actions Documentation — 自托管运行器、秘密和上述工作流中使用的GitHub Actions JavaScript SDK的官方参考。
• GitHub Advanced Security定价 — 成本比较的价目表价格参考；验证你实际谈判的条款。
• Qwen3-Coder模型卡 — 推荐审查模型的架构、上下文窗口和许可条款。
• GitLab CI/CD参考 — GitLab团队的等效参考；工作流的LLM调用部分相同。

常见问题

相关阅读

• 用本地LLM替换GitHub Copilot — 考虑自托管AI工具团队成本替换的更广泛背景。
• Continue.dev vs Cline vs Aider：2026年最佳本地编码代理 — 在管道中运行什么vs交互编辑器工作；模型下的harness层。
• 2026年最佳本地编码模型 — 等式的模型端：Qwen3-Coder、DeepSeek、Codestral和许可景。
• 系统提示vs用户提示：有什么区别 — 审查提示系统的提示工程anchor。
• llama.cpp vs Ollama vs vLLM — 推论引擎比较；对高并发团队的vLLM超越Ollama升级路径。
• Power Local LLM Hub — 完整指南库。