从 vLLM 0.5 → 0.8 + SGLang 0.4 + TensorRT-LLM 0.13 + LangGraph 0.3 + Milvus 2.5 全栈 AI 工程化 38 天踩坑录:13 反模式 + 14 修法

2026 年 4 月初到 5 月中,我和 51 位算法 / 平台 / SRE 工程师一起,用 38 天把公司"AI 工程化基础设施"从 2024 年的"散养小作坊"全面升级:vLLM 0.5 → 0.8 + SGLang 0.4 + TensorRT-LLM 0.13 + Triton 25.02 + Llama-3.3-70B + Qwen-2.5-72B + DeepSeek-V3 推理引擎全栈;Ray 2.40 + KubeRay 1.3 训练编排;LangGraph 0.3 + LangChain 0.3 + LlamaIndex 0.12 多智能体框架;Milvus 2.5 + Qdrant 1.13 向量库;Argo Workflows 3.6 + Kubeflow 1.9 MLOps。期间踩了 13 个反模式 + 9 次回滚 + 3 次 P0 + 6 次 P1,4.4 PB 向量数据零丢失,日均 LLM tokens 服务 84 亿,平均 first-token 延迟从 1.8s 降到 220ms,推理成本降 61%。这篇是 38 天踩坑全记录,包含 14 套修法 + 30 个 AI 工程化议题。

一、推理引擎选型:vLLM vs SGLang vs TensorRT-LLM

2026 年三大推理引擎在 70B+ 模型上的工程对比:(1) vLLM 0.8:PagedAttention 成熟、社区活跃、HF Transformers 兼容好、continuous batching 默认开;(2) SGLang 0.4:RadixAttention 共享前缀 KV cache、JSON 结构化输出 4x 提速、多轮对话场景最优;(3) TensorRT-LLM 0.13:NVIDIA 原厂、TensorCore 利用率最高、量化(FP8 / INT4)生态最全。我们的策略:对话场景用 SGLang(prefix cache 收益 60%),通用 chat 用 vLLM(开发体验最好),极致吞吐用 TensorRT-LLM。

二、vLLM 调优的"7 个参数"

vLLM 0.8 在 H100 x 8 上服务 Llama-3.3-70B 的 7 个核心参数:(1) tensor-parallel-size=8 全卡切分;(2) gpu-memory-utilization=0.92(留 8% 给系统,过高 OOM);(3) max-num-batched-tokens=8192 控制单次 batch token 上限;(4) max-num-seqs=256 并发序列上限;(5) enable-prefix-caching=true 系统 prompt 自动复用;(6) swap-space=16 GiB 长上下文 swap 到 CPU;(7) quantization=fp8(H100 / H200 必开)。调优后 first-token latency 220ms,throughput 4.7K tokens/s/GPU,GPU 利用率 89%。

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: llama-33-70b
  namespace: ai-prod
spec:
  predictor:
    containers:
      - name: vllm
        image: vllm/vllm-openai:v0.8.0
        args:
          - --model=/models/llama-3.3-70b-instruct
          - --tensor-parallel-size=8
          - --gpu-memory-utilization=0.92
          - --max-num-batched-tokens=8192
          - --max-num-seqs=256
          - --enable-prefix-caching
          - --swap-space=16
          - --quantization=fp8
          - --kv-cache-dtype=fp8_e5m2
          - --served-model-name=llama-33-70b
          - --port=8000
        resources:
          limits:
            nvidia.com/gpu: "8"
            memory: 512Gi
        readinessProbe:
          httpGet:
            path: /health
            port: 8000
          initialDelaySeconds: 300
          periodSeconds: 10
        livenessProbe:
          httpGet:
            path: /health
            port: 8000
          initialDelaySeconds: 600
          periodSeconds: 30

三、KV cache 管理的"4 个反模式"

KV cache 在 70B 模型上的 4 个反模式:(1) 静态分配:为 max-context 提前分全部 KV → 浪费 80% 显存;(2) 不开 paged:碎片化导致大请求被拒;(3) 不开 prefix cache:相同 system prompt 反复算;(4) 不 swap:OOM 时被 kill 而不是降级。修法:PagedAttention(4KB page)+ prefix cache + swap-space + 优先级队列,显存占用降 47%,OOM 事件月均 12 → 0。

四、SGLang RadixAttention 的工程价值

SGLang RadixAttention 在我们多轮对话场景上的工程价值:(1) 把所有请求按 token 前缀建 Radix Tree;(2) 命中前缀的请求 KV cache 直接复用,无需重算;(3) cache LRU 淘汰,空间利用率 ≥ 80%;(4) 多轮对话场景:第 N 轮自动复用前 N-1 轮的 KV;(5) 系统 prompt 几 KB 时,prefix cache 命中率 ≥ 95%。实测:我们 customer-support agent 平均节省 60% compute,latency 降 45%。

五、Triton Inference Server 的"5 个核心特性"

NVIDIA Triton 25.02 在我们多模型场景的 5 个核心特性:(1) Model ensemble:DAG 编排,embedding + rerank + classification 串联;(2) Dynamic batching:服务端自动批合并;(3) Multi-backend:同时跑 PyTorch / TensorRT / ONNX / Python custom;(4) Sequence batching:长对话 sequence 状态保持;(5) Model warmup:启动时预热,首请求不慢。我们 386 模型在 Triton 上的 utilization 比裸 GPU 高 38%。

六、量化策略的"3 套配方"

