lili Blog

再见前后端分离！我用 AI 一个人“合围”了软件工程

Wed, 13 May 2026 00:00:00 +0000

再见前后端分离！我用 AI 一个人卷死了传统团队

—— 告别高昂的“沟通税”：一场关于超级个体的效率回归实验

小时候读《三国演义》，开篇那句话总觉得气势磅礴：“天下大势，合久必分，分久必合。” 那时候以为这是写给帝王将相看的史诗。后来自己从全栈开发做到大型项目的PMO，又开始折腾属于自己的 AI 工作室，才在无数个联调到吐血的深夜恍然大悟——罗贯中这老头，分明是个看透了系统架构的顶级程序员穿越回去的。

这八个字，写的哪是历史？分明就是软件工程的命。

01. 缘起：在两条战线的“极限拉扯”中闭环

最近一个月，我过得异常“激荡”。我正试图用 AI，一个人撑起一间专注软件研发的科技工作室。目前，我的精力和代码正疯狂倾注在两条截然不同的战线上：

ToC 的“尖刀”： 结合我自己做科技岗与体制内求职辅导时洞察到的痛点，我单枪匹马开发了一款求职类效率产品，针对性地做突破。为了这把“尖刀”，我单月提交的代码量突破了数十万行，等解决了支付的问题会正式上线。
ToB 的“阵地”： 同时，我还要负责工作室承接的几个面向高校和科研院所的B端系统交付，面对的是极其硬核且复杂的数据流转业务。

在这些真刀真枪的业务磨砺中，我的工作流进化到了一个极为纯粹的境界：没有前端，没有后端，没有产品经理，甚至没有那个永远在吵架的“协作群”。从需求拆解、架构设计、数据库建模，一路干到打包部署。全链路，一人闭合。这种感觉，像极了我在《2025年终总结》里提到的那种“亲手造引擎”的快感。

听起来像吹牛？为了验证这不是我的幸存者偏差，我专门搞了个“对照实验”。

02. 试炼：一场关于“沟通税”的残酷拆解

我将项目分成了两组赛道：一组是我的“兼职正规军”：前后端分离，角色齐全，流程规范。看起来西装革履，非常专业。另一组是我的“AI 游击队”：全链路 AI 接入，我一人闭环。

我就坐在监工位上，看着两组项目赛跑。结果出来后，我陷入了长久的沉思，甚至觉得有点对不起那些天天开会到深夜的同行。

传统组：时间，在缝隙中被“税”掉了 团队里没人摸鱼，大家都很努力。但软件开发最大的谎言就是：“明天联调。” 加一个简单的字段，前端等后端改接口，后端改完要重启服务，重启完了测试说环境又崩了。一个芝麻大的改动，在三个人之间转了一圈，半天时间凭空消失。那些足以让项目经理心梗的对话，每天都在上演： “这个字段叫 userName 还是 user_name？” “Swagger 上的文档是上周的还是刚才的？” “跨域了！是你Nginx没配好，还是我Header没传对？”

每一句对话背后，都是真实流失的金钱。联调沟通花掉的时间，往往是写代码本身的三倍。前后端分离原本是为了快，最后却变成了——大家都在为低效的协作缴纳高昂的“沟通税”。

AI 组：没有队友，原来可以这么爽 切换到我独立操盘的 AI 组，世界清净了。前端和后端在同一个工程里，数据模型和业务逻辑在同一个脑子里转。我不需要写给“另一个人”看的文档，因为那个人就是我自己。想改就改，改完即生效，沟通成本为零。 AI 承包了所有极端的边界处理和冗长的类型定义，而我成了那个拥有“外骨骼”的指挥官。几个中小型项目跑下来，我一个人的交付节奏，比两人团队快了将近 2 倍。不是因为我天赋异禀，而是我把“协作损耗”从系统中物理切除了。

03. 觉醒：为什么是现在？为什么是“合”？

“一人全栈”是开发者的古老梦想，但在十年前，那是“个人英雄主义”的苦力活。那时，前端框架一年换三套，后端架构门派林立，数据库、运维、安全，每一块都能耗尽一个人的精力。

但 AI 来了以后，这道题的解法变了。现在的“合”，不是因为我们变弱了，而是因为 AI 补齐了我们的短板：

遇到生僻的算法，AI 是随叫随到的资深顾问；
面对枯燥的 CRUD，AI 是从不抱怨的超级实习生；
遇到复杂的服务器部署，AI 是精通指令的运维专家。

复盘技术史，这真是一个有趣的轮回：最早是“合”：工具简陋，只能一个人硬扛，那是没得选；后来是“分”：项目规模爆炸，不得不拆成流水线，但也随之产生了高昂的“沟通税”；现在又回到“合”：AI 把个人生产力直接拉到了天花板，小而美的“一体化闭环”，重新在效率上降维打击了流水线分工。

这一次的“合”，是基于强大的工具，重塑了超级个体的边界。

04. 展望：在人迹罕至的路上，构建自己的引擎

回望这段时间的尝试，正如我之前在分享中反复回响的诗句： “林中有两条路，我选择了人迹更少的那一条，而这让一切都截然不同。”

前后端分离没错，它是上一个时代的满分答案。但 AI 时代的超级个体，并不是在开历史倒车。我们是在用一种全新的耦合方式，重新定义交付的效率。

我这间 AI 工作室，写的是落地的代码，解的是真实的痛点。我不卖课，只做真实的交付。

如果你是创业者： 有灵感但怕被传统开发的“重”拖累，我们可以聊聊，用轻量化的方式让创新落地。
如果你是甲方或项目负责人： 想要交付得轻一点、快一点、沟通少一点，这里有一个不一样的答案。

我已不再是那个在岸边看潮起潮落的人。我已经跳进了海里，通过自己的经验与思考，用 AI 探索超级个体的上限。

道阻且长，行则将至。 2026，继续在人迹更少的路上，折腾，生长。觉得有意思，点个关注，咱们评论区见。

🚀 实战进阶：将 ComfyUI 封装为 AI 视频生成网站 (FastAPI + WebUI)

Mon, 20 Oct 2025 00:00:00 +0000

🚀 实战进阶：将 ComfyUI 封装为 AI 视频生成网站 (FastAPI + WebUI)

背景： 在上一篇文章中，我们已经在 Ubuntu 服务器 (RTX 4090) 上成功部署了 ComfyUI 并跑通了 Wan2.1 文生视频工作流。但 ComfyUI 原生界面太复杂，不适合直接丢给最终用户使用。

目标： 我们要构建一个“业务网关”，包含：

