ops x - 筑码
type: channel
link: https://opsx.me/category/%E7%AD%91%E7%A0%81/
items: vLLM 内网离线部署：脱敏后的服务端与客户端脚本
items: 把经验写进项目：AI Coding 如何用文档、技能和工具摆脱上下文依赖
items: 本地化 AI Agent 平台落地：模型、MCP 与运维系统的连接方式
items: 从点状工具到体系协同：一套运维体系化建设思路
items: 用 Oxidized 自动备份网络设备配置文件
items: 用 Nginx 给 vLLM 做动态负载均衡
items: 在本地部署 MiniMax 大模型服务
items: 搭建Syslog服务接收交换机日志

vLLM 内网离线部署：脱敏后的服务端与客户端脚本
type: item
date: 2026-03-23T17:31:00+00:00
description: 前面整理这套 vLLM 私有源部署方案时，我把重点放在了思路复盘上。这次换个更直接的版本：不改原始脚本文件，只做脱敏，把服务端部署脚本和客户端部署脚本的可公开版本贴出来，方便自己归档，也方便后续复用。先说明一下边界：仓库里的原始脚本我没有修改，这篇文章里的代码块是单独整理出来的脱敏版本。处理方式主要是把内网 IP、固定端口、默认账号、硬编码 API Key 以及过于贴近生产环境的目录替换成占位写法，保留脚本结构和部署逻辑。一、这套脚本解决什么问题目标很明确：在一台可联网的内部服务器上准备 APT 和 PyPI 私有源，然后让目标 GPU 节点通过一键脚本完成 vLLM 环境部署、systemd 托管和基础验证。整体分两段： 服务端脚本：负责下载和暴露依赖。 客户端脚本：负责安装和启动推理服务。 二、脱敏后的服务端部署脚本下面这个版本对应“在私有源服务器本机运行”的服务端脚本。它会准备 APT 源、PyPI 源，并用 systemd 把两个服务托起来。#!/bin/bash # vLLM 私有源服务端部署脚本（脱敏版） # 直接在私有源服务器本机执行 set -e APT_REPO="/opt/vllm-private-repo/apt/ubuntu22.04/cuda-12.4" PYPI_REPO="/opt/vllm-private-repo/pypi/packages/cuda-12.4/python3.10" APT_PORT="${APT_PORT:-8888}" PYPI_PORT="${PYPI_PORT:-9999}" echo "======================================" echo "开始部署 vLLM 私有源" echo "======================================" if [ "$EUID" -ne 0 ]; then echo "错误：请使用 root 用户运行此脚本" echo "使用: sudo bash deploy-server-local.sh" exit 1 fi echo "" echo "[1/8] 创建目录结构..." mkdir -p "$APT_REPO" mkdir -p "$PYPI_REPO" echo " ✓ 目录创建完成" echo "" echo "[2/8] 配置基础环境..." apt-get update -qq apt-get install -y python3-pip wget gpg dpkg-dev echo " 配置 NVIDIA CUDA 仓库..." wget -qO- https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/3bf863cc.pub \ | gpg --dearmor -o /usr/share/keyrings/cuda-archive-keyring.gpg echo 'deb [signed-by=/usr/share/keyrings/cuda-archive-keyring.gpg] https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/ /' \ > /etc/apt/sources.list.d/cuda-ubuntu2204-x86_64.list apt-get update -qq echo " ✓ 基础环境配置完成" echo "" echo "[3/8] 安装 pypiserver..." pip3 install pypiserver echo " ✓ pypiserver 安装完成" echo "" echo "[4/8] 下载 CUDA 及系统依赖..." apt-get install -d \ -o Dir::Cache::Archives="$APT_REPO/" \ cuda-toolkit-12-4 \ libcudnn8 \ libcudnn8-dev \ build-essential \ ninja-build \ python3.10-dev echo " ✓ CUDA 依赖下载完成" echo "" echo "[5/8] 下载 vLLM、ModelScope 及 Python 依赖..." pip download \ --index-url https://pypi.org/simple \ --extra-index-url https://download.pytorch.org/whl/cu124 \ --dest …

