背景与目标

手头几台实验室服务器都是消费级显卡（RTX 3090 24G×4 / ×8），之前用 vLLM 部署 Qwen3.8-27B 时体验很一般：BF16 权重 52G，tp=8 摊到每张卡上解码速度也就几十 tok/s，长上下文 prefill 更是慢。目标是又快又准、上下文尽量大，并且不碰机器上已有的任何服务和数据（共享机器，上面有 gluster、AIGC 服务、一堆 docker 容器）。

这篇文章记录从 0 到上线的完整过程，包括驱动升级、镜像选择、参数调优、DFlash2 投机解码接入，以及后续的 sgLang-router 缓存感知负载均衡。所有内网 IP、主机名等敏感信息均已隐去，用 node1 / node2 代称。

背景：我想复刻的东西是什么

最近看到一个叫 JEV 的产品（TypeSafe 出品），它做的事很有意思：给定一段共享上下文（state）和一组问题，一次性返回所有问题的判别结果——不是生成式地一个一个写答案，而是"判断"。官方宣称比传统 LLM 工作流快 193.6×、便宜 444.6×。

它的几个可观察行为很吸引我：

• 没有首 token 等待：判别类任务不需要等自回归解码出第一个 token，单次前向就能出结果；
• 零非法选项：输出只可能是你声明的候选之一，不会"幻觉"出一个没提供的选项；
• 多问共享 state：同一上下文下的一堆问题摊薄 prefill 成本，问得越多越划算。

但 TypeSafe 没公开它的架构、参数量、训练数据，那套 RLCD 也摸不到。所以我的目标定得很实际：复刻它的可观察能力和工程效果，不复刻它没公开的内部实现。本文记录这条路的完整过程——立项、调研、基线、一路踩坑、对比 benchmark、蒸馏、写 API、上线，所有数字都可复现。

内网主机名/IP 等敏感信息一律隐去（下文用"GPU 验收机"指代），仓库代码见文末。

📌 简单好用的浏览器小助手：Better DeepSeek 扩展

DeepSeek这段时间真的是太火啦。不仅仅是在国内，更是给整个 AI 市场带来了新的挑战。相信大家也都开心地用上了DeepSeek，不过我在使用的时候有一些不太趁手的地方，所以今天给大家介绍一个我最近开发的特别实用的小工具 —— Better DeepSeek浏览器扩展。它就像给你的浏览器装了个"智能小帮手"，能自动帮你处理一些使用DeepSeek时的麻烦事。

🛠️ 这个工具能帮你做什么？

1. 自动预览网页 Mermaid 图

我们在使用DeepSeek时有时会让DeepSeek给我们生成一些流程图、架构图、泳道图、思维导图等等，而默认情况下DeepSeek网页上看到的都是文字。可能有些文章会告诉你将这些代码复制到能显示Mermaid的网址就可以看到图片了。但我这个工具就会自动帮你渲染图片，再也不需要复制到其它地方查看了。给你们看看效果：

🚀 jd-cookie-helper - 京东cookie辅助工具

🛠️ 工具简介

jd-cookie-helper 是一款基于Electron开发的京东多账号 Cookie 管理工具，专为青龙面板自动化任务玩家量身打造。告别传统浏览器反复登录、手动抓取Cookie的繁琐操作，一键实现全自动登录+Cookie提取！

🚀 iGit - 智能 Git 工作流助手

💡 项目简介

在日常开发中，Git 工作流是每个开发者必不可少的一部分。然而，标准化提交信息、执行代码检查、确保代码质量等工作往往需要耗费大量的时间和精力。iGit 正是为解决这些问题而生的智能 Git 工作流助手，它能够帮助你实现更智能、更高效的 Git 工作流程。

✨ 核心特性

• 🤖 AI 驱动的提交信息 - 自动生成符合约定式提交规范的提交信息，让你的提交历史更清晰、更专业
• 🎯 智能 Git Hooks - 提供一系列开箱即用的 Git Hooks，帮助你规范代码提交流程
• 🎈 简单易用 - 通过简单的命令行工具，轻松集成到你的项目中
• ⚙️ 高度可配置 - 提供灵活的配置选项，满足不同项目的需求

🛠️ 技术栈

• Node.js
• OpenAI API
• Git Hooks
• YAML 配置

📝 安装与使用

1. 安装依赖

1
2
3
4
5
6
7
8

# 使用 npm
npm install -D @doremijs/igit-cli

# 使用 yarn
yarn add -D @doremijs/igit-cli

# 使用 pnpm
pnpm add -D @doremijs/igit-cli

🚀 fe-conf - 配置生成器

