2026-03-19

发布时间 :
  1. 03月19日
    1. 一、今日完成情况
    2. 二、今日感悟
    3. 三、备注
    4. 四、vscode免密登录
      1. 指定文件夹-启动模型
        1. 1. 通过进程名称查找 (最常用)
        2. 2. 通过端口号查找
        3. 3. 通过显存占用判断 (针对 GPU)
        4. 4. 直接给它发个“信号” (API 测试)
    5. 五、大模型部署模型代码–错误总结
      1. 1. 并发控制缺失
      2. 2. 参数不兼容
      3. 3. 超时与重试机制缺失
      4. 4. 模型名称配置不匹配
      5. 5. 错误处理与请求过滤不完善
      6. 6. 异常捕获不全面
      7. 七、深度排查补充：推理性能与环境陷阱
      8. 💡 避坑小结（给未来的自己）
    6. 六、《金瓶梅》经验总结
      1. 1、前情回顾
      2. 2、类比职场

03月19日

一、今日完成情况

  • 完成vscode远程连接服务器，两个设备都完成
  • 查看服务器模型是否启动，8000端口是否工作方法
  • 配置异步并行代码，数据抽取项目
  • 完成文章写作[[2026-03-19 心理咨询小作文]]

二、今日感悟

  • 核心业务数据​：
    • 大模型的使用，慢慢上手吧，异步并行的语法总是要掌握的
  • ​今日工作总结：​
    • 无
  • ​明日工作计划：
    • Google 自动化邮箱部署
    • 打通数据抽取，然后知道今天的错误主要在什么地方，并且对比两次抽取的不同
  • ​今日学习成长：​
    • 异步和并行了解了一下，还需要继续深入了解

三、备注

  • 预定–完成GLM和KiMi模型 opencode相关CLI的测试，查看其效果/codex openai 产品business尝试，对比效果。 截止日期：无
  • 预定–华尔街AI发展推演没有系统化了解，导出为图谱的形式，导出笔记，进行理解。 截止日期：3月20日 预计时间：1h
  • 预定–老大的论文阅读还是没有完成，这里需要花点时间梳理其算法逻辑。 截止日期：3月22日 预计时间：~~
  • 预定–完成dify工作流本地游戏本部署服务。
  • 预定–完成Google自动检测邮件，并且实现自动化脚本
  • 预定–完成实验室项目数据抽取，打通同步抽取线程
  • 已完成–数据科学数据预处理，完成两部分，实验和实验报告纸质版 截止日期：3月22日 预计时间：20min
  • 已完成–vscode remote ssh 实验室服务登录、vscode github账户配置一步到位 预计时间：30min
  • 已完成–服务器上面部署AI的接口，然后就是大语言模型的部署，这个可以了解一下，查看是否麻烦。 截止日期：3月20日

四、vscode免密登录

指定文件夹-启动模型

code --folder-uri vscode-remote://ssh-remote+lab-server/root/Documents/code/python

启动大语言模型：

VLLM_USE_V1=0 CUDA_VISIBLE_DEVICES=0 python -m vllm.entrypoints.openai.api_server     --model /root/models/Qwen3-30B-A3B-Instruct-2507     --served-model-name qwen3     --tensor-parallel-size 1     --gpu-memory-utilization 0.9     --max-model-len 8192     --trust-remote-code      --host 0.0.0.0     --port 8000

CUDA_VISIBLE_DEVICES=0 python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen3-14B \
  --served-model-name qwen3-14b \
  --gpu-memory-utilization 0.6 \
  --max-model-len 8192 \
  --trust-remote-code \
  --host 0.0.0.0 \
  --port 8000

查看终端是否启动模型线程：

1. 通过进程名称查找 (最常用)

你可以使用 ps 命令配合 grep 来搜索 vLLM 相关的进程。

Bash

ps aux | grep vllm
  • 如何看结果： 如果看到一行包含 python -m vllm.entrypoints.openai.api_server 的记录（且不是你刚刚运行的 grep 进程本身），说明它还在跑。

2. 通过端口号查找

你在启动命令中指定了 --port 8000。如果模型启动成功，该端口应该处于监听状态。

netstat -tulnp | grep 8000
  • 如何看结果： 如果看到 LISTEN 状态，并且对应的进程是 python，说明服务正开着门做生意呢。

3. 通过显存占用判断 (针对 GPU)

nvidia-smi
  • 如何看结果： 观察编号为 1 的 GPU。如果你看到 Memory-Usage 已经占用了约 90%（因为你设置了 --gpu-memory-utilization 0.9），那它肯定在运行。

4. 直接给它发个“信号” (API 测试)

如果服务活着，它应该会响应你的请求。你可以尝试调用它的健康检查接口：

curl http://localhost:8000/health
  • 如果返回： OK，说明一切正常。
  • 如果返回： Connection refused，说明它已经挂了。

五、大模型部署模型代码–错误总结

1. 并发控制缺失

代码未限制异步请求并发数，大量请求同时发送导致本地vLLM模型服务器过载，触发502错误。

2. 参数不兼容

  • 本地模型调用时携带阿里云百炼专属参数extra_body={"enable_thinking": False}，vLLM服务无法识别该参数导致请求异常。
  • 设置max_tokens=4000未适配模型实际处理能力，虽启动时指定--max-model-len 8192，但推理阶段token数设置不合理加剧服务器压力。

3. 超时与重试机制缺失

  • 未设置请求超时时间，长时间未响应的请求易导致连接挂死触发502错误。
  • 无失败重试机制，临时网络波动/服务器响应异常直接导致请求失败，无容错能力。

4. 模型名称配置不匹配