把经验写进项目：AI Coding 如何用文档、技能和工具摆脱上下文依赖
type: item
date: 2026-03-15T17:03:00+00:00
description: 很多人用 AI coding 一段时间之后，都会遇到同一个问题：刚开始很好用，但项目一复杂、上下文一长、对话一断开，体验就迅速下滑。模型并不是突然变笨了，而是项目本身没有把“该知道的事情”沉淀下来，导致每次协作都像重新开工。所以，AI coding 真正要解决的，不只是提示词怎么写，而是怎样把项目知识、约束、流程和工具组织进仓库里，让 AI 不再严重依赖即时上下文。换句话说，重点不是“如何喂更多上下文”，而是“如何让项目自己带着上下文”。这篇文章想整理一套更可持续的做法：善用 Markdown 文档、技能包、工具包、环境文件和项目约定，把一次次对话中的经验沉淀成结构化资产。这样做的结果，不是让 AI 永远记住一切，而是让它在任何一个新上下文里，都更容易重新接住项目。一、AI coding 最大的问题，往往不是模型能力，而是知识挥发很多团队在用 AI 编码时，会自然陷入一种“会话式工作流”：需求来了，开个对话，解释背景，写代码，改一轮，结束。这个流程在短任务里没有问题，但一旦项目进入持续开发，就会暴露出非常明显的损耗： 规则只存在于聊天记录里，没有沉淀到仓库。 模型知道怎么做，却不知道为什么这样做。 换个上下文、换个成员、换个入口，很多约定就丢了。 每次都要重新解释目录结构、发布流程、命名习惯和边界条件。 这类问题本质上不是“上下文不够长”，而是项目知识没有外化。只要知识还停留在对话里，AI 就很难真正形成持续协作能力。二、先接受一个现实：AI 不会天然记住项目很多人对 AI coding 的期待，隐含着一种假设：只要模型足够强，它就会慢慢“理解这个项目”。但现实里，大多数协作型 AI 更像是按上下文工作的系统，而不是长期驻留在项目中的开发成员。所以更可持续的思路不是要求模型“像人一样记住”，而是让项目本身具备可被重新理解的结构。你可以把它理解成： 对人类开发者，项目需要 README、注释、设计文档。 对 AI 开发者，项目同样需要规则、技能、工具入口和边界说明。 一旦你接受这一点，很多实践就会变得非常明确：不要把关键信息藏在聊天里，而要写进仓库。三、Markdown 不是补充材料，而是 AI coding 的“长期记忆层”在这件事上，Markdown 的价值非常高，因为它同时具备几个特点： 结构简单，AI 很容易读取和理解。 能跟代码一起版本化管理。 对人也友好，不会变成只给机器看的黑箱配置。 适合从粗到细逐步拆分，不需要一开始就设计复杂系统。 真正用得好的项目，Markdown 往往不只是 README 一篇，而是形成一个轻量但清晰的知识层。例如： AGENTS.md：告诉 AI 这个项目怎么协作。 SKILL.md：告诉 AI 某类任务怎么做。 docs/architecture.md：解释系统边界和核心决策。 docs/runbooks/：记录运维、发布、排障和回滚流程。 .env.local.example：定义本地运行需要哪些环境变量。 这些文档一旦形成，AI 的工作方式就会从“每次吃一大段背景说明”，逐步转成“按项目结构自己找答案”。四、AGENTS.md：把项目协作规则固定下来AGENTS.md 最适合写的是“项目级规则”，而不是实现细节。它更像一张给 AI 的协作说明书，用来告诉它： 这个仓库主要做什么。 有哪些现成技能可以用。 哪些目录最关键。 默认的工作方式是什么。 哪些事情绝对不能乱做。 比较好的写法不是堆很多长篇解释，而是尽量高密度、低歧义。例如： “技术文默认发到筑码。” “首页摘要通常两段后加 。” “发文和更新统一走某个技能。” “敏感信息从环境变量读取，不写入仓库。” 这类规则的好处在于，哪怕换一个全新上下文，只要 AI 能读到仓库，它就能迅速恢复正确的工作方式。五、Skill：把重复任务做成可复用能力如果说 AGENTS.md 解决的是“在这个项目里怎么合作”，那么 Skill 更适合解决“某一类事应该怎么做”。它本质上是一个可复用的任务能力包，通常至少包含： SKILL.md：任务流程、默认参数、适用场景。 scripts/：可执行脚本。 必要时再加模板、参考文档或资源文件。 Skill 最适合承载那些“会重复出现、又容易做歪”的任务，例如： 博客发布。 日志分析。 部署脚本生成。 固定格式的周报或复盘。 某类代码迁移或重构。 一旦这类任务沉淀成 Skill，AI 下次就不必重新猜你的习惯，而是按已经写好的方法执行。六、工具包：把“方法”变成“可执行动作”只写文档还不够，因为很多任务不是“知道怎么做”就能稳定做好，而是需要真正可执行的动作。这时候就要把方法继续往下沉到工具包里。工具包通常包括： 脚本，例如 scripts/publish.py、scripts/deploy.sh。 模板，例…

