启鑫的黑板报

作者： 启鑫

  • Token 预算是 AI 系统真正的硬约束

    Token 预算是大语言模型（LLM）系统中的核心硬约束，直接限制每次交互可使用的 Token 数量，包括输入、输出及工具调用。它不仅影响计算成本和延迟，也决定系统可用性与任务成功率。有效管理 Token 预算依赖上下文压缩（Summarization、关键状态保留、递归编码）、动态分配策略以及实时消耗监控。在多轮对话、RAG 系统和 LLM Agent 架构中，预算驱动设计可保证信息完整性、生成稳定性和成本可控性。长期优化 Token 使用效率是系统可扩展性、可控性和可靠性提升的关键。

    概念

    Token Budget（Token 预算）：在大语言模型（LLM, Large Language Model）系统中，Token 预算指每次模型交互允许消耗的最大 Token 数量，包括输入 Prompt 和模型输出。Token 预算是对计算资源、延迟和成本的直接约束，而非单纯的文本长度限制。

    Token Cost：Token 的计算成本由模型架构、序列长度和硬件资源决定。长序列不仅增加推理时间，也会线性或超线性地增加 GPU 显存占用和运行成本。

    Context Compression（上下文压缩）：在 Token 预算限制下，为保持任务信息完整性，需要对历史上下文进行策略性压缩，包括摘要（Summarization）、选择性保留关键状态和递归编码。

    Token-Budget-Driven Design（Token 预算驱动设计）：系统架构需以 Token 预算为硬约束来规划任务拆分、状态管理、工具调用和多轮交互流程。

    运作机制

    1. Token 消耗结构分析
    • Input Tokens：用户输入、系统指令、历史上下文。
    • Output Tokens：模型生成的响应。
    • Overhead Tokens：控制符、特殊标记和工具接口调用占用的 Token。
    1. 预算分配策略
    • 静态分配（Static Allocation）：为 Prompt、上下文和输出分别预设 Token 上限。适用于确定性任务或单轮交互。
    • 动态分配（Dynamic Allocation）：根据任务复杂度、上下文信息密度或工具调用需求动态调整 Token 上限。适用于多轮任务或 Agent 系统。
    1. 上下文压缩方法
    • 摘要压缩（Summarization）：将多轮历史对话或文档内容生成简短表示。
    • 关键状态保留（Key-State Retention）：只保留对任务决策至关重要的信息。
    • 递归编码（Recursive Encoding）：将长序列内容编码成向量或标记化形式，以减少 Token 占用。
    1. Token 消耗监控与反馈
    • 实时跟踪输入、输出和工具调用的 Token 消耗。
    • 根据预算消耗自动触发上下文压缩或任务拆分机制。
    • 对多轮系统提供 Token 使用报告，用于优化系统设计和提示工程（Prompt Engineering）。

    实际应用

    1. 多轮对话系统
    • 确保对话状态管理在 Token 预算内，防止长轮次交互导致上下文截断或生成失败。
    • 对重要信息使用递归摘要，实现长期对话记忆。
    1. RAG 系统（Retrieval-Augmented Generation）
    • 限制检索内容长度，使向模型提供的文档片段不会超过预算。
    • 在检索-生成闭环中动态分配 Token，保证生成质量和上下文完整性。
    1. LLM Agent 架构
    • 工具调用前评估输出 Token 需求，避免因生成过长导致预算溢出。
    • 复杂任务拆解为子任务，每个子任务对应独立 Token 预算管理，确保整体系统稳定。
    1. 成本控制与可扩展性
    • Token 预算直接对应云计算成本，可用于实时估算系统运行成本。
    • 对大规模部署和高并发场景，Token 预算是保证系统稳定性和可预测性的核心指标。

    深刻的见解/反思

    • Token 预算是系统设计的根约束：与模型参数、算法优化相比，Token 预算直接影响系统的可用性、响应时间和成本。任何忽略 Token 预算的系统设计必然导致性能退化或任务失败。
    • 设计思路应“预算优先”：在多轮交互、复杂任务或 Agent 系统中，先规划 Token 预算，再设计上下文管理、工具调用和生成策略，比先生成内容再裁剪更高效。
    • Token 使用效率是长期优化核心：通过上下文压缩、关键状态保留和动态分配，系统可以在固定预算下提高信息利用率和任务成功率。
    • Token 预算驱动的架构演化：随着任务复杂性增加，系统设计会趋向模块化、可递归的上下文管理结构，实现“预算可控 + 信息完整”的最佳平衡。
    • Token 与 AI 可控性关联：预算限制迫使系统选择信息优先级、明确工具调用边界，从而提升生成内容的可靠性和决策可解释性。

  • 使用 nc（netcat）进行网络故障排查

    一、nc 在网络排错体系中的技术定位

    1. nc 解决的核心问题

    nc（netcat）的唯一目标是验证：在指定路径与方向上，L3/L4 层通信是否成立。

    换句话说，nc 回答的是一个极其具体的问题：

    在当前网络拓扑与安全策略下，这个 IP + 端口，是否真的可达？

    nc 不关心：

    • 应用协议是否合法
    • 业务逻辑是否正确
    • 数据是否符合预期

    它只关注 网络层与传输层是否建立通信条件。

    2. nc 的能力边界

    从 OSI 分层角度看，nc 的作用严格限定在：

    • L3（IP 路由可达性）
    • L4（TCP / UDP 端口连通性）

    因此，nc 适合用于判断：

    • 是否存在路由问题
    • 防火墙 / ACL 是否阻断
    • NAT / 端口映射是否生效
    • 端口是否存在监听进程
    • TCP 与 UDP 行为差异导致的误判

    但 nc 无法替代：

    • 抓包分析（tcpdump / Wireshark）
    • 应用层协议验证（HTTP / TLS / SQL）

    3. nc 在标准排错链路中的位置

    在成熟的网络排错流程中，nc 位于关键的分界点：

    ping → nc → tcpdump → 应用层分析

    其作用是：
    在进入复杂分析之前，先确认“网络是否真的通”。

    二、nc 的工作机制与判定逻辑

    1. TCP 场景的判定模型

    在 TCP 场景中，nc 的行为等同于一个最小化的客户端：

    • 主动发起 TCP 三次握手
    • 根据返回结果判断链路状态

    其输出具有明确语义：

    nc 行为网络含义
    succeededTCP 会话建立成功
    refused对端可达，但端口未监听
    timeout路由或防火墙丢弃

    TCP 场景下，nc 的结论是确定性的。

    2. UDP 场景的判定局限

    UDP 不存在连接状态，nc 在 UDP 场景中仅完成一件事：

    • 发送 UDP 数据包

    这意味着：

    • 无返回 ≠ 不通
    • timeout ≠ 失败
    • nc 输出本身不具备充分判定能力

    UDP 场景下，nc 只能作为发包工具，不能作为结论工具。

    三、典型网络故障场景与应用

    场景一：ICMP 可达，但业务不可用

    问题本质

    • ping 验证的是 ICMP
    • 业务使用的是 TCP / UDP

    ICMP 成功不能推导业务端口可达。

    nc 验证方式

    nc -vz server_ip 443

    判定逻辑

    • succeeded：网络路径与端口策略成立
    • refused：服务未监听或未启动
    • timeout：中间防火墙或路由阻断

    场景二：验证防火墙策略是否生效

    客户端侧验证

    nc -vz -w 3 server_ip 22

    工程化解读

    nc 结果结论
    succeeded策略允许
    refused端口关闭
    timeout高概率被防火墙丢弃

    在 TCP 排错中，timeout 是最典型的安全策略阻断信号。

    场景三：VPN / UDP 业务异常（500 / 4500 / DNS）

    nc 的使用方式

    nc -vu -w 3 server_ip 500

    必须明确的事实

    • UDP 无握手
    • nc 不会确认对端状态
    • 无输出是常态

    正确排查模型

    tcpdump -ni any udp port 500

    结论依据：

    • 无出包：本机或路由问题
    • 有出包无回包：防火墙或对端异常

    场景四：NAT / 端口映射验证

    服务端监听

    nc -l 8080

    外部测试

    nc public_ip 8080

    结论判断

    • 成功连接：NAT / DNAT 生效
    • 无法连接：映射或安全策略问题

    场景五：区分网络问题与应用问题

    这是 nc 在工程实践中最核心的价值。

    方法论

    • 使用 nc 直接访问端口
    • 绕过真实应用逻辑
    nc -vz app_server 3306

    结论划分

    • nc 可连：网络层成立，问题属于应用或配置
    • nc 不可连：网络、防火墙或监听异常

    四、标准化 nc 网络排错流程

    在实际运维中，推荐固定以下执行顺序：

    1. DNS 解析是否正确

    nslookup host

    2. IP 层是否可达

    ping host

    3. 端口层是否可达

    nc -vz host port

    4. 是否真实发包

    tcpdump -ni any port port

    5. 检查防火墙、NAT、监听状态

    五、nc 输出结果

    TCP 场景

    输出技术结论
    succeeded端口连通
    refused端口未监听
    timeout路由或防火墙阻断

    UDP 场景

    现象正确理解
    无任何输出正常行为
    timeout无法作为失败依据
    ICMP 不可达明确不通

    UDP 排错必须结合抓包或服务端日志。

    六、常用 nc 排错命令速查

    # TCP 端口连通性测试
