前端调用大模型：从工程化实践到深度思考

秃头敲码小姐姐
61 阅读9分钟

在人工智能与前端开发深度融合的今天，如何安全、高效地从前端调用大语言模型（LLM）已成为现代全栈开发者必须掌握的核心技能之一。本文将围绕今日学习内容——基于 Vite 的全栈项目中通过 HTTP 请求调用 LLM 接口——展开系统性总结，并从面试官与求职者双重视角深入探讨相关技术要点，帮助读者构建扎实的知识体系与实战能力。

1. 今日学习内容总结

今天的学习聚焦于“前端通过 HTTP 请求调用大语言模型（如 DeepSeek）”这一典型场景，并结合 Vite 全栈脚手架进行工程化落地。以下是四个核心要点：

（1）前端调用 LLM 的标准 HTTP 模式

大模型服务通常以 RESTful API 形式提供，前端需通过 POST 方法向指定端点（如 https://api.deepseek.com/chat/completions）发送请求。请求头必须包含 Content-Type: application/json 和授权令牌（如 Authorization: Bearer ${apiKey}），请求体则为序列化后的 JSON 字符串（使用 JSON.stringify()），而非直接传递 JavaScript 对象。

（2）Vite 全栈项目的工程化初始化

借助 Vite 脚手架可快速搭建支持前后端一体化开发的项目结构。通过配置 vite.config.js 和环境变量文件（如 .env.local），实现开发与生产环境的分离管理。尤其重要的是，API 密钥等敏感信息应存放在 .env 文件中，并通过 import.meta.env.VITE_API_KEY 在客户端安全读取（注意：仅限公开密钥或代理方案下使用）。

（3）Fetch API 的异步处理最佳实践

使用原生 fetch 发起请求时，推荐采用 async/await 语法替代传统的 .then() 链式调用，使异步逻辑更接近同步代码，提升可读性与可维护性。同时需注意错误处理（如网络异常、HTTP 状态码非 2xx）和加载状态管理，以构建健壮的用户体验。

（4）安全边界与架构权衡

虽然前端可直接调用 LLM API，但暴露 API Key 存在安全风险。理想方案是通过后端代理转发请求，由服务端持有密钥。但在某些轻量级原型或内部工具场景中，若 LLM 提供方支持 CORS 且密钥具备访问限制（如绑定域名、IP 白名单），前端直连仍具可行性。

🌰 实际应用场景：智能客服对话界面

假设我们正在开发一个企业官网的智能客服模块。用户输入问题后，前端通过 Vite 项目中的 useChat 自定义 Hook，调用 DeepSeek 的聊天补全接口，实时返回回答并渲染到 UI。整个流程包括：

  • 用户输入 → 触发 handleSubmit
  • 构造请求体 { messages: [{ role: 'user', content: input }] }
  • 使用 fetch 发送 POST 请求（携带环境变量中的 API Key）
  • 解析流式或完整响应，更新聊天历史

该案例体现了从工程初始化、环境配置到实际业务集成的完整链路。

2. 面试官视角：深度思考题

以下三道题目由浅入深，旨在考察候选人对前端调用 LLM 的理解深度、工程思维与架构意识。

Q1（基础概念题）

在前端使用 fetch 调用 LLM 的 POST 接口时，为什么必须将 JavaScript 对象通过 JSON.stringify() 转换后再赋值给 body？直接传对象会有什么后果？

考察点：

  • 对 HTTP 协议与 Fetch API 底层机制的理解
  • 对请求体数据格式规范的认知

期望回答方向：
应指出 fetch 的 body 字段只接受字符串、FormData、Blob 等可序列化类型，不接受原生 JS 对象。若直接传对象，浏览器会隐式调用其 toString() 方法（结果为 [object Object]），导致服务端无法解析有效 JSON，返回 400 错误。

Q2（应用分析题）

你在 Vite 项目中将 LLM 的 API Key 存放在 .env 文件并通过 import.meta.env.VITE_API_KEY 读取。请问这种做法是否安全？在什么条件下可以接受？如果不安全，有哪些替代方案？

考察点：

  • 对前端环境变量机制的理解
  • 安全意识与架构权衡能力
  • 对 CORS、代理、服务端中转等方案的掌握

期望回答方向：
需明确指出：任何暴露在前端代码中的密钥本质上都是不安全的，因为最终会打包进公开的 JS 文件。但若满足以下条件，可视为“可接受风险”：

  • LLM 服务商支持 CORS 且允许前端直连
  • API Key 绑定了严格的域名/IP 白名单
  • 密钥权限受限（如仅限特定 endpoint、有 QPS 限制）

更安全的做法是：

  • 前端请求发送至自建后端 /api/proxy-llm
  • 后端持有密钥并转发请求，隐藏敏感信息
  • 结合用户认证、速率限制、审计日志等增强防护

Q3（开放性问题）

假设你需要为一个高并发 Web 应用设计一个“前端驱动的大模型交互系统”，既要保证响应速度，又要控制成本与安全性。你会如何设计整体架构？请从请求链路、缓存策略、错误恢复、成本优化等角度展开。

考察点：

  • 系统设计能力
  • 对 LLM 调用特性的理解（延迟、费用、幂等性）
  • 工程实践经验与创新思维

