1. 项目概述：一个为本地大语言模型量身定制的推理与部署框架

如果你最近在折腾本地大语言模型，比如Llama、Qwen或者Mistral这些开源模型，那你大概率经历过这样的场景：费了九牛二虎之力从Hugging Face下载了一个几GB甚至几十GB的模型文件，然后开始在网上搜索各种教程，尝试用 transformers 库加载，结果要么是内存爆了，要么是推理速度慢得让人怀疑人生。好不容易跑起来了，又想给它加个Web界面方便交互，或者想试试不同的量化版本，整个过程就像在玩一个充满未知陷阱的拼图游戏。

今天要聊的这个项目—— bobazooba/xllm ，就是为了解决这些痛点而生的。它不是一个新模型，而是一个专门为 本地大语言模型推理与部署 设计的Python框架。你可以把它理解为一个“开箱即用”的工具箱，它把从模型下载、加载、量化、推理到提供API服务、搭建Web UI这一整套繁琐流程，用统一的、高度可配置的方式封装了起来。它的核心目标很明确： 让开发者和研究者能够以最低的认知成本和最少的代码，快速、高效地在自己的机器上运行起一个功能完备的大语言模型服务。

这个项目特别适合以下几类人：一是AI应用开发者，想快速集成本地LLM能力到自己的产品中，不想深陷底层细节；二是研究者或学生，需要频繁切换和测试不同模型，需要一个稳定的实验环境；三是技术爱好者，对本地运行大模型感兴趣，但被复杂的配置劝退。 xllm 通过其模块化设计和丰富的预设配置，试图成为这个领域的“瑞士军刀”。

2. 核心设计哲学：模块化、配置驱动与生产就绪

2.1 为什么是“框架”而非“脚本”？

市面上有很多运行本地LLM的“一键脚本”或“工具”，那 xllm 的独特价值在哪里？关键在于它从设计之初就遵循了 框架 的思维。一个脚本解决一个特定问题（比如用某个特定参数运行某个特定模型），而一个框架提供了一套可扩展的 架构 和 约定 ，让你能系统性地解决一类问题。

xllm 将整个LLM服务生命周期抽象为几个清晰的核心模块：

  1. 模型加载器 ：负责从Hugging Face Hub或本地路径识别、下载、加载模型。它内部处理了复杂的逻辑，比如自动识别模型架构、选择正确的 transformers 类、处理分词器等。
  2. 量化与优化器 ：这是性能关键。框架集成了对 bitsandbytes （GPTQ、AWQ等）和 llama.cpp （GGUF格式）等主流量化方案的支持。你不需要手动去记那些复杂的量化命令和参数，只需在配置文件中指定量化类型（如 int4 ）和提供者（如 bitsandbytes ），框架会自动应用最优的加载策略。
  3. 推理引擎 ：这是模型“思考”的核心。它封装了生成文本的循环，支持流式输出（一个字一个字地往外蹦，体验更好）、控制生成参数（如 temperature , top_p , max_new_tokens ）。
  4. 服务层 ：这是让模型变得可用的接口。它提供了RESTful API（通常基于FastAPI），让你可以通过HTTP请求与模型对话；同时，它也常常集成一个轻量级的Gradio或类似技术的Web界面，让你在浏览器里就能直接聊天。

这种模块化的好处是巨大的。首先， 可维护性 极强，每个模块职责单一，出了问题容易定位。其次， 可扩展性 好，如果你想支持一个新的模型格式或量化方法，理论上只需要实现对应的加载器或量化器模块即可，而不必重写整个流程。最后， 可配置性 高，所有行为都通过一个中心化的配置文件（通常是YAML或JSON）来驱动，切换模型、调整参数就像改几行配置一样简单。

2.2 配置即代码：一切行为的源头

xllm 深度践行“配置即代码”的理念。一个典型的项目结构里，会有一个 config.yaml 文件，它可能长这样： 

model:
  name: “Qwen/Qwen2-7B-Instruct”
  revision: “main”
  quantization: “awq”
  device_map: “auto” # 自动分配模型层到GPU/CPU

server:
  host: “0.0.0.0”
  port: 8000
  api_prefix: “/v1”
  enable_webui: true

generation:
  max_new_tokens: 512
  temperature: 0.7
  top_p: 0.9
  do_sample: true

