企业官网建设流程全解析

1. 项目概述：这不是又一个“大模型入门课”，而是一份从实验室代码到生产环境的实战手记

“SGG-大模型：从算法优化到工程落地的双重范式”——这个标题里没有“零基础”“速成”“保姆级”，也没有“爆火”“风口”“躺赢”。它直白得近乎冷酷：SGG，是项目代号，也是我们团队内部对这套技术栈的简称；大模型，不是泛指LLaMA或Qwen，而是特指我们在真实业务场景中反复打磨、最终跑通全链路的7B级中文对话模型；算法优化与工程落地，不是并列的两个模块，而是同一枚硬币的两面：你调参时没考虑显存碎片，推理服务就必然OOM；你设计API时忽略请求队列积压，再好的微调结果也卡在网关。我带过三支不同行业的AI落地团队，见过太多项目死在“模型指标漂亮，上线即崩盘”的断崖上。这次SGG项目，我们用142天，把37次模型迭代、21轮服务压测、8次架构重构的原始日志、监控截图和失败回滚记录，全部沉淀为可复现、可审计、可交接的技术路径。它不教你怎么写prompt，但会告诉你为什么在batch_size=4时GPU利用率只有32%；它不讲transformer原理，但会拆解如何把一个12GB的LoRA权重，在不重启服务的前提下热加载进正在响应用户请求的vLLM实例。如果你正卡在“训完模型不知道下一步该部署到哪”“部署后QPS上不去还老超时”“微调效果好但一上生产就变智障”这些具体而真实的困境里，这篇就是为你写的。它适合两类人：一类是刚跑通Lora微调的算法同学，想真正理解自己写的那几行peft_config.py背后发生了什么；另一类是运维或后端工程师，被临时拉来“支持下AI服务”，面对一堆陌生的CUDA_VISIBLE_DEVICES和--tp-size参数一头雾水。我们不用“范式”这种词装点门面，只说人话：怎么让大模型在你公司的服务器上，老老实实、稳稳当当地干活。

2. SGG项目整体设计与思路拆解：为什么放弃“标准流程”，选择一条更笨但更稳的路

2.1 核心矛盾识别：算法指标与工程指标的天然撕裂

很多团队启动大模型项目时，第一张PPT永远是“准确率提升X%”“BLEU分数提高Y点”。这本身没错，但问题在于，这些指标是在理想数据集、固定batch、无并发压力、单卡测试环境下得出的。而真实世界里，一个客服对话系统，它的核心KPI是“95%的请求在800ms内返回”，不是“BLEU得分高”。我们最初也走了弯路：在A100上微调出一个BLEU 42.3的模型，兴奋地部署到T4集群，结果首日上线，平均延迟飙到2.3秒，错误率17%。根因排查发现，问题不在模型本身，而在三个被算法侧完全忽略的工程细节：第一，训练时用的FlashAttention-2，在T4上因compute capability 7.5不支持，自动fallback到慢速kernel，推理吞吐直接腰斩；第二，微调时用的bf16精度，但T4不支持bf16，强制转为fp16后，部分层权重出现NaN，导致输出乱码；第三，最致命的是，训练脚本里hardcode了max_length=2048，而线上用户输入的长对话历史，经tokenizer处理后实际token数常达2300+，触发了vLLM的sequence overflow保护机制，直接拒绝服务。这三点，没有任何一篇论文会提，但每一点都足以让项目停摆一周。SGG项目的设计起点，就是承认这个撕裂：算法优化的目标，必须是“可工程化”的优化。我们定义了SGG的三条铁律：所有算法改进，必须附带对应的工程验证方案；所有工程改造，必须有可量化的算法影响评估；任何技术选型，必须同时通过“单卡性能测试”和“多卡服务压测”双关卡。

2.2 技术栈选型逻辑：为什么是vLLM + LoRA + Triton，而不是HuggingFace TGI或DeepSpeed-Inference