2026 年 LLM 量化的 3 套主流配方:(1) FP8(E4M3 / E5M2):H100 / H200 / B100 原生支持,精度损失 < 0.5%,吞吐升 1.8x;(2) INT4 AWQ / GPTQ:消费级 GPU(4090 / 5090)首选,精度损失 1-2%,吞吐升 3x;(3) INT4 + FP8 混合:大模型 weight INT4 + KV cache FP8,边缘场景最优。我们 H100 集群全部 FP8,A100 备用集群 INT4 AWQ,综合算力提升 2.1x,token 单价降 51%。

七、模型服务的"6 个 SLI/SLO"

LLM 推理服务的 6 个核心 SLI/SLO:(1) Time-to-first-token(TTFT):p99 < 500ms(交互场景必备);(2) Time-per-output-token(TPOT):p99 < 50ms(流式输出);(3) End-to-end latency:p99 < 5s(整个请求);(4) Throughput:tokens/s/GPU;(5) Error rate:< 0.1%;(6) GPU utilization:> 80%(成本指标)。SLO 不达标的模型自动降权 + 触发扩容。

八、Ray 2.40 的"5 个工程价值"

Ray 2.40 + KubeRay 1.3 在我们 GPU 训练的 5 个工程价值:(1) Ray Train:PyTorch DDP / DeepSpeed / FSDP 一键编排;(2) Ray Serve:与 KServe 互补,Python 编写 inference graph;(3) Ray Tune:超参 sweep,集成 Optuna / HyperOpt;(4) Ray Data:大数据预处理,流式向量化;(5) Multi-cluster 支持:跨集群提交作业。我们 8 PB 训练数据 + 600 GPU,Ray 替代 Airflow + 自研调度器后,作业启动从 12 分钟降到 90 秒。

九、LangGraph 多智能体框架

LangGraph 0.3 在多智能体编排上的 4 个工程价值:(1) State machine 显式建模:每个节点 / 边 / 条件清晰可见,替代 LangChain Agent 的"黑盒";(2) Checkpoint:状态可持久,支持 human-in-the-loop;(3) Streaming:逐 token / 逐节点流式输出;(4) Time travel debug:回放历史决策路径。替代了 LangChain Agent + 自研 state machine 的混乱方案,客服 agent 开发周期从 6 周降到 2 周。

from langgraph.graph import StateGraph, END
from langgraph.checkpoint.postgres import PostgresSaver
from typing import TypedDict, Annotated
import operator

class AgentState(TypedDict):
    messages: Annotated[list, operator.add]
    intent: str
    tool_calls: list
    final_answer: str

def classify_intent(state: AgentState):
    last_msg = state["messages"][-1].content
    intent = llm_classifier.invoke(last_msg)
    return {"intent": intent}

def route_by_intent(state: AgentState):
    if state["intent"] == "order_query":
        return "order_agent"
    elif state["intent"] == "refund":
        return "refund_agent"
    return "general_agent"

graph = StateGraph(AgentState)
graph.add_node("classify", classify_intent)
graph.add_node("order_agent", order_agent_fn)
graph.add_node("refund_agent", refund_agent_fn)
graph.add_node("general_agent", general_agent_fn)
graph.set_entry_point("classify")
graph.add_conditional_edges("classify", route_by_intent)
graph.add_edge("order_agent", END)
graph.add_edge("refund_agent", END)
graph.add_edge("general_agent", END)

checkpointer = PostgresSaver.from_conn_string("postgresql://...")
app = graph.compile(checkpointer=checkpointer)

十、Agent 的"5 个反模式"

多智能体框架的 5 个反模式:(1) 死循环:Agent A 调 B,B 又调 A,无 max_iteration → 无限烧 token;(2) Tool 调用无 timeout:外部 API 卡死 → 整个 agent 链卡死;(3) Prompt 注入:用户输入直接拼到 system prompt → 被 jailbreak;(4) 状态膨胀:对话历史无 truncate,context 越来越长;(5) 无 checkpoint:中间 step 失败,需从头重跑。修法:max_iteration=20,tool timeout=10s,prompt 模板化 + sanitize,history sliding window 8K,checkpoint 每 step 写 Postgres。

十一、向量库选型:Milvus vs Qdrant vs Pinecone

2026 年向量库 3 大选型:(1) Milvus 2.5:分布式架构(8 个组件)、HNSW + IVF + DiskANN、原生 K8s Operator、复杂但 PB 级最强;(2) Qdrant 1.13:Rust 实现单进程、payload + 向量混合检索、易部署、中等规模(10B 向量)首选;(3) Pinecone:全托管 SaaS、运维 0 成本,但成本高 + 数据出境合规。我们的 4.4 PB / 22 亿向量用 Milvus(自托管 + 成本可控),小型实验用 Qdrant。

十二、Milvus HNSW 调优

Milvus 2.5 HNSW 索引在 22 亿向量上的调优:(1) M=16(每节点出度);(2) efConstruction=200(构建质量);(3) ef=64(查询时探索深度,延迟 vs 召回平衡);(4) metric_type=COSINE(归一化后 = 内积);(5) shards_num=16(按 collection size 分片);(6) replicas=2(查询副本数,提升 QPS)。调优后:p99 latency 47ms,recall@10 = 0.96,QPS 18K。

十三、向量 + 元数据混合检索

2026 年 RAG 系统中 vector + metadata 混合检索的 4 步:(1) Pre-filter:先按元数据(tenant_id / 时间 / 标签)过滤,缩小候选集;(2) Vector search:HNSW 在过滤后候选集上找 top-K;(3) Re-rank:用 cross-encoder(bge-reranker-v2)精排;(4) Aggregate:多向量(query / doc / image)结果融合。我们的 multi-tenant SaaS,每 tenant 平均 50 万向量,混合检索 p99 38ms。

