DeepSeek教程网

Appearance

Transformer入门 ​

为什么应该深刻理解自注意力机制，但只需要粗略了解下Transformer架构，大致了解它作为“黑箱算子”的性能特征即可？这其实对应了非常需要解惑的问题：工程师背景转向 LLM 工程，入门一点也不难！

产业现状 ​

目前 90% 的中小 AI 公司不需要算法工程师，他们需要的是：

  • 能把模型跑起来的 系统工程师。
  • 能把模型用到业务的 应用工程师 / 产品工程师。

为什么用不到算法设计？ ​

算法设计层关注的是“怎么改公式”，比如提出新的注意力机制、优化收敛、改训练目标。这是论文产出、顶会 PK 的内容。工程应用层用的是现成的成果，开源社区已经帮你实现了（HuggingFace、vLLM、DeepSpeed、TensorRT 等）。

目前的产业分工，绝大多数公司并没有在算法层“造新轮子”，而是直接用现成架构（Transformer、Diffusion），把重心放在 微调 + 部署 + 业务集成。

一、场景职责 ​

1. 入门 ​

能跑通

  • 范围：不用关心训练，主要关心推理，也就是调用现成模型。
  • 怎么做：
    • 下载 HuggingFace 上的模型（比如 BERT、LLaMA2、Qwen）。
    • 写 20 行 Python，就能把文本丢进去得到结果。
    • 这个阶段几乎 不用碰硬件，本地 CPU/GPU 或者云服务都能跑。
  • 本质：跟你之前写一个 Nginx 插件差不多，接个 API 就行。自注意力、位置编码、残差这些，已经被 PyTorch / TensorFlow / JAX / HuggingFace 封装好了。

2. 应用层 ​

业务微调 + 部署

  • 范围：
    • 微调训练：把大模型“调教”成适合你业务的版本（比如法律文本、客服场景）。
    • 推理部署：把模型放到服务端，用户可以高并发调用。
  • 硬件关系：
    • 小模型（几亿参数） → 一张消费级 GPU 就能搞。
    • 大模型（几十亿参数） → 云 GPU（A100、H100）或多机多卡。
  • 你需要的技能：
    • 写 LoRA / PEFT 脚本 → 做小规模训练。
    • 学会用推理框架（vLLM、ONNX Runtime、TensorRT）。
  • 本质：这里你已经要 稍微关心硬件资源（显存够不够，量化怎么做），但具体 CUDA 内核优化不需要你写。

3. 工程化 ​

商用推理服务

  • 范围：
    • 支撑高并发、多用户。
    • 做缓存、批处理、调度，提高 GPU 利用率。
  • 硬件关系：
    • 你不用自己写 CUDA，但必须懂 GPU 是稀缺资源，要学会怎么排队、合批、分配任务。
    • 类似传统分布式系统里的 资源调度问题。
  • 你需要的技能：
    • KV Cache、批量推理、模型量化。
    • 部署到 GPU 集群（Kubernetes + GPU Operator）。
  • 本质：这个阶段，你的分布式/服务器经验会非常有价值。

4. 顶层 ​

大规模训练 & 平台

  • 范围：
    • 从零开始训练 GPT 级别模型。
    • 或者做一个对外开放的大规模推理平台。
  • 硬件关系：
    • 必须懂 分布式训练，涉及 GPU 拆分（模型并行、流水线并行）。
    • 这不是“写插件”，而是 跟硬件、调度、CUDA 优化团队深度协作。
  • 你需要的技能：
    • Megatron-LM、DeepSpeed、FSDP。
    • 大规模数据管道、checkpoint 容错、算子优化。
  • 本质：这不是单兵作战，而是大厂/创业公司级别团队合作。

二、CML启示 ​

DeepSeek案例 ​

即便是成名前的DeepSeek，“深度推理”功能也是典型的工程创新。

DeepSeek 并没有改 attention 的数学原理，而是在推理环节和上下文管理机制上做了效率创新，侧重的是系统和流程的创新，通过工程手段，把“模型 + 上下文管理 + prompt 优化 + 运行效率”封装成一个高效、目标导向的黑箱推理流程。

  1. 上下文追踪：把之前对话、历史输入、业务约束都记住。
  2. 目标导向推理：根据你给的 prompt 或指令，把模型输出尽量对齐你的目标。
  3. 自动优化流程：内部做了分块、缓存、批量处理，你只感受到流畅、高效、目标明确的反馈。

结果就是：你在和模型交互时，感受到像有一个**懂你意图、帮你把任务拆解的“虚拟产品经理”**在负责推理内部调度，而不仅仅是一堆虚拟工程师直接和你沟通。

上下文管理，跟自注意力机制代表的算法层无关，也不属于 Transformer 架构本身的核心范畴，而是模型推理功能设计和任务设计上层的概念。

这是一个很好的范例，而借助CML，理论上应该可以带来新的变化才对。

CML定位 ​

在 应用层 描述上下文、场景、语义关系（比如业务流程、交互、知识表达），再把这些上下文映射到 LLM 的 prompt、微调数据、知识检索，那么CML就可能变成了 “AI 应用编排语言”。

这一点在产业里其实缺口很大：

  • Prompt 工程现在很混乱，没有统一标准。
  • 企业级 AI 项目经常需要把业务逻辑和 LLM 调用绑定，但没有统一语言。如果 CML 能作为 “AI 业务上下文的标准描述层”，它反而有应用价值。

Copyright © 2025-present 雾拓网络