阅读视图

发现新文章,点击刷新页面。

前端开发者也能玩转大模型:使用HTTP请求调用DeepSeek全记录

无需后端支持,纯前端技术栈也能集成人工智能大模型

作为一名前端开发者,我最近探索了一个有趣的技术方案:如何在前端项目中直接调用大型语言模型。在这个过程中,我发现了不少值得分享的经验和技巧,今天就带大家一步步实现前端调用DeepSeek大模型的全过程。

项目背景与初衷

传统上,调用AI大模型通常需要后端服务的支持,前端通过API与自己的服务器交互,再由服务器调用AI服务。这样做主要是出于安全考虑,特别是为了保护API密钥。但有时候,我们只是想快速原型验证,或者构建简单的个人项目,这时候如果能直接从前端调用大模型,会大大简化开发流程。

我决定尝试使用纯前端技术栈调用DeepSeek大模型,并记录下整个过程。

项目初始化:从零搭建

为了简化开发流程,我使用了 Trae(一种 AI 辅助开发工具)帮我快速初始化了一个基于 Vite 的前端项目。V

选择构建工具

我选择了Vite作为项目构建工具,它不仅速度快,而且内置了丰富的功能,特别是对环境变量的支持,这对保护API密钥至关重要。

npm create vite@latest frontend-llm-demo
cd frontend-llm-demo
npm install

项目结构设计

保持简洁的项目结构:

frontend-llm-demo/
├── index.html
├── styles/
│   └── style.css
├── scripts/
│   └── app.js
└── .env.local

其中,index.html 是主页面,app.js 负责发起 API 请求,而 .env.local 将用于存放敏感的 API Key。

核心实现:HTTP请求调用LLM

构建API请求

app.js中,我实现了完整的API调用逻辑:

// DeepSeek API端点
const endpoint = 'https://api.deepseek.com/chat/completions'

// 设置请求头
const headers = {
  'Content-Type': 'application/json',
  'Authorization': `Bearer ${import.meta.env.VITE_DEEPSEEK_API_KEY}`
}

// 构建请求体
const payload = {
  model: 'deepseek-chat',
  messages: [
    {
      role: 'system',
      content: 'You are a helpful assistant.'
    },
    {
      role: 'user',
      content: '你好 DeepSeek'
    }
  ]
}

// 发送请求并处理响应
const response = await fetch(endpoint, {
  method: 'POST',
  headers: headers,
  body: JSON.stringify(payload)
})

const data = await response.json()
console.log(data)

// 将模型回复动态挂载到页面
document.getElementById('reply').textContent = data.choices[0].message.content

关键技术点解析

1. 请求方法选择

我使用了POST而非GET方法,原因有二:

  • POST请求更安全,参数不会暴露在URL中
  • 我们需要传递请求体,GET请求通常不包含请求体 而 LLM 调用需要传递复杂的 messages 结构,必须使用 POST

2. 请求头设置

请求头包含了两个关键信息:

  • Content-Type: application/json - 告诉服务器我们发送的是JSON格式数据
  • Authorization: Bearer ... - 用于身份验证的API密钥

3. 请求体构建

请求体是一个JSON对象,包含:

  • model - 指定要使用的模型版本
  • messages - 对话消息数组,包含角色和内容

4. 数据序列化

使用JSON.stringify()将JavaScript对象转换为JSON字符串,因为HTTP协议只能传输文本或二进制数据,不能直接传输对象。

安全考虑:保护API密钥

环境变量的重要性

直接将API密钥硬编码在前端代码中是极其危险的,任何用户都可以查看源代码获取密钥。为了解决这个问题,我使用了环境变量。

Vite环境变量配置

Vite使用特殊的import.meta.env对象来访问环境变量。以VITE_开头的变量会被嵌入到客户端代码中。

  1. 创建.env文件:
VITE_DEEPSEEK_API_KEY=your_api_key_here
  1. 在代码中访问:
const apiKey = import.meta.env.VITE_DEEPSEEK_API_KEY

注意:即使使用环境变量,前端代码中的API密钥仍然可能被有心人获取。对于生产环境,最佳实践仍然是使用后端服务作为代理。

异步处理:从Promise到async/await

传统的Promise链式调用

fetch(endpoint, options)
  .then(response => response.json())
  .then(data => {
    // 处理数据
  })
  .catch(error => {
    // 错误处理
  })

现代的async/await

我选择了async/await语法,因为它更简洁、更易读:

try {
  const response = await fetch(endpoint, options)
  const data = await response.json()
  // 处理数据
} catch (error) {
  // 错误处理
}

结果展示:动态更新DOM

