空桑

Appearance

AI在ctf中的应用 ​

这速度太快了 —— 图恒宇

目前测试了一下本地AI打CTF，感受到惊人的速度与算力提升，分钟级速通带来与传统CTF手工题解完全不同的体验。颠覆性的变革，且同质化程度极高门槛极低，很多意想不到的环节反而成了瓶颈

尽管PD速度300/20非常慢，但是对于人类极限的每分钟1200/300的输入输出速度而言依然堪称光速，ctf的竞赛的逻辑被彻底改变。进入分钟级一血时代

ctf非常吃长上下文和KV缓存，甚至由于KV缓存爆掉可能带来无可挽回的损失

操作速度上脚本 >> 云端模型 >> 本地小模型 > 本地大模型。因此为了节省宝贵的token，能用脚本的就绝不要模型自行处理

准备 ​

  • HyperVistor：vmware虚拟机，不建议WSL，磁盘有点慢
  • Kali虚拟机及运行环境：Kali虚拟机及容器和代理镜像等
  • LLM后端服务：lm-studio或unsloth-studio底层软件
  • 渗透harness：deepseek-harness、cyberstrike
  • 指导大模型：deepseek or gpt。https://platform.deepseek.com

常见QA ​

  • 做的越慢，做的越快悖论：大模型的智力功率是有限的，尽管小参数模型看起来更快，但很多都是无效思考和重复复读，尽管大参数量模型速度慢但可能更少token所以更快做完。变相的the more you buy，the more you save

本地模型 ​

本地模型的特点就是受限、上下文及并发受限，无法开展大规模并发以数量换质量

三种硬件、四种模型 ​

三种硬件指的是常见的三种设备，相同模型的速度差不多2:6:1

  1. 大内存UMA设备: 128G+显存，4060级别的算力。GB10、AIMAX395、MAC PRO
  2. 大显存显卡：24G+显存，4090级别算力。5090、4090
  3. 内存核显：32g内存的一般，1030级别算力。本地5060或者HX370、X7 358H等

四种模型（至少也要q2量化，q1太蠢了）。1、2的速度基本一致、3、4的速度也基本一致

  1. 核显/凑合的辅助模型：3-9B级别，能跑就行了，不做探讨
  2. 高速而生的35BA3B MOE：3-10K+Prefill、Decode 100+的超高速模型，要速度有速度要质量有速度。不过根据“做的越慢，做的越快”定律来说太快了
  3. 消费级显卡极限的27B级别Dense模型：pd相对较慢，395上差不多300+20，但算是最快的有一定智力的模型了
  4. FLASH级别的MOE模型：基本上300+Prefill速度、Decode速度20，已经踩着合格下限的速度了，而且未来新模型有128G显存撑不下的倒霉问题了

硬件准备 ​

没什么好说的，清清灰，重点是保证别死机了

  1. BIOS内调成高性能模式，清灰，少装垃圾软件。懂得可以显卡降压超频频率和拉显存
  2. 有线网卡、电源、硬盘不要有问题
  3. 烤机确认下没问题

软件准备 ​

N卡基本上没什么兼容性问题，A卡问题比较大，需要linux环境

基本上所有版本的大模型后端服务都是llama.cpp，不论是lm-studio/unsloth，实际上unsloth desktop体验和自动调优做的比较好但是麻烦，参数不太自由，LM Studio比较简单直接。linux下N卡可以考虑VLLM和SGLANG调优，AMD就windows vulkan/Linux RoCM的llama.cpp组合得了

系统级调优 ​

windows默认共享显存为内存一半：即395 windows下很难跑的通大模型，小模型速度又比不上显卡

395专项调优

bash
# linux 7.0内核以后对395兼容性还行。可以GTT设置分配112G显存并且关闭iommu提升性能
nano /etc/default/grub "ttm.pages_limit=29360128 amd_iommu=off"
update-grub
reboot

启动参数调优 ​

微调基本没什么意义，unsloth自动调就完事了，压榨不出来什么性能。控制核心参数就行

  • 核心出装：上下文、并发、MTP
    • 上下文长度：有多长拉多长
    • 并发：llama.cpp有slot概念，且是硬性共享直接除法，实际可用长度为上下文长度/并发，尽可能控制在128k以上
    • mtp：同系列小模型当草稿省算力，可以开，预测长度2-4就行
  • 辅助：该不该差距不大
    • KV缓存：尽可能不量化f16、最多q8。会积累误差导致智力下降
    • 视觉：可开可不开，除了MISC应该没啥用
    • Micro-batch Size：小上下文设置到256性能有提升，但是没什么意义
    • 1M上下文 --rope-scaling yarn --yarn-orig-ctx 1024000

模型选择 ​

模型上没什么好说的，qwen、DS、glm这三家。小模型千问为王，120B以下尺寸无非就是选择多少B的千问而已

关键词解释：

  • UD：Unsloth Dynamic，市面上最好的量化格式
  • MTP：同系列小模型输出类似大模型，可以给大模型当草稿提速
  • Uncensored/Heretic: 去除审查
  • Fable/Astra: 使用了对应的思维链进行训练

模型推荐：上面两档基本上可以忽略。qwen直接用最新的就行

联调 ​

目标

  1. model和harness都可以正常运行
  2. 模型在长上下文下不会死循环、能正常压缩
  3. 工具能正常调用

实战 ​

常用工具其实没太多区别，除了智能外就是比拼谁得编排更好，智能体、mcp这些反而都可以轻易移植

  • worker模式：自己就是
    • deepseek harness：提示词最极简的一个，甚至只有一句
    • pi：凑合
    • CyberStrike：相对专业的工具，但也可能过于沉重了。默认53k提示词
    • claudecode：编排及体验的王者，但是默认提示词太重不太适合本地
  • sceduler：作为调度器需要配置worker
    • chying：实测，约20K左右的起始token
    • crain：实测，18k左右起始token

本地AI特点 ​

  • 三低：低算力、低并发、低上下文。本地算力始终相对较慢、以27b左右的小模型、少并发为主、多并发PD会抢算力导致速度1+1<2
  • 极度精简：

提示词核心 ​

  • 技能
    • CTF竞赛的相关要点
    • 会写辅助脚本、最好是调用宿主浏览器
    • 编排要求
  • 智能体
    • 主AGENT：
      1. 如何准备题目
      2. 编排子代理交付内容
    • 子AGENT：读取题干、写入进展、交付flag和readme

踩坑 ​

  • 完全可以混合编排模型：日常云端大模型协助本地调参和评估本地模型表现实现RSI，赛前辅助编写登录脚本等
  • 绝对要控制上下文，128k上下文下数百的prefill速度会导致甚至无法计算，100k上下文配合300perfill速度差不多需要6分钟，这个TTFT可能直接超时了
  • 模型要随时WP，应对压缩和接手，否则无法复现就搞笑了
  • 下载、复制、提交是很费时间的、用脚本搞定，可能这一两分钟就是决定性差距
  • agent使用low思考强度就行