nc -vz -w 3 host port

# UDP 发包测试
nc -vu -w 3 host port

# 禁用 DNS 解析
nc -n host port

# 监听端口
nc -l port

# 抓包辅助分析
tcpdump -ni any port port

  • Debian 使用 Speedtest CLI 进行网络测速

    Speedtest CLI 让用户能够快速、稳定地测试网络带宽和延迟，适用于服务器运维监控、自动化网络状态记录，以及内网环境下的测速优化。

    安装

    # 安装必要的依赖
apt-get install curl

# 安装脚本
curl -s https://packagecloud.io/install/repositories/ookla/speedtest-cli/script.deb.sh | bash

# 安装
apt-get install speedtest

    运行测速

    speedtest

  • 企业内网Docker加速方案：基于 Docker Registry 搭建私有镜像缓存代理

    在企业内网环境下，受限于出口带宽与合规性，Docker 镜像拉取缓慢甚至超时已成为研发痛点。利用 Docker Registry 的 Pull-through Cache（拉取透传缓存） 模式，构建一套“一次拉取、全速复用”的内网镜像加速系统。为企业提供低成本、高效率的镜像分发方案。

    一、 部署指南

    1. 编写配置文件

    在服务器创建目录（如 /opt/docker-proxy），并创建 docker-compose.yaml：

    services:
  registry:
    image: registry:3
    container_name: registry
    ports:
      - "5000:5000"
    restart: always
    environment:
      REGISTRY_PROXY_REMOTEURL: https://registry-1.docker.io
    volumes:
      - ./data:/var/lib/registry

    2. 启动服务

    docker-compose up -d

    二、 客户端配置

    配置好加速器后，内网的终端设备（开发者电脑、测试服务器等）可以通过以下两种方式享受加速。

    方式 A：无侵入式拉取（推荐用于脚本）

    直接在镜像名前加上内网代理服务器的 IP 和端口：

    # 格式：docker pull <代理IP>:5000/<镜像名>