十四、Embedding 模型的"3 个选择"

2026 年 embedding 模型 3 个主流选择:(1) BGE-M3:中英多语 + 稠密 / 稀疏 / multi-vec 三合一,SOTA 中文;(2) OpenAI text-embedding-3-large:闭源但稳定,3072 维;(3) Voyage AI voyage-3:针对 RAG 优化,商业最强。我们用 BGE-M3(中文场景)+ voyage-3(英文知识库),按 namespace 切换。

十五、RAG 系统的"6 层架构"

2026 年企业级 RAG 的 6 层架构:(1) Ingestion:文档解析(unstructured / Tika)+ chunking(语义 / 滑窗 / 标题层级);(2) Embedding:BGE-M3 / Voyage,batch 4096;(3) Vector store:Milvus;(4) Retrieval:vector + BM25 + metadata 混合;(5) Re-rank:bge-reranker-v2;(6) Generation:LLM with citation。我们的 ChatBI 系统(企业知识问答)在这 6 层上的 latency 分配:300ms / 80ms / 47ms / 32ms / 120ms / 1500ms = 2.1s end-to-end。

十六、LLM 评估的"5 个维度"

LLM 应用上线前的 5 个评估维度:(1) 准确性:Ragas faithfulness / answer_relevance / context_precision;(2) 安全性:Detect harmful / PII / prompt injection;(3) 延迟:end-to-end p50 / p95 / p99;(4) 成本:每 1K request 的 $ 成本;(5) 用户体验:在线 thumbs up/down + 人工抽检。我们建了 5000 条人工标注的 golden set,每次模型 / prompt 更新跑回归,阻断准确率下降 ≥ 2% 的发布。

from ragas import evaluate
from ragas.metrics import (
    faithfulness,
    answer_relevancy,
    context_precision,
    context_recall,
    answer_correctness,
)
from datasets import Dataset

ds = Dataset.from_dict({
    "question": questions,
    "answer": predictions,
    "contexts": retrieved_contexts,
    "ground_truth": gold_answers,
})

result = evaluate(
    ds,
    metrics=[
        faithfulness,
        answer_relevancy,
        context_precision,
        context_recall,
        answer_correctness,
    ],
)

assert result["faithfulness"] >= 0.92
assert result["answer_relevancy"] >= 0.88
assert result["context_precision"] >= 0.85
print(result.to_pandas())

十七、Prompt 工程的"7 个铁律"

2026 年生产 prompt 工程的 7 个铁律:(1) Role + Task + Context + Output format 4 段式;(2) Few-shot 3-5 个 demo,覆盖正例 + 负例 + 边界;(3) 思考链(Chain-of-Thought)+ 输出 JSON;(4) 显式拒绝模式:不知道就说不知道;(5) 长 context > 32K 时,关键信息放头尾(LLM 中间遗忘);(6) Temperature 0.1(确定性任务)/ 0.7(创造);(7) Prompt 版本化,changelog 留痕。我们 prompt 仓库 386 个 prompt,全部 Git 管理,版本号 / A/B test 数据齐全。

十八、Fine-tuning 的"3 个层次"

2026 年 LLM 微调 3 个层次:(1) LoRA / QLoRA:adapter ≤ 200MB,8 张 H100 / 24 小时,适合任务定制;(2) Full SFT:全参数微调,需 H100x32 + 4 天,适合 base 大幅改造;(3) DPO / IPO 偏好优化:对齐人类偏好,在 SFT 后做。我们的客服 agent:DeepSeek-V3 base + 80K 行业问答 SFT(LoRA r=64)+ 12K 人类偏好 DPO,3 阶段后效果超过 GPT-4o(行业基准)。

十九、训练数据的"6 个工程铁律"

训练数据工程的 6 个铁律:(1) 数据 quality > quantity:10 万高质量 ≥ 100 万低质量;(2) 去重(MinHash / SemHash)避免过拟合;(3) PII 脱敏 + 合规审计;(4) 标注质量抽检(双盲交叉)≥ 95%;(5) train / val / test 三集严格隔离,不能 leak;(6) 数据版本化(DVC / lakeFS)。过去 12 个月数据 issue 占故障 47%,数据工程是 ML 的瓶颈。

二十、GPU 集群的"5 个调度铁律"

600 GPU 集群的 5 个调度铁律:(1) Nvidia GPU Operator + MIG 切分(A100 切 7 份,服务多个轻量任务);(2) Volcano / Kueue 优先级 + gang scheduling;(3) Karpenter GPU NodePool 自动扩;(4) Topology aware scheduling:同 rack 优先;(5) Reservation:训练任务提前 reserve GPU,避免抢占。调度优化后,GPU 平均利用率从 47% 升到 78%。

二十一、推理引擎的"3 代演进"

LLM 推理引擎 2022-2026 三代演进:(1) 第一代(2022-2023):HF Transformers 直接 serve,无 batching,每秒 < 50 token;(2) 第二代(2023-2024):TGI / vLLM v0 引入 continuous batching,每秒 500-1000 token;(3) 第三代(2024-2026):vLLM 0.8 + SGLang + TensorRT-LLM,PagedAttention / RadixAttention / FP8 / speculative decoding,每秒 4000-8000 token/GPU。三代演进让单卡吞吐升 100 倍,token 单价降 95%。

二十二、Speculative Decoding 的工程价值

Speculative Decoding 在生产的工程价值:(1) 用小模型(draft)猜下一段 token,大模型验证;(2) 命中则一次 forward 出多 token,理论加速 2-3x;(3) 适合大模型 + 高 token 数生成场景(代码 / 长文档)。我们 70B 主模型 + 1.5B draft,代码生成场景加速 2.4x,精度损失 0%。

