大模型工程化三大支柱：DataOps、MLOps与LLMOps实战

在真正把大模型推进到生产环境之后，你会发现最难的根本不是某个模型效果好不好，而是整个系统能不能稳定、可重复、可观测地跑起来。今天聊的这个话题，项目标题叫“大模型工程化三大支柱详解，从DataOps到MLOps”，说白了就是在解决一个核心矛盾：大模型这东西，研究阶段可以靠灵感和个人英雄主义，但到了工程化阶段，必须靠流程、平台和纪律。这篇文章我会沿着真实项目推进的顺序，把DataOps、MLOps还有大模型时代特有的LLMOps这三根柱子一根一根拆开讲，包括每根柱子解决的问题、落地的关键动作、我在实际部署和迭代中踩过的坑，以及一套可以直接抄作业的最小闭环实践。

这篇文章适合谁？你如果是算法工程师、后端开发、平台工程师，或者正准备把大模型从demo推向生产的创业者，读这篇能帮你少走很多弯路。就算你是刚入门的学习者，我也会把一些关键概念掰开揉碎讲清楚，保证不靠术语糊弄人。

1. 从数据到模型，DataOps先把底座打牢

很多人一上来就关注模型选型、微调、显存占用，却忽略了整个工程链条里最先崩掉的往往是数据环节。DataOps这个名字听起来高大上，本质上就是把数据当成软件一样去管理：要有版本、要有测试、要有发布流程、要有血缘追踪。到了大模型时代，数据工程的重要性不但没降低，反而被放大了。

1.1 大模型场景下DataOps解决的核心问题

传统机器学习场景下，我们处理的数据可能是几万行结构化表格，字段含义清晰，清洗逻辑相对固定。但大模型训练和微调的数据集完全是另一回事：动辄几十GB甚至几TB的文本、代码、图片、音视频，来源五花八门，质量参差不齐，而且数据的"正确性"标准没那么明确。比如你清洗一批中文语料，什么是重复样本？什么是低质量样本？判断标准经常要结合业务场景甚至伦理边界来定。

这个阶段DataOps管三件事：

• 数据版本化：训练集、验证集、测试集必须像代码一样打tag、记录hash。大模型的训练动辄几十万成本，如果数据改了但你不知道改了哪版，出了效果波动根本没法排查。
• 数据质量验证：在数据进入训练管线之前，自动跑一套质量检查——字段完整度、重复率、敏感词命中率、格式校验，不通过就直接阻断管线继续执行。
• 数据血缘追踪：每一行样本从哪来、经过哪些清洗步骤、最终进了哪个训练批次，都要能追溯。一旦模型在线上出了事故，你能反向定位是哪一批数据闯的祸。

我见过太多团队，数据文件命名是"train_v2_final_真的最终版.jsonl"，然后第二天又来了一个"train_v2_final2_最新版.jsonl"。你用这个文件训练出来的模型，过了一个月连自己都说不清楚训练集里到底有什么。这在大模型场景下是致命的，模型一旦出现胡言乱语或者偏见问题，没有数据血缘你根本无从下手。

1.2 从数据采集到特征工程的标准链路

实际操作中，我建议用一套标准化的流水线来管理数据生命周期。别一上来就追求什么分布式调度平台或者复杂的Airflow DAG，先把手动流程走通、走稳，再逐步自动化。

一条典型的大模型数据管线长这样：

bash复制# 1. 数据采集：从业务库、日志系统、外部数据源抽取原始数据
# 示例：从Kafka消费用户行为日志
kafka-console-consumer \
  --bootstrap-server kafka-cluster:9092 \
  --topic user-interaction-log \
  --from-beginning \
  --max-messages 1000000 \
  > raw_data/user_interactions.json

# 2. 数据清洗：去重、去噪、格式标准化
python scripts/clean_data.py \
  --input raw_data/user_interactions.json \
  --output clean_data/user_interactions_v1.jsonl \
  --dedup \
  --filter-language zh \
  --min-length 20

# 3. 数据质量检查：自动质检
great_expectations checkpoint run user_interactions_checkpoint

# 4. 数据推送：写入集中存储并打版本
dvc add clean_data/user_interactions_v1.jsonl
dvc push
git add clean_data/user_interactions_v1.jsonl.dvc
git commit -m "data: add user interaction v1"