市面上的大模型推理框架不少，TGI、vLLM、Text Generation Inference（TGI）、llama.cpp，甚至还有团队自己魔改PyTorch。我们花了三周时间，用同一套模型、同一组测试数据，在A10、A100、L4、T4四类卡上做了横向对比。结果很清晰：TGI在A100上表现优异，但在L4上，其PagedAttention内存管理策略因L4的16GB显存限制，导致prefill阶段频繁触发CPU-GPU数据搬运，延迟波动极大；llama.cpp主打CPU推理，对我们要求的“亚秒级响应”完全不达标；而vLLM，在L4上展现出惊人的鲁棒性——它通过自定义的PagedKVCache，将KV缓存按block切分，每个block大小严格控制在L4显存页对齐边界（4KB），配合高效的block swapping策略，使得即使在显存仅剩2GB时，仍能维持85%以上的GPU利用率。这是算法层面的精巧设计，更是工程落地的刚需。所以SGG选择了vLLM作为推理底座。微调方案上，我们放弃了全参数微调（Full Fine-tuning）和QLoRA，原因很实在：全参数微调需要至少24GB显存，超出我们主力L4卡的物理上限；QLoRA的4-bit量化，在推理时需实时dequantize，引入额外计算开销，实测在L4上反而比标准LoRA慢12%。最终选定标准LoRA，但做了关键改造：将LoRA的r（rank）参数从默认的8，根据各层敏感度分析，动态设为4/8/16三级，使总参数量减少37%，加载速度提升2.1倍。至于Triton，它不是用来写新算子的，而是用来重写vLLM中那个最耗时的函数：paged_attention_v1。原生CUDA kernel在L4上存在严重的warp divergence，我们用Triton重写后，该kernel执行时间从1.8ms降至0.6ms，占整个prefill阶段时间的比重从34%压到12%。这个选择不是为了炫技，而是因为L4的SM数量（32个）远少于A100（108个），对kernel的并行效率极度敏感。每一个技术选型，背后都是硬件规格、业务指标、团队能力三者的精确咬合。

2.3 架构演进路径：从单机单卡到高可用服务的五次迭代

SGG的架构不是一开始就想好的，而是踩着坑一步步长出来的。第一版（V1）：本地Jupyter Notebook跑transformers.pipeline，纯属验证想法，连API都没有。第二版（V2）：用FastAPI包装，单进程，单卡，无任何并发控制。上线第一天，一个用户发了个2000字长文，直接把GPU占满，其他所有请求排队等待，P95延迟突破5秒。第三版（V3）：引入vLLM，配置--tensor-parallel-size 1 --pipeline-parallel-size 1，解决了单卡瓶颈，但未解决服务稳定性。我们发现vLLM的--max-num-seqs参数若设得过大，会导致请求队列积压，内存暴涨；设得太小，又浪费GPU资源。于是我们开发了动态队列控制器，根据GPU显存剩余率和当前请求平均长度，实时调整--max-num-seqs，这个逻辑后来被我们抽成独立模块sgg-queue-adaptor。第四版（V4）：加入Prometheus+Grafana监控，但只监GPU利用率、显存占用等基础指标。一次深夜告警，GPU利用率98%，显存95%，但QPS却跌到谷底。深入排查才发现是PCIe带宽打满，nvidia-smi dmon -s u -d 1显示rx_util持续100%，根源是vLLM的--enable-chunked-prefill未开启，导致大请求一次性拉取所有KV cache，压垮PCIe。第五版（V5），也就是当前稳定版：采用vLLM的--enable-chunked-prefill+--max-num-batched-tokens 2048组合，并在Nginx层配置proxy_buffering off，彻底解决PCIe瓶颈；同时，将模型服务拆分为prefill和decode两个独立vLLM实例，前者专攻长文本理解，后者专注流式生成，通过Redis Pub/Sub解耦，实现真正的异步流水线。这五次迭代，每一次都源于一个具体的、无法回避的线上问题，而非理论推演。所谓“双重范式”，其本质就是算法与工程在真实压力下的相互校准与驯化。

3. 核心细节解析与实操要点：那些文档里不会写的“魔鬼细节”

3.1 LoRA微调中的权重冻结陷阱：为什么你的微调结果在vLLM上失效

LoRA微调看似简单，peft.get_peft_model(model, lora_config)一行代码搞定。但SGG项目初期，我们遇到了一个诡异现象：在训练脚本里用model.generate()测试，效果完美；但将LoRA权重导出为adapter_model.bin，加载到vLLM中，输出质量断崖式下跌。排查了三天，最终定位到一个被所有人忽略的细节：peft_config.target_modules的设置。我们最初照搬HuggingFace示例，设为["q_proj", "v_proj"]。这在训练时没问题，因为transformers.Trainer会自动将这些模块替换为LoraLinear。但vLLM加载LoRA时，其LoraRequest机制要求，LoRA权重必须与base model的对应层完全同名且同结构。问题来了：HuggingFace的LlamaForCausalLM源码里，q_proj和v_proj是nn.Linear，但vLLM的LlamaModel实现中，这两个层被封装在LlamaAttention类里，其属性名为qkv_proj（一个将q/k/v合并的线性层）。当我们用["q_proj", "v_proj"]微调时，peft创建的LoraLinear层，在vLLM的模型图中根本找不到匹配的父节点，导致LoRA权重被静默忽略！解决方案是：必须查看vLLM源码中对应模型的forward函数，找到其实际使用的层名。对于vLLM的Llama，正确target_modules是["qkv_proj", "o_proj", "gate_up_proj", "down_proj"]。我们为此写了一个小工具sgg-lora-checker.py，它能自动解析vLLM模型的forward签名，列出所有可注入LoRA的层名，并生成标准配置。这个细节，没有任何官方文档提及，但它决定了你的微调工作是否真的“生效”。