期望回答方向：
优秀回答应体现分层架构思想：

  • 前端：使用 AbortController 支持取消请求；本地缓存常见问答（localStorage + LRU）
  • 边缘层（可选）：通过 Cloudflare Workers 或 Vercel Edge Functions 实现轻量代理与简单缓存
  • 后端：统一 LLM 网关，集成密钥管理、请求去重、超时熔断、用量监控
  • 成本优化：对重复/相似 query 进行语义缓存（如 embedding + 向量检索）；设置最大 token 限制；异步批处理非实时需求
  • 可观测性：记录 latency、token usage、error rate，用于后续优化

3. 求职者视角：高质量回答示范

回答 Q2：关于 API Key 安全性的问题

“在 Vite 项目中将 LLM 的 API Key 放在 .env 并通过 import.meta.env.VITE_API_KEY 读取，这种做法是否安全？”

这是一个非常关键且常被忽视的问题。我的观点是：这种做法在绝大多数生产场景下是不安全的，但在特定约束条件下可用于原型验证或内部工具。

首先，我们需要理解 Vite 的环境变量机制。只有以 VITE_ 开头的变量才会被嵌入到客户端 bundle 中。这意味着 VITE_API_KEY 最终会出现在公开的 JavaScript 文件里，任何用户打开浏览器开发者工具都能看到它。因此，从安全模型上讲，这等同于将密钥硬编码在前端代码中。

那么，什么情况下可以接受？我认为需同时满足三个条件：

  1. LLM 服务商支持 CORS，允许浏览器直接跨域请求；
  2. API Key 具备强访问控制，例如绑定了精确的域名白名单（如 https://my-app.vercel.app），防止被其他网站盗用；
  3. 密钥权限最小化，仅能访问特定 endpoint，且设置了严格的 QPS 和每日配额上限。

即便如此，我仍建议在正式产品中采用后端代理模式。具体做法是：前端请求发送到自己的 /api/ask 接口，由后端 Node.js/Python 服务读取服务器环境变量中的密钥，再转发给 LLM。这样不仅隐藏了密钥，还能在此过程中加入用户鉴权、请求日志、敏感词过滤、响应缓存等增值功能。

举个实际例子：我在上一家公司开发 AI 写作助手时，初期为了快速验证 MVP，确实采用了前端直连。但上线前一周，我们紧急重构为 Express 中间层代理，并集成了 Redis 缓存——对相同 prompt 的请求在 5 分钟内直接返回缓存结果，不仅提升了首屏速度，还将月度 LLM 费用降低了 37%。

所以，我的原则是：永远不要在前端暴露真正的生产密钥。工程便利性永远要让位于安全性和可维护性。

回答 Q3（节选）：高并发 LLM 交互系统设计

“如何设计一个兼顾性能、成本与安全的前端驱动 LLM 系统？”

我会采用“分层防御 + 智能缓存 + 成本感知”的架构思路。

第一层：前端体验优化

  • 使用 AbortController 支持用户中断长耗时请求，避免资源浪费；
  • 对高频、低变异性 query（如“你好”、“谢谢”）做 localStorage 缓存，TTL 24 小时；
  • 请求发送前进行本地校验（长度、敏感词），减少无效调用。

第二层：边缘智能代理

  • 利用 Vercel Edge Functions 或 Cloudflare Workers 作为第一跳网关；
  • 在边缘节点缓存热门响应（如产品 FAQ），命中率可达 40%+；
  • 实现简单的速率限制（per IP / per user），防止恶意刷量。

第三层：核心 LLM 网关（后端）

  • 统一封装所有 LLM 调用，支持多模型切换（DeepSeek / GPT / Claude）；
  • 集成向量数据库（如 Pinecone），对新 query 计算 embedding 并检索相似历史回答，实现语义级缓存；
  • 设置动态 token 上限，根据用户等级分配不同预算；
  • 所有请求记录到日志系统，用于分析 cost-per-feature 和异常检测。

成本控制方面，我们曾通过以下措施将单次对话成本降低 52%：

  • 启用流式响应（streaming），让用户尽早看到部分结果，提升感知速度；
  • 对非关键场景使用 cheaper model（如 DeepSeek-Lite）；
  • 异步处理后台任务（如内容摘要），避免阻塞主线程。

这套架构已在我们日活 10w+ 的 SaaS 产品中稳定运行 6 个月，平均 P95 延迟 <1.8s，月度 LLM 支出控制在预算的 85% 以内。

总结

从前端发起一次看似简单的 LLM 调用，背后涉及工程配置、安全边界、异步编程、系统架构等多重维度。今日的学习不仅教会我们“如何做”，更启发我们思考“为何这样做”以及“如何做得更好”。

对于面试准备而言，掌握基础 API 用法只是起点，真正拉开差距的是对安全模型的理解、对成本效益的权衡，以及将技术融入业务场景的能力。建议大家在练习时，不仅要跑通 demo，更要追问：“如果这是线上系统，我会如何加固它？”

技术的价值，在于解决问题；而工程师的成长，在于不断追问“更好的解”。

avatar
文章
阅读
粉丝