ENSP脚本自动化调用LLama-Factory REST API完成配置生成

ENSP脚本自动化调用LLama-Factory REST API完成配置生成

在现代网络运维中，一个常见的痛点是：即便只是部署一组VLAN或配置几条ACL规则，工程师仍需逐行敲入命令，反复核对语法与逻辑。稍有疏忽，就可能导致整网中断。更现实的问题是——新员工上手难、跨厂商设备命令不统一、多人协作时配置风格不一致……这些都让“自动化”成为刚需。

而如今，随着大语言模型（LLM）能力的跃迁，我们不再满足于“脚本替代人工输入”，而是追求更高阶的智能：能否直接用自然语言描述需求，由AI自动生成准确、可执行的设备配置？

答案是肯定的。通过将华为ENSP仿真平台的Python脚本能力，与基于LLama-Factory框架部署的定制化大模型API结合，我们可以构建一条完整的“意图→配置→验证”自动化链路。这条路径不仅技术可行，而且已在实验环境中稳定运行。

想象这样一个场景：你在ENSP中画好拓扑后，只需填写一行需求：

“创建VLAN 10用于财务部，接口G0/0/1加入；VLAN 20为研发部使用，接口G0/0/2加入；SVI地址分别为192.168.10.1/24和192.168.20.1/24，并启用DHCP。”

下一秒，系统自动输出如下CLI命令并注入交换机：

vlan batch 10 20 interface GigabitEthernet0/0/1 port link-type access port default vlan 10 interface GigabitEthernet0/0/2 port link-type access port default vlan 20 interface Vlanif10 ip address 192.168.10.1 255.255.255.0 dhcp select interface interface Vlanif20 ip address 192.168.20.1 255.255.255.0 dhcp select interface

这一切的背后，正是LLama-Factory训练出的领域专用模型在起作用。它不是通用聊天机器人，而是经过大量华为CLI语料微调后的“网络专家”。它的输出高度结构化、无冗余解释、符合命令层级规范，甚至能自动补全隐含动作（如system-view进入全局模式）。

要实现这种能力，核心在于两个系统的协同：一端是具备推理服务能力的LLama-Factory，另一端是能够发起HTTP请求并将结果落地的ENSP脚本引擎。

先看服务端。LLama-Factory之所以适合此类任务，是因为它提供了一套标准化、模块化的全流程支持。你可以从Hugging Face加载Qwen-7B作为基座模型，然后使用LoRA进行高效微调。训练数据可以是一张Excel表，左边是自然语言描述，右边是对应的完整CLI配置。例如：

整个训练过程可通过YAML配置驱动，无需编写复杂代码。一旦完成微调，即可启动REST API服务：

CUDA_VISIBLE_DEVICES=0 python src/train_bash.py \ --stage api \ --model_name_or_path /models/Qwen-7B \ --adapter_name_or_path /adapters/qwen-lora-network \ --template qwen \ --finetuning_type lora \ --api_host 0.0.0.0 \ --api_port 8080

这个命令会启动一个基于FastAPI的服务，监听在8080端口，暴露标准OpenAI风格接口/v1/completions。这意味着任何能发POST请求的应用都可以调用它——包括运行在ENSP中的Python脚本。

值得注意的是，--template qwen参数至关重要。不同模型对输入格式的要求不同，Qwen需要特定的tokenization方式，若忽略此参数，可能导致模型无法正确理解提示词。此外，低秩适配（LoRA）使得我们只需保存几MB的小型权重文件，就能复用庞大的基础模型，极大降低部署成本。

当API就绪后，接下来就是客户端集成。ENSP虽然主要面向图形化操作，但它内置了Python脚本支持，允许开发者扩展功能边界。关键点在于：如何让脚本安全、可靠地与外部服务通信，并将文本结果转化为有效配置？

以下是一个精简但实用的实现片段：

import requests import time class NetworkConfigAI: def __init__(self, api_url="http://192.168.1.100:8080/v1/completions"): self.api_url = api_url self.headers = {"Content-Type": "application/json"} def generate(self, requirement: str) -> str: payload = { "model": "qwen-7b-lora-network", "prompt": f"你是一名资深华为网络工程师，请根据以下需求生成精确的CLI配置命令：\n{requirement}\n只输出命令，不要任何解释。", "max_tokens": 1024, "temperature": 0.2, "top_p": 0.85, "stop": ["#", "注：", "说明："] } try: response = requests.post(self.api_url, json=payload, headers=self.headers, timeout=30) if response.status_code == 200: return response.json()["choices"][0]["text"].strip() else: raise Exception(f"{response.status_code}: {response.text}") except Exception as e: return f"# 请求失败：{e}"