二十三、流式输出的工程实现

LLM 流式输出的工程实现 4 要素:(1) 协议:OpenAI-compatible SSE(text/event-stream)是事实标准;(2) Token-by-token 推送,首 token 立即返(TTFT 优化点);(3) 中间错误:用 [DONE] 或 error event 标记,前端正确处理;(4) Backpressure:client slow 时 server 也得 throttle。我们所有 LLM 服务统一 OpenAI-compat,前端 ChatBot 完全无感切换不同 backend。

二十四、Multi-LoRA Serving 的工程价值

vLLM Multi-LoRA serving 在多租户场景的工程价值:(1) 基础模型只 load 一份(70B 共占 140GB FP16);(2) 每个租户的 LoRA adapter 200-500MB,动态 attach;(3) batch 推理时,多租户请求一起处理,各自用自己 LoRA 算;(4) 100 个租户共享 1 个 base model,GPU 成本降 99%。实战:380 个企业租户,每个有专属 LoRA,共用 8 卡 H100,平均 GPU 利用率 92%。

二十五、Long Context 的工程现实

Long Context(128K - 1M token)在 2026 年的工程现实 5 点:(1) Llama-3.3 / Qwen-2.5 都已 128K;(2) KV cache 量随 context 线性增长,128K 单序列 KV ≈ 40GB;(3) Attention 复杂度 O(n²),128K 比 8K 慢 256 倍;(4) RAG 仍是更经济选择,除非真需要全文 reasoning;(5) Long context 准确率会下降,中间信息遗忘(lost in the middle)。我们 90% 场景用 RAG + 8K context,10% 用 32K,极少用 128K。

二十六、A/B Testing LLM 的"5 个维度"

LLM 应用 A/B test 的 5 个维度:(1) 用户行为:点赞率 / 完成率 / 满意度;(2) 业务指标:转化率 / GMV / 留存;(3) 模型质量:Ragas / 人工标注准确率;(4) 性能:latency / cost / GPU util;(5) 安全:harmful / PII rate。每次大改(新模型 / 大 prompt)都做 5 维 A/B,持续 1-2 周,数据置信后再全量。

二十七、AI Guardrail 的"6 道防线"

2026 年 LLM 应用 guardrail 6 道防线:(1) 输入 filter:PII / 敏感词 / prompt injection;(2) 输入分类:意图识别,违规拒绝;(3) 输出 filter:harmful / 偏见 / 法律风险;(4) 输出验证:fact check / hallucination detection;(5) 后处理:对错误回答兜底(template fallback);(6) 审计 log:全留痕,合规审查。我们 6 道防线拦截违规请求月均 47K,误拦率 < 0.8%。

二十八、Hallucination 的"4 个缓解"

LLM hallucination 在 RAG 系统的 4 个缓解:(1) 强制 citation:回答必引用具体文档段,无法引用就说"不知道";(2) Self-RAG:模型自评估是否需要检索 / 检索是否相关;(3) Cross-check:多模型投票,差异大触发人工;(4) Confidence threshold:LLM 输出 logprob 低于阈值时降级到 template。4 法叠加后 hallucination 率从 12% 降到 1.8%。

二十九、LLMOps 平台的"7 大模块"

2026 年 LLMOps 平台 7 大模块:(1) Model registry(MLflow / WandB);(2) Prompt registry + versioning;(3) Evaluation pipeline + Ragas;(4) Online observability(LangSmith / Phoenix);(5) Cost tracker(token / GPU 双维度);(6) Feedback loop:用户反馈 → 训练数据 → 微调;(7) Compliance + audit log。我们的 LLMOps 平台基于 MLflow + LangSmith + 自研 cost tracker,LLM 应用上线周期从 6 周降到 1.5 周。

三十、AI 安全的"6 个红线"

2026 年 AI 应用 6 个安全红线:(1) Prompt injection 防御:严格 system / user 边界;(2) PII 脱敏:训练 + 推理双重;(3) Model 偷窃防御:rate limit + 输出 watermark;(4) Adversarial example 检测;(5) Bias 监控 + 主动平衡;(6) 合规:GDPR / EU AI Act / 个保法 全链路审计。过去 12 个月安全事件 0 起,合规审计一次通过(EU AI Act 高风险应用)。

三十一、AI 应用的"5 个用户体验设计"

2026 年 LLM 应用 UX 5 个核心:(1) Streaming 首选,避免长时间等待白屏;(2) Citation 永远显示,让用户判断可信;(3) Thumbs up/down 收集反馈,数据回流训练;(4) Edit/regenerate 一键改答案;(5) Fallback message:模型不知道时输出"我不知道"而不是编造。这 5 个细节决定了用户是觉得 AI 智能还是觉得 AI 在胡说。

三十二、Function Calling 的"5 个工程铁律"

Function Calling / Tool use 在生产环境的 5 个铁律:(1) JSON schema 必须严格 + 校验,异常输入降级处理;(2) 函数描述用自然语言 + 输入 / 输出示例,大幅提升 LLM 调用准确率;(3) 串行 / 并行调用分清:数据库查询并行,有状态操作串行;(4) Tool 调用 timeout 5-10s,超时降级;(5) 工具调用全链路 trace + log,排错刚需。Function calling 是 Agent 的灵魂,这 5 条做不到生产化 = 玩具。

from openai import OpenAI
import json

