AIGC应用落地实战：从大模型微调到生产部署的完整技术路径



AIGC应用开发前的技术选型评估

AIGC应用落地面临的核心问题不是模型能力不足，而是工程化链路缺失。大量团队在概念验证阶段跑通了Prompt调用，进入生产环境后却发现推理延迟、并发瓶颈、成本失控接踵而至。技术选型阶段需要从模型能力、推理性能、部署成本三个维度做量化评估。

模型能力评估要建立基准测试集，覆盖目标业务场景的典型任务。不要依赖通用Benchmark排名，那和实际业务表现差距很大。建议用自有业务数据构造100-200条评测样本，按准确率、一致性、拒答率做打分。模型选型时还要考虑上下文窗口长度——长文档处理场景下，128K窗口模型比32K模型省下大量分块和检索的工程复杂度。

推理性能方面，首Token延迟（TTFT）和吞吐量（Tokens/s）是两个关键指标。对话类AIGC应用TTFT要控制在500ms以内，批量处理场景更关注吞吐。部署成本核算要把GPU租赁、API调用、存储、网络带宽全部纳入，很多团队只算API费用，忽略了向量检索和对象存储的隐性成本。

大模型微调的工程实践要点

微调是让基座模型适配垂直场景最高效的手段。LoRA微调在大多数业务场景下已经够用，全量微调的ROI很低，除非数据分布和基座模型差异极大。

数据准备是微调成败的关键。实操中有几个常见坑：第一，训练数据格式要和推理时的Prompt格式严格一致，格式不匹配是微调效果差的首要原因。第二，数据质量远比数量重要，500条高质量标注数据的效果往往超过5000条噪声数据。第三，要做好数据去重和去污染，避免训练集和评测集有重叠。

训练超参数上，LoRA的rank一般设16-64，alpha设为rank的2倍。学习率从2e-4开始，配合cosine scheduler。训练轮数通常2-3轮就够，再多容易过拟合。用8卡A100做7B模型的LoRA微调，数据量1000条，训练时间大约30分钟到1小时。

from peft import LoraConfig, get_peft_model
from transformers import AutoModelForCausalLM

model = AutoModelForCausalLM.from_pretrained("Qwen/Qwen2-7B", torch_dtype="auto")
lora_config = LoraConfig(
    r=32,
    lora_alpha=64,
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj"],
    lora_dropout=0.05,
    task_type="CAUSAL_LM"
)
model = get_peft_model(model, lora_config)
model.print_trainable_parameters()
# trainable params: 26M || all params: 7.2B || trainable%: 0.36%

推理服务部署与性能调优

模型推理部署方案要根据业务QPS选择。QPS低于10的场景，单卡部署+vLLM推理框架即可。QPS在10-100之间，需要多卡推理+负载均衡。QPS超过100，要考虑模型蒸馏或更小的蒸馏版本。

vLLM是目前最成熟的开源推理框架，核心优势是PagedAttention机制和Continuous Batching。实测对比，vLLM在并发请求下吞吐量比原生HuggingFace推理高出3-5倍。部署时注意几个配置：gpu_memory_utilization设0.9，max_model_len按实际需要设，不要用默认最大值，否则会浪费显存。启用prefix caching可以加速重复前缀的请求，对系统Prompt固定的场景效果显著。

# vLLM 启动命令
python -m vllm.entrypoints.openai.api_server \
    --model ./qwen2-7b-lora-merged \
    --served-model-name qwen2-7b-ft \
    --host 0.0.0.0 --port 8000 \
    --gpu-memory-utilization 0.9 \
    --max-model-len 4096 \
    --enable-prefix-caching

KV Cache是显存消耗大户。7B模型在4096 Token上下文下，KV Cache约占4GB显存。合理设置max_model_len可以控制显存占用，避免OOM。显存不够时，先考虑降低max_model_len而不是换更大的卡。

Prompt工程与输出质量控制

AIGC应用的输出质量不只取决于模型本身，Prompt设计和后处理逻辑同样重要。结构化输出是工程化的基础——让模型输出JSON格式而不是自由文本，下游处理逻辑才能稳定。

实现结构化输出的方案有三种：一是系统Prompt约束，要求模型按指定JSON Schema输出；二是使用Constrained Decoding，在推理阶段强制按Schema生成；三是Output Parser做后处理，正则提取或修复格式。推荐方案二+方案三的组合，Constrained Decoding保证格式合法，Parser兜底处理异常情况。

Few-shot示例对输出一致性影响很大。在System Prompt中放入3-5个高质量示例，比任何格式说明都有效。示例要覆盖正常case和边界case，包含模型容易犯错的场景。实测中，加Few-shot后输出格式合规率从70%提升到95%以上。

监控告警与持续迭代机制

AIGC应用上线后的监控维度和传统Web服务不同。除了常规的延迟和错误率，还需要监控：Token消耗量趋势（关联成本）、输出长度分布（异常短或异常长都是信号）、格式合规率（JSON解析失败比例）、内容安全拦截率。

建立A/B测试机制做模型迭代。新旧模型版本并行服务，按流量比例分流，对比业务指标而不是模型评测指标。业务方关心的是转化率和用户满意度，不是Perplexity的数值。

日志采集要保留完整的Prompt和Response，配合用户反馈信号（点赞/点踩/编辑修改），构建持续学习数据集。这些数据是下一轮微调最有价值的训练素材，比人工标注的数据更贴近真实业务分布。