模型专题

问题：MinerU 是什么

MinerU 是由 OpenDataLab（上海人工智能实验室）开源的高精度文档解析引擎，专门为 LLM / RAG / Agent 工作流设计。

核心功能：

将 PDF、DOCX、PPTX、XLSX、图片、网页 等复杂文档转换为结构化 Markdown / JSON
支持 VLM + OCR 双引擎，覆盖 109 种语言
自动去除页眉/页脚/页码，按人类阅读顺序输出
公式 → LaTeX，表格 → HTML，支持扫描件、手写体、多栏布局、跨页表格合并
支持纯 CPU / GPU / NPU 环境，兼容华为昇腾等 10+ 国产芯片

集成方式：

提供 MCP Server（Cursor / Claude Desktop / Windsurf）
原生集成 LangChain、LlamaIndex、Dify、FastGPT 等 RAG 框架
Python / Go / TypeScript SDK、CLI、REST API、Docker
当前最新版本 3.1.x（2026年5月），已从 AGPLv3 切换到基于 Apache 2.0 的开源协议

本质上，MinerU 解决的是"非结构化文档 → LLM 可消费的结构化数据"这一关键链路问题。

问题：vLLM 是什么

vLLM 是一个高性能、高吞吐量的开源 LLM 推理和服务框架，最初由 UC Berkeley Sky Computing Lab 开发，现已成为 PyTorch Foundation 托管项目，社区驱动。

核心创新 — PagedAttention：

受操作系统虚拟内存和分页机制启发，将 KV Cache 分页管理，消除显存碎片
使 GPU 可以同时处理更多请求，吞吐量可达 HuggingFace Transformers 的 24 倍

关键特性：

连续批处理：请求动态进出 batch，不等待完整序列结束
PagedAttention：高效管理注意力 KV 缓存内存
多种量化：GPTQ、AWQ、INT4/INT8、FP8
分布式推理：张量并行、流水线并行、数据并行、专家并行
前缀缓存：共享前缀的请求复用 KV Cache
推测解码：小模型打草稿，大模型验证
OpenAI 兼容 API，流式输出
支持 NVIDIA / AMD / Intel / Google TPU / 华为昇腾等硬件

版本状态：

2025 年已全面迁移至 V1 引擎（V0 代码已移除），架构更简洁、性能更高
vLLM Router（Rust 构建）已发布，提供智能负载均衡
已实现 2.2k tok/s/H200 的大规模服务性能

vLLM 是目前业界部署最广泛的 LLM 推理框架之一，尤其擅长高并发场景。

问题：SGLang 是什么

SGLang（Structured Generation Language）是一个高性能的 LLM 和多模态模型推理服务框架，由 Stanford、UC Berkeley 和 LMSYS 联合研发，是全球增长速度最快的推理框架之一。

核心创新 — RadixAttention：

使用基数树（Radix Tree）结构来索引和复用 KV Cache
共享前缀的请求（如 RAG 中相同的系统提示词）直接跳过计算，仅处理差异部分
在 RAG 场景下速度可达 vLLM 的 6 倍，DeepSeek-V3 推理速度业界第一（比 vLLM 快 3.1 倍）

关键特性：

极快运行时：零开销 CPU 调度器、预填充-解码分离、连续批处理、分页注意力
结构化生成：原生支持 JSON / 函数调用的约束解码，无需额外后处理
广泛模型支持：Llama、Qwen、DeepSeek、GLM、GPT、Gemma 等语言模型 + 嵌入模型 + 扩散模型（WAN、Qwen-Image）
广泛硬件支持：NVIDIA（GB200/B300/H100…）、AMD、Intel CPU、Google TPU、华为昇腾
RL 后训练支撑：被 AReaL、verl 等主流强化学习框架采用作为 rollout 后端
已部署在全球 40 万+ GPU 上，日均处理万亿级 Token
被 xAI、NVIDIA、美团、阿里云等采用

SGLang 通过声明式 DSL 让开发者用几行代码实现约束生成、多智能体协作，兼顾开发效率与运行性能。

问题：vLLM 和 SGLang 有什么区别

两者都是高性能 LLM 推理框架，核心区别在于KV Cache 管理策略和设计侧重不同：

维度	vLLM	SGLang
核心创新	PagedAttention（分页管理 KV Cache）	RadixAttention（基数树索引复用）
共享前缀场景	前缀缓存（Prefix Caching），固定粒度	RadixTree 天然支持，任意粒度共享，RAG 场景可达 6x
结构化生成	需外部约束库（如 Outlines、LiteLLM）配合	原生 JSON Schema / 函数约束解码，零开销
生态成熟度	业界最广泛，社区最大，硬件支持最全	快速增长，已被 xAI、NVIDIA、美团、阿里云采用
模型覆盖面	更广，对冷门模型和新硬件支持更快	聚焦主流模型，追赶速度很快
DeepSeek-V3	支持	快 3.1 倍，目前业界最快
适用场景	通用高并发服务，生产稳定优先	RAG / 共享 Prompt 密集 / 结构化输出要求高的场景

选型建议：