tools = [
    {
        "type": "function",
        "function": {
            "name": "search_order",
            "description": "Search user order by order_id or by user_id + date range",
            "parameters": {
                "type": "object",
                "properties": {
                    "order_id": {"type": "string", "description": "Order ID like ORD-123456"},
                    "user_id": {"type": "string"},
                    "start_date": {"type": "string", "format": "date"},
                    "end_date": {"type": "string", "format": "date"},
                },
                "required": [],
            },
        },
    },
]

client = OpenAI(base_url="http://vllm:8000/v1")
resp = client.chat.completions.create(
    model="llama-33-70b",
    messages=[{"role": "user", "content": "查我上周的订单"}],
    tools=tools,
    tool_choice="auto",
    timeout=10,
)

if resp.choices[0].message.tool_calls:
    for call in resp.choices[0].message.tool_calls:
        args = json.loads(call.function.arguments)
        result = TOOL_REGISTRY[call.function.name](**args)

三十三、Embedding 维度的"3 个权衡"

Embedding 维度选择 3 个权衡:(1) 高维(3072 / 1024):召回好,但存储成本 + 检索延迟高;(2) 低维(384 / 256):快但召回弱;(3) Matryoshka Embedding:同一向量截断可用多维度,兼顾。我们的方案:存 1024 维(BGE-M3 maxlen 8192),检索时按场景动态截断到 256(粗筛)+ 1024(精排)。

三十四、向量库的"4 个反模式"

向量库使用 4 个反模式:(1) 单 collection 装 10 亿+ 向量,不分片 → 查询慢 / 索引重建天级;(2) 不开 partition,跨租户数据混在一起 → 安全 + 性能双坑;(3) 全量 reload 而不 upsert → 业务停机;(4) 无监控 / 无备份 → 数据丢失风险。修法:每 collection 按租户 partition + 分片 + 增量 upsert + 每日全量 dump 到 S3。

三十五、Knowledge Graph + LLM 的工程价值

Knowledge Graph(Neo4j 5.x)+ LLM 的工程价值:(1) GraphRAG:实体 + 关系查询补充 vector;(2) Multi-hop reasoning:vector 难以处理,KG 天然擅长;(3) 实体消歧:同名不同实体精准区分;(4) Domain expert 模型:医疗 / 金融 / 法律 KG 是基础。我们的合规问答系统:KG 关系查询 + vector 文档检索 + LLM 回答,准确率比纯 RAG 高 23%。

三十六、模型蒸馏的"3 个流派"

2026 年 LLM 蒸馏 3 个流派:(1) Logit 蒸馏:teacher 输出 logit,student 学 softmax 分布;(2) 数据蒸馏:teacher 生成数据,student SFT;(3) 任务蒸馏:针对特定 task 用 teacher 数据做 LoRA。我们 70B teacher → 7B student(数据蒸馏 + LoRA),在客服领域准确率达 teacher 的 94%,推理成本降 89%。

三十七、Agent Memory 的"4 个层次"

Agent Memory 系统 4 层:(1) Short-term:当前对话上下文(8K-32K token);(2) Episodic:近期事件,Redis 24h TTL;(3) Long-term:用户偏好 / 历史 / 知识,Postgres + vector;(4) Procedural:Agent 学会的技能 / 工具用法,版本化存。4 层 memory 让我们的客服 agent 记住老用户 1 年内的偏好,客户满意度提升 31%。

三十八、AI 成本优化的"7 个杠杆"

AI 工程成本优化 7 杠杆,按 ROI:(1) FP8 / INT4 量化,降 50-70%;(2) 模型蒸馏 70B→7B,降 80%+;(3) PagedAttention / RadixAttention,降 40%;(4) 多 LoRA serving,降 90% GPU;(5) Reserved / spot GPU,降 65%;(6) Cache(prompt + answer)命中率高场景,降 50%;(7) Routing:简单查询用小模型,复杂用大模型。7 杠杆叠加,我们的 LLM token 成本月度降 78%。

三十九、Prompt Caching 的工程价值

Prompt Caching(OpenAI / Anthropic / vLLM 都支持)的工程价值:(1) System prompt 几 KB 时,服务端 cache,后续请求只算 user input 增量;(2) cache 命中减少 50-90% input token 成本;(3) cache TTL 默认 5-10 分钟,长 system prompt 必开。我们的 system prompt 平均 6KB,cache 命中率 87%,月度 input token 成本降 73%。

四十、Routing 的"3 种模式"

LLM Routing 3 种模式:(1) 静态 routing:按业务类型直接路由,简单可靠;(2) Classifier routing:小模型分类 → 路由到大 / 中 / 小模型;(3) Difficulty estimation:用 perplexity / confidence 估算难度。我们用 classifier routing,80% 请求由 7B 处理,15% 由 32B,5% 由 70B,平均成本降 64%。

四十一、LLM 隐私的"4 道防线"

LLM 隐私 4 道防线:(1) Self-host:敏感数据不出公司,绝对隔离;(2) PII 脱敏:训练 + 推理双重;(3) Differential privacy:模型权重不泄漏个体;(4) Compliance contract:云厂商必须签 DPA + 数据不训练协议。金融 / 医疗 / 政府 客户必 self-host,普通 SaaS 自建 + DPA。

四十二、Multi-modal LLM 的工程现实

2026 年 Multi-modal LLM(Vision / Audio / Video)的工程现实:(1) Qwen2.5-VL / Llama 3.2 Vision 文档理解已生产可用;(2) Image token 数比纯文本多 10-30x,成本 / latency 都更高;(3) Vision RAG:文档 chunk 时保留 image,vector 编码 image + text 双路;(4) OCR + LLM 混合方案仍是性价比最高(简单文档)。我们的合同审查系统 90% 用 OCR + LLM,10% 高复杂度用 Vision LLM。