通过这样一份配置文件，你清晰地定义了要运行什么模型、如何量化、服务怎么开、生成文本的风格如何。当你需要从Qwen切换到Llama，或者从7B模型切换到14B模型时，你通常只需要修改 model.name 这一行，然后重启服务。这种将“做什么”和“怎么做”分离的设计，极大地降低了使用门槛和操作风险。

注意 ：配置文件的具体键名和结构可能因 xllm 的不同版本或分支而略有差异，但其核心思想是共通的。在实际使用前，务必查阅项目 README 或示例配置，理解其最新的配置规范。

2.3 面向生产环境的设计考量

很多个人项目在本地跑通就结束了，但 xllm 考虑得更多。它的一些特性显露出其“生产就绪”的野心：

  • 健康检查端点 ：一个运行良好的生产服务需要能被监控。 xllm 提供的API服务通常会包含一个 /health 或 /ready 端点，供外部系统（如Kubernetes、负载均衡器）探测服务状态。
  • 日志与监控 ：框架会结构化的输出日志，记录模型加载进度、推理耗时、请求频率等信息，方便集成到ELK、Prometheus等监控体系中。
  • 资源管理 ：通过 device_map 等配置，可以精细控制模型在多个GPU甚至CPU上的分布，优化内存使用和计算效率。
  • 安全与速率限制 ：虽然基础版本可能不内置复杂的安全特性，但其基于FastAPI等现代Web框架的架构，使得集成API密钥认证、请求速率限制等中间件变得非常容易。

这些特性使得 xllm 不仅适用于个人玩具项目，也具备了支撑小型团队内部AI工具或特定垂直领域应用的后端服务潜力。

3. 从零开始：手把手部署你的第一个本地LLM服务

理论说了这么多，我们来点实际的。假设你有一台配备至少8GB显存（例如RTX 3070/4060或同等级别）的NVIDIA显卡的电脑，我们将一步步使用 xllm 部署一个聊天模型。

3.1 环境准备与依赖安装

第一步是搭建一个干净、可控的Python环境。强烈建议使用 conda 或 venv 创建虚拟环境，避免包冲突。 

# 使用 conda 创建环境（推荐）
conda create -n xllm-env python=3.10
conda activate xllm-env

# 或者使用 venv
python -m venv xllm-env
source xllm-env/bin/activate  # Linux/Mac
# xllm-env\Scripts\activate  # Windows

接下来，安装 xllm 。由于它可能不是一个通过 pip install xllm 就能直接获取的官方包（具体取决于作者发布方式），我们通常需要从源码安装。 

# 克隆仓库
git clone https://github.com/bobazooba/xllm.git
cd xllm

# 安装依赖和框架本身
pip install -e .  # “-e”代表可编辑模式，方便后续修改和调试
# 或者根据项目要求安装
pip install -r requirements.txt

这里有一个关键的 实操心得 ：大模型相关的依赖，特别是 torch （PyTorch）和 transformers ，对版本非常敏感。 xllm 的 requirements.txt 或 setup.py 通常会指定兼容的版本。如果安装后运行出错，首先检查这些核心包的版本是否匹配。一个常见的技巧是，先去PyTorch官网根据你的CUDA版本获取正确的 torch 安装命令，先安装 torch ，再安装项目其他依赖。

3.2 模型选择与配置编写

环境好了，我们选一个模型。对于入门和8GB显存，一个经过4-bit量化的7B参数模型是理想选择。例如， Qwen2-7B-Instruct 的AWQ量化版，或者 Llama-3-8B-Instruct 的GPTQ量化版。这些模型在Hugging Face Model Hub上都能找到。

我们在项目根目录创建一个 config.yaml 文件： 

# config.yaml
model:
  # 从Hugging Face加载模型
  model_name_or_path: “Qwen/Qwen2-7B-Instruct-AWQ”
  # 使用AWQ量化（需要模型本身是AWQ格式）
  quantization: “awq”
  # 自动将模型分配到可用的GPU和CPU上
  device_map: “auto”
  # 使用bfloat16精度，兼顾速度和效果
  torch_dtype: “bfloat16”

server:
  # 服务绑定到所有网络接口
  host: “0.0.0.0”
  # 服务端口
  port: 7860  # Gradio常用端口
  # 启用Web UI
  enable_webui: true
  # Web UI类型，可能是gradio或自定义
  webui_type: “gradio”

generation:
  # 最大生成token数
  max_new_tokens: 1024
  # 温度，控制随机性。0.7是一个平衡值
  temperature: 0.7
  # 核采样参数，与temperature配合使用
  top_p: 0.95
  # 是否使用采样（否则是贪心解码）
  do_sample: true