这里有个关键细节我必须要强调：数据集打标签不是在文件名上加个日期，而是用版本管理工具记录整个数据集的元信息。我推荐用DVC来做这件事，它会记录文件hash、依赖关系、当时的参数配置，一条dvc repro命令就能完整重现某个版本的数据产物。

特征工程在LLM场景下的理解也和传统ML不一样。对大模型来说，很多"特征"其实就是文本本身。你不需要像传统机器学习那样做one-hot或者embedding降维，但你需要做的是如何组织文本结构。比如构造指令微调数据时，指令、输入、输出怎么分隔，系统提示词要不要拼进去，上下文窗口怎么截断，这些决策直接影响模型指令遵循能力。

1.3 数据闭环与自动化的价值

DataOps的最终目标是形成数据闭环：线上产生的数据回流到存储，经过清洗进入下一轮训练，评估后发布的模型再回到线上。这个循环越快，模型的迭代效率越高。

我在实际项目中搭过一个简单但实用的结构：线上日志 → Kafka → Spark批处理 → 数据湖 → 训练集构造 → 版本管理 → 触发微调任务。整个链路用Airflow调度，每天晚上跑一次。数据从产生到成为训练样本，延迟不超过24小时。这么做的好处是，模型能快速适配线上数据分布的变化，避免"训练数据和推理数据分布不一致"的经典翻车问题。

自动化之后还有一层隐性收益——它逼着团队把数据处理逻辑沉淀成代码。手动跑脚本、手动改文件，过程不可复现；但只要变成代码和配置，就天然具备评审、测试、回滚的可能。这才是DataOps真正的价值。

2. MLOps如何让大模型训练和交付变成流水线

数据这头稳住了，下一步就是模型训练和交付。MLOps的概念在传统机器学习时代已经讲了很多年，核心思想是把机器学习模型的开发、部署、运维当成软件工程来做。但大模型的MLOps有几个显著的差异点：训练成本巨大、分布式训练复杂度高、部署和推理的性能瓶颈多、评估维度更复杂。这些差异导致传统MLOps的经验不能完全照搬。

2.1 实验管理与版本控制

大模型的迭代，本质上是拿钱换信息。一次全参数微调可能就要几千到几万块成本，如果不做好实验记录，钱花了但没留下任何可复用的知识，那才是最大的浪费。

实验管理我强烈推荐用MLflow或Weight & Biases这类工具。每次训练任务启动时，自动记录以下内容：

• 代码版本：git commit hash，保证任何实验结果能对应到具体代码
• 数据版本：数据集的DVC hash，确保训练数据可追溯
• 模型架构与超参数：学习率、批次大小、LoRA rank等，最好全量记录
• 训练指标：loss曲线、learning rate调度、梯度范数
• 资源消耗：GPU利用率、显存峰值、训练时长，这关系到成本核算

一个我踩过的坑：有次我用LoRA微调一个7B模型，怎么调都效果不好，后来对比实验记录才发现，期间换过一次数据清洗脚本，训练数据分布变了。如果没有完整的实验记录，这个问题可能永远定位不到。数据、代码、参数、指标四者必须绑定归档，这是实验管理的底线。

代码层面建议这样组织：

python复制# 伪代码示例：训练任务的完整参数配置
import mlflow

with mlflow.start_run(run_name="llama3_lora_v3"):
    # 记录代码和数据版本
    mlflow.log_param("git_commit", "8f3a2b1")
    mlflow.log_param("data_version", "sha256:ae3f...")
    
    # 记录超参数
    mlflow.log_param("base_model", "meta-llama/Llama-3-8B")
    mlflow.log_param("lora_rank", 64)
    mlflow.log_param("learning_rate", 2e-4)
    mlflow.log_param("batch_size", 128)
    mlflow.log_param("max_seq_len", 4096)
    
    # 记录训练结果
    mlflow.log_metric("train_loss", 1.23)
    mlflow.log_metric("eval_accuracy", 0.91)
    
    # 保存模型产物
    mlflow.pytorch.log_model(model, "model")

你可能会觉得，这不就是记日志吗？但区别在于，MLflow把这些元数据结构化地存起来了，你可以随时查询、对比、筛选。今天跑了50个实验，用一条SQL或者一条API调用就能找到效果最好的那组参数配置，这个能力在模型迭代的关键时期就是效率本身。

2.2 自动化训练与CI/CD流水线

大模型训练的自动化程度，决定了团队的迭代速度。我推荐的架构是：代码仓库里的变更触发CI，CI通过后自动发起训练任务，训练完成后自动跑评估，评估达标自动发版。