如果服务模型种类多、用户请求模式不固定、生产环境追求最长稳定运行时间，vLLM 更稳妥
如果场景有大量共享前缀请求（RAG）、强依赖结构化输出（JSON Mode / Function Calling）、或主要跑 DeepSeek 系列，SGLang 优势明显
两者可以共存：不同业务线用不同的推理框架，LiteLLM 统一路由，互不干扰

问题：在项目里 vLLM 和 SGLang 的部署形式是什么样的

vLLM 部署（国能智能评标平台）：

我们实际部署的是 vLLM，整体架构是 vLLM + LiteLLM + Langfuse 三层堆叠：

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│  Agent 服务   │────▶│  LiteLLM     │────▶│  vLLM 实例   │
│  (业务侧)     │     │  (路由/降级)  │     │  (推理引擎)   │
└──────────────┘     └──────────────┘     └──────────────┘
                            │                      │
                            ▼                      ▼
                     ┌──────────────┐     ┌──────────────┐
                     │  Langfuse    │     │  备用模型     │
                     │  (全链路追踪) │     │  (Fallback)   │
                     └──────────────┘     └──────────────┘

vLLM 层——负责模型推理。部署在单台 8×4090 服务器上，拉起多个 vLLM 实例，分别承载不同模型（如 Qwen 系做文本评审、Code 模型做评分代码生成）。每个实例暴露 OpenAI 兼容 API。
LiteLLM 层——作为统一网关部署在容器中，配置了多个 model group：主模型指向 vLLM 实例，备用模型指向其他服务（如阿里云通义 API）。主模型失败自动 fallback，保证评审流程不中断。
Langfuse 层——所有 LiteLLM 通过的请求上报到 Langfuse，记录每次调用的 Prompt、Completion、Latency、Token 用量，用于 bad case 回溯和成本分析。

SGLang 部署（参考架构，当前项目未使用）：

如果切换或混用 SGLang，部署形式类似——SGLang 实例替代部分 vLLM 实例。典型方式：

┌──────────────┐     ┌──────────────┐     ┌────────────────┐
│  Agent 服务   │────▶│  LiteLLM     │──┬─▶│  vLLM (通用)    │
│              │     │  (路由调度)   │  ├─▶│  SGLang (RAG类) │
└──────────────┘     └──────────────┘  │ └────────────────┘
                                       │    （根据请求类型路由）

路由策略：LiteLLM 配置两个 model group，Agent 服务根据任务类型选择路由——结构化生成、RAG 检索密集的任务走 SGLang，通用文本评审走 vLLM。
共享 GPU 资源：在同一台 8×4090 上，按端口区分实例，由 LiteLLM 统一管理路由和负载均衡。
关键考虑：SGLang 对 DeepSeek-V3 等 MoE 模型的推理效率更高，如果未来切换到这类模型，SGLang 是优先选型。

核心就是：推理框架可替换、上层无感知——无论底层是 vLLM 还是 SGLang，Agent 业务代码只需要面向 LiteLLM 的 OpenAI 兼容接口，框架切换对业务透明。

问题：LiteLLM 是什么

LiteLLM 是一个开源的 LLM 网关/代理（Gateway/Proxy）库，提供统一的 OpenAI 兼容接口来调用 100+ 种大语言模型（OpenAI、Anthropic、Vertex AI、Bedrock、vLLM、Ollama、HuggingFace 等）。

两种使用方式：

SDK 模式 — 直接替代 OpenAI 客户端：

from litellm import completion
response = completion(model="gpt-3.5-turbo", messages=[...])
# 模型名一换就切到别的提供商

代理服务器模式（LLM Gateway）— 自托管网关：
```
litellm --model ollama/codellama   # 启动代理，监听 http://0.0.0.0:4000
```
- 任何 OpenAI 兼容客户端无需改代码即可接入
- 支持虚拟密钥（按密钥/团队/用户做预算和用量追踪）
- 负载均衡：同一模型的多个部署间路由，支持重试/回退
- 集中式日志、缓存、护栏（Guardrails）、监控 UI
- 支持 A2A 代理 和 MCP 网关，一个端点管理 LLM + Agent + MCP 工具

典型场景：

公司内部统一管理多个模型提供商的 API 密钥和成本
在生产环境中做模型降级（主模型失败自动回退到备用模型）
跨多个 vLLM/SGLang 部署做负载均衡

LiteLLM 定位是 LLM 基础设施的控制面，解决的是多模型管理和接入的碎片化问题。

提示词工程

问题：什么是

问题：提示词怎么优化

上下文工程

问题：什么是

上下文工程就是围绕 LLM context window 做的信息筛选、排序、压缩和结构化设计，目标是用最少 token 提供最高质量的输入，从而提升模型输出的稳定性和准确性。

问题：与提示词工程的区别

提示词工程关注的是“如何表达问题”，而上下文工程关注的是“如何构建输入信息”，后者是一个更接近 RAG 和系统设计层面的能力，本质是对 LLM 输入数据流的整体优化。

提示词工程​

上下文工程​

提示词工程

上下文工程