-
MCP与Dify并存：各管一段别搅成一锅
现状两套能力一起用： MCP：给 Cursor / 终端 Agent 做运维只读与受限写操作 Dify：给业务侧工作流、知识库、对外 API不要把两套并成一套。Dify 全改 MCP，或 MCP 全改 Dify，边界会对不上。边界 MCP Dify 用户 内部开发/运维 业务与终端用户 强项 宿主原生工具调用、IDE 内闭环 可视化编排、知识...…
-
长上下文实测：宣称能吃下和线上敢开是两件事
怎么测挑支持长窗的常用开源模型，分别在 A100、PRO 6000 上： 把 max-model-len 提到业务想要的档（如 32K/64K/128K） 塞入「前面埋关键数字、末尾提问」的针测 看：能否启动、单请求显存、TTFT、是否答对埋点发现 宣称 128K ≠ 配置拉满还能并发；经常是 max-num-seqs=1 才勉强 中间遗忘真实存在：窗越长，针测失败越多，和卡型关系不如和模型实现/插值关系大 前缀很长时，首包延迟和费用一起涨；Dify 里再叠知识库片段，更容易超...…
-
Embedding与Rerank模型复测：知识库换模记
问题多库 Embedding 不一致时无法调权重。换模前，在同一批文档（制度 + 运维 Runbook）上比较常用中文/多语 Embedding 和一档 Rerank 的召回。看什么 固定 50 条问答的 hit_rate（应命中文档是否进 TopK） 单次 embedding 延迟、批量吞吐 向量维度与磁盘/内存占用 Rerank 加上后 TopN 是否更稳，以及额外延迟结论怎么用选「效果够用、延迟可接受、团队只维护一个」的 Embedding，而不是榜上第一。换模 = 全库重建...…
-
Coding令和CTF令牌别混着用
问题两条模型用途不同，令牌却能混用。CTF 用的去审模型进了 IDE，或 Coding 模型被拿去跑题。模型限制没勾死时，换一个 model 字段就能打到另一条线。两条线 pi coding / zcode → qwen38-flash-next，分组 coding CTF 研究 → qwen38-27b-ctf，分组 ctf-lab，IP 绑研究机引擎可以在同一机房。别名和卡组分开，避免补全的短请求被 CTF 长推理拖住。处理令牌上把模型限制勾死，不要默认全开。分组分开。CTF 令牌...…
-
内网pi coding和zcode接上Qwen3.8-Flash-Next
问题内网 IDE（pi coding、zcode）要做补全，不能直连公网。用满血稠密模型时，首包慢，还和在线聊天抢同一组卡。补全一抖，看起来像聊天服务挂了。处理编码场景用 Qwen3.8-Flash-Next（FP8）做后端。A100 上 vLLM 版本太旧时，多卡和专家并行起不来，先升到能开 --enable-expert-parallel 的版本。上下文开 32K/64K 即可，IDE 自己会截断，引擎开到顶没有意义。vllm serve Qwen/Qwen3.8-Flash-Next...…
-
PRO 6000 上FP8常见模型：速度有了质量怎么验
测法在 RTX PRO 6000 上对若干提供 FP8 权重的常用模型做： 冷启动能否稳定 serve 固定长度吞吐、并发 8 的 TTFT 同一 prompt 集与 A100 BF16/AWQ 输出对比（人工抽检 + 简单一致性）结果FP8 吞吐优势明显，和公开材料同向。质量上：多数日常问答抽检可接受；个别工具调用 JSON 边界偶发更脆，要在真实 schema 上回归，不能只看「能聊天」。长上下文打开后，显存账同样吃 KV；96GB 不是无限。max-model-len 与 ma...…
-
CTF研究机上的Qwen3.8-27B去审版
官方 Qwen3.8-27B 能力可以，但密码、逆向相关提示经常直接拒。授权 CTF / 本地靶场里 Agent 第一步就被挡，很浪费时间。处理：内网另起一份去审权重，端口和令牌都单独，不进默认聊天，也不给业务 Dify。CUDA_VISIBLE_DEVICES=6 \vllm serve /models/Qwen3.8-27B-uncensored \ --host 127.0.0.1 --port 8010 \ --served-model-name qwen38-27b-ctf ...…
-
工具调用对比测试：谁稳、谁爱瞎编参数
方法把内部 MCP / 网关暴露的同一组工具 schema（健康查询、日志检索等）交给不同模型，固定 30 个用户问法，统计： 是否选对工具 参数是否通过校验 是否在不该调用时硬调写工具温度压低，提示词相同。结果梗概 中等指令模型（调教好的 14B～32B）：只读工具选对率高，偶尔把别名写错 偏推理蒸馏模型：爱先长篇分析再调工具，延迟高；有时分析对了却忘了调用 小模型（7B）：简单查询还行，复杂「先查健康再查日志」链式易跳步或编参数乱参最常见：把展示名当 alias、把百分比传...…
-
常见开源模型A100复测：Qwen / DeepSeek / Llama 对照
测什么把「常被点名」的几类开源指令模型又过了一遍，统一在 A100 80G、vLLM、同一套压测包 llmops_tools： Qwen2.5 / Qwen3 系中小尺寸指令模型 DeepSeek-R1 蒸馏系（7B/14B/32B） Llama 3.x Instruct 同量级指标：单卡能否 BF16/AWQ 启动、并发 8/32 的 p95 TTFT、简单工具调用是否格式稳定、中文指令遵从抽检。体感结论（运维向） 档位 更适合 注意 ...…
-
New API和自研网关怎么并存
问题自研 FastAPI 网关负责 TTFT、新版本流量比例、request_id。New API 负责令牌、额度、渠道。两边各发一把 Key、各写一套模型名时，同一次请求对不齐：令牌能过，上游 404；或者网关日志里的名字和 New API 用量对不上。处理对外只认 New API 发的令牌。灰度、埋点仍要保留时，挂在 New API 后面：Dify / 脚本 → New API →（可选）自研网关 → vLLM流量简单就 Dify → New API → vLLM。不要两套都维护用户表...…
-
MCP里改新版本流量，必须带确认串
问题只读工具能查状态，不能把坏版本的流量降下来。如果直接给 shell，或者允许任意百分比，模型会先改再问，一次把流量切满。处理只增加两个写工具：set_new_version_percent、rollback_alias_to_stable。都调网关已有接口，不 SSH，不改引擎进程。约束： percent 只允许 0～20。全量切换没有这个入口，走变更单 确认串必须是 NEW_{alias}_{percent}，对不上直接拒绝，流量不变 同一别名幂等。对话重试连打两次，不能把比例...…
-
MCP用stdio还是HTTP，权限怎么收
问题传输选错，或者参数不设边界，只读工具也会变成入口。stdio 被当成 HTTP 暴露到公网，或 HTTP 没有鉴权，模型还能把路径写成 ../。选哪种本地 Cursor 用 stdio：进程随宿主起来，不听端口。多人远程再用 HTTP。HTTP 要鉴权，限制请求体大小，只绑内网，不要裸奔到公网。stdio 更简单，但 stdout 只能走协议。日志、进度条、print 都会把会话弄挂，这些输出改到 stderr。权限默认按下面收，不要等出事再加： 参数当不可信输入，按 schema ...…
-
New API挂了主备渠道之后
问题上游要维护，或者主实例已经挂了。调用方不能改 Key，也不能改 Base URL。如果主备各发一把令牌，切换就变成改所有客户端。处理在 New API 里给同一个对外模型名挂主、备两个渠道。优先级高的走主，主失败再重试到备。客户端一直用同一把令牌。上线前： 备渠道先单独测通，再抬权重。没测通的备等于没有 两边模型映射一致。只改一边，请求会 404 重试次数收小。主挂时重试太猛，会把备一起打满，超时更难看 主备不要指向同一张卡。那张卡挂了，两条渠道一起没维护把主渠道禁用，或把优先...…
-
用Python写MCP Server：结构、校验和异步调用
目录怎么拆参考官方/社区常见拆法，内部仓库大致是：llmops_mcp/ server.py # 入口与工具注册 models.py # Pydantic 入参/出参 clients.py # 网关、ES、GPU 采集客户端 consts.py pyproject.toml业务逻辑不堆在装饰器里。工具函数只做：校验 → 调 client → 裁剪返回。工具示例（示意）from mcp.server.fastmcp import FastMCPfrom ...…
-
对话里查别名和GPU：只用只读MCP
问题要在对话里确认别名是否存活、哪张卡满了。每次打开 Grafana 或 SSH 太慢。把 shell 交给 Agent，等于把机器交出去：它会重启进程、改环境变量，失败了还说自己成功了。处理用 Python MCP SDK 只挂只读工具，描述里写明「只读」： list_model_aliases：别名和上游的对应关系 get_alias_health：是否可服务、最近错误码 get_gpu_node_snapshot：利用率、显存占用，字段脱敏 search_request_lo...…
-
把压测和巡检收成Python包：版本混乱之后
问题压测和巡检脚本各存一份，参数含义不一致。跑到旧脚本时，结果对不上。处理一个内部包，例如 llmops_tools： bench：固定请求集打 vLLM health：扫别名 /health 与抽样 chat gpu_report：拉 nvidia-smi 与拓扑摘要pyproject.toml 锁住 httpx、版本号。机器上 pip install 同一版本，输出 JSON 方便进日志。llmops-bench --base-url http://127.0.0.1:8000 ...…
-
Dify对象存储膨胀：向量化失败留下的孤儿文件
现象MinIO 用量持续涨，知识库界面里的文档数对不上。有一批对象在桶里，Postgres 没有对应有效文档记录——典型是上传成功、向量化失败或中途取消后的残留。生产案例分析里也把「孤儿对象」列为常见问题。处理 列桶内对象与 DB 附件表做差集，确认无引用后再删 失败任务修根因（Embedding 超时、格式不支持、worker OOM）再重传 生命周期策略：临时前缀定期过期，避免人工忘删清理脚本要干跑（dry-run）输出清单，人看过再删。知识库文件误删比多占一点盘更痛。预防 监...…
-
八卡A100在离线混部：怎么避免评测打死在线
现象在线 p95 TTFT 抖动，GPU 利用率上八张卡同时打满。离线全量评测脚本使用 --gpus all，把在线实例的卡也占了。改法物理隔离优先于礼貌约定。 在线：固定 CUDA_VISIBLE_DEVICES，例如 0–5 评测/刷向量：只许 6–7，或空闲探测后申请 调度系统里在线队列权重高于离线；离线可抢占评测脚本模板删掉 all，改成读环境变量 EVAL_GPU_IDS。CI 镜像里不放「默认全卡」的方便脚本。观测看板按 job_type=online|eval 拆 GP...…
-
客户端接New API时常见翻车
问题IDE、脚本、Dify 接不上时，往往三处里坏了一处：Base URL、令牌、模型名。先改 IDE 配置，会把 New API、反代、引擎的问题混在一起。就这三样base_url = https://new-api.example.com/v1api_key = New API 令牌model = 令牌允许的模型名from openai import OpenAIclient = OpenAI(base_url="https://new-api.example.com/v1",...…
-
AI辅助Web题与权限题：研究里踩的边界
范围只在授权 CTF / 本地靶场里试。Web 与权限类题和纯 crypto 不同：Agent 一旦拿到「可以发 HTTP」的工具，就容易扩展成乱扫。研究重点变成刹闸，不是追求自动打穿。做法 HTTP 工具只允许题目给出的 host/路径前缀 每次请求前后由人确认（至少在初期研究阶段） 响应体截断，避免把整页 HTML 塞进模型 禁止内网网段、云元数据地址等与题目无关目标模型擅长：根据报错改参数、写小脚本解析响应、整理已经发现的输入点。模型不擅长：在缺少题面线索时「创造」攻击面；一...…