一个标准的GitHub Actions工作流大概长这样：

yaml复制name: train-eval-publish

on:
  push:
    branches: [main]
    paths:
      - 'configs/**'
      - 'src/**'

jobs:
  train:
    runs-on: [self-hosted, gpu]
    steps:
      - uses: actions/checkout@v4
      
      - name: Setup environment
        run: |
          pip install -r requirements.txt
          export HF_HOME=/mnt/hf_cache
      
      - name: Run training
        run: python src/train.py --config configs/llama3_lora.yaml
      
      - name: Run evaluation
        run: python src/evaluate.py --checkpoint output/checkpoint-500
      
      - name: Publish model
        if: github.ref == 'refs/heads/main'
        run: python src/publish.py --alias production

这里有个特别重要的工程实践：训练和评估必须用不同数据集的切分，否则在训练集上评估出来的指标没有任何参考价值。别笑，我见过不止一个团队，评估脚本里直接加载了训练集来做验证，指标好得离谱，一上线就现原形。

CI/CD不仅仅用于自动发布，更重要的是质量门禁。比如团队约定：新模型的指标不低于当前线上模型，否则不允许发布。这些门禁写在代码里，比写在口头上有效一百倍。

2.3 模型部署、推理优化与上线策略

训练只是一个阶段，部署和推理优化才是生产环境真正的考验。

大模型推理的核心挑战是显存和时延。17B的FP16参数权重就占34GB显存，加上KV cache和中间激活值，没有优化手段，普通单卡基本跑不动。这一块实际上就是各种优化技术的用武之地：

• 量化：把权重从FP16压到INT8或者INT4，牺牲少量精度换取大幅显存节省。GGUF格式配合llama.cpp，可以让原本需要24GB显存的模型跑到显存更小的机器甚至CPU上。GPTQ和AWQ也是常见的量化方案，各有侧重——GPTQ偏重量化精度，AWQ则关注激活值感知，实测在相同压缩比下AWQ的鲁棒性略好。
• 服务框架：vLLM是当前生产环境部署大模型的优先选择之一，它的PagedAttention机制能把显存利用率提升一个台阶，此外Continuous Batching也能显著提高吞吐。我实测过，同样是Llama 3 8B，Naive部署和vLLM部署的吞吐量差距能到5-10倍。
• 缓存策略：vLLM的Prefix Caching可以复用公共前缀的KV Cache，比如系统提示词、固定开场白这些内容。提高缓存命中率对成本和时延都有直接帮助。实际操作中，我会把系统提示词固定不变，用户输入尽量追加在后面，同时开启--enable-prefix-caching，实测命中率可以从20%提升到60%以上。

部署上线也讲究策略。新版本模型不要一刀切切换流量，建议灰度发布：

code复制流量切分策略：
- 先在测试环境跑2-3天，观察日志有无异常
- 线上切 5% 流量，观察准确率、反馈、时延
- 稳定后逐步提升到 30%、50%、100%
- 任一阶段指标下滑，立即回滚到上一版本

线上监控重点盯这几个指标：平均时延、P99时延、Token生成速度、错误率、用户反馈。我自己在项目里会把所有推理日志记录到ClickHouse，定时跑聚合查询，一旦发现某个版本的用户负面反馈上升，立刻触发告警通知到值班人。

3. LLMOps：面向大模型特有的工程化新战场

如果说DataOps和MLOps是传承自传统机器学习的工程方法，那LLMOps就是大模型时代真正意义上的新东西。它专门解决大模型的独特问题：Prompt怎么写才稳？RAG怎么搭才准？幻觉怎么抑制？上下文窗口怎么管？Agent怎么调度才可控？Token怎么花才省钱？

3.1 Prompt工程与版本管理

传统软件工程管理代码，LLMOps则要管理Prompt——这玩意儿比代码难搞多了。代码有语法检查，有编译期错误，Prompt呢？同一个Prompt，模型这次回答好，下次可能就翻车；换个模型又完全变了。这本质上是因为Prompt的"运行"环境是一个概率系统。

实用做法是引入Prompt模板管理工具（比如LangSmith、PromptFlow或者一套自己的配置系统），把Prompt模板化、版本化。每个Prompt模板包含：变量插槽、示例few-shot、输出格式约束、适用模型列表。上线前先在测试集上跑一批case，比较不同版本Prompt的效果。

