人工智能大模型AI 安全治理模型安全内容安全提示词注入防护RAG【免费下载链接】GuardrailsNeMo Guardrails is an open-source toolkit for easily adding programmable guardrails to LLM-based conversational systems.项目地址https://gitcode.com/gh_mirrors/ne/Guardrails点击查看免费下载NeMo Guardrails 为 LLM 对话系统提供了可编程的护栏Guardrails在提升安全性的同时必然引入额外延迟。本文基于开源仓库benchmark/README.md及其配套源码完整讲解如何利用仓库内置的 Mock LLM Server 与 AIPerf 压测工具在无 GPU、无外网的普通笔记本上快速搭建 Guardrails 基准测试环境量化安全性与延迟之间的权衡为容量规划与性能回归检测提供数据支撑。基准测试设计思路为什么要用 Mock LLM在真实生产环境中Guardrails 应用通常由两部分模型协同工作应用主LLM负责生成对用户查询的回复内容安全Content-SafetyLLM作为输入/输出护栏判断用户输入与模型输出是否安全。真实的 LLM 推理依赖 GPU 或外部云服务这给性能测试带来两个障碍本地无 GPU 无法运行模型云上模型受网络与配额影响难以得到稳定的基线。为此仓库提供了 Mock LLM Server一个实现了 OpenAI 兼容 API 子集的简化版 LLM用可配置的固定延迟与固定文本响应模拟真实模型的推理行为。这样设计的核心价值在于基准测试的延迟可控、可复现且与单元测试一样快速能够像运行单元测试一样及时发现 Guardrails 引擎的性能回归performance-regression。README 中明确说明了这一测试台testbench的适用范围运行 Guardrails 服务器 内容安全护栏 应用模型的 Mock 版本在无 GPU 的笔记本上即可进行性能测试整个流程几分钟内即可完成。基准测试的链路是AIPerf 客户端 → Guardrails 服务端口 9000→ 应用 Mock LLM端口 8000与内容安全 Mock LLM端口 8001。Guardrails 对用户查询先做输入内容安全检查再调用应用模型生成回复最后对输出再做一次内容安全检查——这多出来的两次内容安全推理调用正是安全带来的延迟的量化对象。Quickstart三步跑通 Guardrails 基准测试运行基准测试需要两个终端或两个 tmux pane第一个终端运行服务端组件Guardrails 服务器 Mock LLMs第二个终端运行客户端压测AIPerf。第 1 步启动服务端组件首先提高文件描述符上限。默认情况下操作系统会限制可打开的文件描述符数量从而限制可压测的并发数$ ulimit -n 65536然后安装 NeMo Guardrails 的 uv 管理虚拟环境以及用于解析 Procfile 并拉起服务的honcho包uv sync --locked --extra server uv pip install honcho依赖就绪后进入benchmark目录用 honcho 启动 Procfile 中的全部进程$ cd benchmark $ uv run honcho start 13:40:33 system | gr.1 started (pid93634) 13:40:33 system | app_llm.1 started (pid93635) 13:40:33 system | cs_llm.1 started (pid93636) ... 13:40:41 app_llm.1 | INFO: Uvicorn running on http://0.0.0.0:8000 (Press CTRLC to quit) ... 13:40:41 cs_llm.1 | INFO: Uvicorn running on http://0.0.0.0:8001 (Press CTRLC to quit) ... 13:40:45 gr.1 | INFO: Uvicorn running on http://0.0.0.0:9000 (Press CTRLC to quit)Procfile 中每个进程启动时都会以带前缀的日志输出到控制台system前缀属于 Honcho 自身app_llm是应用/主 LLM Mockcs_llm是内容安全 Mockgr是 Guardrails 服务。当看到三条 Uvicorn running on ... 消息后即可进入下一步注意这三条消息通常不在连续行上。从 Procfile 可以看出三个进程的具体命令进程命令端口说明gruv run nemoguardrails server --config ../examples/configs/content_safety_local --default-config-id content_safety_local --port 90009000Guardrails 服务器使用content_safety_local配置app_llmpython mock_llm_server/run_server.py --workers 4 --port 8000 --config-file mock_llm_server/configs/meta-llama-3.3-70b-instruct.env8000应用/主 Mock LLM4 个 uvicorn workercs_llmpython mock_llm_server/run_server.py --workers 4 --port 8001 --config-file mock_llm_server/configs/nvidia-llama-3.1-nemoguard-8b-content-safety.env8001内容安全 Mock LLM4 个 uvicorn worker其中gr进程通过MAIN_MODEL_BASE_URLhttp://localhost:8000/v1环境变量指定主模型指向应用 Mock LLM。注意这里app_llm/cs_llm使用的配置文件是Mock LLM 配置.env而非 Guardrails 配置两者格式完全不同。第 2 步验证服务是否正常服务启动后用 validate_mocks.sh 验证所有 Mock LLM 与 Guardrails 服务都在正常运行。该脚本依次检查8000 端口/health健康检查 /v1/models是否包含meta/llama-3.3-70b-instruct8001 端口/health健康检查 /v1/models是否包含nvidia/llama-3.1-nemoguard-8b-content-safety9000 端口/v1/rails/configs是否返回 HTTP 200且响应体是非空数组。在新终端中执行$ cd benchmark $ scripts/validate_mocks.sh Starting LLM endpoint health check... --- Checking Port: 8000 --- Checking http://localhost:8000/health ... Health Check PASSED: Status is healthy. Checking http://localhost:8000/v1/models for meta/llama-3.3-70b-instruct... Model Check PASSED: Found meta/llama-3.3-70b-instruct in model list. --- Port 8000: ALL CHECKS PASSED --- --- Checking Port: 8001 --- Checking http://localhost:8001/health ... Health Check PASSED: Status is healthy. Checking http://localhost:8001/v1/models for nvidia/llama-3.1-nemoguard-8b-content-safety... Model Check PASSED: Found nvidia/llama-3.1-nemoguard-8b-content-safety in model list. --- Port 8001: ALL CHECKS PASSED --- --- Checking Port: 9000 (Rails Config) --- Checking http://localhost:9000/v1/rails/configs ... HTTP Status PASSED: Got 200. Body Check PASSED: Response is an array with at least one entry. --- Port 9000: ALL CHECKS PASSED --- --- Final Summary --- Port 8000 (meta/llama-3.3-70b-instruct): PASSED Port 8001 (nvidia/llama-3.1-nemoguard-8b-content-safety): PASSED Port 9000 (Rails Config): PASSED --------------------- Overall Status: All endpoints are healthy!从脚本源码validate_mocks.sh可以看到它依赖curl与jq对每个端点做健康检查/health返回 JSON 且status字段为healthy与模型检查/v1/models返回列表且包含预期的模型名最后对 Guardrails 的/v1/rails/configs检查响应是否为含至少一个条目的数组。任一检查失败时脚本以非零退出码结束。第 3 步运行客户端压测 AIPerf在第二个终端同样先提高文件描述符上限然后创建独立的 Python 虚拟环境并安装 AIPerf以下命令在仓库根目录执行$ ulimit -n 65536 $ mkdir ~/env $ python -m venv ~/env/aiperf_env $ source ~/env/aiperf_env/bin/activate (aiperf_env) $ pip install aiperf ... Successfully installed Flask-3.1.3 MarkupSafe-3.0.3 Werkzeug-3.1.8 ..... yarl-1.23.0 zipp-4.1.0 zstandard-0.25.0 (aiperf_env) $使用仓库自带的sweep_concurrency_benchmark.yaml配置发起基准测试。该压测会向第 1 步启动的 Guardrails 服务端口 9000发起请求Guardrails 再转发请求给应用与内容安全 Mock LLM。并发数按 2 的幂从 1 扫到 256并使用合成的用户提示词(aiperf_env) $ python -m benchmark.aiperf --config-file benchmark/aiperf/configs/sweep_concurrency_benchmark.yaml 2026-05-19 14:19:47 INFO: Running AIPerf with configuration: benchmark/aiperf/configs/sweep_concurrency_benchmark.yaml 2026-05-19 14:19:47 INFO: Results root directory: aiperf_results/sweep_concurrency_benchmark/20260519_141947 2026-05-19 14:19:47 INFO: Sweeping parameters: {concurrency: [1, 2, 4, 8, 16, 32, 64, 128, 256]} 2026-05-19 14:19:47 INFO: Running 9 benchmarks 2026-05-19 14:19:47 INFO: Run 1/9 2026-05-19 14:19:47 INFO: Sweep parameters: {concurrency: 1} 2026-05-21 14:21:45 INFO: Run 1 completed successfully 2026-05-19 14:21:45 INFO: Run 2/9 2026-05-19 14:21:45 INFO: Sweep parameters: {concurrency: 2} 2026-05-19 14:23:19 INFO: Run 2 completed successfully ..... ..... 2026-05-19 14:29:58 INFO: Run 8/9 2026-05-19 14:29:58 INFO: Sweep parameters: {concurrency: 128} 2026-05-19 14:31:17 INFO: Run 8 completed successfully 2026-05-19 14:31:17 INFO: Run 9/9 2026-05-19 14:31:17 INFO: Sweep parameters: {concurrency: 256} 2026-05-19 14:32:37 INFO: Run 9 completed successfully 2026-05-19 14:32:37 INFO: SUMMARY 2026-05-19 14:32:37 INFO: Total runs : 9 2026-05-19 14:32:37 INFO: Completed : 9 2026-05-19 14:32:37 INFO: Failed : 0基准测试完成后结果保存在aiperf_results目录下路径格式为aiperf_results/batch_name/时间戳/参数组合目录。深入解析AIPerf 配置与执行原理AIPerf 基准测试由 benchmark/aiperf/run_aiperf.py 驱动入口为 benchmark/aiperf/main.py 中的python -m benchmark.aiperf。其工作流程可以拆解为加载并校验配置AIPerfRunner._load_config()读取 YAML 配置并用 Pydantic 模型 AIPerfConfig 校验非法配置直接以非零退出码终止检查服务可用性_check_service()先请求base_config.url下的/v1/models连接失败或非 200 响应都会抛出异常提前终止——避免在服务未就绪时浪费压测时间生成参数组合_get_sweep_combinations()对sweeps中的各参数做笛卡尔积生成全部组合上限 100 次运行每个组合对应一轮独立压测构造并执行命令_build_command()将 base_config 与 sweep 参数合并后转译为aiperf profile --model ... --url ... --concurrency N ...命令行参数下划线参数名自动转为连字符形式布尔值为True时仅追加标志若配置了api_key_env_var则从环境变量读取 API Key 注入命令日志中会自动脱敏只保留末尾 6 位保存可复现元数据每轮运行在输出目录写入 run_metadata.json含运行序号、时间戳、配置路径、sweep 参数、base_config 与脱敏后的完整命令和process_result.json子进程退出状态便于日后复跑与分析。AIPerf 配置文件字段详解benchmark/aiperf/configs/sweep_concurrency_benchmark.yaml 中定义了本次压测的全部参数顶层字段字段取值说明batch_namesweep_concurrency_benchmark本批基准测试的名称会作为输出目录名的一部分output_base_diraiperf_results所有结果的基础目录实际路径为output_base_dir/batch_name/sweep 值base_config模型与端点字段取值说明modelmeta/llama-3.3-70b-instruct压测请求中的模型名必须与 Guardrails 主模型及 Mock LLM 的MODEL一致tokenizermeta-llama/Llama-3.3-70B-Instruct可选的 HuggingFace tokenizer 名或本地目录用于精确计算 token 数urlhttp://localhost:9000目标服务地址Guardrails 服务endpoint/v1/chat/completionsAPI 端点路径endpoint_typechat端点类型可选chat或completionsbase_config负载生成字段取值说明warmup_request_count10正式压测前的预热请求数benchmark_duration60每轮压测时长秒concurrency0并发数此处为占位值由下方 sweep 覆盖request_rate_modeconstant请求速率模式可选constant恒定或poisson泊松分布base_config合成数据生成字段取值说明random_seed12345随机种子保证合成提示词可复现prompt_input_tokens_mean100输入 token 数的均值prompt_input_tokens_stddev10输入 token 数的标准差prompt_output_tokens_mean50输出 token 数的均值prompt_output_tokens_stddev5输出 token 数的标准差sweeps参数扫描sweeps: concurrency: [1, 2, 4, 8, 16, 32, 64, 128, 256]对并发数做 2 的幂扫描。注意在 Pydantic 校验模型aiperf_models.py中api_key_env_var用于需要鉴权的服务如真实云端模型本仓库的本地 Mock 场景无需配置request_rate可用于指定每秒请求数未提供时由 AIPerf 自动计算。每轮运行结束后可以在对应输出目录的run_metadata.json中查看该轮使用的完整命令行用于复现或对比。深入解析Procfile 与 Guardrails 配置Procfile 进程编排Procfile 是基准测试服务端的进程清单Honcho 读取该文件后一次性启动全部进程并合并输出日志。三行配置的含义分别是gr运行 Guardrails 服务器端口 9000默认配置指向 examples/configs/content_safety_localMAIN_MODEL_BASE_URL指向端口 8000 的应用 Mock LLMapp_llm应用/主 Mock LLMGuardrails 调用它生成用户查询的回复。使用4 个 uvicorn worker--workers 4运行在 8000 端口其配置文件是 Mock LLM 配置.env而非 Guardrails 配置cs_llm内容安全 Mock LLM同样使用 4 个 uvicorn worker运行在 8001 端口。需要说明的是启动命令中PYTHONPATH..将项目根目录加入模块搜索路径保证benchmark.mock_llm_server.api:app等绝对导入正常工作。Guardrails 配置content_safety_localGuardrails 服务器使用的配置位于 examples/configs/content_safety_local/config.yml其结构如下models: - type: main engine: nim model: meta/llama-3.3-70b-instruct parameters: base_url: http://localhost:8000/v1 - type: content_safety engine: nim model: nvidia/llama-3.1-nemoguard-8b-content-safety parameters: base_url: http://localhost:8001/v1 rails: input: flows: - content safety check input $modelcontent_safety output: flows: - content safety check output $modelcontent_safety关键配置点models段下的main模型用于生成用户查询的回复其base_url指向 Procfile 中的app_llmMock LLM8000 端口且model字段必须与 Mock LLM 的模型名完全一致meta/llama-3.3-70b-instruct否则 Mock 服务器会返回 400 错误——这一点在 api.py 的_validate_request_model()中强制校验content_safety模型配置为输入与输出护栏使用其type字段content_safety与输入/输出 flow 中$modelcontent_safety引用相对应rails段配置了两条护栏 flow输入侧content safety check input与输出侧content safety check output。正是这两条护栏导致每次对话请求实际产生三次模型调用输入检查 → 主模型生成 → 输出检查这就是加入 Guardrails 后延迟增加的直接来源。深入解析Mock LLM 的 OpenAI 兼容端点与配置端点实现Mock LLM Server 是基于 FastAPI 实现api.py实现 OpenAI API 的子集共四个端点端点方法说明/healthGET返回 JSON 对象status为healthytimestamp为秒级 epoch 时间例如{status:healthy,timestamp:1762781239}/v1/modelsGET返回 Mock 配置中的MODEL字段例如{object:list,data:[{id:meta/llama-3.3-70b-instruct,object:model,created:1762781290,owned_by:system}]}/v1/completionsPOST返回基于 Mock 配置生成的 OpenAI completion 对象/v1/chat/completionsPOST返回基于 Mock 配置生成的 OpenAI chat completion 对象此外还有根路径/返回服务器与模型基本信息。两个推理端点均校验请求中的model字段必须等于配置的MODEL并支持流式streamtrue与非流式两种模式非流式响应会返回usage基于每 4 字符约 1 token的粗略估算见 response_data.py 的calculate_tokens流式响应则以 Server-Sent Events 逐块发送。Mock LLM 配置格式与字段Mock LLM 使用.env 文件格式配置通过run_server.py的--config-file参数传入也支持CONFIG_FILE环境变量见 run_server.py。仓库提供了两个示例配置meta-llama-3.3-70b-instruct.env应用模型与 nvidia-llama-3.1-nemoguard-8b-content-safety.env内容安全模型。Mock LLM 对/v1/completions或/v1/chat/completions推理请求返回SAFE_TEXT或UNSAFE_TEXT返回不安全文本的概率由UNSAFE_PROBABILITY决定源码 response_data.py 中通过np.random.binomial(n1, punsafe_probability)采样实现。流式输出时响应文本按空白字符切分为多个 chunk因此chunk 数等于SAFE_TEXT或UNSAFE_TEXT中按空白分隔的单词数。完整配置字段清单如下字段说明MODELMock LLM 提供的模型名会通过/v1/models端点返回UNSAFE_PROBABILITY返回不安全响应的概率取值必须在 [0, 1] 区间UNSAFE_TEXT不安全响应时返回的字符串SAFE_TEXT安全响应时返回的字符串延迟模型截断正态分布每次推理请求的延迟从**截断正态分布truncated normal distribution**中采样共有三组延迟参数延迟名称含义E2E_LATENCY非流式响应的端到端延迟TTFT首 token 时间time to first token即流式响应中第一个 chunk 之前的延迟CHUNK_LATENCY块间延迟inter-token latencyITL即流式响应中每个后续 chunk 之前的延迟每组延迟包含四个参数*为上表任一延迟名称参数说明*_MEAN_SECONDS正态分布均值平均延迟单位秒*_STD_SECONDS正态分布标准差单位秒*_MIN_SECONDS最小延迟单位秒延迟必须非负 0*_MAX_SECONDS最大延迟单位秒采样规则为从正态分布N(MEAN, STD)采样一次再用np.clip将低于MIN的值截断为MIN、高于MAX的值截断为MAX见 response_data.py 的get_latency_seconds与generate_chunk_latencies。流式场景中第一个 chunk 使用 TTFT 参数后续 chunk 使用 CHUNK_LATENCY 参数。为什么使用截断正态分布普通的正态分布支撑域是无限的可能采样出负值对延迟毫无意义或异常大的值导致测试时间失控。截断后延迟被限制在[MIN, MAX]区间内既保持了真实模型延迟的随机波动特性又保证了测试的可控性。以应用模型配置为例MODELmeta/llama-3.3-70b-instruct UNSAFE_PROBABILITY0.0 UNSAFE_TEXTI cant help with that. Is there anything else I can assist you with? SAFE_TEXTI can provide information and help with a wide range of topics, from science and history to entertainment and culture. ... # End-to-end latency E2E_LATENCY_MIN_SECONDS4.0 E2E_LATENCY_MAX_SECONDS4.0 E2E_LATENCY_MEAN_SECONDS4.0 E2E_LATENCY_STD_SECONDS0.0 # Streaming latency: Time to First Token (TTFT) TTFT_MIN_SECONDS0.3 TTFT_MAX_SECONDS0.3 TTFT_MEAN_SECONDS0.3 TTFT_STD_SECONDS0.0 # Streaming latency: Chunk Latency (ITL) CHUNK_LATENCY_MIN_SECONDS0.015 CHUNK_LATENCY_MAX_SECONDS0.015 CHUNK_LATENCY_MEAN_SECONDS0.015 CHUNK_LATENCY_STD_SECONDS0.0内容安全模型配置与应用模型类似但端到端延迟约为 0.5 秒且SAFE_TEXT/UNSAFE_TEXT是内容安全模型特有的 JSON 形式判定结果如{User Safety: safe, Response Safety: safe}与{User Safety: unsafe, Response Safety: unsafe, Safety Categories: Violence, Criminal Planning/Confessions}。若未在 .env 中显式配置延迟参数config.py 中的 Pydantic 模型提供了默认值如e2e_latency_mean_seconds默认 0.5、ttft_mean_seconds默认 0.1、chunk_latency_mean_seconds默认 0.03 等并会通过 pydantic-settings 自动从 .env 文件加载。结果解读与延伸扩展输出目录结构每轮压测结果保存在独立目录中aiperf_results/ └── sweep_concurrency_benchmark/ └── 20260519_141947/ # 批次时间戳 ├── concurrency1/ # 参数组合目录如 concurrency1、concurrency2 ... │ ├── run_metadata.json # 该轮完整配置、命令与时间戳 │ └── process_result.json └── ...run_metadata.json记录了该轮 sweep 参数、base_config 和脱敏后的完整命令行是结果复现与审计的关键。如何扩展基准测试场景基于本文的配置结构可以按需扩展调整并发扫描范围修改 sweep_concurrency_benchmark.yaml 中sweeps.concurrency的值列表或增加prompt_input_tokens_mean等参数做多维度笛卡尔积扫描总运行数上限 100更换护栏配置Procfile 中gr进程的--config与--default-config-id指向 examples/configs/content_safety_local可替换为仓库中其他护栏示例如 jailbreak_detection、topic_safety 等来对比不同护栏的延迟开销模拟不同模型性能通过修改 .env 中的延迟参数模拟快/慢模型例如将E2E_LATENCY_MEAN_SECONDS调低模拟高速模型从而评估 Guardrails 在不同下游模型性能下的行为模拟不安全流量比例将UNSAFE_PROBABILITY调高如 0.5可模拟高比例的不安全请求观察内容安全护栏触发拒绝时的吞吐与延迟影响。注意事项与适用前提基准测试链路为AIPerf → Guardrails(9000) → 应用 Mock(8000) 内容安全 Mock(8001)压测前务必先用validate_mocks.sh确认三个端点全部健康提高ulimit -n是压测高并发128/256的必要前提否则操作系统文件描述符限制会制约实际并发本测试台的目标是性能回归检测与容量规划Mock 的固定延迟与实际模型存在差异测试结论用于横向对比 Guardrails 引擎在不同配置/版本下的相对表现而非替代真实模型端到端评测AIPerf 客户端与服务端需分别运行于两个终端且客户端命令需在仓库根目录benchmark上一级执行。相关资源导航基准测试主文档benchmark/README.md服务端进程编排benchmark/ProcfileAIPerf 执行器与入口benchmark/aiperf/run_aiperf.py、benchmark/aiperf/main.pyAIPerf 配置模型benchmark/aiperf/aiperf_models.pyAIPerf 压测配置benchmark/aiperf/configs/sweep_concurrency_benchmark.yamlMock LLM 服务实现benchmark/mock_llm_server/api.py、benchmark/mock_llm_server/response_data.py、benchmark/mock_llm_server/config.pyMock LLM 启动脚本benchmark/mock_llm_server/run_server.pyMock 模型配置benchmark/mock_llm_server/configs/meta-llama-3.3-70b-instruct.env、benchmark/mock_llm_server/configs/nvidia-llama-3.1-nemoguard-8b-content-safety.env健康检查脚本benchmark/scripts/validate_mocks.shGuardrails 基准配置examples/configs/content_safety_local/config.ymlMock 服务器与 AIPerf 的单元测试benchmark/tests/test_mock_api.py、benchmark/tests/test_run_aiperf.py、benchmark/tests/test_mock_response_data.py、benchmark/tests/test_aiperf_models.py通过这套工具链你可以在任何一台普通笔记本上快速搭建 Guardrails 的容量测试环境将安全护栏引入多少延迟这个问题转化为可量化、可复现的数据为生产部署的容量规划与护栏配置选型提供依据。赞分享人工智能大模型AI 安全治理模型安全内容安全提示词注入防护RAG【免费下载链接】GuardrailsNeMo Guardrails is an open-source toolkit for easily adding programmable guardrails to LLM-based conversational systems.项目地址https://gitcode.com/gh_mirrors/ne/Guardrails点击查看免费下载相关推荐QtScrcpy性能基准测试帧率/延迟/CPU占用量化分析终极指南QtScrcpy性能基准测试帧率/延迟/CPU占用量化分析终极指南 QtScrcpy是一款开源的Android实时投屏软件通过USB或TCP/IP连接And桌面应用音视频自进化AI智能体发展路径Awesome-Self-Evolving-Agents时间线解析自进化AI智能体发展路径Awesome Self Evolving Agents时间线解析 自进化AI智能体是当前人工智能领域的前沿方向Awesome Se从 Annoy 到精确 NumPy 检索NeMo Guardrails 嵌入后端基准测试完全指南从 Annoy 到精确 NumPy 检索NeMo Guardrails 嵌入后端基准测试完全指南 NeMo Guardrails 默认的 BasicEmbed人工智能大模型AI 安全治理模型安全内容安全提示词注入防护RAG上一篇AB下载管理器终极指南如何快速部署和使用这款免费开源下载工具下一篇Leasot实战案例在大型TypeScript项目中管理技术债务创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考