本地化 AI Agent 平台落地：模型、MCP 与运维系统的连接方式
type: item
date: 2026-03-15T16:55:00+00:00
description: 很多团队在谈 AI Agent 落地时，最先想到的往往是“接一个大模型，再连几个工具”。但真正做进本地环境以后，很快就会发现问题不在于模型会不会回答，而在于这套系统能不能接进真实工作流：能不能接 IM，能不能调本地工具，能不能访问内网资源，能不能区分开发、测试、生产环境，能不能把动作和审计收进现有运维体系。所以，本地化 AI Agent 建设真正要解决的，不是“让模型更像人”，而是把模型、工具、上下文、权限、执行和观测拼成一条可持续运行的链路。只有当 Agent 能稳定接入模型服务、MCP、技能包、工具包和企业内部平台，它才会从一个 Demo 变成一套基础设施。这篇文章尝试整理一套更适合本地或私有环境落地的 AI Agent 建设思路，重点不是某个单一产品，而是整体架构和实践路径。内容会覆盖 IM 对接、模型接入、本地与云上模型协同、MCP、技能包、工具包、环境隔离，以及如何与前面提到的运维体系平台联动。一、AI Agent 落地的核心，不是聊天，而是执行闭环如果把 AI Agent 只理解成一个“会对话的机器人”，它很快就会撞上天花板。业界这两年更成熟的方向，其实已经越来越清楚：Agent 不只是回答问题，而是围绕目标进行推理、调用工具、访问上下文、产出动作，并在必要时持续运行。OpenAI 在《A practical guide to building agents》里把工具分成数据类和动作类，这个划分很实用。因为一个真正有价值的 Agent，往往至少要同时具备三件事： 能读：读文档、读系统状态、读平台数据、读内部知识。 能想：选择模型、规划步骤、决定是否调用工具。 能做：发消息、开工单、改配置、执行脚本、触发自动化流程。 真正的建设重点，就是把这三件事拆成稳定的系统边界，而不是让一个“大模型实例”去承载全部复杂性。二、一套更适合本地环境的 Agent 架构如果按落地视角来看，一套本地化 AI Agent 平台通常可以拆成七层： 入口层：IM、Web、CLI、API。 Agent 编排层：任务路由、状态管理、上下文拼装、工具调度。 模型接入层：本地模型、私有推理集群、云上模型统一路由。 能力层：MCP、技能包、工具包、知识检索、执行器。 环境层：dev / test / prod、凭据、变量、工作目录、权限策略。 平台集成层：监控、日志、资产、工单、变更、配置库。 治理层：审计、授权、配额、告警、回滚、评估。 .panel { fill: #fcfcfd; stroke: #dbe4ee; stroke-width: 1.5; rx: 26; ry: 26; } .layer { fill: #f8fafc; stroke: #cbd5e1; stroke-width: 1.2; rx: 22; ry: 22; } .box { fill: url(#b1); stroke: #334155; stroke-width: 2; rx: 18; ry: 18; } .blue { fill: url(#b2); stroke: #2563eb; stroke-width: 2.2; rx: 18; ry: 18; } .cyan { fill: url(#b3); stroke: #0891b2; stroke-width: 2.2; rx: 18; ry: 18; } .green { fill: url(#b4); stroke: #16a34a; stroke-width: 2.2; rx: 18; ry: 18; } .orange { fill: url(#b5); stroke: #ea580c; stroke-width: 2.2; rx: 18; ry: 18; } .line { stroke: #334155; stroke-width: 3; fill: none; marker-end: url(#arrow); stroke-linecap: round; stroke-linejoin: round; } .dashed { stroke-dasharray: 8 8; } .title { font: 22px -apple-system,BlinkMacSystemFont,'Segoe UI',sans-serif; font-weight: 700; fill: #0f172a; } .label { font: 18px -apple-system,BlinkMacSystemFont,'Segoe UI',sans-serif; font-weight: 650; fill: #0f172a; } .small { font: 14px -apple-system,BlinkMacSy…

从点状工具到体系协同：一套运维体系化建设思路
type: item
date: 2026-03-15T16:52:00+00:00
description: 很多团队在运维建设早期，往往都是“先把工具装起来”：日志上 ELK，可视化上 Grafana，指标监控上 Zabbix，网络流量用 sFlow，配置备份交给 Oxidized，资产管理再补一个 NetBox。单看每个工具都没问题，但真正到了线上，最常见的问题反而不是“工具不够多”，而是这些工具彼此之间没有形成闭环。体系化建设的关键，不是再继续加工具，而是先回答清楚三个问题：什么是权威数据源，什么负责实时观测，什么负责变更留痕。只有资产、日志、指标、流量、配置和告警被串成一条统一链路，运维平台才会从“工具集合”变成“可持续运转的系统”。这篇文章尝试整理一套比较务实的建设思路，适合中小团队或正在从零散运维往平台化演进的环境。核心组件以 ELK、Grafana、Zabbix、sFlow、Oxidized、NetBox 为主，再补上更符合业界最佳实践的体系化要点，比如 Source of Truth、统一标签、自动化编排、权限分层、告警治理、数据保留策略和变更审计。一、体系化建设真正要解决什么问题一套成熟的运维平台，最终要解决的不是“看见更多图表”，而是下面这几类长期问题： 资产信息是否一致，能不能知道一台设备属于谁、在哪个站点、接在哪个网段。 故障发生时，能不能从指标、日志、流量和配置变更四个方向快速交叉验证。 变更发生后，能不能知道谁改了、改了什么、影响了哪些对象。 值班时收到的告警，能不能直接触发动作，而不是制造噪音。 平台本身是否能长期维护，而不是一年后变成没人敢碰的遗留系统。 因此，体系化建设的目标应该是“把运维对象、观测数据和响应动作收敛成一个闭环”，而不是把单点工具简单拼在一起。二、先定原则，再选工具如果一上来就讨论“选 ELK 还是 Loki”“选 Zabbix 还是 Prometheus”，往往会把注意力带偏。真正先要确定的，其实是平台层面的职责划分。 NetBox 负责资产和地址空间，是 Source of Truth。 Oxidized 负责网络设备配置备份和变更留痕。 Zabbix 负责主机、网络设备、服务可用性和关键指标采集。 ELK 负责日志采集、搜索、聚合和关联分析。 Grafana 负责跨系统可视化、统一大盘和告警整合。 sFlow Collector 负责流量画像、带宽热点和异常会话分析。 这套拆分的好处很明确：每个系统都围绕自己最擅长的数据类型工作，既不重复造轮子，也避免把所有问题都推给一个平台。三、最佳实践先于具体组件如果把业界实践收成几条最重要的原则，我会优先坚持下面这七条： 先统一 Source of Truth：资产、命名、地址、拓扑标签要有唯一来源。 先统一标签体系：站点、环境、业务线、服务、责任人这些标签要跨系统一致。 先做 Git 留痕：配置、规则、仪表盘、告警和自动化脚本尽量代码化。 先分层告警：症状告警用于值班，信号类告警用于辅助分析，避免全部升级成页面通知。 先建权限边界：读写分离、SSO、审计日志、凭据隔离要早做，不要等平台变大再补。 先做平台自身可运维：监控这些工具本身、做好备份、保留策略和容灾恢复。 先把自动化放进闭环：Ansible、Webhook、Runbook 不只是加分项，而是运维平台的执行臂。 这些原则成立以后，工具怎么替换其实都还有余地；但如果原则缺位，哪怕工具都是主流，也很容易越建越散。四、推荐的体系结构从落地角度看，一套比较稳的运维体系，通常可以分成四层： 基础数据层：NetBox、Git、对象存储、数据库。 采集层：Zabbix Agent / SNMP、Beats 或 Logstash、sFlow Exporter、Oxidized。 分析层：Elasticsearch、Kibana、Zabbix Server、sFlow Collector。 展示与响应层：Grafana、告警通道、工单平台、自动化脚本。 .panel { fill: #fcfcfd; stroke: #dbe4ee; stroke-width: 1.5; rx: 26; ry: 26; } .layer { fill: #f8fafc; stroke: #cbd5e1; stroke-width: 1.2; rx: 22; ry: 22; } .box { fill: url(#g1); stroke: #334155; stroke-width: 2; rx: 18; ry: 18; } .blue { fill: url(#g2); stroke: #2563eb; stroke-width: 2.2; rx: 18; ry: 18; } .green { fill: url(#g3); stroke: #16a34a; stroke-width: 2.2; rx: 18; ry…

用 Oxidized 自动备份网络设备配置文件
type: item
date: 2026-03-15T12:35:00+00:00
description: 网络设备的配置备份，最怕的不是“没有工具”，而是设备数量慢慢变多以后，备份动作开始依赖人工记忆：有人改了交换机配置却忘了留档，有人调了防火墙策略却没有版本记录，真到回滚和排障的时候，才发现手上没有一份可信的基线。Oxidized 这类工具的价值，就在于把这件事做成一条自动化流水线：定时登录设备、抓取 running-config、检测变更、写入 Git 仓库，并通过 Web 界面或 API 做统一查看。对中小规模网络来说，它足够轻，落地成本也很低。这篇文章整理一套比较稳的部署方式：基于 Ubuntu 22.04，使用 systemd 托管 Oxidized，配置 Git 作为版本后端，再通过 Nginx 做反向代理和密码登录加固。文中默认采用最常见的 router.db 方式管理设备清单，同时补一段可选的 LibreNMS 集成思路。部署思路整套链路可以先收成四个角色： Oxidized 负责登录网络设备并抓取配置。 Git 仓库负责保存配置历史和差异。 systemd 负责把服务稳定跑起来并开机自启。 Nginx 负责把 Web 界面和 REST API 放在反向代理后面，并补上访问控制。 落地时建议优先遵循这几个原则： 不要用 root 运行 Oxidized，单独建服务用户。 不要把 Oxidized 的 rest 端口直接暴露到公网。 尽量给设备创建只读备份账号，而不是复用高权限运维账号。 配置仓库用 Git 保存，后续再同步到异机或远端代码仓库。 一、安装依赖与程序官方 README 给出的 Debian 安装方式，是先装 Ruby 及依赖，再通过 gem 安装 oxidized、oxidized-script 和 oxidized-web。在 Ubuntu 22.04 上可以直接沿用这条路径。sudo apt-get update sudo apt-get install -y ruby ruby-dev libsqlite3-dev libssl-dev pkg-config cmake libssh2-1-dev git nginx apache2-utils sudo gem install oxidized sudo gem install oxidized-script oxidized-web 安装完成后先确认命令可用：oxidized --version oxidized-script -h 二、创建专用用户与工作目录官方文档明确建议不要用 root 运行 Oxidized，而是单独创建一个服务用户。这样做的好处很直接：最小权限、目录边界清晰、systemd 托管也更干净。sudo useradd -r -m -d /home/oxidized -s /usr/sbin/nologin oxidized sudo mkdir -p /etc/oxidized sudo mkdir -p /var/lib/oxidized/git-repos sudo chown -R oxidized:oxidized /etc/oxidized /var/lib/oxidized /home/oxidized 这里我更倾向把配置文件统一放在 /etc/oxidized，把 Git 仓库放在 /var/lib/oxidized。后面做备份、迁移和权限审计时会更省心。三、准备设备清单Oxidized 支持 CSV、SQLite 和 HTTP 多种来源。最容易上手的仍然是 router.db，一台设备一行，先把自动备份跑起来，再决定要不要切到 LibreNMS API。先创建设备清单：sudo -u oxidized tee /etc/oxidized/router.db > /dev/null <<'EOF' core-sw-01:ios:backupuser:StrongPassword edge-fw-01:panos:backupuser:StrongPassword dist-sw-01:nxos:backupuser:StrongPassword EOF 格式是：hostname:model:username:password 这里有两个落地建议很值得一开始就做： 设备账号尽量使用只读账号，权限只覆盖 show running-config、show version 一类查询动作。 如果不同厂商或不同区域用不同凭据，后续可以再引入 group 机制，不必一开始就把所有账号揉在一起。 四、编写主配置文件下面这份配置比较适合作为生产起步版本：轮询间隔按小时级设置，启用 Web/API，输出采用 Git，输入以 router.db 为主。--- username: backupuser password: Stro…

用 Nginx 给 vLLM 做动态负载均衡
type: item
date: 2026-03-14T15:59:00+00:00
description: 在多台 vLLM 推理节点同时提供服务时，最直接的做法通常是先在前面放一层 Nginx 做转发，再由上游节点共同承接请求。但如果只是静态轮询，实际效果往往并不理想。因为大模型服务的负载并不均匀，某一台节点可能已经接近 KV Cache 极限、出现等待队列，甚至开始发生 preemption，而另一台节点却还比较空闲。这个时候，负载均衡如果不能感知后端状态，就容易把请求继续打到“已经很忙”的节点上。这篇文章整理一套比较实用的做法：使用 Nginx 作为统一入口，配合一个定时执行的权重调整脚本，根据 vLLM 指标动态改写 upstream 配置，并自动 reload Nginx。整体链路整体上可以把这套链路理解成两条并行路径：一条是业务请求流量，另一条是指标采集与权重回写。 .bg { fill: #fcfcfd; stroke: #e2e8f0; stroke-width: 1.5; rx: 24; ry: 24; } .section { fill: #f8fafc; stroke: #cbd5e1; stroke-width: 1.5; rx: 24; ry: 24; } .box { fill: url(#panel); stroke: #334155; stroke-width: 2; rx: 18; ry: 18; } .accent { fill: url(#accentPanel); stroke: #2563eb; stroke-width: 2.5; rx: 18; ry: 18; } .soft { fill: url(#softPanel); stroke: #7c3aed; stroke-width: 2.5; rx: 18; ry: 18; } .line { stroke: #334155; stroke-width: 3; fill: none; marker-end: url(#arrow); stroke-linecap: round; stroke-linejoin: round; } .dash { stroke-dasharray: 8 7; } .label { font: 18px -apple-system,BlinkMacSystemFont,'Segoe UI',sans-serif; fill: #0f172a; font-weight: 600; } .small { font: 14px -apple-system,BlinkMacSystemFont,'Segoe UI',sans-serif; fill: #475569; } .title { font: 20px -apple-system,BlinkMacSystemFont,'Segoe UI',sans-serif; font-weight: 700; fill: #0f172a; } .caption { font: 13px -apple-system,BlinkMacSystemFont,'Segoe UI',sans-serif; fill: #64748b; } 业务流量路径 请求从统一入口进入，再根据 upstream 权重分发到不同推理节点。 Client / SDK OpenAI compatible request Nginx ingress /v1/ unified entry upstream llm_cluster least_conn + dynamic weight vLLM node-a serving backend vLLM node-b serving backend 指标与调度路径 定时任务抓取节点指标，重新计算权重，校验配置后 reload Nginx。 systemd timer periodic trigger vllm_nginx_lb.sh collect metrics + compute weight GET node-a /metrics kv / waiting / running GET node-b /metrics kv / waiting / running rewrite upstream nginx -t & reload new weights applied to ingress 一、Nginx 入口配置先在 Nginx 里定义一个用于承接 OpenAI 兼容接口请求的 server：server { listen 80; server_name 10.0.0.10; access_log /var/log/nginx/llm_access.log upstream_trace; error_log /var/log/nginx/llm_…

在本地部署 MiniMax 大模型服务
type: item
date: 2026-03-14T15:38:00+00:00
description: 这篇文章记录的是在本地 GPU 服务器上部署 MiniMax 大模型服务的一套实践流程，目标是把模型稳定跑起来，并以 OpenAI 兼容接口的方式提供调用能力。整体过程包括模型下载、运行环境准备、systemd 托管、接口验证，以及用 vLLM 自带工具做一轮基础压测。重点不在概念，而在于把一套可复用的部署链路整理清楚。一、准备模型与运行环境先安装 ModelScope：pip install modelscope 然后把模型下载到本地。下面以 Minimax-M2.5 为例：modelscope download \ --model Minimax-M2.5 \ --local_dir /opt/Minimax-M2.5 接着准备一个独立的 Python 虚拟环境，用来运行 vLLM：python3 -m venv /home/service-user/vllm-env source /home/service-user/vllm-env/bin/activate pip install --upgrade pip pip install vllm pip install -U lmcache 二、配置 LMCache在长上下文和多并发场景下，KV Cache 的管理会直接影响推理服务的稳定性。LMCache 可以看作 vLLM 之外的一层缓存扩展能力，主要价值在于缓解显存压力、提升缓存复用效率，并让服务在复杂请求场景下更稳。先创建配置目录和配置文件：sudo mkdir -p /etc/lmcache sudo nano /etc/lmcache/lmcache_config.yaml 配置示例如下：chunk_size: 256 local_cpu: true max_local_cpu_size: 16 reserve_local_cpu_size: 32 enable_lazy_memory_allocator: true lazy_memory_initial_ratio: 0.2 lazy_memory_expand_trigger_ratio: 0.5 lazy_memory_step_ratio: 0.1 lazy_memory_safe_size: 8 三、安装 CUDA Toolkit如果当前机器已经安装了可用的 NVIDIA Driver，这里只安装 CUDA Toolkit 即可，不需要重新装驱动：wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/cuda-keyring_1.1-1_all.deb sudo dpkg -i cuda-keyring_1.1-1_all.deb sudo apt-get update sudo apt-get install -y cuda-toolkit-12-4 安装完成后可以简单确认一下：/usr/local/cuda-12.4/bin/nvcc --version 这一组命令只会安装 Toolkit，不会主动覆盖系统现有的显卡驱动。四、通过 systemd 托管 vLLM 服务为了让模型服务具备开机自启、异常重启和日志可追踪能力，建议直接交给 systemd 管理。创建服务文件：sudo nano /etc/systemd/system/vllm-llm.service 如果你是部署 Minimax-M2.5 这类大模型，下面这份启动参数会更贴近真实运行配置：[Unit] Description=vLLM Service for MiniMax After=network.target [Service] User=root WorkingDirectory=/home/service-user Environment=PYTHONUNBUFFERED=1 Environment=CUDA_VISIBLE_DEVICES=0,1,2,3 Environment=PATH=/usr/local/cuda-12.4/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin Environment=LD_LIBRARY_PATH=/usr/local/cuda-12.4/lib64 Environment="LMCACHE_CONFIG_FILE=/etc/lmcache/lmcache_config.yaml" Environment="PYTHONHASHSEED=0" ExecStart=/home/service-user/vllm-env/bin/python -m vllm.…

搭建Syslog服务接收交换机日志
type: item
date: 2025-12-25T08:21:00+00:00
description: 在Ubuntu平台下搭建Syslog服务，并通过定义规则，实现日志分类和分日期存储，因交换机日志一般输出内容不多，采用syslog采集是比较轻量化的方案基于Ubuntu 22.04系统创建日志存储目录并设置权限mkdir -p /data/network-syslog chmod 777 /data/network-syslog 安装Syslog服务apt install rsyslog 编辑配置文件/etc/rsyslog.conf，将# provides UDP syslog reception段替换为以下内容# provides UDP syslog reception $ModLoad imudp $UDPServerRun 514 $ModLoad immark $template Remote,"/data/network-syslog/%HOSTNAME%/%$YEAR%-%$MONTH%-%$DAY%.log" :fromhost-ip, !isequal, "127.0.0.1" ?Remote & ~ 启动服务并设置开机运行systemctl start rsyslog systemctl enable rsyslog 交换机侧配置，以华为交换机为例info-center loghost source "替换为源IP接口" info-center loghost “替换为服务器IP” facility local5 local-time info-center timestamp log short-date without-timezone info-center timestamp trap short-date without-timezone 在服务器端日志会生成以交换机名字命名的文件夹，并在文件夹内按日期生成文件