SuperBigMango

你在做项目的时候，是不是也遇到过这些问题？ 每次都开一堆终端，写代码的、跑服务的、看日志的，窗口顺序一乱，就得挨个点开找。 远程连接的窗口关了，里面的终端和 Agent 也跟着断了。再连上去，又要找目录、启动 Agent、找回之前的对话。 在一台电脑上开的终端，换到另一台电脑就接不上，还得重新打开一遍。 想同时用几个模型、让多个 Agent 分工，结果自己先忙着在窗口之间来回切。 服务器放在家里或者办公室，没有公网 IP，出了局域网就不知道怎么连。 手边没有电脑，只有手机，想看看任务跑到哪了，或者补一句要求，也不方便。 单独看，每个问题都能找到办法。放到一起，就会发现：光能远程连接还不够，终端得留得住，任务得找得到，换设备以后还得接得上。 你可能已经想到 tmux 了。确实，会话保持和多终端管理，它早就能做。这里我想分享的是另一套组合：herdr + Tailscale + Termius，需要远程桌面时再用 ToDesk。重点聊这些工具怎么配合，以及用它们可以怎样安排工作。 先让任务有个固定的地方这套方法里，代码、环境和 Agent 都放在服务器上。家里的一台主机、办公室的...

在单机推理中，KV Cache 通常只是引擎内部的一块显存。上下文和并发规模上升后，它会跨出 GPU，进入 CPU、NVMe 和远端节点。随之而来的索引、放置、传输、逐出、持久化与监控问题，已经超出 Attention 内核本身的职责，也会影响推理框架怎样调度请求。 LMCache 和 Mooncake 处理的是这套系统的不同部分。LMCache 偏向 KV Cache 管理层，负责索引、分层、逐出和预取；Mooncake 偏向 分布式存储与传输数据面，负责跨节点保存和搬运大块 KV。它们既能单独接入推理框架，也能组合部署。 全文围绕五个问题展开： LMCache 管什么？它通过 Connector 接入 vLLM 等运行时，把 KV Cache 从 GPU 扩展到 CPU、本地盘和远端后端，并提供索引、逐出、预取、共享和观测能力。 Mooncake 管什么？Transfer Engine、Mooncake Store 以及 Prefill/Decode 分离连接器，解决高速 KV 传输和分布式存储问题。 两者怎样配合？在 LMCache 多进程架构中，Mooncak...

环境背景：一台连续运行 25 天的 3×RTX 4090 计算服务器（Ubuntu 22.04，NVIDIA 驱动 595.71.05，CUDA 13.2）。执行 nvidia-smi 时，三张 GPU 的风扇、温度、功耗读数全部显示 ERR!，GPU 不可用。本文完整记录故障的排查、定位、在线恢复与后续加固过程。 最重要的话说在前面：不要重启机器！不要重启机器！不要重启机器！ 不然你会得到一张返厂维修单。。。 故障现象三张 GPU 的 nvidia-smi 输出如下： 1234567891011+-----------------------------------------+------------------------+----------------------+| GPU Name Persistence-M | Bus-Id Disp.A || Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compu...

目标：移除 RTX 4090 P2P/GDR 非官方改造，恢复 NVIDIA 官方普通驱动和官方 NCCL，同时保留 CUDA 工具链、业务数据和 RDMA 网络栈。 推荐路径是恢复与现有用户态完全匹配的官方 595.71.05 open DKMS。不要用通配符清除所有 nvidia-* 或 libnvidia-* 包；这种做法容易一并删除 CUDA、容器运行时和桌面依赖。 恢复后的目标状态 项目 目标 NVIDIA 内核模块 官方 nvidia-dkms-open 595.71.05-1ubuntu1 NVIDIA 用户态和固件 官方 595.71.05-1ubuntu1 NCCL 仓库提供的官方 libnccl2 / libnccl-dev P2P 补丁 nvidia-open-p2p-dkms 不再安装，DKMS 无 nvidia-open-p2p GDR shim 业务进程不再设置 LD_PRELOAD=...libgdrshim.so 补丁 NCCL 不再通过 LD_LIBRARY_PATH 加载 /opt/rtx4...

适用范围：Ubuntu 22.04、RTX 4090、NVIDIA 595.71.05 open 驱动、CUDA 13、NCCL 2.31.x，以及 ConnectX-6/7 RoCE 网络。 本文依据本机 /home/antl/ncu 中的补丁驱动、NCCL Tests 和实验报告整理。P2P 与 GDR 均属于非官方改造，不受 NVIDIA 支持。驱动安装或切换会中断所有 GPU 任务，并需要重启。 先理解 P2P 与 GDRP2P 和 GDR 解决的是两类不同问题： 功能 数据路径 主要用途 本机实现方式 PCIe P2P GPU 显存直接访问另一张 GPU 显存 单机多卡 NCCL、DDP、TP 社区补丁版 NVIDIA open 内核模块 GPUDirect RDMA（GDR） RNIC 直接 DMA 到/从 GPU 显存 跨节点 IB/RoCE 通信 NV503C 注册 shim + 补丁 NCCL 正确顺序是：先完成 P2P，再配置 GDR。P2P 成功不等于 GDR 成功；nvidia_peermem 已加载也...