获取到API响应后,需要将结果显示在页面上:

document.getElementById('reply').textContent = data.choices[0].message.content

这里使用了直接操作DOM的方式,在现代前端框架流行的今天,这种原生方法依然简单有效。

完整HTML结构

<!doctype html>
<html lang="zh-CN">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <meta name="color-scheme" content="light dark">
  <title>前端调用大模型示例</title>
  <link rel="stylesheet" href="styles/style.css">
</head>
<body>
  <h1>Hello DeepSeek</h1>
  <div id="reply"></div>
  <script type="module" src="./scripts/app.js"></script>
</body>
</html>

开发心得与总结

通过这个项目,我获得了以下几点经验:

1. 前端调用LLM的可行性

事实证明,前端直接调用大模型API是完全可行的,这为快速原型开发和个人项目提供了便利。但需要注意安全性问题,不建议在生产环境中直接暴露API密钥。

2. HTTP请求的细节重要性

调用外部API时,请求的每个部分都很重要:

  • 正确的端点URL
  • 恰当的HTTP方法
  • 必要的请求头
  • 正确格式化的请求体

3. 现代JavaScript特性的价值

ES6+的特性让代码更加简洁:

  • 模板字符串
  • 箭头函数
  • 解构赋值
  • async/await

4. 构建工具的重要性

Vite等现代构建工具不仅提供开发服务器和打包功能,还解决了环境变量、模块化等工程化问题。

5. 安全意识的培养

即使是在个人项目中,也应该养成良好的安全习惯,使用环境变量管理敏感信息。

结语

前端技术日新月异,如今我们甚至可以直接在前端调用强大的人工智能模型。这个项目虽然简单,但展示了前端开发的强大能力和无限可能性。作为前端开发者,我们不应该将自己局限在传统的界面开发中,而应该积极探索前端技术的边界。

希望这篇文章能为想要在前端项目中集成AI能力的开发者提供一些参考和启发。前端的世界很精彩,让我们一起探索更多可能性!


注意:本文示例仅适用于开发和测试环境,生产环境中请务必通过后端服务调用第三方API,确保API密钥的安全性。

刚刚,DeepSeek 又发新模型,小而美玩出新高度

就在刚刚,DeepSeek 开源了一个 3B 模型 DeepSeek-OCR。虽然 3B 体量不大,但模型思路创新的力度着实不小。

众所周知,当前所有 LLM 处理长文本时都面临一个绕不开的困境:计算复杂度是平方级增长的。序列越长,算力烧得越狠。

于是,DeepSeek 团队想到了一个好办法。既然一张图能包含大量文字信息,而且用的 Token 还少,那不如直接把文本转成图像?这就是所谓的「光学压缩」——用视觉模态来给文本信息「瘦身」。

而 OCR 正好天然适合验证这个思路,因为它本身就是在做「视觉→文本」的转换,而且效果还能量化评估。

论文显示,DeepSeek-OCR 的压缩率能达到 10 倍,OCR 准确率还能保持在 97% 以上。

啥意思呢?就是说,原本需要 1000 个文本 Token 才能表达的内容,现在只用 100 个视觉 Token 就搞定了。即使压缩率拉到 20 倍,准确率也还有 60% 左右,整体效果相当能打。

OmniDocBench 基准测试结果显示:

  • 只用 100 个视觉 Token,就超过了 GOT-OCR2.0(每页 256 个 Token)的表现
  • 用不到 800 个视觉 Token,干翻了 MinerU2.0(平均每页超过 6000 个 Token)

在实际生产中,一块 A100-40G 显卡就能每天生成超过 20 万页的 LLM/VLM 训练数据。20 个节点(160 块 A100)直接飙到每天 3300 万页。

DeepSeek-OCR 由两个核心组件组成:

  • DeepEncoder(编码器):负责图像特征提取和压缩
  • DeepSeek3B-MoE(解码器):负责从压缩后的视觉 Token 中重建文本

让我们来重点说说 DeepEncoder 这个引擎。

它的架构很巧妙,通过把 SAM-base(8000 万参数)和 CLIP-large(3 亿参数)串联起来,前者负责「窗口注意力」提取视觉特征,后者负责「全局注意力」理解整体信息。

中间还加了个 16×卷积压缩器,在进入全局注意力层之前把 Token 数量大幅砍掉。

举例而言,一张 1024×1024 的图像,会被切成 4096 个 patch token。但经过压缩器处理后,进入全局注意力层的 Token 数量会大幅减少。

这样的好处是,既保证了处理高分辨率输入的能力,又控制住了激活内存的开销。

