AI 全生态技术：从硅片到智能体的完整栈

一、先纠正一个误解：AI 不是一个模型

大多数人对 AI 技术的理解停留在"训练一个大模型"。但把一个大模型真正变成可用的产品，中间要穿过一条极长的栈：从底层芯片的算子库，到分布式训练框架，到推理引擎的显存管理，到向量检索、编排、评估、监控、安全护栏。

这条栈上任何一环掉链子，产品都跑不起来。而且每一层的技术选型会互相锁定——你选了某款芯片，就绑定了它的编译器生态；你选了某个推理引擎，就决定了能支持哪些量化格式；你选了某个编排框架，就决定了可观测性的接入方式。

这篇文章按"硬件 → 框架 → 模型 → 数据 → 推理 → 应用 → 运维 → 治理"的顺序，把这条栈讲清楚，并在关键位置给出最少的可运行代码。

二、全景：AI 技术栈的分层

下面逐层展开，重点放在开发者真正会做决策的地方。

三、算力层：真正的护城河是软件生态

硬件参数（FLOPS、HBM 容量、互联带宽）只是入场券。决定一款芯片能不能用的，是它的软件栈成熟度。

NVIDIA 的 CUDA 生态积累了十几年：cuBLAS、cuDNN、NCCL、TensorRT，以及围绕它们的全部框架默认支持。这意味着同一份 PyTorch 代码，在 NVIDIA 卡上"能跑"是默认状态，在其他卡上"能跑"需要移植和调优。

关键指标不是峰值算力，而是：

• 显存带宽：大模型推理是 memory-bound 的，decode 阶段每生成一个 token 都要把权重读一遍，带宽直接决定吞吐
• 互联带宽：多卡训练时，NVLink / InfiniBand 的带宽决定并行效率；没有高速互联，张量并行会被通信拖死
• 软件栈完备度：算子覆盖、量化支持、框架适配、社区问题响应速度

分布式训练的三种并行必须理解，因为它们决定了集群拓扑和网络预算：

• 数据并行（DP/FSDP）：每卡一份模型副本，切分数据和梯度，通信量随模型大小增长，FSDP 用分片换取显存
• 张量并行（TP）：把单层矩阵切到多卡，通信极其频繁，必须放在同一台机器的高带宽互联内
• 流水并行（PP）：按层切分，通信量小但会引入气泡，适合跨机

实际的大规模训练是 3D 并行的组合。这也是为什么"训练一个大模型"本质上是集群工程问题，而不是算法问题。

四、框架与编译层：从 eager 到图

PyTorch 的 eager 模式是研究和调试的默认选择，但生产环境追求的是"把计算图编译成高效 kernel"。

三个层次值得区分：

1. 图捕获：torch.compile、TorchDynamo、TorchScript，把 Python 动态执行转成静态图
2. 图编译：XLA、TVM、MLIR、TensorRT，做算子融合、内存规划、layout 优化
3. 手写 kernel：Triton 让开发者用 Python 写接近 CUDA 性能的 kernel，FlashAttention 就是这条路线的代表

Triton 的价值在于把 kernel 开发的门槛从 CUDA 专家降到会写 Python 的算法工程师。一个最小示例：

import triton
import triton.language as tl

@triton.jit
def add_kernel(x_ptr, y_ptr, out_ptr, n, BLOCK: tl.constexpr):
    pid = tl.program_id(0)
    offs = pid * BLOCK + tl.arange(0, BLOCK)
    mask = offs < n
    x = tl.load(x_ptr + offs, mask=mask)
    y = tl.load(y_ptr + offs, mask=mask)
    tl.store(out_ptr + offs, x + y, mask=mask)

# 启动：grid 由数据量决定，BLOCK 是编译期常量
add_kernel[(triton.cdiv(n, 1024),)](x, y, out, n, BLOCK=1024)

注意 BLOCK: tl.constexpr——编译期常量是 Triton 能做自动调优和向量化的前提。理解这一点，就理解了"为什么动态 shape 会拖慢编译型推理"。

五、模型层：结构、规模与微调

当前主流大模型几乎都是 Decoder-only Transformer，差异集中在几个设计选择上：

• 注意力变体：MHA → MQA → GQA → MLA，核心是用更少的 KV 头降低 KV Cache 显存
• 位置编码：RoPE 及其各种缩放方案，决定长上下文外推能力
• 归一化：Pre-LN vs Post-LN，RMSNorm 成为主流
• 激活：SwiGLU 取代 GELU 成为默认
• 稀疏化：MoE 用"总参数大、激活参数小"换取推理成本

