去年我在嵌入式团队裁撤后转头搞AI部署，接的第一个活就是把大模型塞进CI流水线检测SQL注入。当时团队用的是正则规则集，漏报率高达42%，每周至少被甲方安全审计揪出三个绕过案例。我花了三周，把一个微调过的CodeBERT模型塞进了GitHub Actions的标准Runner——2核CPU、7GB内存、无GPU，最终推理延迟从850ms压到110ms，内存占用从620MB砍到180MB，准确率还守住了97.3%。这个过程没有用到一张A100，全是资源约束下的打磨，这篇笔记就是完整的复现手册。
30秒速览
- - 用CodeBERT在2000条SQL注入样本上微调，验证准确率97.5%，模型体积499MB
- - 通过ONNX导出+INT8量化，模型压缩到180MB，GitHub Actions 2核CPU上推理延迟从850ms降到110ms，内存峰值从620MB降到180MB
- - 集成GitHub Actions，在PR diff中自动检测注入，34秒内完成审查并评论，连续两周零误拦
第一步：用两千条SQL注入样本教会CodeBERT什么叫“危险”
我选的是微软的CodeBERT，microsoft/codebert-base（1.25亿参数），原始模型在代码理解任务上基础不错，但完全没做过安全分类。数据方面，我从CVE和GitHub Advisory Database收集了1200个包含SQL注入的代码片段，又从OWASP Benchmark和开源仓库的修复commit里抽了800个安全案例，拼成2000条的平衡二分类数据集。所有样本都是真实代码上下文，长度控制在256 token以内，保证训练时一张T4 16GB就能跑起来，不需要动用团队唯一的A10服务器。
微调只用了Transformers 4.45.0的Trainer接口，三行关键配置：学习率2e-5、batch size 32、训练3个epoch。分类头是单层Linear，输出safe/unsafe两个logit。我在Colab的T4上跑了12分钟，验证集准确率就稳在97.5%左右，召回率96.8%。模型体积不大，PyTorch checkpoint才499MB，但直接拿这个二进制放进CI Runner就是灾难——我测了一次，在GitHub Actions的2核CPU上单次推理850ms，内存峰值620MB，而且第一次加载就要9秒，这会把PR检查流程直接拖死。
# 核心微调代码片段
from transformers import AutoTokenizer, AutoModelForSequenceClassification, Trainer, TrainingArguments
model = AutoModelForSequenceClassification.from_pretrained("microsoft/codebert-base", num_labels=2)
tokenizer = AutoTokenizer.from_pretrained("microsoft/codebert-base")
# 数据集为两个文件夹：train/safe, train/unsafe，通过datasets库加载
training_args = TrainingArguments(output_dir="./results", num_train_epochs=3, per_device_train_batch_size=32, learning_rate=2e-5)
trainer = Trainer(model=model, args=training_args, train_dataset=train_dataset, eval_dataset=val_dataset)
trainer.train()第二步：把模型压进180MB，CI Runner推理从6秒落到2秒内
ONNX转换是第一个拐点。我用torch.onnx.export把CodeBERT的序列分类部分导出为静态图，输入固定为256 sequence length，batch size 1。转换后的ONNX模型体积从499MB微涨到502MB，但在CPU上推理时间已经降到320ms。真正的收益来自量化——我把模型从FP32压到INT8，使用onnxruntime的quantization工具，校准数据只用了200条训练集样本，量化后模型文件体积骤降到180MB，推理延迟直接砸到110ms，内存峰值控制在180MB左右，而且模型加载时间压缩到1.2秒。（延伸阅读：12GB显存里的ROI死磕：我把Gemma 2、Phi-3、Qwen-1.8B在法律/医疗微调上烧透了的成本账）
下面是三个版本的完整对比，测试平台是标准GitHub Actions ubuntu-22.04 runner（2 vCPU, 7 GB RAM, 仅CPU）：（延伸阅读：MTTR从47分钟砍到3分钟，但大模型给出的第一版修复建议差点rm -rf了生产库）
| 模型版本 | 体积 | 单次推理延迟 | 内存峰值 | 加载时间 | 准确率 |
|---|---|---|---|---|---|
| PyTorch FP32 | 499 MB | 850 ms | 620 MB | 9.2 s | 97.5% |
| ONNX FP32 | 502 MB | 320 ms | 410 MB | 3.1 s | 97.4% |
| ONNX INT8 量化 | 180 MB | 110 ms | 180 MB | 1.2 s | 97.3% |
精度掉0.2个点完全可以接受，因为这套审查系统的关键使命是抓漏报，不是追求实验室指标。量化后我特意拿50条刻意构造的绕过样本测试，发现一个都没放过去，召回率依旧在96%以上。唯一的问题是在INT8下，两个边缘样本的置信度从0.89降到0.72，但阈值设在0.5完全不受影响。于是我决定就用这个180MB的.onnx文件，随仓库一起分发，CI跑的时候直接从Git LFS拉取。（延伸阅读：我照着普林斯顿SWE‑Agent论文搭了一条需求即交付管线，但在生成验收标准上卡了两个月——LLM在第287次构建时给我上了一课）
第三步：让机器人在PR里自动开喷，连误报都附带置信度
GitHub Actions工作流我写得很克制，只在pull_request事件触发。核心脚本是一个单文件python程序，用onnxruntime加载模型，对PR diff中新增的每一处代码变更逐块推理。diff解析用Python标准库difflib，只抽取添加的行，拼接成token数不超过200的片段。如果模型输出“unsafe”且置信度高于0.75，脚本就调用GitHub API在对应的代码行下发布审查评论，附上风险类型和置信度分数。（延伸阅读：凌晨两点，线上模型开始胡言乱语，因为有人改了我的Prompt注释——于是我把MLflow塞进了LLM实验流水线）
测试那天我故意提了一个包含经典SQL注入的PR：query = "SELECT * FROM users WHERE name = '" + user_input + "'"。Actions在PR创建后23秒开始运行，4秒完成模型加载，110ms推理后直接在这行代码下炸出一条评论：“检测到SQL注入风险 (置信度0.94)，请使用参数化查询”。整条流水线从触发到评论出现总共34秒，完全在开发者能接受的等待区间内。我特意又提了三个安全写法，模型全部正确放了“safe”标签，没有误报。后来我们在三个内部项目里部署了这套检查，连续运行两周，在210次PR中准确标记出7处真实注入，零误拦，而且CI运行成本毫无增加——因为全部在免费额度的Runner上跑。
这个项目的真正收获不是又多了一个模型，而是证明了安全AI不必依赖大算力。一个1.25亿参数的CodeBERT，配上ONNX量化和合理的片段拆分，就能在GitHub Actions的弱鸡CPU上跑到生产可用。对那些还在用静态规则的团队，我建议直接用这个方案替换掉正则审查，漏报率从40%+压到个位数，代价仅仅是一个180MB的模型文件和两小时的微调时间。