docker pull 192.168.1.100:5000/library/nginx:latest

    注意：对于 Docker Hub 的官方镜像，必须加上 library/ 前缀。

    方式 B：透明加速（推荐用于开发环境）

    修改 Docker 守护进程配置文件 /etc/docker/daemon.json，添加 registry-mirrors：

    {
  "registry-mirrors": ["http://192.168.1.100:5000"],
  "insecure-registries": ["192.168.1.100:5000"]
}

    由于我们默认使用的是 HTTP 协议，需要同时在 insecure-registries 中放行。

  • 在 Debian 13 Trixie 上安装 Fcitx5 中文输入法

    1. 安装中文输入法

    在终端执行以下命令，安装 Fcitx5 及中文输入法插件：

    apt update
apt install --install-recommends fcitx5 fcitx5-chinese-addons

    2. 配置 Fcitx5

    1. 打开 Fcitx5 配置工具：
       fcitx5-configtool
    1. 在“输入法”中点击 + 添加 Pinyin（拼音） 输入法。

    3. 切换输入法

    使用快捷键 Ctrl + 空格 在中英文输入法间切换。

  • SSH 报错REMOTE HOST IDENTIFICATION HAS CHANGED解决方法

    一、问题背景

    重装服务器系统再次连接 SSH 连接时，会出现如下报错：

    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Host key verification failed.

    提示信息中可能还会包含：

    Offending ECDSA key in /Users/username/.ssh/known_hosts:26
Host key for 192.168.XXX.XXX has changed

    二、为什么会发生

    SSH 通过 主机密钥（Host Key） 验证服务器身份：

    1. 第一次连接服务器时，SSH 会保存服务器的公钥指纹到本地：
    2. 后续连接时，会对比服务器发来的指纹与本地保存的指纹。
    3. 如果指纹不一致，SSH 会拒绝连接，防止中间人攻击。
    • 重装系统时，服务器会重新生成新的 SSH 主机密钥。
    • 因此，旧的指纹与新的不匹配。
    • SSH 就会报“REMOTE HOST IDENTIFICATION HAS CHANGED”。

    三、解决方法

    在本地终端执行：

    ssh-keygen -R <服务器IP>
    ssh root@<服务器IP>

    首次连接会提示：

    Are you sure you want to continue connecting (yes/no)?

    输入：

    yes