关键参数解析 ：

  • device_map: “auto” ：这是 transformers 库的神奇功能。它会自动分析你的模型大小和可用硬件（GPU显存、CPU内存），尝试将模型层最优地分布上去。对于大于显存的模型，它会将一部分层放在CPU上，需要时再交换到GPU（速度会慢）。对于刚好能放入显存的模型，它会全部放在GPU上。
  • torch_dtype: “bfloat16” ：BF16是一种浮点数格式，在支持它的GPU（如Ampere架构及以后的NVIDIA GPU）上，能在几乎不损失精度的情况下大幅减少内存占用并提升计算速度。如果你的显卡不支持，可以改为 float16 。
  • quantization: “awq” ：这告诉框架，我们加载的模型文件是AWQ格式的。框架底层会调用 bitsandbytes 库以4-bit精度加载模型，从而将显存占用降低到原来的约1/4。 非常重要的一点 ：这个配置项必须与你下载的模型文件的实际量化格式严格对应。如果你下载的是GPTQ模型，这里就要写 gptq ；如果是GGUF，那么 xllm 可能会使用 llama.cpp 作为后端，配置方式会不同。

3.3 启动服务与初步验证

配置写好后，启动服务通常只需要一条命令。根据 xllm 的设计，可能会有一个主入口脚本，比如 app.py 或 serve.py 。 

python serve.py --config config.yaml

或者直接使用模块运行： 

python -m xllm.serve --config config.yaml

启动时，你会看到控制台输出大量日志。重点关注以下几个阶段：

  1. 加载分词器 ：很快完成。
  2. 加载模型 ：这里会耗时较长，你会看到进度条，显示正在从Hugging Face下载模型（如果本地没有缓存），或者从本地缓存加载。如果启用了量化，你会看到类似“Loading 4-bit quantized model…”的提示。
  3. 应用设备映射 ：你会看到类似“Moving model to device…”的日志，显示每一层被分配到了 cuda:0 （GPU）还是 cpu 。
  4. 启动服务 ：最后，你会看到“Application startup complete.”和“Uvicorn running on http://0.0.0.0:7860”这样的信息。

此时，打开浏览器，访问 http://localhost:7860 （如果你在本地运行），应该就能看到一个简洁的聊天界面了。输入“Hello, who are you?”，模型应该能给出一个连贯的自我介绍。

踩坑记录 ：第一次启动时最常见的错误是 内存不足 。如果加载过程中程序崩溃或报CUDA out of memory错误，说明你的显存放不下这个模型（即使量化了）。这时你需要尝试更小的模型（如3B参数模型），或者尝试更激进的量化（如果支持），或者使用 device_map 参数更精细地控制，将更多层放到CPU上（但这会严重影响速度）。另一个常见错误是 量化类型不匹配 ，比如配置写了 awq 但模型文件是 gptq ，这会导致加载失败，仔细检查模型卡页面上的说明。

4. 深入核心：模型加载、量化与推理优化详解

服务跑起来了，但作为开发者，我们有必要了解水面之下发生了什么。这能帮助我们在出现问题时进行调试，也能让我们更好地压榨硬件性能。

4.1 模型加载的“黑盒”与白盒化

xllm 的模型加载器简化了我们的操作，但其内部流程是标准的：

  1. 模型识别 ：根据 model_name_or_path ，框架首先检查是否是本地路径。如果不是，则视为Hugging Face模型ID，准备从网络下载。
  2. 配置读取 ：它会从模型仓库下载 config.json 文件。这个文件定义了模型的架构（是Llama还是Qwen）、层数、隐藏层大小、注意力头数等超参数。 transformers 库根据这个配置实例化对应的模型类。
  3. 权重加载 ：根据配置和量化设置，加载对应的模型权重文件（ .safetensors 或 .bin ）。如果是量化模型， bitsandbytes 会在此介入，将4-bit的权重在加载时动态反量化为计算所需的精度（如BF16）。
  4. 分词器加载 ：同时加载对应的 tokenizer.json 或 tokenizer.model 文件。分词器将文本转换为模型能理解的token ID序列，反之亦然。

一个重要的注意事项 ：Hugging Face的模型缓存默认在 ~/.cache/huggingface/hub 。如果你磁盘空间紧张，或者想指定缓存位置，可以通过设置环境变量 HF_HOME 来改变。 