四十三、Voice Agent 的工程链路

Voice Agent 工程链路 4 段:(1) ASR:Whisper Large v3 / Faster-whisper / 自训 RNN-T,latency 200ms;(2) LLM:Llama / Qwen 70B,流式 200ms TTFT;(3) TTS:Coqui / XTTS / 自训,latency 400ms;(4) 端到端:Voice → Text → Reasoning → Text → Voice,< 1.2s 用户无感。4 段全用国产 GPU + 自训模型,成本是 OpenAI Realtime 的 1/8。

四十四、AI Agent 评测的"5 类基准"

AI Agent 评测 5 类基准:(1) Tool use:能否正确调用工具(BFCL / API-Bank);(2) Multi-turn:多轮对话连贯性(MT-Bench);(3) Reasoning:数学 / 逻辑(MATH / GPQA);(4) Coding:代码生成(HumanEval / SWE-Bench);(5) Long context:大海捞针(needle-in-haystack)。我们 386 个 prompt + 80 个 agent 全部跑这 5 类基准,数据进 dashboard 月度回顾。

四十五、SWE-Agent 与代码生成

SWE-Agent / Cursor / Cline / Claude Code 在 2026 年代码 agent 的工程进展:(1) SWE-Bench 解决率从 2024 年的 12% 升到 2026 年的 67%;(2) Cursor / Windsurf 集成 IDE,context 自动注入;(3) Claude Code / Codex CLI 命令行 agent;(4) Agent 自迭代:写测试 → 跑 → fail → 改 → pass 自循环。我们内部 dev productivity 实验:代码 agent 让 67 名工程师人均 commit/天 从 4.2 升到 7.8,bug 引入率不变。

四十六、模型注册的"5 个核心字段"

Model Registry 5 个核心字段:(1) Name + version + tag(stable / canary / experimental);(2) Lineage:基于哪个 base 模型 + 训练数据集 + 训练代码 commit;(3) Metrics:eval 准确率 / latency / cost;(4) Safety:harmful rate / bias test;(5) Approval:谁批准上线 + 时间。没有 registry 的团队,模型上线 = 黑盒抽奖。

四十七、训练 → 推理的"5 个鸿沟"

训练 → 推理的 5 个鸿沟:(1) Tokenizer 不一致:训练用 fast tokenizer,推理用 slow → 输出错乱;(2) Chat template 不一致:微调时拼接方式与推理不同 → 性能腰斩;(3) Special token 处理:eos / bos / pad 配置错;(4) Dtype 不匹配:FP16 训练 FP8 推理需 calibration;(5) Sampling 参数:训练 temperature=1.0 但推理跑 temperature=0 时结果差异巨大。每次模型上线必跑 train/inference parity test,过去 12 个月避免 7 次潜在事故。

四十八、AI 监控的"7 个 dashboard"

LLM 应用 7 个核心 dashboard:(1) Latency(TTFT / TPOT / E2E p50/p95/p99);(2) Throughput(tokens/s);(3) GPU(utilization / memory / temperature);(4) Cost(token / GPU 双维度,按 BU / 用户分账);(5) Quality(Ragas / human label);(6) Safety(harmful / PII rate);(7) User feedback(thumbs / 满意度)。7 张 dashboard 在 Grafana 上每周回顾,周会重点。

四十九、Multi-tenant LLM SaaS 的"5 个挑战"

Multi-tenant LLM SaaS 5 个挑战:(1) GPU 资源公平分配:不能让大客户挤死小客户(quota + priority queue);(2) 数据隔离:vector store partition + LoRA per tenant;(3) 成本分摊:精确到 token / GPU-second;(4) 自定义 prompt + knowledge base 互不污染;(5) SLA 分级:enterprise / pro / free 三级 latency / availability。380 个企业租户的 SaaS,这 5 个挑战每个都踩过坑。

五十、AI 系统的"7 个故障类型"

AI 工程化 38 天踩过的 7 类故障:(1) GPU OOM(2 次 P0):batch size 配错 + 长 context 序列;(2) vLLM 卡死(1 次 P0):特定 prompt 触发 deadlock;(3) Milvus 查询超时(2 次 P1):collection 过大未分片;(4) LangGraph 死循环(1 次 P1):无 max_iteration;(5) Embedding 服务 OOM(1 次 P1):batch 4096 太大;(6) Tool 调用超时雪崩(1 次 P1):某外部 API 慢导致整链卡死;(7) Prompt 注入(1 次 P1):用户输入直接拼到 system。每类故障都做完整 postmortem + action item + 自动化检测。

五十一、AI 工程的"5 个团队角色"

52 人 AI 团队 5 个角色:(1) Research scientist 12 人:模型架构 + SFT + DPO;(2) MLE 18 人:数据 + 训练 pipeline + 评估;(3) Platform 8 人:vLLM / KubeRay / Milvus 平台化;(4) SRE 6 人:GPU 集群 / 监控 / on-call;(5) Product 8 人:Agent + RAG + 用户体验。核心是 MLE + Platform 共建 LLMOps,Research 用平台做实验而非自建。

五十二、ML 系统设计的"6 原则"

ML 系统设计 6 原则:(1) Data first:数据质量 > 模型架构;(2) Iterate fast:小步快跑,日内迭代;(3) Eval-driven:eval set 是黄金,先建 set 再调模型;(4) Cost-aware:每次决策考虑 $;(5) Safety by design:guardrail 不能事后加;(6) Observable:trace / log / metric 三件套必备。这 6 原则在我们 38 天的实践中是 LLMOps 平台的"宪法"。

