一上手就调文风，常见的结果是程序起不来、或者能起来但每次生成慢得没法用，然后开始反复改温度、top_p、提示词——但问题根本不在参数上。按可分辨的顺序走：先确认运行时版本和依赖装齐了，再看显存能给到哪个模型档位，然后发一条最小请求证明服务真的通了，最后才碰文风和提示词。下面每一步都对应一个可执行的动作和一个可观察的输出现象，不靠猜。

先把环境跑通、再调文风，处理顺序应当是依赖核对 → 显存余量 → 最小请求 → 日志级别。部署前用运行时版本命令和显存命令各看一次，程序启动后再看一次显存，对比就能判断模型档位是否超上限。最小请求跑通（有正常文本返回、耗时可接受）之前，任何文风调整都没有参考价值。边界：显存够不等于速度可接受，日志默认级别往往看不到关键信息，需要手动调高后再复现一次问题。

核对运行时版本与依赖安装状态

这一步的目标是把“依赖缺失或版本不匹配导致的启动失败”先排除掉。先看运行时和包管理器版本，再看依赖清单，最后看这些包到底装在哪个环境里。

# 运行时版本
python `--version`
# 或 node `--version`，按你实际使用的运行时选一个

# 依赖列表（列出全部，再按关键字过滤）
python -m pip list
python -m pip list | grep -i -E "torch|cuda|transformers|fastapi|uvicorn"

# 如果用 conda
conda list

# 确认当前用的解释器路径，避免装到另一个环境
which python
python -c "import sys; print(sys.executable)"

常见冲突分三类。第一类是版本不匹配，典型表现是安装阶段能过、导入阶段直接抛错，信息里通常出现两个互相要求的版本号，这时不要急着升级全部依赖，先按项目声明的约束回退或对齐其中一个。第二类是缺包，报错里出现 ModuleNotFoundError 之类字样，装完还要再确认一次是否装进了当前解释器对应的环境。第三类是装错环境，虚拟环境没激活、或者系统解释器和项目解释器混用，表现是“明明装过了却还是找不到”。

判断依据只认两样东西：pip list 里是否真实列出该包，以及导入时是否报错。不写死具体版本号，因为不同显卡驱动和项目分支的匹配关系不一样，需要结合你本机环境确认。

查显存余量，判断能承载的模型规模方向

显存要分两次看：程序没启动时看一次，得到“空载上限”；服务起来并加载完模型后再看一次，得到“实际占用”。两次相减，才是留给上下文和并发的余量。

# 空载时
nvidia-smi

# 启动服务并等待模型加载完成后再看一次
nvidia-smi

# 想持续观察波动，可以每隔一秒刷新一次
watch -n 1 nvidia-smi

不装工具时，也可以用系统自带的显卡监控面板看显存占用曲线，判断方法是相同的：看总量、看已用、看还有多少剩余。加载完成后如果已用接近总量，通常说明当前档位对这台机器偏大，应先换更小的量化档位或更短的上下文长度，而不是先去调生成参数。加载过程中如果直接报显存不足并退出，那属于环境容量问题，不是文风问题。

建议的取舍方式：先定档位再定上下文，档位调小、上下文调短是可先尝试的方向；确认能稳定加载之后，再考虑是否需要更大的上下文。这里不做“能提升多少”的承诺，只按本机实测余量判断。

发一条最小生成请求，确认服务真的通了

服务启动日志显示监听端口，不代表推理链路可用。用一条最短的请求验证：短提示词、小的输出长度、不叠加任何文风要求。

# 通用接入骨架，路径和字段名以你部署的服务实际声明为准
curl -s -X POST http://127.0.0.1:8000/v1/completions \
  -H "Content-Type: application/json" \
  -d '{
    "prompt": "你好",
    "max_tokens": 16,
    "temperature": 0
  }'

成功的判断看三处：HTTP 状态码是否为 2xx；返回体里是否有非空的生成文本字段；从发出到返回的耗时是否在可接受范围（这条是体感判断，不设具体数值）。失败的判断同样明确：连接被拒绝说明端口或进程不对；长时间无返回说明加载或排队卡住；返回 5xx 且信息指向模型加载，说明是环境侧问题；参数被拒绝则信息里通常会点名具体字段。

如果命令行不方便，服务自带的网页对话页也能当最小验证：随便输入两个字，看是否正常输出、是否等很久。两种方式选一种即可，但要留一次记录，方便后面出问题时对比。

打开日志级别，区分环境报错与参数报错

日志级别一般有三个调整入口：启动参数、配置文件、环境变量。三者任选其一，通常以启动参数或环境变量优先级最高，具体以你部署时的启动脚本为准。

# 常见形态之一：启动参数
python main.py `--log-level` debug

# 常见形态之二：环境变量
LOG_LEVEL=debug python main.py

# 常见形态之三：配置文件里改为 debug 或 verbose 后重启服务

调高之后，日志通常分成两段可读区域。启动阶段输出的内容偏环境类：依赖导入、模型路径、显卡设备选择、显存分配、后端初始化，这些报错要回到前两节去处理。请求阶段输出的内容偏参数类：请求体字段、上下文长度、模板或提示词格式、超时，这些才是文风之外需要单独调的部分。

复现问题时建议只保留一次操作，再去看新增的那几行日志，不要把整段刷屏内容当成错误原文去对照；报错文字随版本变化，判断看的是它出现在哪个阶段、指向哪个模块。

环境稳定后再进入文风与提示词调整

进入调文风之前，应当固定下来的几项设置：模型与量化档位、上下文长度上限、推理后端与监听端口、启动参数（含日志级别）、以及单次请求的输出长度上限。这几项确认后写进启动脚本或配置文件，不再在调文风过程中改动。

之后每次对比文风，只改提示词和采样参数（例如温度、top_p、系统提示词结构），一次只改一个变量，用同一条输入做前后对照。如果改完效果不对，先确认服务没被重启、模型档位没变，再怀疑提示词本身。这样一来，出问题时能快速判断是新提示词的问题，还是环境被悄悄改动过——这是把配置问题和创作问题分开处理的最省事做法。