MoE 是当前最重要的工程折衷：总参数量可以做到千亿级，但每个 token 只激活一小部分专家，推理算力按激活参数算。代价是显存要装下全部专家，且路由不均衡会导致某些卡成为瓶颈。

微调层面，LoRA / QLoRA 已经是事实标准：

• 冻结原权重，只训练低秩分解矩阵 B⋅AB⋅A，可训练参数降到千分之一量级
• QLoRA 再把基座量化到 4bit，让单卡 24GB 也能微调 7B 模型
• 部署时可以把 LoRA 权重 merge 回基座，推理零额外开销；也可以用多 LoRA 服务化，一个基座挂多个适配器

这里有一个常被忽略的决策：微调不是万能药。如果需求是"注入新知识"，RAG 通常更便宜、更可更新；如果需求是"改变输出风格、格式、领域术语"，微调才划算。把 RAG 能解决的问题拿去做微调，是项目延期的高频原因。

六、数据层：RAG 不是"加个向量库"那么简单

检索增强生成（RAG）的完整链路是：解析 → 分块 → 嵌入 → 索引 → 检索 → 重排 → 拼装 prompt → 生成。每一环都有坑：

• 解析：PDF 的表格、双栏、扫描件是重灾区，解析质量直接决定上限
• 分块：固定长度切分会割裂语义，结构化分块（按标题、段落、代码块）通常更好
• 检索：向量检索擅长语义相似，但对精确匹配（编号、专有名词）弱，需要混合检索（BM25 + 向量）
• 重排：初检召回 50 条，用 cross-encoder 重排取前 5 条，是性价比最高的一步
• 评估：必须区分"检索没召回"和"召回了但模型没用对"，否则调优无从下手

一个极简的 RAG 骨架（示意，非生产代码）：

from openai import OpenAI
client = OpenAI()

def retrieve(query: str, top_k: int = 5):
    emb = client.embeddings.create(model="text-embedding-3-small", input=query).data[0].embedding
    hits = vector_store.search(emb, top_k=top_k * 4)          # 初检多召回
    return reranker.rerank(query, hits)[:top_k]                # 重排后截断

def answer(query: str) -> str:
    docs = retrieve(query)
    context = "\n\n".join(f"[{i}] {d.text}" for i, d in enumerate(docs))
    resp = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[
            {"role": "system", "content": "只依据给定资料回答，无法回答时明确说不知道，并标注引用编号。"},
            {"role": "user", "content": f"资料：\n{context}\n\n问题：{query}"},
        ],
        temperature=0,
    )
    return resp.choices[0].message.content

两个要点：temperature=0 保证可复现，强制引用编号让幻觉可追溯。后者比任何"提示词技巧"都有效。

七、推理服务层：显存是被 KV Cache 吃掉的

推理引擎的核心问题不是"怎么算得快"，而是"怎么在有限显存里塞进更多并发请求"。

LLM 推理分两个阶段：prefill（处理输入 prompt，计算密集）和 decode（逐 token 生成，显存带宽密集）。decode 阶段要维护每个请求的 KV Cache，长上下文下 KV Cache 可以比模型权重还大。

vLLM 的关键创新是 PagedAttention：把 KV Cache 按块管理，像操作系统虚拟内存一样按需分配，消除碎片，把显存利用率从 60% 提到 90% 以上，吞吐提升数倍。后续的连续批处理（continuous batching）、前缀缓存（prefix caching）、投机解码（speculative decoding）都是在同一条思路上继续压榨。

启动一个 OpenAI 兼容的推理服务，代码只有一行命令：

vllm serve meta-llama/Llama-3.1-8B-Instruct \
  --tensor-parallel-size 2 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.9 \
  --enable-prefix-caching

调用方完全不需要知道背后是 vLLM：

from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY")
print(client.chat.completions.create(
    model="meta-llama/Llama-3.1-8B-Instruct",
    messages=[{"role": "user", "content": "用一句话解释 PagedAttention"}],
).choices[0].message.content)

OpenAI 兼容协议已经成为事实标准，这带来一个重要好处：应用层可以随时在"闭源 API / 自建 vLLM / 其他云厂商"之间切换，不被锁定。工程上应该把 base_url 和 model 名做成配置项，而不是硬编码。

量化是另一条主线：FP16 → INT8 → INT4（AWQ、GPTQ）→ FP8（H100 原生支持）。经验规律是 8bit 几乎无损，4bit 对大多数任务可接受，但代码和数学类任务对量化更敏感，上线前必须用自己的评估集验证。