我在实践中总结了一个好用的检查清单，每次改Prompt都要过一遍：

• 是否明确了角色与任务边界？
• 是否提供了期望的输出格式示例？
• 是否有应对边界情况的说明（比如不知道答案时怎么回复）？
• 指令中是否有歧义术语？
• 对Token长度的控制是否到位？

这套清单看起来简单，但能过滤掉大部分Prompt质量问题。还有个技巧：效果不理想时，先别急着改Prompt，先把bad case收集下来，看是Prompt理解问题还是模型能力问题。

3.2 RAG架构、向量检索与其效果验证

RAG（检索增强生成）是让大模型接入外部知识的最主流方式。原理很直观：用户提问，系统先从知识库中检索出相关文档片段，拼接进Prompt，让模型基于这些内容生成回答，而不是凭空发挥。

RAG的工程难点在于"检索质量"和"生成质量"的耦合。很多时候模型回答得不好，不是模型不行，而是检索回来的文档就不对。

一个完整的RAG流水线：

python复制# RAG核心流程示意
from langchain.embeddings import HuggingFaceEmbeddings
from langchain.vectorstores import Milvus

# 1. 文档切分——最关键也最容易被忽视的环节
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,
    chunk_overlap=64,
    separators=["\n\n", "\n", "。", "！", "？", " "],
)

# 2. 向量化与入库
embeddings = HuggingFaceEmbeddings(model_name="BAAI/bge-large-zh-v1.5")
vector_store = Milvus.from_documents(
    documents=chunks,
    embedding=embeddings,
    collection_name="enterprise_qa",
)

# 3. 检索时注意：向量检索 + 关键词检索的混合召回
retriever = vector_store.as_retriever(
    search_type="mmr",
    search_kwargs={"k": 8, "lambda_mult": 0.7},
)

# 4. 拼接上下文并生成
from langchain.prompts import PromptTemplate

prompt = PromptTemplate(
    template="""基于以下参考内容回答问题：
{context}

问题：{question}
要求：如果参考内容不包含答案，请明确说明”未找到相关信息“，不要编造。""",
    input_variables=["context", "question"],
)

这里有一个我长期强调的点：chunk切分策略对RAG效果的影响，比Embedding模型的选择还大。切得太小，上下文不完整；切得太大，检索精度下降，还浪费Token。我实测下来，512字符、重叠64字符，兼顾了精度和召回，但具体数字要根据你的文档类型微调。

混合检索也是提升召回质量的实用手段。纯向量检索对语义理解强，但对专有名词、ID号这类字面匹配不敏感。把BM25关键词检索的结果和向量检索结果合并、去重、重排序，能明显提升命中率。Rerank模型可以进一步提高排序质量，但要注意推理开销。

RAG上线前，一定要建立自己的评估集。从真实业务问题中抽100-200条，人工标注每条问题对应的正确答案和支撑文档。然后分别评估检索的Recall@K和生成的ROUGE/BLEU。效果不行，就回到chunk策略、Embedding模型、Rerank这三个环节找问题。

3.3 Agent工程化：从单模型到多Agent协作

Agent是当前大模型应用最热闹的方向之一，但工程化程度相对滞后。所谓Agent工程化，核心目标只有一个：让Agent在复杂任务中表现稳定、过程可控、结果可预期。

我的经验是，别一开始就设计复杂的多Agent协作框架。先把单个Agent的"感知-决策-行动"循环打磨稳定：感知阶段明确给模型提供哪些上下文，决策阶段是用ReAct还是Plan-and-Execute，行动阶段定义好可调用的工具集。工具集的返回格式必须严格结构化，否则Agent会胡乱理解工具的返回结果。

多Agent协作的场景，比如一个「研究型写作Agent」，拆解成规划Agent、检索Agent、写作Agent、评审Agent，好处是每个Agent职能单一、Prompt好写、结果可控。坏处是交互轮次增加，时延和Token成本上升，故障概率变大。我的建议是：能用单个Agent解决的，就不要拆多个；拆成多个的，一定要有调度中心负责状态管理和容错。

Agent的可观测性比传统模型推理更难。模型推理只要记录输入输出，Agent跑一个任务可能是几十轮工具调用，每一轮都可能出错。我强烈要求在Agent代码里埋点，记录完整轨迹：

• 每轮Agent的思考内容
• 调用的工具、参数、返回结果
• 每步的Token消耗和耗时
• 最终结果与预期的差异