# 在启动服务前设置
export HF_HOME=“/your/custom/path”

4.2 量化技术选型：GPTQ、AWQ与GGUF

xllm 可能支持多种量化后端，理解它们的区别对性能影响很大。

量化方案 核心原理 优点 缺点 典型文件后缀 常用工具
GPTQ 基于二阶信息（Hessian矩阵）逐层对权重进行量化，精度损失小。 精度高，推理速度快（尤其是与ExLlama等定制推理器配合）。 量化过程（校准）非常耗时，需要大量数据。 .safetensors , .pt AutoGPTQ , exllamav2
AWQ 识别并保护模型中最重要的权重（通过激活尺度判断），只对次要权重进行量化。 量化速度快，在保持高精度的同时，对激活值也友好。 相对较新的技术，社区生态稍弱于GPTQ。 .safetensors autoawq
GGUF Llama.cpp团队推出的格式，将权重和模型架构信息统一封装。量化粒度非常灵活。 内存效率极高，纯CPU推理友好，跨平台支持好（有Metal、CUDA、OpenCL后端）。 通常需要转换原始模型，推理速度可能略低于GPU原生方案。 .gguf llama.cpp , ollama

如何选择？

  • 追求极致GPU推理速度 ：选择 GPTQ 或 AWQ 格式的模型，并使用对应的 bitsandbytes 加载。确保你的 xllm 配置中 quantization 参数正确。
  • 显存极其有限或主要用CPU ：选择 GGUF 格式的模型（如 q4_0 , q5_k_m 等）。这时 xllm 可能会调用 llama.cpp 的Python绑定（如 llama-cpp-python ）作为后端。你需要确保安装了 llama-cpp-python 并正确配置了其编译后端（CUDA、Metal等）。
  • 简单省事 ：对于大多数入门用户，从Hugging Face上找下载量大的、标注清晰的 *-AWQ 或 *-GPTQ 模型是一个稳妥的选择。

4.3 推理参数调优：控制模型的“创造力”

Web UI上那些温度、Top-p滑块不是摆设，它们直接控制着模型输出的质量和风格。

  • max_new_tokens ：单次回复的最大长度。设得太短，回答可能不完整；设得太长，浪费计算资源且可能生成冗余内容。对于对话，512-1024通常足够。对于长文生成，可能需要2048或更多。
  • temperature ： 控制随机性的核心参数 。
    • temperature = 0 ：模型总是选择概率最高的下一个token（贪心搜索）。输出确定性强，但容易重复、枯燥。
    • temperature = 0.7 ~ 0.9 ：常用范围。增加一些随机性，使输出更有创意、更自然。是聊天和创意写作的推荐设置。
    • temperature > 1.0 ：随机性过高，输出可能变得不连贯、荒谬。
  • top_p (核采样) ：与temperature配合使用。它设定一个概率累积阈值，只从概率累积和达到 top_p 的token中采样。例如 top_p=0.9 ，模型会从概率最高的token开始累加，直到总和达到0.9，然后只从这个集合里采样。这能动态地限制候选词范围，避免采样到那些概率极低的奇怪token。
  • do_sample ：必须设为 True ，上述 temperature 和 top_p 才会生效。如果设为 False ，则使用贪心或beam search。

个人经验 ：对于事实性问答，我会用较低的 temperature （0.3-0.5）和较高的 top_p （0.95），让回答更准确、集中。对于写故事或诗歌，我会把 temperature 调到0.8-1.0， top_p 调到0.9，给模型更多“放飞自我”的空间。多试几次，找到适合你任务的“甜点”。

5. 进阶应用：集成API、定制化与性能监控

当基础服务稳定后，我们可能会想把它集成到自己的应用里，或者进行一些定制化开发。

5.1 将LLM服务集成到你的应用

xllm 启动的API服务通常遵循OpenAI API的部分兼容格式，这大大降低了集成难度。假设服务运行在 http://localhost:8000 ，并开启了API（配置中可能 enable_webui: false , enable_api: true ）。

你可以使用 curl 或任何HTTP客户端进行调用： 

curl -X POST “http://localhost:8000/v1/chat/completions” \
  -H “Content-Type: application/json” \
  -d ‘{
    “model”: “Qwen2-7B-Instruct”, # 这里可能只是标识符，实际模型由服务决定
    “messages”: [
      {“role”: “system”, “content”: “You are a helpful assistant.”},
      {“role”: “user”, “content”: “Explain the concept of quantization in one sentence.”}
    ],
    “stream”: false,
    “max_tokens”: 150
  }’

