AscendLab

项目背景

AscendLab 是我用来做 AI 工程化实验的个人项目集合，不是单一应用，而是一组围绕”大模型落地”展开的子项目。

工作中接触了大量 AI 应用接入的需求，发现从 API 调通到真正稳定可用之间有很大距离。AscendLab 就是我用来验证、踩坑、沉淀方案的地方。

主要子项目

1. LLM 对话服务

基于 FastAPI 封装统一的 LLM 调用层，支持多模型切换（GPT-4o、Claude、本地模型），统一处理：

• 上下文窗口管理（滑动截断 + 摘要压缩）
• 流式输出（SSE）
• 错误重试与降级
• Token 用量记录

2. 语音交互链路（ASR + TTS）

实时语音交互完整链路：

麦克风 → VAD 端点检测 → ASR 转文字 → LLM 生成回复 → TTS 合成音频 → 播放

使用的组件：

• ASR：FunASR（本地部署，支持流式识别）
• TTS：CosyVoice / Edge TTS
• VAD：Silero VAD
• 传输：WebSocket 双向流

延迟目标：首字节音频 < 800ms

3. 数字人系统

将语音交互链路与数字人渲染结合，实现可对话的数字人原型：

• 驱动方案：MuseTalk（唇形同步）
• 渲染：浏览器端 WebGL
• 状态管理：对话状态机（idle / listening / thinking / speaking）

4. Agent 编排实验

测试不同的 Agent 模式：

• ReAct（推理 + 行动循环）
• Function Calling（结构化工具调用）
• MCP（Model Context Protocol）接入本地工具

技术架构

前端（React）
    ↓ WebSocket / REST
FastAPI 服务层
    ├── LLM Router（多模型路由）
    ├── ASR Service（FunASR）
    ├── TTS Service（CosyVoice）
    └── Agent Engine（工具编排）
         ↓
Docker Compose / K8s 部署

踩坑记录

延迟是核心挑战：语音交互对延迟极敏感，ASR + LLM + TTS 三段叠加很容易超过 2 秒。优化点在于流式处理——ASR 出第一个句子就立刻送给 LLM，LLM 出第一个句子就立刻送给 TTS，整个链路并发流水线。

本地模型 vs 云端 API：本地部署 FunASR 比云端 ASR 便宜很多，但需要 GPU，冷启动慢。适合长期运行的服务，不适合偶发调用场景。

数字人渲染性能：MuseTalk 的推理在 CPU 上太慢，需要 GPU 加速。在没有独显的机器上，退化为静态形象 + 口型动画会是更实用的降级方案。

当前状态

• LLM 对话服务：✅ 可用
• 语音链路：✅ 基础版跑通，延迟还在优化
• 数字人：🔧 实验阶段
• Agent 编排：🔧 持续实验中