这些轨迹数据是调试Agent的唯一依据。我在项目里把轨迹存成JSON Lines日志，配合简单的可视化工具回放，排查问题效率提升明显。

4. 三大支柱怎么拧成一股绳：一套完整的最小闭环

前面讲了DataOps、MLOps、LLMOps各自的工作，但实际工程中它们不是孤立的，而是互相咬合、协同运转的。这一节我给出一个可以落地的最小闭环：数据回流 → 自动训练 → 自动评测 → 灰度发布 → 监控反馈。这个闭环跑起来，你的大模型应用才算真正具备了持续迭代的能力。

4.1 设计一个从数据入库到模型发布的全自动链路

我以"电商智能客服"这个场景来举例，这是大模型落地最成熟的方向之一，读者容易理解。

整体链路分五层：

• 数据层：客服对话日志、商品库、售后规则文档，统一入湖。每天凌晨定时抽取，经过清洗入库。
• 训练层：每周用增量数据构造微调样本。用LoRA微调一个7B基础模型，训练时长控制在4-8小时内。
• 评测层：评测集包括自动化指标（意图准确率、答案相关性）和人工抽检（N=50）。自动化指标通过后进入人工抽检环节。
• 发布层：评测通过后推送到灰度环境，切10%流量，观察24小时。
• 监控层：实时监控平均响应时延、用户点赞点踩率、转人工率。指标异常自动回滚。

为了直观，我把关键环节画成下面表格，方便你对照落地：

这套闭环跑起来后，一次完整的数据到模型迭代周期大概是7-10天。相比纯手工流程（每次迭代要一周的准备 + 一天训练 + 三天评估），效率提升是数量级的。

4.2 数据回放与模型再训练策略

闭环跑通了，一个不可避免的问题是：**线上积累的数据怎么变成下一轮训练的数据？**这就是数据回放机制。

我建议的策略是：

• 定期全量回放：每4周，把过去一个月的优质交互数据全部清洗，加上原始基础数据集，构成新的训练集。
• 增量补充：每周挑出用户明确"点赞"的高质量问答，以及经过人工标注修正的bad case，补充到训练集。
• 保留一致性：数据集的构建代码必须版本化，保证不同批次构造出的数据格式一致。

这里有个数据配比的讲究：不是新数据越多越好。如果新数据只占10%，那你一周的增量训练实际上是在原有知识基础上做小幅校准；如果新数据占50%，那模型可能出现灾难性遗忘，把之前学好的能力丢掉。通常我建议增量数据占20%-30%比较稳，具体要看任务变化大不大。任务需求变化剧烈时，比如客服新增了一类业务，那增量占比可以适当提高，同时加大基础数据的重复采样。

4.3 成本控制与算力规划

大模型工程化绕不开钱的问题。训练一次7B模型的LoRA微调，用单张A100（80GB），大约需要4-8小时，电力和折旧成本大概几百块。如果是全参数微调或者更大规模模型，成本指数级增长。而线上推理的成本是持续发生的，一个7B模型用vLLM部署，算上量化、批处理优化，每秒可以服务几十到上百个请求。

成本控制的实际手段：

• 离线场景尽量用CPU推理：如果对时延要求不高（比如批量内容审核），量化后的模型在CPU上完全可以跑，成本相比GPU下降80%以上。
• 峰值费用优化：根据业务流量曲线，推理实例动态扩缩容。这个需要上层做K8s HPA（水平自动伸缩），大模型部署经常用KServe或Seldon Core这类Serverless推理框架，按请求量自动伸缩，没流量时缩到零。
• Token预算管理：应用层限制单次请求的输入输出长度上限，监控每个应用的平均Token消耗。最怕的是某条Prompt隐性地把大量RAG上下文拼进去，导致每个请求都消耗好几千Token而你毫无察觉。

算力规划的另一个要点是：把实验环境和生产环境分离。实验环境可以使用抢占式实例，便宜但可能随时被回收，适合跑参数扫描和小规模验证；生产环境务必保障稳定性，用包年包月的独占实例，千万别在生产上贪便宜用抢占式，我在这上面栽过跟头——凌晨推理服务被回收，线上直接挂了两个小时，客户投诉电话打爆。

5. 常见问题与排查技巧实录