这里有几个工程上的细节值得强调：

• temperature设为0.2：确保输出稳定，避免创造性“发挥”。
• 添加stop tokens：防止模型输出无关内容，比如自动追加注释。
• 设置30秒超时：大模型推理可能耗时较长，尤其是首次加载时，必须避免脚本过早中断。
• 错误兜底机制：即使API不可达，也要返回可识别的失败标记，便于后续排查。

获取到配置文本后，下一步是将其应用到虚拟设备。这依赖于ENSP提供的设备控制接口（假设存在SDK形式的封装）：

def apply_to_device(self, device, config_lines): device.send_command("system-view") time.sleep(0.5) for line in config_lines.splitlines(): line = line.strip() if not line or line.startswith(('#', '!', '//', '---', '说明')): continue if line.lower() in ['quit', 'exit', 'reboot', 'delete flash:']: print(f"危险命令拦截：{line}") continue device.send_command(line) time.sleep(0.1) # 控制发送速率，模拟人工输入 device.commit() # 若支持事务提交 print(f"配置已下发至 {device.name}")

这段逻辑中加入了基本的安全防护：过滤掉潜在高危指令（如重启、删除存储），同时通过延时控制命令节奏，防止因过快输入导致设备缓冲区溢出或命令解析错误。

整个系统的架构其实非常清晰：

+------------------+ +----------------------------+ | | HTTP | | | ENSP Client | ----> | LLama-Factory REST API | | (Script Engine) | | (Running on GPU Server) | | | | | +------------------+ +----------------------------+ | | | +---> [Qwen-7B + LoRA] | +---> [Data: Huawei CLI corpus] | v +------------------+ | Virtual Devices | | (Switch, Router) | +------------------+

所有交互基于JSON over HTTP完成，完全解耦。服务端可在内网GPU服务器上长期运行，客户端则按需调用。通信延迟通常在3~8秒之间（取决于模型大小和硬件性能），对于非实时性要求的配置生成场景完全可以接受。

更重要的是，这套方案带来了传统方式难以企及的优势：

• 一致性保障：同一类需求每次生成的配置结构一致，杜绝“一人一种写法”的问题；
• 知识沉淀：模型本身就是一个可复用的知识库，新人培训周期大幅缩短；
• 审计追踪：每一次生成都可以记录原始prompt与输出结果，形成完整日志链；
• 持续进化：若某次生成出错，可将修正后的配置加入训练集，迭代优化模型。

当然，在实际落地时也需要考虑一些现实约束。

首先是安全性。虽然目前API仅限内网访问，但仍建议做进一步加固：
- 使用Nginx反向代理增加身份认证；
- 对输入内容做正则过滤，屏蔽敏感关键词；
- 在模型层面加入“拒绝回答”机制，例如当检测到越权请求时主动终止输出。

其次是可靠性。模型并非永远正确，尤其面对罕见拓扑或复合策略时可能出现遗漏。因此，生成后的配置仍需配合自动化测试验证。好在ENSP本身就支持仿真连通性检测，可以编写脚本自动Ping网关、抓包分析ARP响应等，形成闭环反馈。

最后是扩展性。当前聚焦于华为设备，但只需更换训练语料和模板（--template huawei→--template cisco），即可快速适配H3C、Cisco等其他厂商。未来甚至可构建多模型路由机制，根据目标设备类型动态选择最优AI引擎。

回过头看，这项技术融合的意义远不止“省几个命令”那么简单。它标志着网络运维正在从“手工编程”迈向“意图驱动”的新时代。

过去，我们教会机器“怎么做”；现在，我们只需告诉它“做什么”。

而LLama-Factory这样的开源框架，正是打通AI能力与行业系统的桥梁。它把复杂的微调流程封装成一条命令，又通过标准化API让模型能力像水电一样即插即用。当这类工具与ENSP这类专业平台相遇，所产生的化学反应才刚刚开始。

也许不久的将来，我们会看到更多类似的组合：
- 用AI生成防火墙策略草案；
- 根据流量日志自动推荐QoS配置；
- 将故障告警翻译成自然语言诊断报告……

每一步，都在推动网络系统向自治化演进。

而现在，你只需要写一段Python脚本，就能迈出第一步。