3.2 vLLM服务启动参数的物理意义：不只是调参，是理解GPU的“呼吸节奏”

vLLM的启动命令像天书：python -m vllm.entrypoints.api_server --model /path/to/model --tensor-parallel-size 1 --pipeline-parallel-size 1 --max-num-seqs 256 --max-model-len 2048 --gpu-memory-utilization 0.9 --enforce-eager。新手常把它当作黑盒参数去试错。但在SGG项目中，我们给每个参数赋予了明确的物理意义，将其视为对GPU硬件资源的“精准调度指令”。--max-num-seqs，不是“最多处理多少个请求”，而是“最多在GPU显存中同时驻留多少个请求的KV Cache Block”。每个Block大小为block_size * (num_layers * 2 * hidden_size * dtype_size)，其中block_size默认为16。这意味着，--max-num-seqs 256，在我们的7B模型（hidden_size=4096, num_layers=32）上，仅KV Cache就需占用约1.8GB显存。--gpu-memory-utilization 0.9，不是简单的“显存使用率90%”，而是vLLM向CUDA申请显存时的“信用额度”。它告诉vLLM：“你可以按90%的显存总量来规划Block Cache，但实际使用中，如果某个请求突发增长，可以临时超限，只要不超过100%”。这个参数必须与--max-num-seqs协同调整。我们曾将utilization设为0.95，max-num-seqs设为512，结果服务启动失败，报错CUDA out of memory。原因在于，vLLM的Block Cache预分配逻辑，会按utilization * total_memory计算总Block数，再除以单Block大小，得到最大Block数。当utilization过高，计算出的最大Block数，超过了GPU物理显存所能容纳的极限，就会在初始化阶段崩溃。最终，我们通过nvidia-smi监控memory.used和memory.total，结合vllm的日志Initializing KV cache with ... blocks，反向推导出最优组合：utilization=0.85,max-num-seqs=384，在L4上实现了显存利用率达84.7%，且无OOM风险。这不再是调参，而是对GPU内存管理机制的一次深度测绘。

3.3 Python环境与CUDA版本的“隐性绑定”：为什么pip install vllm总是失败

SGG项目部署在Ubuntu 22.04 LTS上，Python版本3.10。我们遇到最头疼的问题不是模型，而是环境。pip install vllm在不同机器上，有时成功，有时报错nvcc fatal : Unsupported gpu architecture 'compute_86'。根源在于CUDA Toolkit版本与GPU compute capability的严格匹配。我们的L4卡，compute capability是8.9，而CUDA 11.8官方支持的最高compute capability是8.6。这意味着，如果你的系统里装了CUDA 11.8，pip install vllm会尝试编译一个针对compute_86的kernel，自然失败。解决方案不是升级CUDA（因为Ubuntu 22.04的nvidia-cuda-toolkit包只提供11.8），而是强制vLLM使用预编译的wheel包。我们发现vllm的PyPI页面上，有针对不同CUDA版本和平台的wheel文件。我们下载了vllm-0.4.2+cu118-cp310-cp310-manylinux_2_28_x86_64.whl（注意+cu118后缀），然后pip install ./vllm-0.4.2+cu118-cp310-cp310-manylinux_2_28_x86_64.whl。这个wheel包是vLLM官方用CUDA 11.8编译的，但它内部的kernel是用--generate-code arch=compute_80,code=sm_80 --generate-code arch=compute_86,code=sm_86 --generate-code arch=compute_89,code=sm_89指令编译的，完美支持L4。这个细节，vllm文档只字未提，但却是能否在主流云服务器上顺利部署的生命线。我们为此建立了一个sgg-env-checklist.md，里面明确列出：L4卡 → 必须用+cu118wheel；A100卡 → 必须用+cu118或+cu121；T4卡 → 必须用+cu111。Python版本也必须严格匹配，cp310代表Python 3.10，用错版本，wheel包会直接拒绝安装。环境不是“配好了就行”，它是整个工程落地的第一道、也是最不可妥协的门槛。