工程化做得越多，遇到的坑越多。这节我把我踩过、也帮别人排查过的高频问题整理成一份速查表，含排查思路。这些问题单看都不难，但真正卡住人的往往是几个问题叠加在一起。

5.1 模型训练与推理的典型故障速查表

还有一个必查项：本地推理和线上推理的结果不一致，先怀疑API参数不一致。有次排查线上生成的文本格式混乱，最后发现是服务端调用时temperature写成了0.9，而评测时用的是0.1。这类低级错误，靠日志定位最快。

5.2 微调显存不足的实操解法

大模型微调最催人泪下的错误就是CUDA out of memory。首先明确一个原则：能上LoRA就不要全参数微调，除非你有明确理由必须调全部参数。LoRA把可训练参数压缩到原来的0.1%-1%，显存需求大幅下降，效果在很多任务上接近全参数微调。

针对显存不足的具体解法：

• 梯度累积：批量大小设成1，累积8步再更新一次。效果近似batch size=8，但显存占用不变。
• 混合精度训练：用FP16或BF16替代FP32训练，显存直接砍半。7B模型在BF16下，权重部分约占15GB。
• 梯度检查点（Gradient Checkpointing）：以少量计算换显存，大概能省30%-50%的激活值显存。
• 8bit优化器：像bitsandbytes这种库，优化器状态显存减少75%左右。
• 序列长度压缩：先把长文本切到2048或1024token，能塞进一批就先跑通流程，再逐步加长。

实际操作中，我通常按这个顺序排查：先开BF16混合精度，再开梯度检查点，然后调整梯度累积步数，还不行就降低batch或max length，最后才考虑换更大的GPU。目标是在代价最小的前提下让训练跑起来。

5.3 Agent效果不稳的调试路径

Agent的效果不稳定，是当前大模型应用最头疼的工程问题。同一套Prompt，昨天跑得好好的，今天换了模型版本就拉胯；同一个请求，跑十次生成十种答案。这种不稳定本质上来自大模型的采样随机性，以及Agent决策路径的分叉。

我的调试方法论分三步：

第一步，降熵。把temperature调到0或者0.1，关闭随机采样，先把不稳定因素降到最低。如果调低temperature后结果稳定了，那说明问题主要来自采样随机性；如果还不稳定，那就是Prompt或者工具定义有问题。

第二步，加约束。用结构化输出（JSON mode / Function Calling）限定Agent的输出格式。比如让Agent每次先输出"thought"，再输出"action"和"action_input"，少给自由发挥的空间。工具的名称、参数说明务必避开同义词，比如一个工具叫search_product，就不要同时存在search_products。

第三步，加验证与重试。Agent每次调用工具前，先校验参数合法性；工具返回后，校验返回格式。校验失败则自动重试一次或终止并返回明确错误信息。对最终结果，有条件的项目可以引入一个独立的LLM去check Agent的最终回答是否满足用户需求。这个"Compositional QA"的思路在客服场景中效果不错。

Agent工程化的终极目标是让不确定性被封装起来，在用户看来的表现是稳定的。这需要工程手段和模型能力两条腿走路，不能只靠调Prompt一步到位。

6. 最后聊两句实操感想

整套大模型工程化体系跑下来，我的一个深体会是：数据、模型、平台三件事，永远不要等完善了再做，而是在迭代中逐步补全。你可以在第一天用最简单的手动脚本跑通数据管线，用一个小模型验证业务闭环，再随着流量增长逐步引入DVC、MLflow、vLLM这些重武器。

另一个心得是关于团队分工的：DataOps、MLOps、LLMOps最好有明确的责任人，但知识要全员共享。让做数据的人懂一点模型评估，让做部署的人懂一点Prompt调试，跨环节协作的摩擦会小很多。我见过太多团队，数据说模型效果差是数据脏，模型说推理慢是部署不行，部署说Prompt不稳定是产品不会写提示词——互相甩锅，没有一个全局视角，工程化推进自然处处受阻。

最后再分享一个小技巧：每次大版本迭代后，保存一份完整的"踩坑记录"文档。不要只记录问题和解法，还要记录当时为什么走到这个坑里、当时的排查过程是怎样的。大模型技术迭代太快，很多坑在不同模型版本、不同框架版本下会反复出现。有一份自己的知识库，你的工程化能力会随着项目年限指数级增长。

这篇内容基于个人实际项目经验，具体工具和参数在不同场景下可能需要调整，但底层的工程思路是通用的。希望对你正在做的项目有帮助。