而且 DeepEncoder 还支持多分辨率输入,从 512×512 的 Tiny 模式(64 个 Token)到 1280×1280 的 Large 模式(400 个 Token),一个模型全搞定。

目前开源版本支持的模式包括原生分辨率的 Tiny、Small、Base、Large 四档,还有动态分辨率的 Gundam 模式,灵活性拉满。

解码器用的是 DeepSeek-3B-MoE 架构。

别看只有 3B 参数,但采用了 MoE(混合专家)设计——64 个专家中激活 6 个,再加 2 个共享专家,实际激活参数约 5.7 亿。这也让模型既有 30 亿参数模型的表达能力,又保持了 5 亿参数模型的推理效率。

解码器的任务就是从压缩后的视觉 Token 中重建出原始文本,这个过程可以通过 OCR 风格的训练被紧凑型语言模型有效学习。

数据方面,DeepSeek 团队也是下了血本。

从互联网收集了 3000 万页多语言 PDF 数据,涵盖约 100 种语言,其中中英文占 2500 万页。

数据分两类:粗标注直接用 fitz 从 PDF 提取,主要训练少数语言的识别能力;精标注用 PP-DocLayout、MinerU、GOT-OCR2.0 等模型生成,包含检测与识别交织的高质量数据。

对于少数语言,团队还搞了个「模型飞轮」机制——先用有跨语言泛化能力的版面分析模型做检测,再用 fitz 生成的数据训练 GOT-OCR2.0,然后用训练好的模型反过来标注更多数据,循环往复最终生成了 60 万条样本。

此外还有 300 万条 Word 文档数据,主要提升公式识别和 HTML 表格解析能力。

场景 OCR 方面,从 LAION 和 Wukong 数据集收集图像,用 PaddleOCR 标注,中英文各 1000 万条样本。

DeepSeek-OCR 不仅能识别文字,还具备「深度解析」能力,只需一个统一的提示词,就能对各种复杂图像进行结构化提取:

  • 图表:金融研究报告中的图表可以直接提取为结构化数据
  • 化学结构式:识别并转换为 SMILES 格式
  • 几何图形:对平面几何图形进行复制和结构化解析
  • 自然图像:生成密集描述(dense captions)

这在 STEM 领域的应用潜力巨大,尤其是化学、物理、数学等需要处理大量符号和图形的场景。

这里就不得不提 DeepSeek 团队提出的一个脑洞大开的想法——用光学压缩模拟人类的遗忘机制。

人类的记忆会随时间衰退,越久远的事情记得越模糊。DeepSeek 团队想,那能不能让 AI 也这样?于是,他们的方案是:

  1. 把超过第 k 轮的历史对话内容渲染成图像
  2. 初步压缩,实现约 10 倍的 Token 减少
  3. 对于更久远的上下文,继续缩小图像尺寸
  4. 随着图像越来越小,内容也越来越模糊,最终达到「文本遗忘」的效果

这就很像人类记忆的衰退曲线,近期信息保持高保真度,久远记忆自然淡化。

虽然这还是个早期研究方向,但如果真能实现,对于处理超长上下文将是个巨大突破——近期上下文保持高分辨率,历史上下文占用更少计算资源,理论上可以支撑「无限上下文」。

简言之,DeepSeek-OCR 表面上是个 OCR 模型,但实际上是在探索一个更宏大的命题:能否用视觉模态作为 LLM 文本信息处理的高效压缩媒介?

初步答案是肯定的,7-20 倍的 Token 压缩能力已经展现出来了。

当然,团队也承认这只是个开始。单纯的 OCR 还不足以完全验证「上下文光学压缩」,后续还计划开展数字–光学文本交替预训练、「大海捞针」式测试,以及其他系统性评估。

不过不管怎么说,这在 VLM 和 LLM 的进化路上,又多了一条新赛道。

去年这个时候,大家还在卷想着怎么让模型「记得更多」。

今年 DeepSeek 直接反其道行之:不如让模型学会「忘掉一些」?确然,AI 的进化,有时候不是做加法,而是做减法。小而美,也能玩出大花样,DeepSeek-OCR 这个 3B 小模型就是最好的证明。

GitHub 主页:
http://github.com/deepseek-ai/DeepSeek-OCR
论文:
https://github.com/deepseek-ai/DeepSeek-OCR/blob/main/DeepSeek_OCR_paper.pdf
模型下载:
https://huggingface.co/deepseek-ai/DeepSeek-OCR

#欢迎关注爱范儿官方微信公众号:爱范儿(微信号:ifanr),更多精彩内容第一时间为您奉上。

爱范儿 | 原文链接 · 查看评论 · 新浪微博


❌