后端 (FastAPI)：封装 ComfyUI 的 API，将复杂的 ComfyUI 工作流封装为干净、标准的 RESTful API，供上游服务 (如RuoYi) 调用。
运行环境: 独立 Python venv (fastapi_venv)
前端 (HTML/JS)：提供一个清爽的 Web 界面，用户只需输入提示词即可生成视频。
依赖服务: ComfyUI AI 引擎 (必须在 http://127.0.0.1:8188 运行)
架构：用户访问 -> FastAPI (9000端口) -> 内部转发 -> ComfyUI (8188端口)。

🛠️ 第一步：准备独立环境

为了保证环境纯净，我们不要复用 ComfyUI 的 venv，而是为 FastAPI 创建一个独立的虚拟环境。

创建并激活环境

Bash

cd ~/My-ComfyUI
python3 -m venv fastapi_venv
source fastapi_venv/bin/activate

安装依赖

Bash

pip install "fastapi[all]" uvicorn requests -i https://pypi.tuna.tsinghua.edu.cn/simple

📂 第二步：导出 API 工作流 (“菜谱”)

FastAPI 需要知道如何“指挥” ComfyUI。我们需要将工作流导出为 JSON 模板。

打开 ComfyUI 界面 (http://服务器IP:8188)。
加载 T2V 工作流：确保这是您调试通过的、包含 “Save Video” 节点的工作流。
- 注意：必须有 Save Video 节点，否则 FastAPI 无法捕获结果文件。
导出 API 格式：
- 点击右侧菜单的 “Save (API format)” 按钮。
- 下载 JSON 文件。
上传服务器：
- 将文件重命名为 t2v_api.json。
- 上传到服务器的 ~/My-ComfyUI/ 目录下。

💻 第三步：编写后端代码 (`api_server.py`)

在 ~/My-ComfyUI/ 目录下创建 api_server.py。这段代码实现了：

静态文件托管：让用户访问 http://IP:9000 就能看到网页。
API 转发：接收前端请求，注入提示词，调用 ComfyUI。
结果解析：智能解析 ComfyUI 复杂的输出路径，返回真实 URL。

Python

import uvicorn
import requests
import json
import uuid
from fastapi import FastAPI
from pydantic import BaseModel
from fastapi.middleware.cors import CORSMiddleware # 允许 RuoYi 前端跨域

# (!!!) 新增下面这一行导入 (!!!)
from fastapi.staticfiles import StaticFiles
from fastapi.responses import HTMLResponse

app = FastAPI()

# --- CORS 跨域设置 ---
# 允许所有来源 (生产环境您应该改成 RuoYi 的前端地址)
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"], 
    allow_credentials=True,
    allow_methods=["*"],
    allow_headers=["*"],
)

# (!!!) 新增以下代码 (!!!)

# 1. 挂载静态文件目录，这样前端才能访问 static 里的资源
app.mount("/static", StaticFiles(directory="static"), name="static")

# 2. 添加根路由，直接返回 index.html
@app.get("/", response_class=HTMLResponse)
async def read_root():
    with open("static/index.html", "r", encoding="utf-8") as f:
        return f.read()


# --- ComfyUI 配置 ---
COMFYUI_URL = "http://127.0.0.1:8188"
# (!!!) 新增此行 (!!!)
# 请将 [YOUR_SERVER_IP] 替换为您的公网 IP 或域名
PUBLIC_FACING_URL = "http://127.0.0.1:8188" # 返回给 RuoYi 时使用
# 启动时加载 API 工作流模板
try:
    with open("text_to_video_wan.json", "r", encoding="utf-8") as f:
        API_WORKFLOW_TEMPLATE = json.load(f)
    print("text_to_video_wan 加载成功。")
except FileNotFoundError:
    print("错误:text_to_video_wan.json 未找到！")
    API_WORKFLOW_TEMPLATE = None

# --- Pydantic 模型定义 ---
class T2VRequest(BaseModel):
    prompt: str
    negative_prompt: str = "low quality, worst quality, bad quality"

# --- 辅助函数：定位提示词节点 ---
def find_prompt_node_id(workflow_template):
    """在工作流 JSON 中自动查找 CLIP Text Encode 节点的 ID"""
    for node_id, node_data in workflow_template.items():
        if node_data.get("class_type") == "CLIP Text Encode (Simple)":
            # 假设第一个找到的是我们的目标
            return node_id, "positive" # "positive" 是该节点的输入字段名
        if node_data.get("class_type") == "CLIPTextEncode":
            # 兼容 ComfyUI 原生节点名
            return node_id, "text"
    return None, None # 如果找不到

# 动态查找 Positive 提示词节点的 ID 和字段
POSITIVE_NODE_ID, POSITIVE_FIELD_NAME = find_prompt_node_id(API_WORKFLOW_TEMPLATE)
if POSITIVE_NODE_ID:
    print(f"自动定位到 Positive 提示词节点 ID: {POSITIVE_NODE_ID}, 字段: {POSITIVE_FIELD_NAME}")
else:
    print("警告：无法自动定位 Positive 提示词节点！")


# --- API 端点 ---

@app.post("/api/v1/generate-video")
def queue_generation(request: T2VRequest):
    """
    1. 接收 RuoYi 的请求，排队任务
    2. 返回任务 ID
    """
    if not API_WORKFLOW_TEMPLATE:
        return {"error": "服务器工作流模板未加载"}, 500

    if not POSITIVE_NODE_ID:
        return {"error": "服务器工作流配置错误，找不到提示词节点"}, 500

    # 1. 复制模板并注入提示词
    workflow = API_WORKFLOW_TEMPLATE.copy()
    workflow[POSITIVE_NODE_ID]["inputs"][POSITIVE_FIELD_NAME] = request.prompt

    # (可选) 注入负面提示词 (需要您自己找到负面节点的 ID)
    # workflow["NEGATIVE_NODE_ID"]["inputs"]["text"] = request.negative_prompt

    # 2. 准备 payload
    client_id = str(uuid.uuid4())
    payload = {"prompt": workflow, "client_id": client_id}

    # 3. 调用 ComfyUI 的 /prompt 接口
    try:
        response = requests.post(f"{COMFYUI_URL}/prompt", json=payload)
        response.raise_for_status()
        data = response.json()

        if 'prompt_id' not in data:
            return {"error": "ComfyUI 未返回 prompt_id", "details": data}, 500

        return {
            "status": "queued",
            "task_id": data['prompt_id']
        }

    except requests.RequestException as e:
        return {"error": f"调用 ComfyUI 失败: {str(e)}"}, 503


@app.get("/api/v1/status/{task_id}")
def get_task_status(task_id: str):
    """
    1. 接收 RuoYi 的轮询请求
    2. 检查 ComfyUI 的 /history 接口
    3. (最终修正版) 查找 'outputs' -> 'node' -> 'images' -> list -> 'filename' & 'subfolder'
    """
    try:
        # 1. 调用 ComfyUI 的 /history 接口
        response = requests.get(f"{COMFYUI_URL}/history/{task_id}")
        response.raise_for_status()
        data = response.json()

        # 2. 检查 history
        if task_id not in data:
            # 任务还在队列中，尚未开始执行
            return {"status": "pending"}

        history = data[task_id]

        # 3. 检查是否有错误
        if 'status' in history and history['status'].get('exception'):
            return {"status": "error", "message": history['status']['exception'][1]}

        # 4. 检查是否已完成
        if 'outputs' in history:
            outputs = history['outputs']
            video_files = []
            
            # 遍历所有节点的输出 (outputs.values() 会返回 "50": {...} 里的内容)
            for node_output in outputs.values():
                
                # 这是我们从您的 JSON 中找到的精确路径
                if 'images' in node_output:
                    for image_data in node_output['images']:
                        # 确保这是一个已保存的 "output" 类型文件
                        if image_data.get('type') == 'output':
                            filename = image_data.get('filename')
                            subfolder = image_data.get('subfolder')
                            
                            if filename:
                                # 构建 ComfyUI /view 接口能识别的 URL
                                video_url = f"{PUBLIC_FACING_URL}/view?filename={filename}&type=output"
                                
                                # 如果有子目录，必须加上 subfolder 参数
                                if subfolder:
                                    video_url += f"&subfolder={subfolder}"
                                    
                                video_files.append(video_url)
            
            if video_files:
                # 去重，以防万一
                unique_video_files = list(set(video_files))
                return {
                    "status": "complete",
                    "video_urls": unique_video_files
                }
            else:
                # 如果还是没找到 (几乎不可能了)，返回一个错误
                return {"status": "complete_no_files_found_in_history_FINAL"}

        # 5. 如果都对不上，说明还在运行
        return {"status": "running"}

    except requests.RequestException as e:
        return {"error": f"调用 ComfyUI 失败: {str(e)}"}, 503


if __name__ == "__main__":
    print("启动 FastAPI 服务器在 0.0.0.0:9000")
    uvicorn.run(app, host="0.0.0.0", port=9000)

关键配置项 (api_server.py)

在 api_server.py 文件的顶部，有两个关键配置项需要您根据环境修改：

COMFYUI_URL
- 用途: FastAPI 内部调用 ComfyUI 引擎的地址。
- 值: http://127.0.0.1:8188
- 备注: 必须使用 127.0.0.1，确保服务间走内网通信，效率最高。
PUBLIC_FACING_URL
- 用途: 在 GET /status/{task_id} 接口返回给调用方 (RuoYi) 的 URL 中，用于拼接视频地址。
- 值: http://[YOUR_SERVER_IP]:8188 或 https://[YOUR_DOMAIN.COM]
- 备注: 这里必须填写服务器的公网 IP 或域名，否则 RuoYi 前端将无法访问视频。

🎨 第四步：编写前端页面 (`static/index.html`)

创建目录：mkdir -p ~/My-ComfyUI/static
创建文件：nano ~/My-ComfyUI/static/index.html
粘贴以下极简风格的代码：

HTML

<!DOCTYPE html>
<html lang="zh-CN">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Wan2.1 视频生成工坊</title>
    <style>
        :root { --primary: #2563eb; --bg: #f8fafc; --card: #ffffff; }
        body { font-family: 'Segoe UI', sans-serif; background: var(--bg); color: #1e293b; display: flex; justify-content: center; padding: 40px 20px; }
        .container { width: 100%; max-width: 600px; background: var(--card); padding: 30px; border-radius: 16px; box-shadow: 0 10px 25px rgba(0,0,0,0.05); }
        h1 { margin-top: 0; font-size: 24px; color: #0f172a; text-align: center; margin-bottom: 30px; }
        
        .form-group { margin-bottom: 20px; }
        label { display: block; margin-bottom: 8px; font-weight: 600; font-size: 14px; }
        textarea { width: 100%; height: 100px; padding: 12px; border: 2px solid #e2e8f0; border-radius: 8px; font-size: 16px; resize: vertical; transition: border 0.2s; box-sizing: border-box;}
        textarea:focus { border-color: var(--primary); outline: none; }
        
        button { width: 100%; padding: 14px; background: var(--primary); color: white; border: none; border-radius: 8px; font-size: 16px; font-weight: 600; cursor: pointer; transition: opacity 0.2s; }
        button:hover { opacity: 0.9; }
        button:disabled { background: #94a3b8; cursor: not-allowed; }

        .status-box { margin-top: 20px; padding: 15px; background: #f1f5f9; border-radius: 8px; font-size: 14px; display: none; }
        .status-box.active { display: block; }
        .loader { display: inline-block; width: 12px; height: 12px; border: 2px solid #64748b; border-radius: 50%; border-top-color: transparent; animation: spin 1s linear infinite; margin-right: 8px; }
        @keyframes spin { to { transform: rotate(360deg); } }

        .video-result { margin-top: 20px; display: none; }
        video { width: 100%; border-radius: 8px; box-shadow: 0 4px 6px -1px rgba(0, 0, 0, 0.1); }
        .download-link { display: block; text-align: center; margin-top: 10px; color: var(--primary); text-decoration: none; }
    </style>
</head>
<body>

<div class="container">
    <h1>🎬 Wan2.1 文生视频工坊</h1>
    
    <div class="form-group">
        <label for="prompt">提示词 (Prompt)</label>
        <textarea id="prompt" placeholder="例如：An astronaut walking on the moon, cinematic lighting, 4k">An astronaut walking on the moon</textarea>
    </div>

    <button id="generateBtn" onclick="startGeneration()">✨ 开始生成视频</button>

    <div id="statusBox" class="status-box">
        <span class="loader" id="loader"></span>
        <span id="statusText">准备就绪</span>
    </div>

    <div id="videoContainer" class="video-result">
        <label>生成结果：</label>
        <video id="videoPlayer" controls loop autoplay muted></video>
        <a id="downloadLink" href="#" target="_blank" class="download-link">下载视频</a>
    </div>
</div>

<script>
    // 这里填写您的 FastAPI 地址 (如果就在当前页面访问，留空或者是相对路径即可)
    // 由于我们是同源托管，直接用相对路径 "/api/v1"
    const API_BASE = "/api/v1";

    let checkInterval = null;

    async function startGeneration() {
        const prompt = document.getElementById('prompt').value;
        if (!prompt) return alert("请输入提示词！");

        // UI 重置
        const btn = document.getElementById('generateBtn');
        const statusBox = document.getElementById('statusBox');
        const statusText = document.getElementById('statusText');
        const videoContainer = document.getElementById('videoContainer');
        const loader = document.getElementById('loader');

        btn.disabled = true;
        btn.innerText = "生成中...";
        statusBox.classList.add('active');
        videoContainer.style.display = 'none';
        loader.style.display = 'inline-block';
        statusText.innerText = "正在提交任务...";

        try {
            // 1. 提交任务
            const res = await fetch(`${API_BASE}/generate-video`, {
                method: 'POST',
                headers: { 'Content-Type': 'application/json' },
                body: JSON.stringify({ prompt: prompt })
            });

            const data = await res.json();
            if (data.error) throw new Error(data.error);
            
            const taskId = data.task_id;
            statusText.innerText = `任务已提交 (ID: ${taskId.slice(0,8)}...)，正在排队...`;

            // 2. 开始轮询
            checkInterval = setInterval(() => checkStatus(taskId), 3000);

        } catch (e) {
            showError(e.message);
        }
    }

    async function checkStatus(taskId) {
        const statusText = document.getElementById('statusText');
        
        try {
            const res = await fetch(`${API_BASE}/status/${taskId}`);
            const data = await res.json();

            if (data.status === 'running') {
                statusText.innerText = "🚀 AI 正在努力生成中... (这可能需要几十秒)";
            } else if (data.status === 'pending') {
                statusText.innerText = "⏳ 正在排队等待 GPU 资源...";
            } else if (data.status === 'complete') {
                clearInterval(checkInterval);
                showSuccess(data.video_urls[0]);
            } else if (data.status === 'error') {
                clearInterval(checkInterval);
                showError(data.message || "生成失败");
            }
        } catch (e) {
            clearInterval(checkInterval);
            showError("网络连接错误");
        }
    }

    function showSuccess(url) {
        const btn = document.getElementById('generateBtn');
        const statusText = document.getElementById('statusText');
        const loader = document.getElementById('loader');
        const videoContainer = document.getElementById('videoContainer');
        const videoPlayer = document.getElementById('videoPlayer');
        const downloadLink = document.getElementById('downloadLink');

        btn.disabled = false;
        btn.innerText = "✨ 再生成一个";
        loader.style.display = 'none';
        statusText.innerText = "✅ 生成完成！";
        
        videoPlayer.src = url;
        downloadLink.href = url;
        videoContainer.style.display = 'block';
    }

    function showError(msg) {
        const btn = document.getElementById('generateBtn');
        const statusText = document.getElementById('statusText');
        const loader = document.getElementById('loader');
        
        clearInterval(checkInterval);
        btn.disabled = false;
        btn.innerText = "重试";
        loader.style.display = 'none';
        statusText.innerText = "❌ 错误: " + msg;
    }
</script>

</body>
</html>

整体文件结构

服务部署在 ~/My-ComfyUI 目录下：

Bash

~/My-ComfyUI/
├── api_server.py           # (核心) FastAPI 服务的主代码
├── t2v_api.json            # (核心) ComfyUI 导出的 API 格式工作流 "菜谱"
├── fastapi_venv/           # (环境) FastAPI 专用的 Python 虚拟环境
├── ComfyUI/                # (依赖) ComfyUI 引擎的完整目录
├── static/                 # (前端) FastAPI前端页面
└── venv/                   # (环境) ComfyUI 专用的 Python 虚拟环境

🚀 第五步：部署与运行

整体文件结构

Bash

~/My-ComfyUI/
├── api_server.py           # (核心) FastAPI 服务的主代码
├── t2v_api.json            # (核心) ComfyUI 导出的 API 格式工作流 "菜谱"
├── fastapi_venv/           # (环境) FastAPI 专用的 Python 虚拟环境
├── ComfyUI/                # (依赖) ComfyUI 引擎的完整目录
├── static/                 # (前端) FastAPI前端页面
└── venv/                   # (环境) ComfyUI 专用的 Python 虚拟环境

此服务与 ComfyUI 引擎一样，也需要使用 screen 在后台持久化运行。

进入 Screen 会话

Bash

screen -S fastapi

启动服务

Bash

cd ~/My-ComfyUI
source fastapi_venv/bin/activate  # 别忘了激活环境
python api_server.py

停止 / 重启服务 (最常用)

您需要更新代码 (如 api_server.py) 或工作流 (如 t2v_api.json) 时，必须重启此服务。

“重连”到 fastapi 会话：

Bash

screen -r fastapi

您会看到正在滚动的日志。按 Ctrl + C 停止当前服务。

重新启动服务：

Bash

# (此时应仍在 venv 中)
python api_server.py

验证与脱离
- 如果你看到 Uvicorn running on http://0.0.0.0:9000，说明启动成功。
- 按 Ctrl + A，然后松开，再按 D，让它在后台运行。

如何更新 AI 工作流

当您想调整 ComfyUI 的参数（例如更换模型、修改步数）时，必须同时更新此服务：

在 ComfyUI (浏览器):
- 打开 http://[服务器IP]:8188。
- 加载您的工作流，进行修改（例如，更换 KSampler 的步数）。
- 确保最后一步的 “Save Video” 节点被正确连接。
- 点击 “Save (API format)”，下载新的 .json 文件。
在服务器 (终端):
- 将新下载的 .json 文件上传到 ~/My-ComfyUI/ 目录。
- 覆盖（或替换）掉旧的 t2v_api.json 文件。
重启 FastAPI 服务:
- 按照 4.3 中的步骤（screen -r fastapi -> Ctrl+C -> python api_server.py …）重启服务。
- FastAPI 服务只在启动时加载一次 t2v_api.json，因此必须重启才能使新工作流生效。

🎉 最终效果

现在，打开您的浏览器，访问： http://[您的服务器IP]:9000

您将看到一个简洁的 AI 视频生成页面。输入提示词，点击生成，喝口水，视频就出来了！

🔧 运维小贴士

我要修改视频时长/步数怎么办？
1. 在 ComfyUI 浏览器界面修改参数。
2. 重新导出 t2v_api.json 并覆盖服务器上的文件。
3. screen -r fastapi -> Ctrl+C -> python api_server.py (重启 FastAPI 才能加载新配置)。
视频无法播放？ 请检查 api_server.py 中的 PUBLIC_FACING_URL 是否填写了正确的公网 IP。

🚀 实战入门：在服务器单卡部署 ComfyUI + Wan2.1 文生视频最佳实践

Fri, 10 Oct 2025 00:00:00 +0000

🚀 实战入门：在服务器单卡部署 ComfyUI + Wan2.1 文生视频最佳实践

背景： 公司新媒体同事用闭源工具烧钱烧到财务报警，素材还往外网扔，老板直接放话：“本地化，自己搞一个能文生视频的。”

目标： 在一台全新的 Ubuntu 服务器上，“傻瓜式”地部署 ComfyUI，用于 Wan2.1 文生视频 (T2V)。

核心原则：

环境隔离： 绝不污染系统 Python，使用 venv。
资源隔离： 绝不抢占其他服务（如 vLLM），指定 GPU 运行。
网络优化： 全程使用国内镜像加速。
稳定运维： 使用 screen 进行后台持久化运行。

📚 一、环境准备 (Prerequisites)

在开始之前，确保您的新服务器满足以下条件。

检查NVIDIA驱动与CUDA
- nvidia-smi
- 确保能看到显卡列表（如 4090）和 CUDA 版本（如 12.x）。
检查核心工具
- python3 --version (推荐 Python 3.10 或 3.11)
- git --version
- screen --version

(可选) 安装工具

如果缺少工具，运行：

Bash

sudo apt update
sudo apt install python3-venv git screen

组件	详情	检查命令
操作系统	Ubuntu (Linux)	`uname -a`
GPU	8 x NVIDIA GeForce RTX 4090	`nvidia-smi`
NVIDIA 驱动	570.124.06	`nvidia-smi`
CUDA 版本	12.8 (由驱动支持)	`nvidia-smi`
Python 版本	3.10.9	`python3 --version`
Git 版本	2.43.0	`git --version`

📦 二、项目安装与环境隔离 (v-e-n-v)

创建项目根目录：

Bash

cd ~
mkdir My-ComfyUI
cd My-ComfyUI

创建虚拟环境：

Bash

python3 -m venv venv

(关键!) 激活虚拟环境：

Bash
```
1
source venv/bin/activate
```
- 您的终端提示符前面会出现 (venv) 标记。

克隆 ComfyUI：

Bash

git clone https://github.com/comfyanonymous/ComfyUI.git
cd ComfyUI

此时，您应位于 ~/My-ComfyUI/ComfyUI 目录，且 (venv) 已激活。

🚀 三、安装依赖 (国内镜像加速)

(推荐) 升级 pip：

Bash

pip install --upgrade pip -i https://pypi.tuna.tsinghua.edu.cn/simple

(关键) 安装 PyTorch (cu121)：

使用中科大 (USTC) 镜像，它对 PyTorch 的 cuXXX 路径支持最好。

Bash

pip install torch torchvision torchaudio --index-url https://pypi.mirrors.ustc.edu.cn/pytorch-wheels/cu121

安装 ComfyUI 其它依赖：

使用清华 (Tsinghua) PyPI 镜像。

Bash

pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple

💾 四、下载 Wan2.1 (T2V) 核心模型

我们使用 hf-mirror.com 国内镜像，并用 wget -O 直接保存到正确目录。

下载 T2V 核心模型 (约 5.18 GB):

Bash

mkdir -p models/diffusion_models
wget -O models/diffusion_models/wan2.1_t2v_1.3B_fp16.safetensors \
https://hf-mirror.com/ali-vilab/wan2.1-t2v/resolve/main/diffusion_models/wan2.1_t2v_1.3B_fp16.safetensors

下载文本编码器 (约 6.27 GB):

Bash

mkdir -p models/text_encoders
wget -O models/text_encoders/umt5_xxl_fp8_e4m3fn_scaled.safetensors \
https://hf-mirror.com/ali-vilab/wan2.1-fun/resolve/main/text_encoders/umt5_xxl_fp8_e4m3fn_scaled.safetensors

下载 VAE (约 242 MB):

Bash

mkdir -p models/vae
wget -O models/vae/wan_2.1_vae.safetensors \
https://hf-mirror.com/ali-vilab/wan2.1-fun/resolve/main/vae/wan_2.1_vae.safetensors

🛠️ 五、安装 ComfyUI Manager (管理节点)

这是为了方便未来安装新的自定义节点。

进入 custom_nodes 目录：

Bash

cd ~/My-ComfyUI/ComfyUI/custom_nodes

克隆 Manager：

Bash

git clone https://github.com/ltdrdata/ComfyUI-Manager.git

(重要) 未来如何手动安装节点：

我们以 VideoHelperSuite 为例，这是“傻瓜”步骤：

Bash

# 1. 在 custom_nodes 目录克隆
git clone https://github.com/Kosinkadink/ComfyUI-VideoHelperSuite.git
   
# 2. 进入新节点目录
cd ComfyUI-VideoHelperSuite
   
# 3. (关键!) 激活 venv 并安装它的依赖
source ../../../venv/bin/activate
pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple
   
# 4. 回到 ComfyUI 根目录
cd ../..

🖥️ 六、部署与日常维护 (Screen)

1. 首次启动 (前台测试)

回到 ComfyUI 根目录：

Bash

cd ~/My-ComfyUI/ComfyUI

(关键!) 激活虚拟环境 (如果已失效)：

Bash

source ../venv/bin/activate

指定 GPU 6 启动：

Bash

CUDA_VISIBLE_DEVICES=6 python main.py --listen

在您本地电脑浏览器访问 http://[服务器IP]:8188。
拖入 T2V 工作流 (wan_t2v.json)，点击 “Queue Prompt” 测试。
测试成功后，在 SSH 终端按 Ctrl + C 停止。

2. 后台部署 (Screen)

创建一个名为 comfyui 的 screen 会话：

Bash

screen -S comfyui

您会进入一个“新”的终端。在这个新终端里，执行标准启动流程：

Bash

# 1. 进入目录
cd ~/My-ComfyUI/ComfyUI
   
# 2. 激活环境
source ../venv/bin/activate
   
# 3. 指定 GPU 6 启动 (这次不需要 &)
CUDA_VISIBLE_DEVICES=6 python main.py --listen
   
CUDA_VISIBLE_DEVICES=6 python main.py --listen --enable-cors

程序开始运行。现在，您可以“脱离”这个会话了。
- 按 Ctrl + A，然后松开，再按 D。
您会返回主终端，看到 [detached]。程序已在后台运行，您可以关闭 SSH 了。

3. 日常维护

如何重连会话 (查看日志/停止程序):

Bash
```
1
screen -r comfyui
```
- 您会瞬间跳回 ComfyUI 的日志界面。按 Ctrl + C 即可停止。
如何更新 ComfyUI:
1. screen -r comfyui (重连)
2. Ctrl + C (停止)
3. git pull (更新 ComfyUI 代码)
4. source ../venv/bin/activate (激活环境)
5. pip install -r requirements.txt -i ... (更新依赖)
6. CUDA_VISIBLE_DEVICES=6 python main.py --listen (重新启动)
7. Ctrl + A, D (脱离)
如何查看所有 screen 会话：

Bash
```
1
screen -ls
```

❓ 七、常见问题 (Q&A)

Q: 提示 Some Nodes Are Missing (缺少节点)?
- A: 见【五.3】。git clone 节点到 custom_nodes，然后 cd 进去 pip install -r requirements.txt。
Q: 我要 T2V，为什么提示我上传视频?
- A: 您拖入了错误的工作流 (如 wan2.1-fun.json)。T2V 请使用 wan_t2v.json 工作流。

🚀 实战部署：单卡4090跑通DeepSeek-OCR本地WebUI

Wed, 01 Oct 2025 00:00:00 +0000

🚀 实战部署：单卡4090跑通DeepSeek-OCR本地WebUI

大家好！我是李梨。

最近，我们想在本地的 4090 服务器上部署大名鼎鼎的 DeepSeek-OCR 模型，搭建一个内部的 WebUI 测试服务。我是个“小白”，本以为会很顺利，结果一路上遇到了各种“拦路虎”。

这篇文章就是把我们从 0 到 1 成功运行的完整步骤，以及（更重要的）所有报错和解决方案，原汁原味地记录下来。

如果你也是刚接触 AI 部署，这篇文章也许能帮你节省几个小时的“抓耳挠腮”时间！

第一章：基础环境准备 (The “Happy Path”)

我们的目标是使用一个社区的 DeepSeek-OCR-Web-UI 项目，它提供了一个 Gradio 界面，比较简单易用。

🛠️ 第 0 步: “三件套” 跑不了

在开始之前，确保你的 Linux 服务器（或本地电脑）装好了三样东西：

NVIDIA 驱动：确保 4090 显卡驱动是最新的。
Git：用于下载代码。（sudo apt install git）
Miniconda：Python 环境管理的“神器”，避免把你电脑的 Python 环境搞乱。

📦 第 1 步: 创建一个干净的 Python “沙盒”

我们使用 Conda 来创建一个专门给 OCR 用的环境，这里我们用 Python 3.12。

Bash

# 1. 创建一个叫 deepseek-ocr 的环境
conda create -n deepseek-ocr python=3.12 -y

# 2. 激活这个环境 (重要！后续所有命令都在这里执行)
conda activate deepseek-ocr

# 激活后，你的命令行前面会出现 (deepseek-ocr) 

🔥 第 2 步: 安装 PyTorch (适配 4090 的核心)

这是第一个关键点。4090 跑模型需要 CUDA，而 PyTorch 必须和 CUDA 版本匹配。我们选择一个稳定组合：PyTorch 2.6 + CUDA 11.8。

Bash

# 直接运行这整条命令
pip install torch==2.6.0 torchvision==0.21.0 torchaudio==2.6.0 --index-url https://download.pytorch.org/whl/cu118

安装完成后，立即检查 PyTorch 能否“看到”你的 4090 显卡：

Bash

python -c "import torch; print(f'CUDA 可用吗? {torch.cuda.is_available()}')"

[检查点]：你必须看到输出 CUDA 可用吗? True。如果是 False，停下来！检查你的 NVIDIA 驱动。

🧠 第 3 步: 下载模型本体

模型文件很大，我们用 modelscope 工具下载。

Bash

# 1. 安装下载工具
pip install modelscope

# 2. 下载模型 (注意！记住你下载的这个路径，后面要用)
# 我们把它下载到 /home/bjrbds/deepseek-ocr-model
modelscope download --model deepseek-ai/DeepSeek-OCR --local_dir /home/bjrbds/deepseek-ocr-model

🌐 第 4 步: 下载 WebUI 界面

Bash

# 1. 回到你的主目录
cd ~

# 2. 下载 WebUI 项目代码
git clone https://github.com/newlxj/DeepSeek-OCR-Web-UI.git

# 3. 进入项目文件夹
cd DeepSeek-OCR-Web-UI

🧩 第 5 步: 安装 WebUI 的依赖

Bash

# 1. 安装 requirements.txt 里写好的依赖
pip install -r requirements.txt

# 2. 单独安装 flash-attn (一个加速库)
pip install flash-attn==2.7.3 --no-build-isolation

✏️ 第 6 步: 告诉 WebUI 模型在哪

这是最后一步配置。编辑 start_ocr_webui.py 文件，告诉它我们第 3 步下载的模型路径。

Bash

vim start_ocr_webui.py

找到第 26 行左右，把 self.model_path 改成你自己的路径：

Python

# 原本:
# self.model_path = '/path/to/your/DeepSeek-OCR'

# 修改后 (使用你的真实路径):
self.model_path = '/home/bjrbds/deepseek-ocr-model'

保存并退出 (:wq)。

好了！按照“剧本”，我们现在应该可以运行了： python start_ocr_webui.py …然而，战斗才刚刚开始。

第二章：小白“踩坑”实录 (The “Real Path”)

我们遇到了 6 个拦路虎。如果你也遇到了，别慌，这里是答案。

🕳️ 坑 1: `ModuleNotFoundError: No module named 'typer'`

报错日志： import typer ModuleNotFoundError: No module named 'typer'

分析：很明显，requirements.txt 里漏掉了一个 Gradio 依赖的包。 ✅ 解决：手动装上它。

Bash

pip install typer

🕳️ 坑 2: `pip` 说”装了”，Python 说”没有”？

诡异现象：我运行 pip install typer，它提示 Requirement already satisfied (已经满足)。但我再运行 python start_ocr_webui.py，它还是报 No module named 'typer'！

分析：这是个经典的 Python 环境冲突。pip 在你的用户目录 (~/.local/lib...) 找到了 typer，就“偷懒”了。但我们 Conda 环境里的 Python 只在自己的环境目录 (~/.conda/envs/deepseek-ocr/lib...) 里找。

✅ 解决：强制 pip 在当前环境里重新安装。

Bash

pip install --ignore-installed typer

🕳️ 坑 3: `TypeError: argument of type 'bool' is not iterable`

报错日志：一长串 gradio 和 gradio_client 的报错，最后指向 TypeError: argument of type 'bool' is not iterable。

分析：这是 gradio 库的一个 Bug，它和我们用的 Python 3.12 或其他库不兼容。 ✅ 解决：升级 gradio 库到最新版。

Bash

pip install --upgrade gradio gradio_client

🕳️ 坑 4: `模型加载失败: Incorrect path_or_model_id`

报错日志： 模型加载失败: Incorrect path_or_model_id: '/home/bjrbds/deepseek-ocr-model/DeepSeek-OCR'

分析：我在第 6 步改配置时画蛇添足了。我以为模型在 deepseek-ocr-model 文件夹里面的 DeepSeek-OCR 文件夹里。但 modelscope 已经把所有文件（config.json 等）直接下载到了 deepseek-ocr-model 根目录。

✅ 解决：重新编辑 vim start_ocr_webui.py，把路径改对。

Python

# 错误路径: self.model_path = '/home/bjrbds/deepseek-ocr-model/DeepSeek-OCR'
# 正确路径:
self.model_path = '/home/bjrbds/deepseek-ocr-model'

(顺便：在解决这个问题的过程中，我们还遇到了一个 pillow 库的版本警告，用 pip install --upgrade pillow 顺手解决了。)

第三章：让服务“活下去” (后台运行与日志)

我们总不能一直开着这个黑窗口（终端）。我们需要让它在后台稳定运行，并且把日志记录下来。

我选择了最简单粗暴的 nohup 命令。

🚀 启动！

确保你在 (deepseek-ocr) 环境下。
确保你在项目目录 /home/bjrbds/DeepSeek-OCR-Web-UI。
执行下面这条“天书”一样的命令：

Bash

nohup /home/bjrbds/.conda/envs/deepseek-ocr/bin/python start_ocr_webui.py > /home/bjrbds/DeepSeek-OCR-Web-UI/ocr-webui.log 2>&1 &

📖 “天书”翻译

nohup ... &：nohup (No Hang Up) 和 & 组合，让命令在后台运行，你关掉终端它也不死。
/home/bjrbds/.conda/envs/deepseek-ocr/bin/python：[重点] 我们不能只写 python，必须用 Conda 环境里那个 Python 的绝对路径，nohup 才能找对环境。
> .../ocr-webui.log：把所有正常的日志 (stdout) 输出到 ocr-webui.log 这个文件里。
2>&1：把所有错误日志 (stderr) 也合并 ( &1) 到和正常日志 (2>) 一样的文件里。

🏡 后续管理

怎么看日志？ tail -f /home/bjrbds/DeepSeek-OCR-Web-UI/ocr-webui.log (按 Ctrl+C 退出查看)

怎么停掉它？

Bash

# 1. 找到它的进程号 (PID)
ps aux | grep start_ocr_webui.py
# 2. 杀死它 (假设 PID 是 12345)
kill 12345

总结

我们成功了！

这次部署虽然曲折，但非常有价值。我们不仅让 DeepSeek-OCR 跑了起来，还亲手解决了 Python 环境冲突、gradio Bug、模型路径错误、以及最关键的“CPU 假运行”问题。

希望这篇“踩坑”日记能帮到你！

队长别开枪！Java硬接AI模型当场暴毙，我用这套方案救回了项目

Mon, 01 Sep 2025 00:00:00 +0000

队长别开枪！Java硬接AI模型当场暴毙，我用这套方案救回了项目

一个 AI 工程师的“吐槽”，以及 Java 与 Python“异地恋”的正确姿势

大家好，我是、小李。

最近我们团队春风得意，老板“王总”开完会回来，红光满面地拍着我的肩膀说：“小李啊，最近 AI 很火，你给咱们的 RuoYi 框架也整上！就那个，文生视频！明天能上线不？”

我（面带微笑，内心 M**）：”王总…这…这Java…和Python…它俩…”

如果你也是一名 Java 工程师或 AI 工程师，你一定懂我的痛。

我们的 RuoYi 框架（或者 Jeecg、Spring Boot）是 Java 界的“三好学生”，严谨、稳定、企业级。而 AI 模型（PyTorch、Diffusers）是 Python 界的“艺术生”，自由、奔放、贼耗资源。

你让三好学生去管艺术生…这不出事才怪！

这篇文章，就是我这个 AI 工程师的“血泪史”，分享一下踩坑无数后，我们是怎么让 Java 和 Python 这对“欢喜冤家”和平共处，还顺便把性能拉满的。

坑一：天真的“跨国直连” —— Java `exec` Python 脚本

最开始，我们的 Java 队长（一个资深 Java 架构师）提出了一个“天真”的方案：

“不就是调个 Python 吗？我用 ProcessBuilder.command("python", "run_video.py", "一只猫")，分分钟搞定！”

兄弟，千万别！

你知道这行命令背后发生了什么吗？

用户点击“生成”。
Java 启动一个全新的 Python 进程（冷启动）。
Python 颤颤巍巍地开始加载十几 GB 的文生视频模型（加载中…）。
GPU 预热，申请显存（加载中…）。
30 秒过去了，模型终于加载完了，开始吭哧吭哧地算（生成中…）。
又 30 秒过去了，视频生成了，Python 进程退出，GPU 资源释放。
Java 端：“太好了，我终于拿到这个…等等，我的 HTTP 请求呢？”

你的用户请求早就在 30 秒前超时了！

更要命的是，GPU 是“独占”的。当第一个用户在“炼丹”时，第二个用户只能在旁边排队干瞪眼。如果 10 个人同时点，你的 RuoYi 服务器会直接卡死，当场给王总表演一个“服务器宕机”。

结论： AI 模型不是一个“函数”，它是一个“服务”。我们不能每次都请它“出山”，得让它“常驻”。

坑二：异地恋的正确姿势 —— “异步”与”解耦”

重型 AI 任务（文生图/视频）是“慢”任务。对付“慢”任务，唯一的办法就是“异步”。

你不能让 Java 队长在原地傻等 Python 艺术生画完画。

正确的姿势是引入一个“传话筒”—— 消息队列 (MQ)，比如 RabbitMQ 或 Redis。

我们的架构变成了“智能餐厅”模式：

RuoYi (Java 端) 成了“服务员”：
- 用户（顾客）点了个“红烧 AI 视频”。
- RuoYi（服务员）接过菜单（prompt），转身贴在后厨的“订单墙”（RabbitMQ）上。
- 服务员立刻回头对顾客说：“好嘞！您的订单（task_id）已提交，后厨正在做！”
- （RuoYi 瞬间响应，一点都不卡！）
AI Worker (Python 端) 成了“后厨大厨”：
- 大厨（Python 脚本）正闲着呢，一抬头看到“订单墙”上有新活了。
- 他美滋滋地接下单子，开始点火、倒油、开“炼”（GPU 启动）。
- 这个菜（视频）要炒 1 分钟，没关系，餐厅（RuoYi）还在正常营业，服务员还在接新单子。
- 炒完后，大厨把菜（视频文件）放到“出菜口”（MinIO 对象存储），并在数据库里把这个 task_id 标记为“已完成”。
前端 (Vue) 成了“着急的顾客”：
- 顾客（前端）每 5 秒问一次服务员：“我的菜好了吗？”（前端轮询 task_id 状态）。
- 服务员（RuoYi）就去数据库查一下，直到发现“已完成”，立刻把“出菜口”的 URL 端给顾客。

好处： RuoYi 和 AI 服务彻底解耦！就算 AI 后厨着火了（OOM 显存爆炸），RuoYi 前厅依然歌舞升平，继续接客。这才叫“企业级”！

坑三：后厨管理 —— “AI 网关”到底谁来当？

好了，现在后厨（AI Worker）独立了，但后厨里可能不止一个厨子啊！

有炒“文生视频”的（Wan2.1）
有烤“文生图”的（Stable Diffusion）
还有个“云厨子”（智谱 API）

RuoYi 不想管这么细，它只想把订单扔给“后厨总管”（AI 网关），让总管自己去分配。

这个“总管”用谁来当？两个主流候选人：FastAPI 和 LangChain。

候选人 A：LangChain

简历： 博士学位，AI 界的“当红炸子鸡”，精通 RAG、Agents，能说会道（LLM 编排大师）。
面试表现： 当我们让它去管理“文生视频”厨子时，它懵了。
LangChain： “等等…这个厨子（Wan2.1）的 Prompt 模板是啥？他的输出怎么不是 JSON？我怎么给他挂载向量数据库？”
结论： LangChain 是个“文科状元”，你让它去管“文本后厨”（LLM）是天作之合。但你让它去管“视频/图像”这种多模态后厨，它自己都得先学怎么使唤，太别扭了！

候选人 B：FastAPI

简历： 高中毕业，但干了 10 年“物流总管”，快如闪电，极其务实。
面试表现：
FastAPI： “哦，这个是视频单？扔给 1 号厨子（本地 Wan2.1）。这个是 API 单？我打个电话给云厨子（智谱）。这个是图片单？扔给 2 号厨子（本地 SD）。搞定。”
结论： FastAPI 是个纯粹的“接入层”和“路由器”。它不关心 AI 模型是啥，只负责把活儿分下去。这不就是我们网关想要的吗！

胜出： FastAPI。我们用 FastAPI 来当我们的 AI 网关总管。

坑四：后厨的装备 —— “运行器”用啥？

总管（FastAPI）选好了，那厨子们（本地模型）在什么样的“灶台”（运行器）上干活呢？

方案一：DIY 灶台 (也用 FastAPI)
- 就是让厨子自己搭个灶台。
- 问题： 就像给米其林大厨一个“单眼电磁炉”。GPU（灶台）很贵很强大，但一次只能炒一个菜。你来了 10 个“文生图”订单，他就得一个一个炒，GPU 利用率低得可怜，吞吐量是灾难。
方案二：航母级灶台 (NVIDIA Triton)
- NVIDIA 官方出品，C++ 核心，性能核弹。
- 问题： 安装配置手册是“天书”。等你看懂手册（config.pbtxt），王总的项目都黄了。这是“配置地狱”。
方案三：专业级中央厨房 (BentoML)
- Python 优先，专为 AI 应用打包和部署而生。
- 它有个独门绝技：“动态批处理 (Dynamic Batching)”。
- 翻译一下：
  - DIY 厨子：来了 10 份“炒土豆丝”，他得炒 10 锅。
  - BentoML 厨子：来了 10 份“炒土豆丝”，他直接把 10 份的土豆丝倒进一个大锅里一起炒了！（把 10 个请求合并成一个 Batch 喂给 GPU）。
- GPU（大锅）一次就干完了 10 份的活，利用率 100%！然后再把菜（结果）分回 10 个盘子。

胜出： BentoML。它在“易用性”和“高性能”之间取得了完美的平衡。

最终的“梦之队”架构

好了，我们的 Java 和 AI 联姻的“梦之队”诞生了：

门面担当 (Java 业务层): RuoYi
- 职责：处理业务、权限，当个优雅的“服务员”。
传菜通道 (消息队列): RabbitMQ
- 职责：任务解耦、排队、削峰填谷。
后厨总管 (AI 网关): FastAPI (Python)
- 职责：监听 MQ，当“路由器”，把 AI 任务分发给正确的厨子。
专业厨房 (AI 运行器): BentoML (Python)
- 职责：高性能运行本地的“文生图/视频”模型，开启“动态批处理”压榨 GPU。
菜品仓库 (对象存储): MinIO
- 职责：存放所有 AI 生成的图片和视频。

这套架构下来，RuoYi 还是那个稳如老狗的 RuoYi，而 AI 在另一台服务器上玩命“炼丹”，互不打扰，丝般顺滑。

王总看了看，露出了满意的微笑：“小管啊，这个月奖金…可以谈！”

希望这篇“不正经”的分享能帮到你。别再让 Java 和 Python 硬碰硬了，给它们一个舒服的“异地恋”环境吧！

高效 PDF 解析利器：MinerU 实战避坑与高精度调优指南

Wed, 20 Aug 2025 00:00:00 +0000

高效 PDF 解析利器：MinerU 实战避坑与高精度调优指南

在处理海量 PDF 文档（尤其是扫描件、统计年鉴或古籍方志）时，如何精准提取其中的文本和表格数据一直是个痛点。最近在服务器上部署并深入使用了 MinerU，这是一款强大的开源 PDF 提取工具。

在使用过程中，从环境配置到参数调优，我总结了一套“最佳实践”。本文将分享如何规避常见的环境坑，以及如何通过参数组合实现最高精度的中文识别。

1. 环境管理的“第一信条”

在使用 MinerU 之前，最容易被忽视的一步就是环境隔离。

很多时候我们会发现命令报错或者版本不对，原因往往是我们在默认的 (base) 环境中裸奔。为了保证工具的稳定性，必须确保在独立的 Conda 环境中运行。

❌ 错误姿势： 直接在终端操作。 ✅ 正确姿势： 每次开始工作前，请务必激活专属环境：

Bash

conda activate MinerU

当你的终端提示符从 (base) 变为 (MinerU) 时，才代表你进入了正确的工作区。

2. 避坑指南：Pip 安装的正确姿势

在多人共用的服务器环境下，直接使用 pip install 经常会导致包被安装到用户主目录（~/.local/）下，而不是我们激活的 Conda 环境中。这会导致严重的版本混乱——明明安装了新版，运行的却是旧版。

为了彻底解决这个问题，请养成使用 python -m pip 的习惯：

标准安装/升级命令：

Bash

# 这种方式能确保 pip 是当前 Conda 环境下的 pip
python -m pip install --upgrade mineru

# 或者安装指定稳定版本（推荐）
python -m pip install mineru==2.2.2

3. 基础使用与版本验证

环境准备好后，首先验证安装是否成功：

Bash

mineru --version

基本解析命令： 如果你只需要进行标准的文档解析，可以使用以下命令将 PDF 转换为 Markdown 或 JSON：

Bash

# 示例：解析 report.pdf 并输出到 ./output 目录
mineru parse report.pdf --output_dir ./output

4. 进阶调优：如何处理复杂扫描件与表格？

这是本文的核心干货。

如果你的目标是处理统计年鉴、地方志、旧文档扫描件，或者对表格数据的还原度有极高要求，默认的设置可能不够用。

经过多次测试，建议使用以下“黄金组合”参数：

Bash

mineru -p <PDF文件路径> -o <输出路径> --backend pipeline --lang ch_server

为什么选择这个组合？

--backend pipeline (结构化神器) 这个后端模式是专门为精确提取表格、列表、段落设计的。相比于通用的视觉模型（VLM），它拥有专门的表格识别模块，在处理密集数据表格时表现远超预期。
--lang ch_server (精度优先) 这是为了获得最高中文识别准确率而设计的服务器级模型选项。
- 应对模糊字迹：对于扫描件或图像质量不一的老旧文档，它的抗干扰能力最强。
- 严谨数据：对于每一个数字都不能错的统计文档，这个选项能最大程度减少 OCR 幻觉。

5. 常见故障排查 (Troubleshooting)

根据实战经验，如果你遇到以下问题，可以按此流程快速自救：

Q1: 提示 mineru: 未找到命令

检查：你是否忘了运行 conda activate MinerU？
检查：运行 which mineru，看系统是否找到了错误的路径。

Q2: 升级后版本号依然没变 这通常是因为旧版本残留在 ~/.local/bin 中，导致系统优先调用了旧版。

解决方案：执行“彻底清理-重装”流程。

Bash

# 1. 彻底卸载 (建议重复执行直到提示找不到包)
python -m pip uninstall mineru

# 2. 确认环境干净 (应提示 "command not found")
mineru --version

# 3. 使用正确方式重装
python -m pip install mineru

结语

MinerU 是一个强大的工具，但只有配置好环境并选对参数，才能发挥它的最大威力。希望这份基于实战总结的指南，能帮助大家在处理文档解析任务时少走弯路，直接获取高质量的结构化数据。

我刚拿到了8卡GPU服务器的钥匙，现在我慌得一批……”

Fri, 01 Aug 2025 00:00:00 +0000

我刚拿到了8卡GPU服务器的钥匙，现在我慌得一批……

一个“小白”的GPU服务器“踩坑”与“爬坑”指南

朋友们，就在今天，我的人生（职业生涯）达到了一个小高峰。

我拿到了团队一台全新8卡GPU服务器（8 x RTX 4090）的ssh登录权限。

我的第一反应是：“不就是一台CPU核多一点、内存大一点的Linux服务器吗？ssh连上去，htop跑起来，我就是这台机器的王！”

然而，当我输入nvidia-smi并看到我同事的进程（Xinf vLLM worker）密密麻麻地占满了 6 张卡时，我才意识到——

事情没那么简单。

我不是王。在这台机器上，我充其量算是个“新来的租客”。管理这台机器，和我管理一台普通的Linux Web服务器，压根不是一回事。

如果你也像我一样，刚拿到这“核武器的发射按钮”却不知道怎么用，这篇笔记就是为你准备的。

🧠 区别一：思维转变！你管理的不是“厨房”，是“停车场”

这是我学到的第一个痛彻心扉的区别。

普通Linux服务器（比如Web服务器）：
- 它就像一个“共享厨房”（CPU和内存）。
- 张三在用微波炉（一个CPU核心），李四在用另一个灶台（另一个CPU核心）。大家可以同时用，互不干扰。CPU是一种可以“分时共享”的资源。我们最关心的是htop里的CPU占用率别到100%。
GPU服务器（我这台）：
- 它更像一个“VIP停车库”（GPU显存）。
- 每张GPU卡就是一排固定车位（比如24GB显存）。
- 我同事的LLM服务，就像一辆加长悍马（Xinf vLLM worker）。它一停进来，就“哐”地一下占满了0、1、2、3号车位（GPU 0-3）。
- 关键来了： 显存（VRAM）是“独占”的！一个车位被占了，你就不能再往里塞任何东西。哪怕那辆悍马只占了23.8GB，你也不能把你那1GB的“小电驴”（小模型）塞进那剩下的0.2GB空隙里。

管理思维转变： 在普通服务器，我关心“CPU别累死”。在GPU服务器，我关心“显存（车位）还够不够分？”

🩺 区别二：体检工具升级！从`htop`到`nvidia-smi`

在普通Linux上，htop就是我的“听诊器”。

但在GPU服务器上，htop只能算“量个血压”（看CPU和内存）。你真正的“心电图（EKG）”是nvidia-smi。

但nvidia-smi本身只是个“静态快照”。你要用这个：

Bash 猛击

watch -n 1 nvidia-smi

朋友们，watch -n 1（每秒刷新一次）才是灵魂！它把静态的心电图照片变成了实时的心电监护仪。

你必须实时盯着两个指标：

Memory-Usage (显存占用)：你的“车位”还剩多少？
GPU-Util (计算利用率)：如果显存满了（车停进去了），但这玩意儿是 0%，说明司机（程序）在车里睡着了（卡在CPU数据预处理），GPU在“摸鱼”！

🔑 区别三：生存法则！从“我的地盘”到“合租公寓”

这台8卡服务器就是一间“合租公寓”，你和你的同事都是租客。为了不被同事“真人PK”，你必须遵守“合租条约”。

合租条约A：环境隔离（“别用公用牙刷！”）

问题： 服务器的 (base) 环境，就像是公寓里那支公用的牙刷。
场景： 你同事的LLM服务需要 PyTorch 2.1（薄荷味牙膏）。你新来的视频模型要用 PyTorch 2.3（草莓味牙膏）。
你做了什么： 你在 (base) 环境里 pip install --upgrade torch。
后果： 你把牙刷和牙膏全换了。你同事的服务“哐”的一声就崩了。他会顺着网线来找你。

正确做法（Conda / Venv）： 永远别用公用牙刷！ 用 conda 给自己创建一个“专属洗漱包”：

Bash 猛击

# 1. 创建你的专属小天地
conda create -n my_video_env python=3.10

# 2. 激活它（拉上帘子）
conda activate my_video_env

# 3. 在里面随便折腾！爱用什么味牙膏都行！
pip install torch==2.3 ...

合租条约B：GPU隔离（“戴上你的‘魔法眼罩’”）

问题： 你登录进来，默认能看到所有8张卡（0-7号房）。你一跑程序，它默认就想冲进 GPU 0（0号房），那里已经住了你同事的“悍马”！
解决方案：CUDA_VISIBLE_DEVICES 这是我学到的最强黑魔法。它是一个环境变量，就像一副“魔法眼罩”。

在你的终端里输入：

Bash 猛击
```
1
2
# 关键！戴上眼罩！
export CUDA_VISIBLE_DEVICES=6,7
```
奇迹发生了：
- 你的程序（PyTorch等）被“骗”了。它以为这台服务器总共就只有2张卡。
- 它会把你物理上的 GPU 6（6号房）当作 cuda:0（它眼里的0号房）。
- 它会把你物理上的 GPU 7（7号房）当作 cuda:1（它眼里的1号房）。
现在，你让程序“去0号房”，它就会乖乖地走进物理上的6号房，完美避开了你同事！

🤵 终极方案：“酒店管家” (Xinference / BentoML)

学完上面那些，我感觉自己像个“DIY修理工”。

但其实，我（和我的同事）正在用一种更高级的玩法：调度框架 (Xinference)。

Xinference 就像一个“五星级酒店管家”。

我根本不需要自己去设置“魔法眼罩”，我只需要在它的UI界面上点一下（或者用Python API告诉它）：

“管家（Xinference），我要部署 Wan2.1-14B 这个模型，请把它安排到 GPU 6 和 7 这两个套间里。”

“管家”会帮我搞定所有事：模型下载、环境配置、GPU隔离、启动进程，并给我一个API地址。我直接访问API就能用我的视频模型了。

这，才是我这种“小白”该有的、体面的入门方式！

总结（附赠一个忠告）

管理一台GPU服务器，我的思维从“CPU”转向了“VRAM（显存）”，工具从htop转向了watch -n 1 nvidia-smi，心态从“独占”转向了“合租”。

最后的忠告： 这台服务器的功耗是 4000W。它满载时，风扇的声音不像电脑，像一架即将起飞的波音747。千万别想把它放办公桌下面，除非你想体验什么叫“工业噪音疗法”。

好了，不说了，我的 Wan2.1-14B 部署成功了，我要去生成视频了！

玩转Dify：三步设置，让你的AI从“智障”变“专家”

Thu, 10 Apr 2025 00:00:00 +0000

玩转Dify：三步设置，让你的AI从“智障”变“专家”

你是否遇到过这样的情况：明明把文件喂给了 AI，但它的回答总是不尽人意，要么答非所问，要么信息不全？别急，问题通常不出在模型本身，而在于我们“喂”给它知识的方式。

今天，我们就用大白话聊聊 Dify 知识库背后最重要的技术——文本分段（Chunking）。我们将从基础的“通用模式”讲起，再深入到效果拔群的“父子模式”，让你彻底掌握如何配置，将你的 AI 从“人工智障”调教成“行业专家”。

核心概念：AI 是如何“阅读”你的文档的？

想象一下，你扔给 AI 一本厚厚的书。AI 不会真的从头到尾“阅读”一遍。相反，系统会先把这本书拆成一张张的“知识卡片”，这个过程就是分段。当你提问时，系统会先找出与问题最相关的几张卡片，然后交给 AI 根据卡片内容来组织答案。

所以，卡片拆分得好不好，直接决定了最终回答的质量。Dify 提供了两种制作“知识卡片”的模式：“通用分段”和“父子分段”。

第一部分：基础篇 —— 通用分段模式

“通用模式”是最基础、最直接的分段方式，它有三个核心配置项，我们称之为“分段三剑客”。

1. 分段标识符 —— 定义“怎么切”

“分段标识符”就像一把尺子，它告诉系统应该沿着什么规则来切割你的文档。

实战案例：一份《1990年鉴》的启示

我们来看一个真实的用户测试案例。用户上传了一份结构清晰的《1990年鉴》Markdown 文档，并尝试了两种不同的分段标识符：
1. 按段落切分 (\n\n)：系统预估会生成 8310 个知识块。
2. 按标题切分 (\n#)：系统预估只生成 2075 个知识块。
这个数量差异的背后，是质量上的巨大鸿沟。8310 个块意味着年鉴被拆成了非常零碎的段落。而 2075 个块则意味着每个知识块都是一个语义完整的章节（例如“年度经济概述”）。当提问时，AI 得到的是一个完整的章节而不是一个孤立的段落，答案的质量自然会高得多。

结论：对于有标题的文档，按标题分段（如 \n#）是无可争议的最佳选择。

2. 分段最大长度 —— 设置“安全网”

这规定了每张“知识卡片”的最大尺寸，是一个防止单个知识块过大的“保险丝”，而不是一个目标尺寸。

推荐值：1024 characters。
工作原理：系统会先按你的“分段标识符”（比如 \n#）切分。只有当某个切出来的块超过了 1024 个字符，系统才会把它再切得小一点。

3. 分段重叠长度 —— 建立“上下文的桥梁”

它让相邻的两个“知识卡片”之间共享一小部分内容，像一座桥梁，确保了信息的连续性。

推荐值：设置为“最大长度”的 10% 到 15%，例如 150 characters。

通用模式的局限：这种模式存在一个“上下文两难”问题。为了检索精准，知识块不能太大；但块太小，又会导致 AI 回答时上下文信息不足。如何两全其美？这就引出了我们的进阶方案。

第二部分：进阶篇 —— 父子分段模式

“父子模式”是一种更高级的策略，它巧妙地解决了“通用模式”的痛点。

核心思想：用“索引卡”查“原文页”

想象一下，我们为一本书制作了两种东西：

子块 (Child Chunks)：一套非常精炼的“索引卡”，每张卡片只有一小段文字，信息密度极高。
父块 (Parent Chunks)：完整的“原文页”，包含丰富的上下文。

它的工作流程是：

检索时：系统在海量的“索引卡”（子块）里快速、精准地找到匹配项。
回答时：系统不会把这张小小的索引卡直接给 AI，而是找到它指向的那一整页“原文页”（父块），把这页内容交给 AI 去生成答案。

这样就实现了精准检索和丰富上下文的完美结合！

如何配置父子模式？

父块配置 (用于提供上下文)
- 分段标识符：设置为 \n#。这确保了每个“父块”都是一个完整的章节，上下文最丰富。
- 分段最大长度：设置为 1024。作为过长章节的安全网。
子块配置 (用于精准检索)
- 分段标识符：设置为 \n\n。这将父块（章节）进一步拆分为段落，形成小而精的“子块”。
- 分段最大长度：设置为 512。这个尺寸非常适合向量检索。

最终对决：我该如何选择？

选择“通用模式”，如果你…	选择“父子模式”，如果你…
刚刚开始使用，想用最简单的方式配置。	追求最高的问答质量，愿意进行更精细的配置。
你的知识库文档内容比较简单、直接（例如 FAQ 列表）。	你的文档复杂、密集且长（例如技术手册、法律文件、我们案例中的年鉴）。
“通用模式”的测试结果已经让你满意。	发现“通用模式”生成的答案经常缺少上下文，显得很零碎或片面。

最终建议：对于结构化的复杂文档，“父子模式”是能将知识库效果最大化的专业选择。

最后，无论选择哪种模式，请一定记得使用 Dify 提供的“预览块”功能！它能让你直观地看到文档被切分成的样子，是验证配置效果的终极武器。

如何度量代码生成大模型的准确性？

Wed, 10 Apr 2024 00:00:00 +0000

如何度量代码生成大模型的准确性？

项目背景

在公司内网部署StarCoder-1B大模型已经半月有余了，在考虑继续优化升级StarCoder-7B模型的同时，一个重要的问题出现了。

在实际生产开发中，我们应该如何评估代码生成大模型的准确性？是从10亿到70亿参数越多就越好吗？还是看论文测试说哪个模型好就一定更好？

用数据说话！

评估指标

插件的下载数量—-普及度
- 由于我把插件放在飞书文档，因此无法统计下载安装的数量（失策了..）
代码的生成质量—-满意度
- 通过tabby产生的日志可以分析。

日志分析

tabby服务端会每天产生日志如：2024-03-07.json

日志的内容：

{"ts":1709541131885,"event":{"completion":{"completion_id":"cmpl-dea2b314-0518-414e-ace7-f74c3494ba20","language":"java","prompt":"*******","segments":{"prefix":"*****","suffix":"*****"},"choices":[{"index":0,"text":"*********"}]}}}
{"ts":1709541132062,"event":{"view":{"completion_id":"cmpl-dea2b314-0518-414e-ace7-f74c3494ba20","choice_index":0,"view_id":"view-dea2b314-0518-414e-ace7-f74c3494ba20-at-1709541131909"}}}
{"ts":1709541132768,"event":{"select":{"completion_id":"cmpl-dea2b314-0518-414e-ace7-f74c3494ba20","choice_index":0,"view_id":"view-dea2b314-0518-414e-ace7-f74c3494ba20-at-1709541131909","elapsed":704}}}
{"ts":1709541133661,"event":{"view":{"completion_id":"cmpl-dea2b314-0518-414e-ace7-f74c3494ba20","choice_index":0,"view_id":"view-dea2b314-0518-414e-ace7-f74c3494ba20-at-1709541133514"}}}
{"ts":1709541134151,"event":{"select":{"completion_id":"cmpl-dea2b314-0518-414e-ace7-f74c3494ba20","choice_index":0,"view_id":"view-dea2b314-0518-414e-ace7-f74c3494ba20-at-1709541133514","elapsed":489}}}
{"ts":1709541134902,"event":{"view":{"completion_id":"cmpl-dea2b314-0518-414e-ace7-f74c3494ba20","choice_index":0,"view_id":"view-dea2b314-0518-414e-ace7-f74c3494ba20-at-1709541134755"}}}
{"ts":1709541135314,"event":{"select":{"completion_id":"cmpl-dea2b314-0518-414e-ace7-f74c3494ba20","choice_index":0,"view_id":"view-dea2b314-0518-414e-ace7-f74c3494ba20-at-1709541134755","elapsed":412}}}

通过分析日志的结构可以看出，日志一共分为4类

completion：完成
view：展示
select ：选择
dismiss：放弃

数据分析

日期	completion	view	dismiss	select	代码采纳率
2024-03-07	2451	2059	1873	183	8.89%
2024-03-08	1276	933	859	73	7.82%

2024-03-11	2137	1581	1504	77	4.87%
2024-03-12	1642	1527	1407	116	7.60%
2024-03-13	1483	1146	1068	78	6.81%
2024-03-14	1649	1132	1080	52	4.59%
2024-03-15	1495	1159	1096	62	5.35%

2024-03-18	834	645	625	16	2.48%
2024-03-19	931	690	659	30	4.35%
2024-03-20	1395	1017	961	54	5.31%
2024-03-21	1391	1007	937	71	7.05%
2024-03-22	1352	1041	974	66	6.34%

分析结论

通过数据可以得到代码的采纳率大概在5%左右，考虑到很多用户都是设置的自动模式，因此必定会有非常多的无效提示。实际有效的采纳估计会超过15%

数据也算是差强人意，但还有很大的提升空间。

后续规划

升级7B模型，通过测试用例和「代码采纳率」来评估新模型的效果。
优化idea和vscode插件的功能，增加埋点，更精准的统计用户数据，使分析结果更科学。

二次开发tabby插件

Wed, 20 Mar 2024 00:00:00 +0000

二次开发tabby插件

以下同时包含idea和vscode教程。

1、tabby架构

Tabby的架构由多个crate（模块）组成，主要包括：

crates/tabby：处理核心功能和HTTP API。
crates/tabby-download：从互联网获取模型。
crates/tabby-inference：用于LLM推理的功能和工具。
crates/tabby-scheduler：执行异步任务。
ee/tabby-ui：提供Web UI。
ee/tabby-webserver：集成UI并提供团队管理和身份验证。

2、了解下intellij插件结构

开发IntelliJ插件时，插件的基本项目结构如下：

├── build.gradle.kts # 构建脚本文件
├── gradle # Gradle包装器
│   └── wrapper
│       ├── gradle-wrapper.jar
│       └── gradle-wrapper.properties # 包装器配置文件
├── gradlew # shell脚本
├── gradlew.bat # 批处理脚本
├── settings.gradle.kts # 对于单个项目，设置文件是可选的
└── src
    └── main
        ├── java
        │   └── io
        │       └── org
        │           └── example
        │               └── plugin
        │                   ├── MyToolWindow.form
        │                   ├── MyToolWindow.java
        │                   └── MyToolWindowFactory.java
        └── resources 
	    ├── images
	    │		├── a.svg
	    │           └── b.svg
	    ├── messages
	    │		├── TBundle.properties #Bundle
		        └── TBundle_zh_CN.properties #国际化Bundle
            ├── META-INF
            │   ├── plugin.xml # 插件配置文件
            └── └── pluginIcon.svg #Plugin Logo ，插件在IDEA/Plugins中的展示图标

如何打包？

IntelliJ中：

gradle tasks
gradle intellij.buildplugin

VS Code中：

进入./clients/vscode目录。
安装依赖项：yarn。
开发模式下运行：yarn run dev。
修改代码后，打包插件：vsce package --no-dependencies。
安装生成的.vsix文件到VS Code中。

如果遇到问题，确保VS Code版本与package.json中的engines字段兼容，并查看开发者工具控制台日志。

修改插件配置

plugin.xml

1.4.0-dev

修改

<name>Tabby</name>
<vendor url="https://tabbyml.com">TabbyML</vendor>

<description><![CDATA[
    <h1 id="UmeAiCoder-plugin-for-intellij-platform">umeAiCoder Plugin for IntelliJ Platform</h1>
    <p>umeAiCoder is an AI coding assistant that can suggest multi-line code or full functions in real-time.</p>
    <br/>
    <h2 id="demo">Demo</h2>
    <p>Try our online demo <a href="https://tabby.tabbyml.com/playground/">here</a>.</p>
    <h2 id="requirements">Requirements</h2>
    Tabby plugin requires <a href="https://nodejs.org/">Node.js</a> v18+ installed. </p>
]]></description>

设置默认ip端口（不好使）

/Users/guanhongli/Downloads/tabby-main/clients/intellij/src/main/kotlin/com/tabbyml/intellijtabby/settings/ApplicationSettingsPanel.kt

  var serverEndpoint: String
    get() = serverEndpointTextField.text
    set(value) {
      serverEndpointTextField.text = value
    }
#增加默认配置
  init {
    // Set a default value for serverEndpoint
    serverEndpoint = "http://172.24.82.15:8186"
  }

package.json

{
  "name": "intellij-umeAiCoder",
  "version": "1.0.0-dev",
  "description": "IntelliJ plugin for umeAiCoder AI coding assistant.",
  "repository": "https://i2wp4yetps.feishu.cn/wiki/XORAwmB53iORXHk7YSGcRFrWnhh",
  "scripts": {
    "preupgrade-agent": "cd ../tabby-agent && yarn build",
    "upgrade-agent": "rimraf ./node_scripts  &&  cpy ../tabby-agent/dist/cli.js ./node_scripts/ --flat --rename=tabby-agent.js && cpy ../tabby-agent/dist/wasm/* ./node_scripts/wasm/ --flat && cpy ../tabby-agent/dist/win-ca/* ./node_scripts/win-ca/ --flat"
  },
  "devDependencies": {
    "cpy-cli": "^4.2.0",
    "rimraf": "^5.0.1",
    "tabby-agent": "1.0.0-dev"
  }
}

状态栏

idea

StatusBarWidgetFactory.kt //状态栏小部件

TabbyStatusBarItem.ts

修改配置

settings

ApplicationConfigurable.kt ：实现了 Configurable 接口，为插件提供了一个可配置的设置 UI。这是用户与插件设置交互的界面。
ApplicationSettingsPanel.kt ：定义了插件设置界面的布局和逻辑。这个文件负责创建和管理插件配置界面的所有组件（如输入框、复选框等）。
ApplicationSettingsState.kt ：管理和存储插件的设置状态。这个文件定义了一个或多个用于持久化插件配置的数据类。
KeymapSettings.kt ：特别管理键盘映射（快捷键）设置。这可能包括自定义键盘快捷键配置，以及与插件功能交互的快捷方式。

默认ip端口

idea

umeAiCoder/tabby-main/clients/intellij/node_scripts/tabby-agent.js

修改默认endpoint:”https://umeaicoder.local.umetrip.com.cn”
修改默认token:”auth_325ecaec60b84a46b8fc1320a1bfe10c”
修改[server] （感觉不改也行，有空试试）

vscode

/Users/guanhongli/Documents/umeAiCoder/tabby-main/clients/tabby-agent/src/AgentConfig.ts

需要修改的文件

配置设置导航

@ext:TabbyML.vscode-tabby
修改为
@ext:UmeTabby.vscode-ume-ai-coder

package.json文件

修改打包文件：

  "name": "vscode-ume-ai-coder",
  "publisher": "umeAiCoder",
  "displayName": "umeAiCoder",
  "description": "你的代码，何必要自己写...",
  "homepage": "https://umedevops.local.umetrip.com.cn",
  "repository": "https://umedevops.local.umetrip.com.cn/",

启动命令

cpu

docker run -it --gpus all -p 8080:8080 -v $HOME/.tabby:/data tabbyml/tabby serve --model TabbyML/StarCoder-1B --device cuda

常见问题解答

1. 团队自己的代码来训练模型？

是的，您可以使用团队自己的代码来训练模型。具体步骤如下：

检查您使用的工具或平台是否支持自定义代码训练。
确保代码结构化并与工具要求兼容。
上传代码到平台或工具。
配置训练过程，使用自定义代码进行训练。
启动训练并监控进度。
分析结果，调整代码以优化性能。

更多讨论可以访问Tabby社区：Tabby Slack

2. 始终无法获取模型：`TabbyML/SantaCoder-1B`

有时您可能会遇到无法获取模型的情况。可以尝试摆脱对注册表models.json的依赖，或检查是否能够直接加载自定义模型。

3. 如何指定下载镜像？

如果需要使用特定的镜像下载模型，您可以参考Tabby模型下载镜像设置。

4. Tabby支持哪些隐私和安全问题？

Tabby在数据收集和隐私方面有一些问题和解决措施。详细内容请查看：

5. Tabby支持离线模式运行吗？

是的，Tabby支持离线模式运行，您可以设置并在没有互联网连接的情况下使用Tabby。

Tabby离线模式支持

6. 如何在M1 Mac上构建自托管服务器？

可以参考Tabby的文档来在M1 Mac上进行构建：

在M1 Mac上构建Tabby自托管服务器

7. 如何构建和运行具有CUDA支持的Tabby？

如果您想构建并运行支持CUDA的Tabby，可以参考以下资源：

构建Tabby并启用CUDA支持

8. 如何创建交互式聊天窗口？

Tabby支持创建交互式聊天窗口，您可以参考相关文档和讨论：

Tabby创建交互式聊天窗口

9. 如何从头开始构建并安装VS Code扩展？

如果您需要从头开始构建并安装VS Code扩展，按以下步骤操作：

导航到./clients/vscode目录。
使用yarn安装依赖项。
使用yarn run dev启动开发模式。
对代码进行修改后，使用vsce package --no-dependencies命令打包扩展。
安装生成的.vsix文件。

10. 如何在本地工作区使用Tabby VSCode扩展？

如果您希望在本地工作区而不是开发容器中使用Tabby VSCode扩展，请参考以下链接：

使用Tabby VSCode扩展在本地工作区

11. 是否可以在不触发模型下载的情况下启动Tabby容器？

可以通过特定的设置启动Tabby容器而不下载模型。

启动Tabby容器而不触发模型下载

12. 如何使用Python运行Tabby服务器或自定义？

如果您希望使用Python自定义或运行Tabby服务器，请参考相关讨论：

如何使用Python运行Tabby服务器

13. 如何删除Tabby模型？

如果需要删除Tabby模型，可以参考以下讨论：

如何删除Tabby模型

14. 为服务命令添加–chat-device标志

您可以为服务命令添加--chat-device标志，以指定使用的设备类型。更多信息请参考：

如何为服务命令添加–chat-device标志

15. 如何设置身份验证令牌？

要设置身份验证令牌，请参考以下讨论：

如何设置身份验证令牌

16. 编码LLM排行榜简介

Tabby提供了一个编码LLM排行榜，帮助您了解当前模型的性能和排名：

编码LLM排行榜

17. 模型下载地址

以下是一些常见的模型下载链接：

lili Blog

再见前后端分离！我用 AI 一个人“合围”了软件工程

再见前后端分离！我用 AI 一个人卷死了传统团队

01. 缘起：在两条战线的“极限拉扯”中闭环

02. 试炼：一场关于“沟通税”的残酷拆解

03. 觉醒：为什么是现在？为什么是“合”？

04. 展望：在人迹罕至的路上，构建自己的引擎

🚀 实战进阶：将 ComfyUI 封装为 AI 视频生成网站 (FastAPI + WebUI)

🚀 实战进阶：将 ComfyUI 封装为 AI 视频生成网站 (FastAPI + WebUI)

🛠️ 第一步：准备独立环境

📂 第二步：导出 API 工作流 (“菜谱”)

💻 第三步：编写后端代码 (api_server.py)

🎨 第四步：编写前端页面 (static/index.html)

🚀 第五步：部署与运行

🎉 最终效果

🔧 运维小贴士

🚀 实战入门：在服务器单卡部署 ComfyUI + Wan2.1 文生视频最佳实践

🚀 实战入门：在服务器单卡部署 ComfyUI + Wan2.1 文生视频最佳实践

📚 一、环境准备 (Prerequisites)

📦 二、项目安装与环境隔离 (v-e-n-v)

🚀 三、安装依赖 (国内镜像加速)

💾 四、下载 Wan2.1 (T2V) 核心模型

🛠️ 五、安装 ComfyUI Manager (管理节点)

🖥️ 六、部署与日常维护 (Screen)

1. 首次启动 (前台测试)

2. 后台部署 (Screen)

3. 日常维护

❓ 七、常见问题 (Q&A)

🚀 实战部署：单卡4090跑通DeepSeek-OCR本地WebUI

🚀 实战部署：单卡4090跑通DeepSeek-OCR本地WebUI

第一章：基础环境准备 (The “Happy Path”)

🛠️ 第 0 步: “三件套” 跑不了

📦 第 1 步: 创建一个干净的 Python “沙盒”

🔥 第 2 步: 安装 PyTorch (适配 4090 的核心)

🧠 第 3 步: 下载模型本体

🌐 第 4 步: 下载 WebUI 界面

🧩 第 5 步: 安装 WebUI 的依赖

✏️ 第 6 步: 告诉 WebUI 模型在哪

第二章：小白“踩坑”实录 (The “Real Path”)

🕳️ 坑 1: ModuleNotFoundError: No module named 'typer'

🕳️ 坑 2: pip 说”装了”，Python 说”没有”？

🕳️ 坑 3: TypeError: argument of type 'bool' is not iterable

🕳️ 坑 4: 模型加载失败: Incorrect path_or_model_id

第三章：让服务“活下去” (后台运行与日志)

🚀 启动！

📖 “天书”翻译

🏡 后续管理

总结

队长别开枪！Java硬接AI模型当场暴毙，我用这套方案救回了项目

队长别开枪！Java硬接AI模型当场暴毙，我用这套方案救回了项目

坑一：天真的“跨国直连” —— Java exec Python 脚本

坑二：异地恋的正确姿势 —— “异步”与”解耦”

坑三：后厨管理 —— “AI 网关”到底谁来当？

坑四：后厨的装备 —— “运行器”用啥？

最终的“梦之队”架构

高效 PDF 解析利器：MinerU 实战避坑与高精度调优指南

高效 PDF 解析利器：MinerU 实战避坑与高精度调优指南

1. 环境管理的“第一信条”

2. 避坑指南：Pip 安装的正确姿势

3. 基础使用与版本验证

4. 进阶调优：如何处理复杂扫描件与表格？

为什么选择这个组合？

5. 常见故障排查 (Troubleshooting)

结语

我刚拿到了8卡GPU服务器的钥匙，现在我慌得一批……”

我刚拿到了8卡GPU服务器的钥匙，现在我慌得一批……

🧠 区别一：思维转变！你管理的不是“厨房”，是“停车场”

🩺 区别二：体检工具升级！从htop到nvidia-smi

🔑 区别三：生存法则！从“我的地盘”到“合租公寓”

合租条约A：环境隔离（“别用公用牙刷！”）

合租条约B：GPU隔离（“戴上你的‘魔法眼罩’”）

🤵 终极方案：“酒店管家” (Xinference / BentoML)

总结（附赠一个忠告）

玩转Dify：三步设置，让你的AI从“智障”变“专家”

玩转Dify：三步设置，让你的AI从“智障”变“专家”

核心概念：AI 是如何“阅读”你的文档的？

第一部分：基础篇 —— 通用分段模式

1. 分段标识符 —— 定义“怎么切”

2. 分段最大长度 —— 设置“安全网”

3. 分段重叠长度 —— 建立“上下文的桥梁”

💻 第三步：编写后端代码 (`api_server.py`)

🎨 第四步：编写前端页面 (`static/index.html`)

🕳️ 坑 1: `ModuleNotFoundError: No module named 'typer'`

🕳️ 坑 2: `pip` 说”装了”，Python 说”没有”？

🕳️ 坑 3: `TypeError: argument of type 'bool' is not iterable`

🕳️ 坑 4: `模型加载失败: Incorrect path_or_model_id`

坑一：天真的“跨国直连” —— Java `exec` Python 脚本

🩺 区别二：体检工具升级！从`htop`到`nvidia-smi`

2. 始终无法获取模型：`TabbyML/SantaCoder-1B`