前端喜欢造轮子，也喜欢搞各种工程化，项目中经常配置了各种工程化工具，而这些工具要么是xxx-cli初始化生成，要么自己手动配置，每次针对项目可能还要做一些配置调整，而且看着package.json里一堆依赖又很碍眼，而fe-config就是用来解决这个问题的。

fe-conf由2个项目共同组成（后续可以合并？），一个配置生成器config-generator，一个默认配置好的配置集合doremi-config。2者配合使用就可以完成项目工程化的配置。当然fe-conf生成的是默认配置，你也可以按照自己的需求进行调整。

🛠️ OpenAPI Generator - API 客户端生成

💡 项目背景

在现代前端开发中，与后端 API 的交互是不可或缺的。然而，手动编写 API 调用客户端不仅耗时，还容易引入类型和调用错误。@doremijs/o2t 正是为了解决这一痛点而生的 OpenAPI 客户端生成工具（简称o2t）。

✨ 核心特性

• 🚀 全自动生成类型安全的 TypeScript API 客户端
• 🎯 简单配置，一键生成
• 📦 灵活的拦截器和错误处理机制
• 🔒 支持 OpenAPI/Swagger 规范（v2 和 v3）

🛠️ 技术栈

• TypeScript
• Fetch API
• OpenAPI/Swagger 规范

🚀 图片压缩工具 - 本地的极速图片压缩工具

在前端开发过程中，图片资源的优化一直是一个重要的环节。过大的图片文件会影响网站的加载速度和用户体验，而手动压缩图片又比较繁琐。市面上虽然有很多图片压缩工具，但大多数要么是在线服务需要上传下载，要么是收费软件。为了解决这个问题，我开发了一个简单易用的本地图片压缩工具。

这是一个使用 Electron 和 Sharp 开发的图片压缩应用程序，专为前端开发者/UI设计师使用，用于批量压缩图片。它模仿了 ImageOptim 的使用体验，但增加了一些个性化的功能。

原本我是打算使用 Tauri 开发的，但是在处理 libvips 和 pngquant 的动态、静态编译时遇到了一些技术难题，所以最终选择了更成熟的 Electron 框架。

🖼️ 预览

🚀 文汇 - 文档管理平台

在企业应用开发过程中，我们经常需要提供各种合规文档，比如隐私政策、用户协议、免责声明等，这些文档通常需要定期更新，以确保它们符合最新的法律法规和公司政策。当我们在小程序中集成这些文档时，通常需要手动更新，非常麻烦，而且需要重新审核，同时网页端应用可能也要展示这些文档，所以一个可以同时服务多端的文档管理工具就比较重要。这也是我创建文汇(wenhui)项目的初衷。

项目的整体框架我是直接从之前的sync-gitea-server项目中继续迭代过来的，所以在开发和配置上会有很多相似的地方。

后来业务上需要使用本服务多项目较少，所以没有继续迭代。未来可扩展的一些方向有文档复制、文档搜索、文档统计等等，也可以做成商业化产品。

文汇是一个文档管理平台，旨在帮助用户更高效地管理和利用文档资源。它提供了一个集中存储、组织和检索文档的系统，同时支持文档的协作和共享。

我为项目创建的 slogan 是：

「汇聚文档，赋能应用」 (Where docs meet apps)

🚀 sync-gitea-server - 代码仓库同步工具

我们开发时的代码仓库一般都放在阿里云效上，刚开始我们尝试使用云效自带的流水线来实践CI/CD流程，但是云效有很多限制，甚至绑定了阿里云的体系，导致很多场景没法实现自动化，于是我们将CI/CD流程迁移到内网实现。我们对比了一些开源方案，最终选择Gitea作为代码同步仓库，并使用Gitea自带的Actions来实现CI/CD流程。Gitea的几个特点正好符合我们的需求：

• 轻量级，资源消耗少，部署简单
• 支持兼容Github Actions的语法来实施CI/CD流程，可以直接服用现有的大量Actions能力
• 支持LDAP认证，可以直接使用内网的用户体系

唯一的问题是无法实现自动、实时地从云效同步代码到Gitea，于是我开发了sync-gitea-server项目，用于实现自动、实时地从云效同步代码到Gitea。项目的整体框架我是直接从之前的fake-sms项目中复制过来的，所以代码结构上会有很多相似的地方。

sync-gitea-server是一个用于同步代码仓库的 webhook 服务器。当上游代码仓库（如云效）发生变更时，它会向此服务器发送webhook 事件，服务器随后调用Gitea API 来同步这些变更。

通过这个服务器，我们可以实现代码仓库的自动、实时同步，无需人工干预。目前该项目已经在我们内网运行，新项目都已经接入，非常稳定。

🖼️ 预览