4. 实操过程与核心环节实现：从零开始搭建SGG服务的完整流水线

4.1 环境准备与依赖安装：一份可直接复制粘贴的Shell脚本

以下是我们SGG项目在Ubuntu 22.04上的标准环境初始化脚本，经过21台不同配置服务器的验证，成功率100%。它规避了所有常见的坑，包括apt源、pip源、CUDA驱动冲突等。

#!/bin/bash # sgg-env-setup.sh set -e echo "=== 步骤1：更新系统与安装基础依赖 ===" sudo apt update && sudo apt upgrade -y sudo apt install -y python3.10 python3.10-venv python3.10-dev build-essential libssl-dev libffi-dev echo "=== 步骤2：配置Python 3.10为默认python ===" sudo update-alternatives --install /usr/bin/python python /usr/bin/python3.10 1 sudo update-alternatives --config python # 手动选择python3.10 echo "=== 步骤3：创建并激活虚拟环境 ===" python3.10 -m venv /opt/sgg-env source /opt/sgg-env/bin/activate pip install --upgrade pip echo "=== 步骤4：安装CUDA 11.8兼容的PyTorch ===" # 注意：此命令会自动下载并安装适配CUDA 11.8的torch和torchaudio pip3 install torch==2.1.0+cu118 torchaudio==2.1.0+cu118 --extra-index-url https://download.pytorch.org/whl/cu118 echo "=== 步骤5：安装vLLM预编译Wheel（L4专用） ===" # 下载地址：https://pypi.org/project/vllm/#files，选择+cu118版本 wget https://files.pythonhosted.org/packages/3c/1b/.../vllm-0.4.2+cu118-cp310-cp310-manylinux_2_28_x86_64.whl pip install ./vllm-0.4.2+cu118-cp310-cp310-manylinux_2_28_x86_64.whl echo "=== 步骤6：安装其他必要依赖 ===" pip install fastapi uvicorn prometheus-client redis echo "=== 步骤7：验证安装 ===" python -c "import torch; print('PyTorch版本:', torch.__version__); print('CUDA可用:', torch.cuda.is_available())" python -c "from vllm import LLM; print('vLLM导入成功')" echo "=== 环境准备完成！请执行 source /opt/sgg-env/bin/activate 激活环境 ==="

这个脚本的关键在于：它不依赖系统自带的nvidia-cuda-toolkit，而是让PyTorch和vLLM各自携带所需的CUDA运行时库（libcudart.so），从根本上避免了系统CUDA版本与框架需求的冲突。我们曾试过用apt install nvidia-cuda-toolkit，结果导致PyTorch的CUDA版本与vLLM的CUDA版本打架，调试了整整两天。这份脚本，是我们用血泪换来的“最小可行环境”。

4.2 LoRA微调全流程：从数据准备到权重导出的逐行注释

SGG的微调数据并非网上爬取的通用语料，而是我们业务中真实的1278条客服对话，每条都包含“用户问题-客服回复-用户满意度评分（1-5星）”三元组。我们只选取评分≥4星的对话，确保数据质量。微调脚本的核心是train_sgg_lora.py，以下是关键片段及其深度注释：

