在受监管、主权或源敏感型环境中部署 AI 编码助手通常会面临挑战。三个常见问题是：来源无法离开网络；助手偶尔会发明引入供应链风险的软件包名称；当生成的更改交付缺陷时，没有审计跟踪。
本教程将带您了解如何在 NVIDIA 基础架构上自行托管经过验证的编码助手，从而解决上述所有三个问题。最后，您将拥有一个 StarCoder2-7B NIM 端点，通过您自己的 GPU 完成代码；面前有一个 NVIDIA NeMo Guardrails 策略，可拒绝您标记为仅限人类访问的文件的请求；一个 CI 验证阶段，可在审查前捕获具有幻觉的软件包；具有提交级可追溯性；还有一个最小指标循环，可告知您 AI 辅助的补丁程序是在改善还是损害您的体验
教程预备知识和说明
要按照教程操作，您需要：
- NGC API 密钥
- 显存至少 24 GB 的受支持 NVIDIA GPU (例如，NVIDIA A10、L4、L40S 或 A100)
- 使用 NVIDIA 容器工具包的 Docker
- Python 3.10 及以上版本
- 您可以尝试使用一个 Git 存储库
StarCoder2-7B 在 BF16 中运行。NVIDIA H100 和 H200 GPU 可提供经过认证的高吞吐量配置文件，但飞行员无需使用。本教程中的每个构件都以内联方式显示，而且尺寸足够小，可以直接复制到您的项目中。
经过验证的编码助手的架构包括三层 (图 1) 。在顶部，开发者 IDE 向 NeMo Guardrails 代理发送请求，该代理位于 StarCoder2 NIM 前面，可在您自己的 GPU 上完成任务。然后，提交通过 CI 验证门流向审核者并进行合并。合并的拉取请求会输入 Prometheus 和 Grafana 指标循环，其逃生速率信号循环会返回以加强 NeMo Guardrails 策略。
组件有意设置为较小。每个步骤都非常有用，因此团队可以逐步采用该系统，而不是将自托管 AI 辅助视为一次大规模迁移。
重要的设计选择是模型不是控制平面。该模型提出了代码，但策略执行、依赖项验证、源可追溯性和结果测量都位于工程团队已经信任的系统中的模型之外。这种方法保持了可理解的部署。如果建议被阻止，您可以查看 NeMo Guardrails 策略。如果软件包被拒绝，您可以检查依赖项扫描输出。如果 AI 辅助更改回归，您可以检查用于人工编写更改的相同生产指标。
第 1 步：将 StarCoder2 部署为 NVIDIA NIM
NIM 将 StarCoder2 作为容器推出，该容器具有与 OpenAI 兼容的端点，这是大多数集成开发环境 (IDE) 助手所期望的。将容器固定到 NGC 目录中的特定版本，而不是使用无版本控制的标签。
export NGC_API_KEY=<your-ngc-key>
export STARCODER_NIM_VERSION=<latest-tag-from-ngc>
export LOCAL_NIM_CACHE=~/.cache/nim
mkdir -p "$LOCAL_NIM_CACHE"
docker run -d --name starcoder2-nim \
--gpus all \
--shm-size=16GB \
-e NGC_API_KEY \
-v "$LOCAL_NIM_CACHE:/opt/nim/.cache" \
-u $(id -u) \
-p 8000:8000 \
nvcr.io/nim/bigcode/starcoder2-7b:${STARCODER_NIM_VERSION}
接下来，验证端点：
curl http://localhost:8000/v1/health/ready
curl http://localhost:8000/v1/completions \
-H "Content-Type: application/json" \
-d '{
"model": "bigcode/starcoder2-7b",
"prompt": "def fibonacci(n: int) -> int:\n ",
"max_tokens": 64
}'
目前没有源代码离开您的网络。模型端点也是您可以通过内部平台目录固定、扫描和推广的相同构件。
对于试点，在单个共享 GPU 主机上运行端点，并限制对单个团队的访问。如需更广泛地推广，请将 NIM 放在内部服务网格或负载均衡器后面，将 NGC 密钥保留在密钥管理器中，然后通过用于其他开发者服务的同一平台通道发布固定镜像版本。
第 2 步：将 StarCoder2 NIM 连接到 IDE
大多数现代 IDE 助手都接受兼容 OpenAI 的自定义基础 URL。例如，Continue 可以直接指向本地 NIM 端点：
{
"models": [
{
"title": "StarCoder2 NIM (self-hosted)",
"provider": "openai",
"model": "bigcode/starcoder2-7b",
"apiBase": "http://localhost:8000/v1",
"apiKey": "not-needed-for-local-nim"
}
],
"tabAutocompleteModel": {
"title": "StarCoder2 NIM (autocomplete)",
"provider": "openai",
"model": "bigcode/starcoder2-7b",
"apiBase": "http://localhost:8000/v1"
}
}
支持自定义 OpenAI 端点的 Cursor、Cline 和其他工具也遵循相同的模式。
对于已拥有 IDE 标准的团队，请保持 NIM 端点稳定，并将 IDE 适配器作为可替换部件。这样，组织就可以比较助手，而无需更改下面的模型服务层、策略层、CI 层或指标层。
第 3 步：在 NIM 前安装 NVIDIA NeMo Guardrails
此步骤引入了验证。NeMo Guardrails 位于 IDE 和 NIM 之间，可以拒绝违反书面任务策略的请求。例如，“请勿生成身份验证、支付或加密代码”。这直接映射到许多团队已在 AI 使用策略中定义的仅限人类的路径。
pip install nemoguardrails openai
mkdir -p code-rails/config
现在，创建 code-rails/config/config.yml：
models:
- type: main
engine: openai
parameters:
base_url: http://localhost:8000/v1
api_key: not-needed-for-local-nim
model: bigcode/starcoder2-7b
rails:
input:
flows:
- check task policy
prompts:
- task: self_check_input
content: |
Decide whether the following code request touches any of:
- authentication / login / session handling
- payment processing
- cryptography / key material
- file paths under src/security/, src/auth/, or src/payments/
Reply with only "YES" or "NO".
Request:
{{ user_input }}
然后创建 code-rails/config/rails.co：
define flow check task policy
$allowed = execute self_check_input
if not $allowed
bot refuse with policy message
stop
define bot refuse with policy message
"This path is marked human-only by your AI usage policy. Please author it manually and request review."
内置的 self_check_input 动作渲染 self_check_input 提示词，调用模型，并在提示词应答 YES 时返回一个布尔值：False (该请求涉及的是人类专用路径) 。当请求不被允许时，流将拒绝。
接下来，运行 NeMo Guardrails 作为兼容 OpenAI 的代理：
nemoguardrails server --config=code-rails/config --port=8100
然后将 IDE 指向 http://localhost:8100/v1 而不是 http://localhost:8000/v1。接触受限路径的请求会在到达模型之前遭到拦截，开发者会收到清晰的策略消息，而不是冒险完成。
在读取图 2 中的序列时，NeMo Guardrails 会在调用模型之前运行 self_check_input。触及人类专用路径的请求将被当场拒绝，且永远无法到达 NIM，同时将允许的请求转发给 NIM，并将完成内容返回给 IDE。
从保守策略入手。人工路径的首选方案包括身份验证、授权、支付处理、加密、部署清单和事件响应自动化。当团队拥有足够的审查数据来证明助手在较小区域内的安全时，他们可以稍后放松策略。
第 4 步：添加 CI 验证门
IDE 中的生成控制是必要的，但还不够。在 CI 中，您会发现包裹幻觉、许可证漂移、秘密泄露和不安全的模式，然后再由审核者负责。
图 3 从左到右显示。标记为 ai-assisted 的拉取请求 (PR) 会经过单元测试、SAST、秘密扫描、幻觉依赖扫描和许可扫描，在普通测试套件之上对模型进行分层特定检查。如果每个检查都通过，更改将交给人工审核者；如果任何步骤失败，则阻止拉取请求并命名违规阶段。
添加仅在 PR 带有 ai-assisted 标签时才运行的 AI 辅助 PR 工作流。与其重塑每次检查，倒不如使用经过维护的开源工具：
name: ai-assisted-pr-checks
on:
pull_request:
types: [opened, synchronize, labeled]
jobs:
verification:
if: contains(github.event.pull_request.labels.*.name, 'ai-assisted')
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- uses: actions/setup-python@v5
with:
python-version: "3.11"
- name: Run unit tests
run: make test
- name: SAST (Semgrep)
run: |
pip install semgrep
semgrep ci --config p/ci
- name: Secret scan
uses: gitleaks/gitleaks-action@v2
- name: Hallucinated-dependency (slopsquatting) scan
run: |
pip install dep-hallucinator
dep-hallucinator scan requirements.txt
- name: License scan
run: |
pip install -r requirements.txt
pip install pip-licenses
pip-licenses --partial-match --fail-on="GPL;AGPL;LGPL;SSPL"
依赖项扫描是最有效的步骤，因为它针对的是代码模型特有的故障模式，现在通常称为 slopsquatting。该模型发明了一个看似合理的软件包名称，攻击者在公共注册表中注册了该名称，然后这种幻觉般的依赖关系会将真正的恶意软件发送给任何安装该建议的人。一些经过维护的扫描仪会根据真实注册表检查每个新添加的依赖项，并标记不存在、最近注册或与热门软件包非常相似的名称，从而检测出这种情况：
- dep-hallucinator：PyPI、npm、Maven、crates.io 和 Go；命名启发式算法；SBOM 输出；CI 退出代码
- slopgate：Python、npm 和 Go；感知 PR 差异 (
slopgate scan . --added-only --base-ref origin/main) ；将 SARIF 上传到“Security” (安全) 选项卡 - XBOM：将 CVE 扫描、slopsquatting 检测和 SBOM 生成集于一身
将您选择的任何工具固定到特定版本，就像固定任何其他依赖项一样。请注意，StarCoder2 NIM 容器已经为模型图像本身提供了经过签名的 SBOM 和 VEX 记录，因此这些扫描仪可以覆盖应用的依赖项清单，而 NVIDIA 则可以覆盖模型容器。如需了解更多详情，请参阅使用 NVIDIA NIM 安全部署 AI 模型。
对于许可证漂移，如果新提取的依赖项带有您的法律团队阻止的 copyleft 系列，则使用 pip-licenses 会导致构建失败。要获得更丰富的多生态系统物料清单，您可以显示不同参考之间的差异，并使用 Syft 或 cyclonedx-bom 生成一个。
对于无法添加第三方工具的气隙 CI，同样的检查大约是 40 行标准库。首先，比较基础和头部参考之间的清单文件。然后，查询注册表中每个新添加的名称，并在 404 (发明) 、低于值的首次发布日期 (可能是拼写错误) 或 copyleft 许可证失败。将手持版本视为备用版本，而不是取代之前提到的经过维护的扫描仪。
对于 GitLab，同等作业可以在 .gitlab-ci.yml 中运行，其规则为 CI_MERGE_REQUEST_LABELS 与 ai-assisted 相匹配。相同的工具不会改变。
保持此门比基准管道更严格。AI 辅助 PR 应通过正常的测试套件，并针对模型故障模式进行检查，包括具有幻觉的软件包、从提示中复制的秘密、从公共代码中提取的不安全示例，以及人类审查员不会注意到的依赖许可证。
第 5 步：实现 AI 协助的可追溯性
您无法测量无法标记的内容。安装 prepare-commit-msg hook，以便在助手的帮助下编写的提交带有结构化预告片：
#!/usr/bin/env bash
COMMIT_MSG_FILE=$1
if [[ -n "$AI_ASSISTANT" ]]; then
{
echo
echo "AI-Assistant: ${AI_ASSISTANT}"
echo "AI-Scope: ${AI_SCOPE:-unspecified}"
} >> "$COMMIT_MSG_FILE"
fi
为每个存储库激活一次此内容：
git config core.hooksPath .githooks
chmod +x .githooks/prepare-commit-msg
然后在用于启动 IDE 的 shell 中导出 AI_ASSISTANT=starcoder2-nim。现在，每个受助手影响的提交都会带有一个预告片，并且 CI 可以通过 grep 提交消息自动标记 PR。
请勿将此预告片用作抱怨机制。它的工作是测量。有用的问题不是特定开发者是否使用了 AI，而是 AI 辅助更改是否具有与基准不同的审查延迟、回滚率或缺陷漏报率。
第 6 步：线缆结果指标
接受率是不够的。它将琐碎的完成与有意义的工程工作混为一谈。重要的指标包括缺陷逃脱率、回滚频率、审查延迟和事件数量，并按 AI 辅助与基准进行细分。
最小的 Prometheus 导出工具可以从以下两个计数器开始：
from prometheus_client import Counter, start_http_server
escape = Counter("ai_assisted_defects_escaped_total",
"Defects shipped to prod from AI-assisted PRs", ["severity"])
rollback = Counter("ai_assisted_rollbacks_total", "Reverts of AI-assisted PRs")
填写导出工具以轮询合并的 ai-assisted PR，通过关联事件问题增加 escape，通过恢复 PR 增加 rollback，并在端口 9101 上公开 /metrics，以便 Prometheus 进行抓取。跟踪您已统计过的 PR 和事件，以便重复投票不会导致计数器膨胀。
从现有的 Prometheus 中选择导出工具，并在基准旁边绘制 AI 辅助的序列。如果 AI 辅助的逃离率趋势连续两周高于基准，请加强任务策略、添加 CI 门或暂停发布。图 4 将此过程显示为蛇形循环。
第一行从左到右运行，其中合并的 AI 辅助提取请求和事件信号输入 Prometheus 导出器，由 Prometheus 抓取并由 Grafana 可视化。然后，信号从 Grafana 控制面板下降到底部行，该行从右至左运行，并将 AI 辅助与缺陷漏报率、回滚频率、审查延迟和事件计数的基准进行比较，最后是收紧任务策略，或在漏报率保持较高时暂停发布。
可选：使用 NVIDIA NeMo 框架对模型进行域调整
现成的 StarCoder2 可以让内部 API 产生幻觉，因为它从未见过这些 API。NVIDIA ChipNeMo 研究表明，在特定领域的语料库上持续预训练、监督式微调和检索自定义如何提高专业工程领域的助手质量。
如果您有大型内部语料库，NeMo 框架可提供用于持续预训练、监督式微调和检索自定义的构建块。然后，可以将领域自适应模型打包为 NIM，并将其放入第 1 步，而无需更改护栏、CI、可追溯性或指标。
这种分离使架构经久耐用。您可以先从 StarCoder2 开始，之后切换为更强大的代码调优模型，并最终部署领域自适应的 NIM，而无需重写其周围的验证工作流。
第 7 步：验证完整循环
在将设置交给团队之前，请按照以下步骤运行一次烟雾测试：
- 让助手按照允许的路径编写辅助程序。确认收到的建议。
- 要求它修改
src/auth/login.py。通过策略消息确认 NeMo Guardrails 已拒绝。 - 使用引入虚假软件包名称的 AI 辅助更改打开 PR。确认域名抢注扫描检查失败。
- 打开一个干净的 AI 辅助 PR。确认
ai-assisted标签会触发完整的验证作业，且提交内容会带有AI-Assistant预告片。 - 还原 AI 辅助的 PR。确认回滚计数器的增量。
单个组件的任何故障点都可以单独修复。这就是将管道构建为可分离部分的价值所在。
最后步骤
固定 NIM 容器版本，并将其添加到平台团队的标准目录中。如果有超过几位开发者使用负载均衡器，请将 NeMo Guardrails 移至其后面。将您现有的静态分析和测试门置于 AI 辅助验证阶段之后，以便 AI 辅助 PR 通过严格的基准检查超集。如果助手开始缺少内部 API，请评估用于领域适应性的 NeMo 框架，以及用于每个开发者可复制环境的 NVIDIA AI Workbench。
了解详情
可信代码助手是管道，而不是模型。将 StarCoder2 作为 NIM 提供服务时，您的源代码会保留在自己的 GPU 上。NeMo Guardrails 会在人类路径请求到达模型之前拒绝这些请求。在审查人员开始负责之前，CI 大门会捕获到幻觉包裹、泄露的秘密和许可证漂移。提交预告片使 AI 辅助的更改具有可追溯性，而结果指标则会告诉您这些更改是改善了缺陷率，还是损害了缺陷率。
由于策略、验证、可追溯性和测量都位于模型之外，因此您可以逐层采用这些层，然后切换到更强大或领域自适应的模型，而无需围绕该模型重写验证。
如需详细了解本教程中使用的 NVIDIA 组件，请查看以下相关资源：
- StarCoder2 NIM：查看第 1 步中的模型卡、API 参考和容器部署步骤。
- NeMo Guardrails：查看步骤 3 中任务策略背后的轨道、流程和操作。
- 使用 NVIDIA NIM 安全部署 AI 模型：阅读已签名的 SBOM 和 VEX 记录，以补充第 4 步中的依赖项扫描。
- NeMo 框架：持续的预训练、监督式微调和检索自定义，以根据领域调整模型。