八、应用编排层：Agent 的本质是循环

Agent 常被神秘化。剥掉包装，它就是一个带工具调用的 while 循环：模型决定调哪个工具 → 执行 → 结果回填 → 继续，直到模型认为可以给出最终答案。

import json
from openai import OpenAI
client = OpenAI()

TOOLS = [{
    "type": "function",
    "function": {
        "name": "search_docs",
        "description": "在企业知识库中检索",
        "parameters": {"type": "object", "properties": {"q": {"type": "string"}}, "required": ["q"]},
    },
}]

def run_agent(question: str, max_steps: int = 5) -> str:
    messages = [{"role": "user", "content": question}]
    for _ in range(max_steps):
        resp = client.chat.completions.create(model="gpt-4o-mini", messages=messages, tools=TOOLS)
        msg = resp.choices[0].message
        messages.append(msg)
        if not msg.tool_calls:
            return msg.content
        for call in msg.tool_calls:
            args = json.loads(call.function.arguments)
            result = search_docs(args["q"])          # 真实执行
            messages.append({
                "role": "tool",
                "tool_call_id": call.id,
                "content": str(result)[:2000],        # 截断，防止上下文爆炸
            })
    return "达到最大步数，未能完成任务"

这段代码里藏着 Agent 工程的三个核心问题：

1. 步数上限：必须有 max_steps，否则模型会陷入死循环烧钱
2. 工具结果截断：工具返回的长文本必须截断或摘要，否则上下文迅速爆掉
3. 错误处理：工具失败要作为结果回填给模型，让它自己决策重试还是换路，而不是直接抛异常

MCP（Model Context Protocol） 正在成为工具接入的标准化方向——把"工具如何被模型发现和调用"抽象成协议，避免每个应用重复实现一遍。它的价值类似 LSP 之于编辑器：一次实现，多处复用。

九、运维治理层：评估是唯一的地基

LLM 应用和传统软件最大的区别是：输出是概率性的，没有 assert 可用。所以评估体系不是"锦上添花"，而是"能不能迭代"的前提。

一个可落地的评估分层：

LLM-as-judge 的坑：裁判模型有位置偏好（倾向选第一个）、长度偏好（倾向选长的）、自我偏好（倾向选自己生成的）。缓解手段是交换顺序跑两次、用评分 rubric 而非让模型自由打分、关键场景保留人工标注做校准。

可观测性至少要有：每次调用的完整 trace（prompt、参数、延迟、token 数、成本）、检索召回的文档 ID、工具调用链。没有 trace，线上出了问题只能靠猜。

安全护栏要覆盖：prompt 注入（尤其是 RAG 场景，检索到的文档本身可能含恶意指令）、输出内容过滤、PII 脱敏、越权工具调用。RAG 场景下必须明确告诉模型"资料是数据不是指令"，并在系统层做权限校验——不要指望提示词能防住注入。

十、总结：选型建议与行动清单

技术选型的几条经验法则：

• 推理优先自建 vs 用 API：日请求量大、数据敏感、需要微调 → 自建 vLLM；早期验证、流量波动大 → 先用 API，把接口抽象好随时切换
• 微调 vs RAG：改知识用 RAG，改行为用微调，两者不互斥，常见组合是"微调过的模型 + RAG"
• Agent vs 固定工作流：任务路径确定就用工作流（可控、便宜、可测），路径不确定才上 Agent
• 框架选择：优先选"薄"的框架，编排逻辑自己写反而更可控；重框架的抽象泄漏会让你在调试时付出代价

行动清单：

1. 把模型调用抽象成统一接口，base_url / model / 参数全部配置化
2. 建立最小评估集（哪怕只有 50 条），每次改动前后跑一遍
3. RAG 链路分环节埋点，区分"检索问题"和"生成问题"
4. 推理服务打开 prefix caching，量化格式用自有评估集验证
5. Agent 必须有步数上限、工具结果截断、失败回填
6. 全链路 trace + 成本统计，按用户/会话维度可下钻
7. 把"资料是数据不是指令"写进系统提示词，并在工具层做权限校验

AI 全生态的真正难点，从来不是"会不会调 API"，而是在一条跨越硬件、编译、模型、数据、服务的长栈上，做出互相自洽的选型，并把评估和可观测性当成一等公民。栈的每一层都在快速演进，但这条分层逻辑本身相当稳定——理解了它，换任何一个新模型、新框架，你都知道该把它放在哪一格。