# train_sgg_lora.py from transformers import AutoTokenizer, AutoModelForCausalLM, TrainingArguments, Trainer from peft import LoraConfig, get_peft_model import torch # 1. 加载基础模型：必须使用vLLM兼容的模型 # 我们选用的是"meta-llama/Llama-2-7b-hf"，但注意，vLLM 0.4.2要求模型必须有"config.json"和"pytorch_model.bin"， # 不能是safetensors格式。因此，我们先用transformers的convert_checkpoint_to_safetensors.py脚本转换。 model_name = "/data/models/llama-2-7b-hf" tokenizer = AutoTokenizer.from_pretrained(model_name) model = AutoModelForCausalLM.from_pretrained( model_name, torch_dtype=torch.float16, # 必须是float16，vLLM不支持bf16 device_map="auto" # 让transformers自动分配到GPU ) # 2. LoRA配置：这里的target_modules是vLLM的层名，不是HuggingFace的！ lora_config = LoraConfig( r=8, # rank，我们实测8是L4卡的甜点值 lora_alpha=16, # alpha，通常设为2*r target_modules=["qkv_proj", "o_proj", "gate_up_proj", "down_proj"], # 关键！见3.1节 lora_dropout=0.05, bias="none", task_type="CAUSAL_LM" ) # 3. 应用LoRA：此时model已经是peft模型 model = get_peft_model(model, lora_config) model.print_trainable_parameters() # 输出：trainable params: 4,194,304 || all params: 6,739,224,576 || trainable%: 0.0622 # 4. 数据预处理：重点在于padding和truncation策略 def preprocess_function(examples): # 将对话拼接为"用户：{question}\n客服：{answer}"格式 texts = [f"用户：{q}\n客服：{a}" for q, a in zip(examples["question"], examples["answer"])] # tokenizer会自动添加bos/eos token tokenized = tokenizer( texts, truncation=True, max_length=2048, # 必须≤vLLM的--max-model-len，否则加载失败 padding="max_length", # 使用max_length填充，保证batch内长度一致 return_tensors="pt" ) # labels必须与input_ids相同，这是因果语言建模的要求 tokenized["labels"] = tokenized["input_ids"].clone() # 将padding token的label设为-100，使其在loss计算中被忽略 tokenized["labels"][tokenized["labels"] == tokenizer.pad_token_id] = -100 return tokenized # 5. 训练参数：关键在于per_device_train_batch_size和gradient_accumulation_steps training_args = TrainingArguments( output_dir="/data/sgg-lora-output", per_device_train_batch_size=4, # L4卡的极限，再大就OOM gradient_accumulation_steps=8, # 用梯度累积模拟更大的batch_size learning_rate=2e-4, num_train_epochs=3, save_steps=100, logging_steps=10, fp16=True, # 必须开启，L4不支持bf16 report_to="none", # 关闭wandb等，减少干扰 # 最重要的一点：disable_tqdm=True，关闭进度条，防止jupyter notebook中日志混乱 disable_tqdm=True ) trainer = Trainer( model=model, args=training_args, train_dataset=tokenized_dataset, data_collator=lambda x: x # 因为我们已经padding好了，不需要collator ) trainer.train() # 6. 权重导出：必须用merge_and_unload，生成vLLM可读的格式 model = model.merge_and_unload() # 将LoRA权重合并回base model model.save_pretrained("/data/sgg-merged-model") # 保存为标准transformers格式 tokenizer.save_pretrained("/data/sgg-merged-model")

这个流程的每一个参数，都经过了在L4卡上的实测。per_device_train_batch_size=4是L4的硬性上限；gradient_accumulation_steps=8是为了达到等效batch_size=32，以稳定训练；max_length=2048是vLLM服务的--max-model-len的镜像。微调不是魔法，它是一系列在硬件约束下做出的精确妥协。

4.3 vLLM服务启动与API封装：一个稳定、可观测的生产级服务

SGG的vLLM服务不是简单地python -m vllm.entrypoints.api_server，而是一个完整的、可运维的服务单元。我们将其打包为systemd服务，并封装了健康检查和指标暴露。

# /etc/systemd/system/sgg-vllm.service [Unit] Description=SGG vLLM Inference Service After=network.target [Service] Type=simple User=ubuntu WorkingDirectory=/opt/sgg Environment="PATH=/opt/sgg-env/bin:/usr/local/bin:/usr/bin:/bin" # 启动命令：关键参数已加注释 ExecStart=/opt/sgg-env/bin/python -m vllm.entrypoints.api_server \ --model /data/sgg-merged-model \ # 微调后的合并模型 --tensor-parallel-size 1 \ # L4单卡 --max-num-seqs 384 \ # 经过测算的最优值 --max-model-len 2048 \ # 与训练时max_length一致 --gpu-memory-utilization 0.85 \ # 显存安全水位 --enforce-eager \ # 禁用CUDA Graph，避免L4上偶发的graph capture失败 --port 8000 \ # API端口 --host 0.0.0.0 \ # 监听所有IP --enable-chunked-prefill \ # 解决PCIe瓶颈 --max-num-batched-tokens 2048 \ # 控制prefill阶段的token总数 --disable-log-requests \ # 关闭请求日志，避免I/O瓶颈 --disable-log-stats \ # 关闭统计日志，由Prometheus统一采集 Restart=always RestartSec=10 StandardOutput=journal StandardError=journal [Install] WantedBy=multi-user.target

启动服务后，我们通过一个轻量级的FastAPI应用，封装vLLM的API，并加入业务逻辑：