五十三、AI 的"6 个未来趋势"

2026-2029 AI 工程化 6 趋势:(1) 多模态融合(Text / Vision / Audio / Video 统一);(2) Agent 工具生态爆发(MCP / OpenAI Function 标准化);(3) Edge AI(7B 在手机)成熟;(4) Synthetic data 主导训练(2027 后人类数据耗尽);(5) Specialized model(医疗 / 法律 / 金融)取代通用模型;(6) AI safety / alignment 工程化(自动 red-team)。6 趋势是确定的,提早布局者占先发。

五十四、从 38 天得到的"7 个工程教训"

38 天 AI 工程化的 7 个最深刻教训:(1) 模型不是问题,数据才是 — 80% 时间在数据;(2) eval set 决定 ceiling — 没有 eval = 飞行盲;(3) 成本可控才能规模化 — 每次决策必算 ROI;(4) Agent 必须有 guardrail — 否则灾难;(5) GPU 调度比算法更难 — utilization 是命门;(6) Long context 不是银弹 — RAG 仍是主流;(7) Vendor lock-in 风险高 — 抽象层必须有。这 7 教训值 38 天 51 人月。

五十五、LLM 应用的"5 个用户价值"

2026 年 LLM 应用为客户创造的 5 大用户价值:(1) 知识问答(企业知识库 / 客服);(2) 代码生成(Copilot / 自动化工具);(3) 内容创作(文案 / 设计 / 视频);(4) 数据分析(ChatBI / 报表生成);(5) Agent 自动化(订票 / 订单 / 流程)。这 5 大场景是 2026 年 toB / toC 商业化的核心,我们 SaaS 平台 5 场景全覆盖,ARR 突破 2.7 亿。

五十六、模型评估的"5 个陷阱"

模型评估 5 个陷阱:(1) Data leakage:eval set 与 train set 重叠;(2) Cherry-picking:只看赢的 metrics;(3) Overfit to benchmark:刷榜 ≠ 实用;(4) Single metric 误判:一个 metric 高,其他可能掉;(5) Human eval 缺失:自动化 metric 永远代替不了人。我们建 5000 人工标注 + 1 万自动 metric 双轨评估,过去 12 个月 0 次"上线后才发现问题"。

五十七、AI 团队的"7 个仪式"

52 人 AI 团队 7 个仪式:(1) 每日 model performance standup 15 分钟;(2) 每周 prompt / model A/B 复盘;(3) 双周 customer feedback review;(4) 月度 LLMOps OKR + 成本回顾;(5) 季度 ML 战略 + 投资决策;(6) 故障 24 小时 postmortem;(7) 半年 ML conference 内部分享。7 仪式让 52 工程师协同有序,产出可预期。

五十八、补遗一:vLLM 0.8 关键改进

vLLM 0.8 相比 0.5 的 6 个工程价值:(1) PagedAttention 进一步成熟,prefix cache 默认开;(2) FP8 KV cache 节省显存 47%;(3) Multi-LoRA 生产可用;(4) Pipeline parallel + tensor parallel 双层切;(5) Speculative decoding 内置;(6) Prefix cache + tool calling 协同。实测:同硬件 throughput 升 80%,latency 降 60%。

五十九、补遗二:DeepSeek-V3 的工程启示

DeepSeek-V3(671B MoE)2024-2026 的工程启示:(1) MoE 是大模型 cost 路径;(2) FP8 训练 + 数据并行 + Pipeline 高效组合;(3) 671B 总参数 / 37B 激活,推理 cost 等同于 30B dense;(4) 开源 + 商用友好,改变了 LLM 生态。对企业:大可以用 V3 而不必自训 70B,节省 90% 算力成本。

六十、补遗三:LangChain 0.3 关键改进

LangChain 0.3 相比 0.1 的 5 个工程价值:(1) Runnable 接口统一所有组件;(2) LCEL(LangChain Expression Language)链式表达更清晰;(3) 与 LangGraph 深度集成;(4) Streaming 全链路支持;(5) Type hint 完整,IDE 友好。我们生产代码完全迁到 LCEL,代码量降 50%,可读性显著提升。

六十一、补遗四:Milvus 2.5 关键改进

Milvus 2.5 相比 2.3 的 5 个工程价值:(1) Sparse / dense hybrid index(BGE-M3 必备);(2) Json field schema-less;(3) Bulk insert 性能提升 3x;(4) DiskANN 大规模(10B+)索引;(5) 多租户 partition key 优化。对 22 亿向量场景:索引重建从 18 小时降到 6 小时,查询 p99 降 40%。

六十二、补遗五:8 个反模式回顾

38 天最值得回看的 8 个反模式:(1) batch size 静态配 = OOM 频发;(2) 不开 prefix cache = 算力浪费 60%;(3) Agent 无 max_iteration = 烧钱黑洞;(4) tool 无 timeout = 雪崩;(5) Milvus 单 collection 10 亿 = 查询超时;(6) prompt 注入未防 = 安全 P0;(7) hallucination 不监控 = 用户流失;(8) GPU util 不监控 = 成本失控。任何 AI 团队自查至少命中 4 个。

六十三、补遗六:38 天的工程节奏

38 天升级期间的工程节奏:(1) 周 1-2:盘点现状 + 列反模式 + 定 14 套修法;(2) 周 3-4:vLLM / SGLang POC + 量化测试;(3) 周 5-6:Milvus 2.5 升级 + 向量库切换;(4) 周 7-8:LangGraph 改造 + Agent guardrail;(5) 周 9-10:Multi-LoRA + 多租户上线;(6) 周 11-12:观察 + 优化 + postmortem。52 工程师 7x10 小时强度,过劳率 18%,值得。