代码本地模式默认模型名qwen3-32b-chat与启动命令指定的served-model-name qwen3不一致，导致模型寻址错误。

5. 错误处理与请求过滤不完善

  • JSON解析容错性差，模型返回非标准JSON格式时直接崩溃，无降级处理逻辑。
  • 未过滤空文本/短文本无效请求，增加服务器无效负载。

6. 异常捕获不全面

未针对性捕获OpenAI客户端专属异常（APIError/APIConnectionError/Timeout），无法精准定位502等服务端错误类型。

七、深度排查补充：推理性能与环境陷阱

1. 物理推理耗时与超时阈值错位

  • 现象：单条请求也触发 TimeoutError。
  • 根因：忽略了 30B 级模型 在执行 ReAct（复杂推理） 任务时的物理耗时。ReAct 模式会生成大量的思考过程 Token，加上 vLLM 的 Prefill 耗时，总时间极易超过 aiohttp 默认或手动设置的 60s 阈值。
  • 对策：将 API 请求超时时间设为 None（永不超时）或至少 300s 以上；同时适当压缩 max_tokens 以减少模型“废话”时间。

2. 异步 ClientSession 管理不当（资源浪费）

  • 现象：高并发下出现连接耗尽或响应延迟增加。
  • 根因：在 get_completion 中循环创建/销毁 aiohttp.ClientSession()。这会导致频繁的 TCP 握手开销，无法发挥异步 IO 的长连接复用优势。
  • 对策：采用 单例模式或全局 Session，在脚本启动时初始化一次 Session，供所有异步任务共用。

3. 终端与 Python 环境的网络隔离/代理干扰

  • 现象：curl 测试秒回或正常，但 Python 脚本持续卡死或超时。
  • 根因：系统环境变量中存在 HTTP_PROXY 或 HTTPS_PROXY，导致 Python 的 aiohttp 尝试走代理访问 localhost，而终端 curl 可能配置了 no_proxy。
  • 对策：在代码中显式指定 proxy=None，或检查服务器环境的代理设置，确保本地回环地址（127.0.0.1）不走代理。

4. vLLM 启动参数对推理速度的副作用

  • 现象：推理速度远低于预期，导致客户端频繁超时。
  • 根因：使用了 --enforce-eager 参数。虽然它能节省约 2-4GB 显存，但会禁用 CUDA Graph，导致小 Batch 或单条推理时的延迟（Latency）大幅增加。
  • 对策：若显存允许，应移除 --enforce-eager 以换取更快的响应速度。

💡 避坑小结（给未来的自己）

“跑大模型异步脚本，并发控制是命门，超时设置是保命符，Session 复用是加速器。”

今天的错误主要是因为 30B 模型 的“重”与 异步 IO 的“快”之间没有做好缓冲（信号量）和容错（超时）。

六、《金瓶梅》经验总结

这个笔记是我第二天补的，因为回过头来看，其实这一节内容还是非常值得记录的，让人深思的。情节大致是，垈安小厮在处理他的主人和主人妻子之间的矛盾，没有做到不偏不倚，一个工具人的身份，其中的经验是，当我们的两个上级领导对我们的指示和任务有矛盾的时候，我们如何与另一方体面的交流，表示困难，而不是提前“站队”。

玳安（你提到的“戴安”或“大雁”）这个行为确实非常典型，他试图利用西门庆的权威来压制吴月娘，这在《金瓶梅》的后宅权力斗争中是一种高风险的“狐假虎威”。但在现代职场中，如果你作为下属，面对两个意见不合的领导（比如A领导和B领导），直接“拿A压B”通常会死得很惨，因为这会让你看起来像是在站队或者挑拨离间。

1、前情回顾

《金瓶梅》的第四十六回，前情回顾：

维度 内容
背景 元宵佳节，西门府内宅。吴月娘作为当家主母，发现二娘李瓶儿的丫鬟偷藏了一块金子，按家规应严惩赶走。
矛盾 玳安（西门庆身边小厮）奉命来传话，说西门庆同意不赶走该丫鬟。吴月娘认为：①玳安越权干预内宅事务 ②搬出西门庆压她 ③挑战她作为正妻的权威
解决 吴月娘当场发怒，斥责玳安”奴才也敢来管我的事”，明确表示内宅事务她说了算，不给西门庆面子。
结果 ①吴月娘维护了当家主母的权威 ②玳安碰了一鼻子灰 ③丫鬟最终未被赶走（西门庆拍板）④埋下吴月娘对西门庆纵容下人的不满

2、类比职场

职场启示笔记：

维度 内容
背景 职场中常遇到多头领导情况：直属领导A与大领导B指令不一致，或跨部门领导介入你的工作。
矛盾 作为执行层员工，夹在中间：①听A的，得罪B ②听B的，架空A ③自己判断，两边都可能不满 ④传话不当，变成”挑拨离间”
解决 三不原则：
• 不站队：不说”我听谁的”，只说”请领导定优先级”
• 不传话：不口头传递领导间的分歧，用邮件抄送双方确认
• 不背锅：重要决策留书面记录，让领导自己签字确认
结果 ①保护自己不卷入权力斗争 ②让矛盾回归领导层解决 ③建立”对事不对人”的职业形象 ④长期获得双方信任

□ 第一步：暂停执行，不急于表态
□ 第二步：向后来布置任务的领导说明当前工作负荷
□ 第三步：请示优先级排序（”您看这个和A总的任务哪个更急？”）
□ 第四步：重要事项邮件确认，抄送相关领导
□ 第五步：执行后同步双方，保持信息透明

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 kipleyarch@gmail.com

浙ICP备2025181060号-2 © litearch

Built with Hexo and 3-hexo theme

Obsidian