# api_server.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel import httpx import asyncio app = FastAPI(title="SGG AI Service") # 使用httpx.AsyncClient进行异步HTTP调用，避免阻塞 vllm_client = httpx.AsyncClient(base_url="http://localhost:8000") class ChatRequest(BaseModel): messages: list[dict] # [{"role": "user", "content": "你好"}] temperature: float = 0.7 @app.post("/v1/chat/completions") async def chat_completions(request: ChatRequest): try: # 将FastAPI的request转换为vLLM期望的格式 vllm_payload = { "prompt": request.messages[-1]["content"], # 简化处理，只取最后一条 "temperature": request.temperature, "max_tokens": 512, "stream": False } # 调用vLLM API response = await vllm_client.post("/generate", json=vllm_payload, timeout=30.0) response.raise_for_status() result = response.json() # 将vLLM的response格式，转换为OpenAI兼容格式 return { "id": "sgg-" + result["request_id"], "choices": [{"message": {"role": "assistant", "content": result["text"]}}], "usage": {"prompt_tokens": result["prompt_len"], "completion_tokens": result["output_len"]} } except httpx.HTTPStatusError as e: raise HTTPException(status_code=e.response.status_code, detail=e.response.text) except asyncio.TimeoutError: raise HTTPException(status_code=408, detail="Request timeout") @app.get("/health") async def health_check(): # 对vLLM的/generate端点做健康检查 try: response = await vllm_client.post("/generate", json={"prompt": "test", "max_tokens": 1}, timeout=5.0) return {"status": "healthy", "vllm_status": response.status_code} except Exception as e: return {"status": "unhealthy", "error": str(e)}

这个API服务，不仅提供了标准的OpenAI兼容接口，更重要的是，它通过/health端点，将vLLM的底层健康状态，向上游（如Nginx、K8s）暴露，实现了真正的服务可观测性。这才是工程落地的终点。

5. 常见问题与排查技巧实录：来自142天线上运维的“血泪清单”

5.1 典型问题速查表：快速定位与解决

这张表，是我们142天运维中，高频问题的结晶。它不追求全面，只解决那些让你抓狂、让你凌晨三点还在服务器前刷新日志的“真问题”。

5.2 独家避坑技巧：那些只能靠经验才能get的点

提示：vLLM的--max-model-len不是“模型能处理的最长文本”，而是“模型权重中position embedding的最大索引”。如果你的base model是Llama-2-7b，其config.json里max_position_embeddings是4096，那么--max-model-len就不能超过4096。但我们训练时用了max_length=2048，所以这里设2048是安全的。但如果未来你想支持更长上下文，必须先用transformers的resize_token_embeddings方法扩展position embedding，再重新微调，否则vLLM会直接报错Position index out of range。

注意：不要在vLLM服务中启用--enable-prefix-caching。这个功能听起来很美，能缓存prefill结果，加速后续相同prompt的响应。但在我们的测试中，它在L4上会导致显存泄漏，服务运行24小时后，显存占用从2GB缓慢爬升到10GB，最终OOM。原因在于L4的显存管理器对prefix cache的block回收不够及时。我们已向vLLM社区提交issue，目前的解决方案是：禁用此功能，用更激进的--max-num-seqs和--max-num-batched-tokens来控制内存。

实操心得：vllm的/generateAPI返回的text字段，是模型生成的完整文本，包括了你输入的prompt。例如，你post{"prompt": "用户：你好"}，返回的text可能是"用户：你好\n客服：您好！有什么可以帮您？"。如果你只需要“客服”的回复部分，必须用tokenizer对text进行后处理，切掉prompt部分。我们为此写了一个sgg-postprocessor.py，它能智能识别用户：和客服：的分隔符，精准提取回复。这个细节，决定了你的前端展示是否干净，也决定了你能否将输出直接喂给下游的语音合成服务。

避坑提醒：pip install vllm安装的wheel包，其CUDA版本是固定的。如果你的服务器上同时装了CUDA 11.8和CUDA 12.1，pip install会优先使用系统PATH中第一个找到的nvcc。我们曾因此在一个装了CUDA 12.1的服务器上，pip install vllm成功了，但运行时报错undefined symbol: __cudaPopCallConfiguration。解决方案是：在安装前，用export PATH=/usr/local/cuda-11.8/bin:$PATH临时切换CUDA版本，再执行pip install。这个环境变量的切换，是很多自动化部署脚本失败的根源。

6. SGG项目的延伸思考：当“双重范式”成为一种工作习惯

SGG项目结束了，但它的影响远未停止。它没有教会我们一个