六十四、最后一句话

38 天 vLLM + SGLang + Triton + Ray + LangGraph + LangChain + LlamaIndex + Milvus + Qdrant + Argo Workflows + Kubeflow 全栈 AI 工程化,如果只让我说最后一句话:"AI 工程化在 2026 年是一场关于推理引擎 / KV cache / 量化 / 向量库 / RAG / Agent / Guardrail / LLMOps / GPU 调度 / 成本控制 / 安全合规的 11 维综合战役,模型只是冰山一角,数据 + 平台 + 评估 + 工程是水下 90%,任何一维的缺失都会让 AI 应用从 demo 走不到生产,52 工程师 38 天的真实工程实践告诉我们:LLMOps 平台是 AI 应用规模化的基石,GPU 集群是 AI 工程化的引擎,数据飞轮是 AI 模型的灵魂。" 这是我作为 AI tech lead 带 52 工程师 38 天的最终结论,愿每位 ML / 平台 / SRE 工程师都能在 vLLM / SGLang / Ray / Milvus / LangGraph / Function Calling / Multi-modal 的 AI 大时代继续保持工程态度。继续提交 commit,我们下次再见。

六十五、补遗七:推理引擎选型矩阵详解

2026 年推理引擎选型矩阵的 6 维评估:(1) 模型规模:vLLM 全规模,SGLang 优秀,TensorRT-LLM 100B+ 性价比最高;(2) 硬件:vLLM 通用,TensorRT-LLM NVIDIA 专属;(3) 量化:TensorRT-LLM 生态最全(FP8/INT8/INT4 multi);(4) 部署灵活:vLLM 最简单,TensorRT-LLM 需重新编译;(5) 社区:vLLM 最活跃,TensorRT-LLM 商业支持最好;(6) 学习曲线:vLLM 最低,TensorRT-LLM 最高。大多数企业:vLLM 起步,有性能瓶颈再 TensorRT-LLM。

六十六、补遗八:RAG 失效的 5 种场景

RAG 系统失效的 5 种典型场景:(1) 多跳推理(用户问题需关联多文档);(2) 时间敏感(知识库未及时更新);(3) 数值精算(LLM 数学能力差);(4) 长尾问题(知识库无相关文档);(5) 模糊查询(关键词缺失)。对应 5 种缓解:Graph RAG + 实时增量 ingest + Tool calling 调计算器 + Fallback 到人工 + Query rewrite 用 LLM 改写。

六十七、补遗九:LLM 训练数据的"3 重清洗"

LLM 训练数据 3 重清洗:(1) 一重 — 规则清洗:去重 + 去 HTML / boilerplate + 长度过滤 + 语言识别;(2) 二重 — 质量清洗:perplexity 过滤 + KenLM 语言模型评分;(3) 三重 — 安全清洗:PII 检测 + 有害内容过滤 + Bias 平衡。我们 2.4 PB 训练数据经 3 重清洗后剩 380 TB(15% 留存率),但模型质量提升显著。

六十八、最最后一句话

38 天 AI 工程化的最后一个 commit,我把这段话留给团队作为 retro 闭幕:"AI 不是魔法,是数据 + 算力 + 工程 + 评估 + 安全的乘积,任何一项归零整体归零;LLM 不是上帝,是统计 + 概率 + 涌现的工程产物,准确率 99% 也意味着 1% 错误必须有兜底;Agent 不是终点,是工具 + 规则 + 学习的有机组合,未来 3 年才是 Agent 真正爆发的关口。52 工程师 38 天,我们建了一个能扛 84 亿 tokens / 天的 LLM 平台,服务 380 个企业租户,跑了 386 个 prompt,80 个 agent,4.4 PB 向量,零数据丢失。下个 38 天,我们会继续把推理成本再降 30%,把 hallucination 率压到 1% 以下,把 Multi-modal 全面投产,把 Voice Agent 推到 < 1s end-to-end。继续提交 commit,继续 ship,继续学,我们 AI 工程师的好时代,才刚刚开始。"

六十九、补遗十:Milvus 索引参数实战 yaml

22 亿向量场景下我们的 Milvus 索引创建脚本,完整可复制:

from pymilvus import MilvusClient, DataType

client = MilvusClient(uri="http://milvus:19530")

schema = MilvusClient.create_schema(auto_id=False, enable_dynamic_field=True)
schema.add_field("id", DataType.INT64, is_primary=True)
schema.add_field("vector", DataType.FLOAT_VECTOR, dim=1024)
schema.add_field("tenant_id", DataType.VARCHAR, max_length=64, is_partition_key=True)
schema.add_field("text", DataType.VARCHAR, max_length=65535)
schema.add_field("ts", DataType.INT64)

index_params = client.prepare_index_params()
index_params.add_index(
    field_name="vector",
    index_type="HNSW",
    metric_type="COSINE",
    params={"M": 16, "efConstruction": 200},
)
index_params.add_index(field_name="tenant_id", index_type="Trie")
index_params.add_index(field_name="ts", index_type="STL_SORT")

client.create_collection(
    collection_name="docs_v3",
    schema=schema,
    index_params=index_params,
    shards_num=16,
    num_partitions=128,
)
client.load_collection("docs_v3", replica_number=2)

res = client.search(
    collection_name="docs_v3",
    data=[query_vec],
    anns_field="vector",
    search_params={"metric_type": "COSINE", "params": {"ef": 64}},
    limit=20,
    filter='tenant_id == "acme-corp" and ts > 1714521600',
    output_fields=["text", "ts"],
)

—— 别看了 · 2026