更常见的是在Python代码中集成： 

import requests
import json

def ask_llm(question, api_url=“http://localhost:8000/v1/chat/completions”):
    payload = {
        “model”: “local-model”, # 模型名按服务配置来
        “messages”: [{“role”: “user”, “content”: question}],
        “temperature”: 0.7,
        “max_tokens”: 500,
    }
    response = requests.post(api_url, json=payload)
    if response.status_code == 200:
        result = response.json()
        return result[“choices”][0][“message”][“content”]
    else:
        return f“Error: {response.status_code}, {response.text}”

# 使用
answer = ask_llm(“什么是机器学习？”)
print(answer)

这种集成方式让你可以轻松地将强大的本地LLM能力嵌入到你的数据分析脚本、自动化工具、内部知识库系统或任何其他应用中。

5.2 模型与提示词定制化

xllm 作为一个框架，通常也预留了扩展点。

加载自定义模型 ：如果你有自己的微调模型（比如用LoRA在特定数据集上微调过的），只需要将模型文件（包含 config.json , model.safetensors , tokenizer.json 等）放到一个本地目录，然后在配置文件中将 model_name_or_path 指向这个目录的路径即可。框架的加载逻辑是通用的。

系统提示词定制 ：很多聊天模型遵循“System/User/Assistant”的多轮对话格式。你可以在启动服务时，通过配置或API请求中的 system 消息来设定模型的角色和行为准则。例如，如果你想让它扮演一个代码专家，可以在每次对话的 messages 列表开头加入： {“role”: “system”, “content”: “You are an expert Python programmer. Provide concise and correct code solutions.”} 。更高级的用法是修改服务端的默认提示词模板，这通常需要你深入研究 xllm 的源码中与对话模板相关的部分。

5.3 性能监控与日志分析

对于长期运行的服务，了解其健康状况和性能瓶颈至关重要。

  • 查看日志 ： xllm 基于的Web框架（如FastAPI）会有访问日志。更关键的是模型推理本身的日志。你可能会在日志中看到每次推理的耗时。例如： 

    INFO - Generation time: 2.34s for 45 tokens (19.2 tokens/s)

    这个“tokens/s”（每秒生成token数）是衡量推理速度的核心指标。它受模型大小、量化程度、GPU型号、生成参数（如 max_new_tokens ）影响。

  • 资源监控 ：在Linux/Mac上，可以使用 nvidia-smi （针对GPU）和 htop （针对CPU/内存）来实时监控资源使用情况。关注GPU显存占用是否稳定，以及GPU利用率（Volatile GPU-Util）在推理时是否达到较高水平（如70%以上），这表示计算资源被充分利用。

  • 常见性能瓶颈与优化 ：

    1. 首次生成慢 ：这是正常的，因为模型需要初始化KV Cache（键值缓存）。后续生成会快很多。
    2. 生成速度慢 ：如果tokens/s很低（比如小于10），可能的原因有：模型部分层被放在了CPU上（检查 device_map 日志）；GPU本身性能较弱；或者你正在使用 llama.cpp 的CPU模式。
    3. 内存缓慢增长 ：可能是由于内存碎片或缓存未及时清理。确保你的Web框架（如Uvicorn）工作进程数设置合理（通常1个就够了，因为模型本身是内存大户），过多的进程会复制多份模型，导致内存爆炸。

6. 避坑指南与疑难杂症排查

即使有了好用的框架，在实际操作中依然会遇到各种问题。下面是我在多次部署中总结的一些典型问题及其解决方案。

6.1 安装与依赖问题

  • 问题 ：安装 bitsandbytes 或 llama-cpp-python 时编译失败。

    • 原因 ：这些包包含C++/CUDA扩展，需要本地编译环境。
    • 解决 ：
      • Linux ：安装 build-essential 和 python3-dev 。
      • Windows ：安装Visual Studio Build Tools（带C++桌面开发工作负载）。
      • 通用 ：尝试使用预编译的wheel。对于 llama-cpp-python ，可以使用 pip install llama-cpp-python --extra-index-url https://abetlen.github.io/llama-cpp-python/whl/cu121 （根据你的CUDA版本调整 cu121 ）来安装预编译版。对于 bitsandbytes ，可以去其GitHub Release页面寻找对应你系统和CUDA版本的wheel文件。

  • 问题 ： ImportError: cannot import name ‘...’ from ‘transformers’ 。

    • 原因 ： transformers 库版本不兼容。 xllm 可能依赖于较新或较旧的特定API。
    • 解决 ：严格按照项目 requirements.txt 或 setup.py 中指定的版本安装。使用 pip install transformers==x.x.x 进行版本锁定。

6.2 模型加载与运行时问题

  • 问题 ： CUDA out of memory.

    • 原因 ：显存不足。这是最常见的问题。
    • 排查与解决 ：
      1. 检查模型大小 ：一个7B参数的FP16模型约占用14GB显存。4-bit量化后理论上约3.5GB，但加上激活值（activations）和KV缓存，可能需要5-6GB。用 nvidia-smi 查看其他进程是否占用了显存。
      2. 调整 device_map ：尝试更保守的策略，如 device_map: “balanced” 或显式指定 device_map: {“”: “cpu”} 先将所有层放CPU，再手动将部分层移回GPU（如果框架支持）。最直接的是换更小的模型。
      3. 调整 max_new_tokens 和 batch_size ：在API请求中，减少单次生成的最大长度。如果服务支持批处理，确保批处理大小设为1。
      4. 启用内存优化 ：在配置中寻找类似 use_cache , offload_folder 等参数。 use_cache=False 可以节省一些内存但会变慢； offload_folder 可以将CPU卸载的层存到磁盘。

  • 问题 ：加载模型时卡住或报错 KeyError: ‘...’ 。

    • 原因 ：模型文件损坏，或模型配置文件与 transformers 库版本不兼容。
    • 解决 ：
      1. 删除Hugging Face缓存目录下的对应模型文件（位于 ~/.cache/huggingface/hub/models--org--model-name ），重新下载。
      2. 检查模型仓库的 config.json ，看是否有特殊的、当前 transformers 版本不支持的字段。可以尝试升级或降级 transformers 版本。

  • 问题 ：Web UI可以访问，但发送消息后无响应或报错。

    • 排查 ：
      1. 查看服务端日志 ：这是最重要的调试信息源。错误信息会直接打印在控制台。
      2. 检查API端点 ：用 curl 直接测试API端点（如 /v1/chat/completions ），看是否返回更具体的错误信息。
      3. 检查网络和端口 ：确保防火墙没有阻止端口。如果服务绑定在 127.0.0.1 ，则只能从本机访问；绑定在 0.0.0.0 才能从局域网访问。

6.3 内容生成质量问题

  • 问题 ：模型回答胡言乱语、重复或无法停止。
    • 原因 ：生成参数设置不当，或模型本身在微调/量化过程中产生了问题。
    • 解决 ：
      1. 调整 temperature 和 top_p ：降低 temperature （如0.2）并设置 top_p （如0.9）可以增加确定性。
      2. 使用重复惩罚 ：在配置或请求参数中寻找 repetition_penalty （通常>1.0，如1.2），它可以降低重复token的概率。
      3. 设置停止词 ：在请求参数中加入 stop 字段，指定一些停止序列，例如 [“\n\n”, “Human:”] ，当模型生成这些序列时自动停止。
      4. 检查模型本身 ：尝试同一个模型家族的不同量化版本，或者换一个基准模型（如从Qwen换到Llama），看问题是否依然存在。

最后，保持耐心和探索精神。本地大模型部署是一个涉及软件栈、硬件和模型本身的复杂工程。 bobazooba/xllm 这样的框架已经为我们扫清了许多障碍，但理解和解决这些底层问题，能让你真正掌控这项技术，并将其灵活地应用到你的具体场景中去。每一次错误的解决，都是对这套技术栈更深的理解。

Logo
乐奇 Rokid 开放社区

更多推荐

在 Rokid AI Glasses 上做背单词应用：AIUI拍照听写的实现

分享在 Rokid AI Glasses 上用 AIUI 开发背单词应用的实践：从镜腿单击拍照、图片编码和多模态识别，到切题时的异步任务处理、语音调度与学习进度保存，结合关键代码和界面动图说明实现过程。

avatar 乐奇 Rokid 开放社区
cover

极刻觅镜 | AI眼镜周报｜智能眼镜周报：销售高增长、标准落地与新品密集发布

avatar 乐奇 Rokid 开放社区
cover

极刻觅镜 | AI眼镜日报｜Rokid无人店落地香港，中科创达发布Veda平台

avatar 乐奇 Rokid 开放社区