经过一系列的测试和压测，最终终于测试出一套可以稳定运行且性能不劣化的配置方案。 服务：qwen38-27b-fp8，Docker 镜像 vllm/vllm-openai:v0.27.1，4090 * 2张 结论先行当前部署以现有 FP8 启动参数为基准，采用 TP2、完整 262144 上下文、FP8 KV cache、最多 4 个并发请求，并保留图片输入能力。最新实测结果： 配置 并发 输入/输出 token 输出吞吐 TTFT P50 TPOT P50 结果 当前最终配置（MTP3、balanced、0.92、8192、图片上限 786432 像素） 1 512/2048 99.54 tok/s 185.36 ms 9.96 ms 稳定，3/3 成功 当前最终配置 4 512/1024 283.04 tok/s（aggregate） 634.87 ms 11.47 ms 稳定，8/8 成功 历史 MTP3 interactivity（条件不同） 8 512/1024 ...

参数与命名总表 分类 参数/对象 最终值或名称 说明 记录时间 配置完成日期 2026-08-28 本文记录当日最终状态 云服务器 公网 IPv4 <服务器公网IP> 腾讯云 Lighthouse 云服务器 管理面板 1Panel 管理 OpenResty、frps 等 云服务器 frps 容器 1Panel-frps-TXDh Docker，network=host 云服务器 frps 版本 0.64.0 与本地 frpc 保持一致 云服务器 frps 控制端口 TCP 7000 本地 frpc 主动连接此端口 云服务器 frps Dashboard TCP 7500 不属于推理 API 公网入口 云服务器 frps 配置 /opt/1panel/apps/frps/frps/data/frps.toml 挂载到容器 /etc/frp/frps.toml 云服务器 FRP 转发监听地址 127.0.0.1 ...

空闲时间翻阅之前的U盘文件，发现高中时期军事社团活动上给大家出的战术想定题目，内容很经典，来自于美方军校的真实题目（应该是），很多都是针对治安战总结出来的相关题目，基本规模控制在班排级别（这也可以理解，毕竟学员出来也要从基层干起）；这其中有些题目还比较有参考价值，因此我将他们整合成一篇博客，供大家参考阅读~ 城市作战情况：你第六陆战队1营A连1排的排长，美军正在进行一次进攻行动，这是在荒废的沙漠国家Kartiq进行的联合作战的一部分。联合国军（淡泊注：美国鬼子还真会做梦阿，哈哈。）此举就是要推翻Kartiqi的极权独裁者并被这一地区带来稳定和安宁。K军队抵抗轻微。一般老百姓蔑视他们的领袖，但是同时他们也对美军在这一地区的存在不安。本地人通常会避开美军但是还没有公开反对过美军。但是，如果确信的他们正在变成军事的行动直接的目标,他们会发动起义保家卫国。在意识到这种可能后，Kartiqi的部队为了把老百姓拉进冲突而在城市中增加了活动次数 。在一个星期以前本团夺取了Rikala 的城镇。1营被赋予在本城恢复秩序的任务，而本团的其他军队仍推向北方（淡泊注：听起来像是纳西里耶发生过的故事）。...

环境说明本文记录在一台单机 4 卡 RTX 4090 服务器上，通过 Docker 部署 NVIDIA Megatron-LM，并完成从环境安装、NCCL 通信验证到 GPT 小模型训练测试的完整流程。 本机环境如下： 123456操作系统：Ubuntu 24 DesktopGPU：4 × NVIDIA GeForce RTX 4090NVIDIA Driver：595.71.05容器运行环境：Docker + NVIDIA Container ToolkitMegatron 路线：NVIDIA/Megatron-LM 主线版本基础镜像：nvcr.io/nvidia/pytorch:26.01-py3 Megatron-LM 主要用于大模型训练和并行训练实验，和 vLLM 的定位不同：vLLM 更偏推理部署，Megatron-LM 更偏训练、预训练、继续预训练、模型并行和分布式训练验证。 停止已有占用显存进程如果机器上正在运行的占用显存的服务，需要先停止，释放GPU。 1docker ps 如果看到正在运行的 vLLM 容器，例如 qwen36-vllm，执行： 1dock...

本文记录在 Ubuntu 24 Desktop 系统上，使用 Docker + vLLM 部署 Qwen3.6-35B-A3B-FP8 大模型的完整流程。测试硬件为 4 张 RTX 4090 24GB，宿主机 NVIDIA 驱动版本为 595.71.05；本安装记录仅在此平台上经过验证，其余平台请按照自身需求调整策略。 本文目标是形成一套可复现的部署教程，因此只保留核心步骤，省略无意义的试错过程。 环境说明本次部署环境如下： 1234567操作系统：Ubuntu 24 Desktop显卡：4 × NVIDIA RTX 4090 24GBNVIDIA 驱动：595.71.05部署方式：Docker + vLLM OpenAI API Server模型：Qwen/Qwen3.6-35B-A3B-FP8模型存放目录：~/model服务端口：8000 由于 4 张 4090 总显存为 96GB，推荐优先使用 FP8 版本模型，即： 1Qwen/Qwen3.6-35B-A3B-FP8 不建议一开始直接部署 BF16 原版，因为 35B BF16 权重和 KV Cache 会带来更大的显...