3万人民币出头,可以买到支持cuda、原厂出品且合法的桌面AI工作站。测试Qwen3-Next-80B-A3B-Instruct-FP8 占满显存,基本是可以运行的最大尺寸模型,每秒生成422个tokens!
spark真容.jpg
spark测试数据.png

# ab_benchmark.sh
#!/usr/bin/env bash
set -euo pipefail

usage() {
  cat <<EOF
Usage: $0 -h <host:port> -m <model> -p <prompt> -g <gen_tokens> -n <total_requests> -c <concurrency>

Required:
  -h  Host:Port of vLLM server (e.g., 127.0.0.1:8000)
  -m  Model identifier (as you use in request)
  -p  Prompt text (e.g., "你好,你是谁?")
  -g  Expected generated token count (integer)
  -n  Total number of requests for ab
  -c  Concurrency for ab

Example:
  $0 -h 127.0.0.1:8000 -m "/models/qwen-full/Qwen3-Next-80B-A3B-Instruct-FP8" \
    -p "你好,你是谁" -g 128 -n 100 -c 5
EOF
  exit 1
}

HOST=""
MODEL=""
PROMPT=""
GEN_TOKENS=""
TOTAL_REQ=""
CONCURRENCY=""

while getopts "h:m:p:g:n:c:" opt; do
  case $opt in
    h) HOST="$OPTARG";;
    m) MODEL="$OPTARG";;
    p) PROMPT="$OPTARG";;
    g) GEN_TOKENS="$OPTARG";;
    n) TOTAL_REQ="$OPTARG";;
    c) CONCURRENCY="$OPTARG";;
    *) usage;;
  esac
done

if [[ -z "$HOST" || -z "$MODEL" || -z "$PROMPT" || -z "$GEN_TOKENS" || -z "$TOTAL_REQ" || -z "$CONCURRENCY" ]]; then
  usage
fi

AB_LOG="ab_chat_${MODEL//[:\/]/_}_${TOTAL_REQ}n_${CONCURRENCY}c.log"
PAYLOAD="ab_chat_payload.json"

# Build the payload
cat > $PAYLOAD <<EOF
{
  "model": "${MODEL}",
  "messages": [
    {"role": "system", "content": "你是一个有帮助的AI助手"},
    {"role": "user", "content": "${PROMPT}"}
  ],
  "temperature": 0,
  "max_tokens": ${GEN_TOKENS}
}
EOF

echo "Running ab with payload:"
cat $PAYLOAD
echo

# Run ApacheBench
ab -n $TOTAL_REQ -c $CONCURRENCY -s 30000 \
  -T "application/json" \
  -p $PAYLOAD \
  http://${HOST}/v1/chat/completions > $AB_LOG 2>&1

echo "ab log saved to $AB_LOG"
echo

# Extract metrics
RPS=$(grep "Requests per second:" $AB_LOG | head -n1 | awk '{print $4}')
MEAN_LAT=$(grep "Time per request:" $AB_LOG | head -n1 | awk '{print $4}')
# Estimate token throughput
TPS_EST=$(echo "$RPS * $GEN_TOKENS" | bc)

echo "===== Result ====="
echo "Host:                 $HOST"
echo "Model:                $MODEL"
echo "Prompt:               $PROMPT"
echo "Total requests (ab):  $TOTAL_REQ"
echo "Concurrency (ab):     $CONCURRENCY"
echo "Estimated Gen Tokens: $GEN_TOKENS"
echo
echo "Requests/sec:         $RPS"
echo "Mean Latency(ms):     $MEAN_LAT"
echo "Est. Tokens/sec:      $TPS_EST"
echo
# 启动方法
./ab_benchmark.sh \
  -h localhost:8000 \
  -m "/models/qwen-full/Qwen3-Next-80B-A3B-Instruct-FP8" \
  -p "你好,你是谁" \
  -g 250 \
  -n 30 \
  -c 5

深入体验 Codex、Gemini3 之后,我只有一个感受:
人类从未如此接近“造物主”,而我从未如此接近“被淘汰者”。

按下回车、等待数秒,一个人就能瞬间成为世界的塑造者。
而我几十年的积累,在模型面前,只剩一句 prompt 的价值。

《在线假期排班》《hey 小维语音唤醒》《婚姻模拟器》……
那些“根本不可能”的想法,在 AI 手里柔软得像橡皮泥。

学习速度?反应速度?思维广度?
原以为是人类智慧的荣耀,如今被 model=gpt5.1 轻松碾压。
二十年构建的经验体系,在它面前甚至成为拖累。

我站在 AI 这座大山脚下,抬头看不见山顶。
这并不是被时代抛弃——
而是这个时代根本没有“我”。
那种无力感,不是差一点,而是差一个物种。

努力四十年,却在技术洪水前脆弱得像一张卫生纸。
所谓价值、意义、努力,
会不会只是慢速时代的幻觉?

越欣喜它的强大,越感到自己的渺小。
这一刻,我不知道该为时代欢呼,还是为自己默哀。

——2025.11.24 共勉

突然在阿里云控制台上看到,可以设置cname的权重,印象里只有mx记录有优先级!特意去查了DNS规范,确实没有

实践是检验真理的唯一标准,开干

2025-10-29T03:10:20.png
按标准dns协议,cname记录是没有“权重”、“优先级”的,阿里应该是自己实现,不是标准,无法影响其他DNS服务器,换句话说,通过DNS控制服务权重不可靠,用户必须使用阿里的dns才能实现。当玩具用吧

在我们的商业场景中,设备和云端需要低消耗、可靠的连接。最终我们使用了mqtt协议。
初代方案
CLB--HAproxy--内网CLB--EMQ集群,稳定维持几百万连接

当前方案
云推出各种负载均衡产品,如ALB、NLB,在和厂商交流过程中,NLB具备卸载证书、限速,天生适合物联网,考虑切换
NLB--EMQ--CLB

随着权重的调整,看着新NLB连接稳定上升!但观察到一直停留在75万连接就上不去了
2025-10-28T02:51:44.png

经过排查,在官方文档中看到NLB对于单一后端服务器的限制 https://help.aliyun.com/zh/slb/network-load-balancer/product-overview/restrictions-on-use “NLB服务器组禁用客户端地址保持功能时,每个可用区的NLB与单一后端服务器(或IP)的组合最多可支持60,000条并发连接。并发超过此限制会自动弹出新的Local IP避免端口分配失败,每个可用区最大支持扩展至8个Local IP,此时每个可用区的NLB与单一后端服务器(或IP)的组合最多支持250,000条并发连接,请确保交换机空闲的IP地址充足以免影响弹性。”
当连接数超百万时提前找阿里云“预热”,后端服务器、NLB都遵循五元组限制

今年4月采购Apple Mac Studio 在本地离线运行模型,实现了云故障诊断的本地化与安全闭环。此方案获得Apple官方认可,被选为典型案例,并由其出资拍摄宣传短片。影片将展示双方品牌Logo,用于宣传。充分展现了商米运维在技术创新上的实力与成果。

两三年前,无意刷到“杨旭游记”视频,独特的房车旅游形式,杨旭操着一口京腔娓娓道来,主人公大多数是自己。从祖国的边陲到非洲的角落,偶尔在寒暑假有他女儿客串。
从一个人穿越500公里无人区,在石油小镇“大漠孤烟直”
到路途中遇到更多房车朋友,在南疆品尝哈萨克美食。
他的视频有种独特的“慢”感,正好符合心中对美好、自由的享受感。
微信图片_20250909144921_3_9.jpg
上周三,预定了周末两天的房车,临时决定去舟山,距离近。周六早上取车,“房车生活家”位于国家会展中心,场地里有大概30辆左右房车,C型居多。我选择的是上汽大通RV80 C型 舒适版 899/天。工作人员强调此车型驻车空调需要接市电,不适合车内居住。升级到尊享款有7.2度电池,但价格翻倍。

这两天共行驶500公里,高速440公里,路况较佳基本无拥堵。记录
车辆租金:899/天*2
保险:40/天*2,最低档,抵扣出险3000
清洁费:150
油费:柴油,396+180,还车时多出一点,约等于1.1/公里
ETC:470
住宿:1000
优势:

  • 驾驶室非常高,视野很好
  • 人在放车内可以站直,我身高1.85,不压抑
  • 底盘和普通SUV差不多,通过性还好
  • 人能躺平,有额头床,车位有两张上下铺的单人床。小朋友和老人能休息

微信图片_20250909144921_2_9.jpg
缺陷:

  • 隔音差,可能和车龄有关,发动机声音直逼座舱,轰隆隆的
  • 变速箱顿挫,AMT手动挡加换挡单元,用A档的时候明显在6档-5档的时候卡一下
  • 动力一般,深踩油门100,持续10-15秒,到110,半分钟缓慢120,踩到底就130
  • 车身高不能进地库,尤其3.2米超高的C型车,注意一定不要靠路边行驶,树枝会刮到车顶!
  • 车内有粘木头的胶水味,暴晒后还是能闻到,这可是有7年车龄的老车
  • 性价比低,想当然认为自带电池足以晚间空调
  • 上下水麻烦,上厕所自己倒黑水箱,全程要小朋友去公厕上了

这款房车,房、车属性都没做好,称其为“床车”更贴切,晚上还是得去宾馆。租房车的价格体系不合理,同样的价格能租车+豪华型酒店
微信图片_20250909144920_1_9.jpg

日常工作会碰到众多文字汇报,如周报、事故贴、分析报告等。本质是填充内容到制式文档中
联想场景:

  1. 每周从任务系统中查看、汇总任务进展形成周报,记录在钉文档中
  2. 在繁杂的事故后总结,人员发言、故障截图、日志片段等,按照事故贴格式梳理时间轴、OCR、总结
  3. 处理新事故时,总结SOP,发布到知识库

看效果,我们的内部任务看板是TB,需要总结上周某板块的内容,按照格式进行总结、归纳
输出markdown格式
微信图片_2025-07-23__172533369.png

输出docx文件,可下载
微信图片_2025-07-23_172956_160.png

流程图
20250723173348.jpg

关键步骤

# 代码执行环节
def main(start_date: str, end_date: str, text: list) -> dict:
    import csv, io, json
    from datetime import datetime

    # 连接文本行
    content = "\n".join(text)
    reader = csv.DictReader(io.StringIO(content), delimiter='|')

    sd = datetime.strptime(start_date, "%Y-%m-%d").date()
    ed = datetime.strptime(end_date,   "%Y-%m-%d").date()

    total_rows = 0
    filtered = []

    for row in reader:
        total_rows += 1

        # 清洗字段名可能含空格
        ct_raw = row.get("创建时间") or row.get(" 创建时间 ") or ""
        ct_raw = ct_raw.strip()
        if not ct_raw:
            continue

        # 解析多种时间格式
        ct = None
        for fmt in ("%Y/%m/%d %H:%M", "%Y-%m-%d %H:%M",
                    "%Y/%m/%d %H:%M:%S", "%Y-%m-%d %H:%M:%S"):
            try:
                ct = datetime.strptime(ct_raw, fmt)
                break
            except:
                pass
        if not ct:
            continue

        # 筛选时间范围
        if sd <= ct.date() <= ed:
            filtered.append(row)

    output = {
        "total_rows": total_rows,
        "total_filtered": len(filtered),
        "filtered": filtered
    }

    return {"result": json.dumps(output, ensure_ascii=False)}


# LLM提示词
下面有一段 JSON 输出,变量名为{{#1753088011989.result#}},结构如下:
- total_rows:原始行数
- total_filtered:符合时间范围的记录总数
- filtered:数组,每个元素是一行解析后的字典,包含列字段

请直接生成一段markdown格式周报:
1. 将每一行的标题、备注进行总结,稍微扩展,保证总体意思清晰不啰嗦,放在下方的分类中(项目支持、TMS、成本、日常、其他);
2. 序号、条理清晰。

示例输出格式:

## 周报摘要
- 总行数:...
- 筛选数:...

# 运维部2025W28

# 项目支持

## 网关

*   复用已有的云效maven仓库,当前规则 
*   开发过程涉及基础设置,无费用新增。可复用,比如已有的云效xxx仓库
*   “绕圈”,不建议。如堡垒机、监控等,流量走一遍阿里云出境再到AWS
*   有费用产生,自行搞定。特殊情况再讨论
*   参与周五AWS workshop,明确需求是,网关团队注意兜底措施,最关键数据库跨云、跨区域、跨账号备份。**厂商答复支持**,待业务稳定后增加

## DMP
*   rocketmq5.0原价使用一年(4.0版本xxx折),申请折扣中,尝试追索些代金券
*   MSE升级完成,未发现异常
*   AU开源版nacos已接入ops平台  
*   kubernetes版本加白,列为技改待办。风险、收益详见文档 。集群承载应用,连接基础设施。和程序框架类似,谨慎升级
# TMS
# 成本
# 日常
# 其他


写技术文档一直是挺花时间,也挺头疼的一项任务。更头疼的是还要配图!
先看效果(推荐手机端观看,可放大):
microservices_architecture-2025-07-03T02-16-12-285Z.png

画的还是有模有样,看步骤
cursor或chatbox添加mermaid MCP
MCP添加方式:
20250703104821.jpg

**提示词:**
生成一个微服务架构图,包含以下组件:
1.前端层:Web客户端、移动客户端
2.API网关层:负责请求路由和统一认证
3.服务集群层:用户服务、订单服务、支付服务、商品服务
4.数据层:MySQL数据库、Redis缓存、MongoDB、Doris、Elasticsearch搜索引擎
5.运维工具层:Prometheus监控、Grafana展示、Kubernetes容器编排

要求如下:

1.使用分层结构展示组件
2.标注各组件之间的通信协议(如REST、gRPC、tcp等)
3.使用不同颜色区分服务类型(如客户端、网关、服务、存储、运维)
4.图中内容必须使用英文
5.使用上下结构,保持图形为长方形
图像保存路径为:/Users/jixing/Downloads/

在今年的大模型落地背景下,敏感信息不和共有模型交互。我们分别评测了 A100 8卡、4090、H800、H20,动辄百万级,在前期探索阶段很难拿到产出数据支撑。
梳理需求后发现,90%场景是推理,只有AI部门涉及训练任务。推理性能和性价比成为重点。

此时注意到,Mac Studio在M2 Ultra芯片上采用了统一内存架构(内存≈显存),可用于推理大型模型。油管也已有博主实测运行 deepseek-R1:671b。

最终选择购入最新的M3 Ultra Mac Studio

  • CPU&GPU:Apple M3 Ultra 芯片 (32 核中央处理器、80 核图形处理器和 32 核神经网络引擎)
  • MEM:512G统一内存

价格不到7万。实测默认参数下,可以运行 deepseek-R1:671b,30个并发响应轻松,推理速度可接受。
20250428144653.jpg
m3ultra.JPG
Mac Studio并不是为全天候服务器设计

虽然推理能力超出预期,但Mac Studio天生不适合全天候服务器,主要存在以下问题:

  1. 重启后需本地登录。即使启用远程登录(SSH)和屏幕共享(VNC),每次重启后,必须在本机物理登录一次,远程连接功能才能恢复。这使得无人值守场景下,稳定性有损失。
  2. 服务部署与Linux不同。在Mac上安装、配置守护进程,与Linux系统差异较大,需要额外适配工作。例如,Ollama绑定地址、环境变量设置,都需要用 launchctl 手动配置。

稳定运行的必要设置

为了最大化稳定性,必须手动关闭系统的各种休眠机制:

# 防止系统进入睡眠
sudo systemsetup -setcomputersleep Never

# 防止显示器睡眠
sudo systemsetup -setdisplaysleep Never

# 防止硬盘休眠
sudo systemsetup -setharddisksleep Never

# 验证配置
systemsetup -getcomputersleep
systemsetup -getdisplaysleep
systemsetup -getharddisksleep

# 设置Ollama监听所有IP地址
launchctl setenv OLLAMA_HOST "0.0.0.0"

# 调整GPU共享内存限制,必选!否则大尺寸模型跑不起来
sudo sysctl iogpu.wired_limit_mb=491520

在 deepseek-r1:32b 中小尺寸模型下,A100 单卡可提供 1.8QPS,单问题 7 秒内完成响应。 对于小团队够用。 单卡推理比4090弱

2025-04-11T03:24:11.png

  • 服务器硬件配置:
    ○ CPU:Intel(R) Xeon(R) Platinum 8336C CPU @ 2.30GHz * 2
    ○ GPU:NVIDIA A100-SXM4-80GB * 8
    ○ MEM:1960G
  • 网络:本机
  • 测试工具:Apache Benchmark (ab)
  • 模型:deepseek-r1:32b
ab -n 1000 -c 10 -s 30000 -T "application/json" -p payload.json -v 4 http://1.1.1.1:11434/v1/completions > ab_detailed_log01.txt 2>&1

# payload.json
{
  "model": "deepseek-r1:32b",
  "prompt": "你好,你是谁?"
}

2025-04-11T03:26:27.png

并发数总请求数成功请求数失败请求数吞吐率 (请求/秒)平均响应时间 (毫秒)95% 响应时间 (毫秒)最长响应时间 (毫秒)
101000100001.825504.49570018423
501000100001.8227520.9912950632275
1001000100001.8354613.0305713258628
1501000100001.8182645.2948717090249
2001000100001.82110118.858113820117009
4001000100001.82220315.946222405224113
8001000100001.24644384.462688739698507

8卡A100,可运行deepseek-r1:671b(671b-q4_K_M 404GB),响应较慢
2025-04-11T03:23:50.png

你购买了test.dev 需要跳转到 test.com,在godaddy上仅需配置转发,http(s)://test.dev 都可正常跳转。在国内云仅支持http://test.dev→https://test.com,https://test.dev不支持

购买差异

指标GoDaddy国内厂商
新顶级域支持实时开放注册(.dev/.app/.io等)暂不支持
备案要求有(法规要求),未备案部分解析功能受限

URL转发机制差异

特性GoDaddy国内云
协议支持同时支持HTTP HTTPS仅支持HTTP明文跳转
证书管理自动续签(ACME协议集成)需手动上传第三方证书

协议测试

# GoDaddy HTTPS重定向验证
curl -v https://test.dev

输出字段可以看到自动帮你加了godaddy颁发证书

结论

在deepseek-r1:32b较大尺寸模型下,4090单卡可提供3QPS,单问题4.4秒内完成响应。 对于个人,几十人小团队够用。

优点:

  • 本地模型问题过滤少,同样问题,官方无法回答,本地可以
  • 速度尚可,不会服务器繁忙
  • ollama动态显存占用,5分钟不问,默认不占用显卡,不影响游戏:)

缺陷:

  • 无搜索、图片识别功能,当然这也不是模型的问题,要借助flowise这种langchain编排工具实现
  • 有一定硬件要求,单卡显存越大越好,推荐3090/4090

no-answer.png

  • 低至中等并发:单卡4090在并发数从10到400时,系统表现稳定,吞吐量和响应时间均在可接受范围内。2.9QPS
  • 高并发情况:单卡在并发数为800时,吞吐量显著增加,但响应时间波动较大,且最大响应时间大幅上升,可能存在性能瓶颈。
  • 系统稳定性:系统在高并发压力下依然能保证请求的成功率,但响应时间波动可能影响整体用户体验

测试环境

  • 服务器硬件配置

    • CPU:AMD Ryzen Threadripper PRO 5975WX 32-Cores
    • GPU:1 x NVIDIA RTX 4090
    • MEM:128G
  • 网络:本机
  • 测试工具:Apache Benchmark (ab)
  • 模型:deepseek-r1:32b
  • 压测命令
ab -n 1000 -c 10 -s 30000 -T "application/json" -p payload.json -v 4 http://1.1.1.1:11434/v1/completions > ab_detailed_log01.txt 2>&1
- **请求总数**:1000

- **并发数**:逐渐升高

- **超时设置**:30秒(`-s 30000`)

- **请求类型**:POST,传送JSON格式的负载
 {
  "model": "deepseek-r1:32b",
  "prompt": "你好,你是谁?"
}

load-test-image.png

测试数据分析

并发数总请求时间(秒)成功请求数失败请求数吞吐量 (请求/秒)平均响应时间 (毫秒)最大响应时间 (毫秒)95% 响应时间 (毫秒)
10344.899100002.903448.9970734424
50341.55100002.9317077.4942027418333
100343.880100002.9134387.9773952335580
150337.687100002.9650653.0325313451942
200340.978100002.9368195.5087073369537
400351.865100002.84140746.048141672139774
800250.2617162844200208.529249642231555

背景

本地部署DeepSeek-Coder-V2-Lite-Instruct:14b。要求基础的高可用、监控、安全能力。ollama默认只能使用第一张显卡,多个模型同时调用会有bug(ollama ps显示100GPU,但使用CPU推理);无法高可用

具体方案

多GPU Ollama部署方案,通过系统服务化+负载均衡实现4块4090显卡的并行利用,边缘使用nginx负载均衡。

  • 服务器名:AIGC-01
  • 服务器硬件配置

    • CPU:AMD Ryzen Threadripper PRO 3955WX 16-Cores
    • GPU:4 x NVIDIA RTX 4090
    • MEM:128G
  • 模型:DeepSeek-Coder-V2-Lite-Instruct:14b

ollama配置

# 备份ollama
cd /etc/systemd/system/
mv ollama.service ollama.service.bak

# 创建4个独立服务文件(每个GPU对应一个端口)
for i in {0..3}; do
sudo tee /etc/systemd/system/ollama-gpu${i}.service > /dev/null <<EOF
[Unit]
Description=Ollama Service (GPU $i)

[Service]
# 关键参数配置
Environment="CUDA_VISIBLE_DEVICES=$i"
Environment="OLLAMA_HOST=0.0.0.0:$((11434+i))"
ExecStart=/usr/local/bin/ollama serve

Restart=always
User=ollama
Group=ollama

[Install]
WantedBy=multi-user.target
EOF
done


# 重载服务配置
sudo systemctl daemon-reload

# 启动所有GPU实例
sudo systemctl start ollama-gpu{0..3}.service

# 设置开机自启
sudo systemctl enable ollama-gpu{0..3}.service

nginx配置

nginx 需要编译额外模块,用于健康检查

root@sunmax-AIGC-01:/etc/systemd/system# nginx -V
nginx version: nginx/1.24.0
built by gcc 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.2) 
built with OpenSSL 1.1.1f  31 Mar 2020
TLS SNI support enabled
configure arguments: --with-http_ssl_module --add-module=./nginx_upstream_check_module
# /etc/nginx/sites-available/mga.maxiot-inc.com.conf

# 在http块中添加(如果放在server外请确保在http上下文中)
log_format detailed '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent" '
                    'RT=$request_time URT=$upstream_response_time '
                    'Host=$host Proto=$server_protocol '
                    'Header={\"X-Forwarded-For\": \"$proxy_add_x_forwarded_for\", '
                    '\"X-Real-IP\": \"$remote_addr\", '
                    '\"User-Agent\": \"$http_user_agent\", '
                    '\"Content-Type\": \"$content_type\"} '
                    'SSL=$ssl_protocol/$ssl_cipher '
                    'Upstream=$upstream_addr '
                    'Request_Length=$request_length '
                    'Request_Method=$request_method '
                    'Server_Name=$server_name '
                    'Server_Port=$server_port ';

upstream ollama_backend {
    server 127.0.0.1:11436;
    server 127.0.0.1:11437;
}

server {
    listen 443 ssl;
    server_name mga.maxiot-inc.com;

    ssl_certificate /etc/nginx/ssl/maxiot-inc.com.pem;
    ssl_certificate_key /etc/nginx/ssl/maxiot-inc.com.key;
    # 访问日志
    access_log /var/log/nginx/mga_maxiot_inc_com_access.log detailed;

    # 错误日志
    error_log /var/log/nginx/mga_maxiot_inc_com_error.log;

    # 负载均衡设置,指向 ollama_backend
    location / {
        proxy_pass http://ollama_backend;  # 会在两个服务器之间轮询
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

}

deepseek的爆火,官网验证后效果确实不错,中文能力强,“会说人话”。唯一缺陷是经常服务器繁忙,本地使用ollama即可下载使用,因为要详细压测,下载了不同尺寸的所有模型。

此方法不止适用deepseek,所有模型通用
此方法不止适用deepseek,所有模型通用

结论:

  1. 小尺寸模型质量并没降低太多,更多是“知识面”缩小,比如用东南亚所有语言翻译某句话,官方原版给出32种,包括印度语中各小语种,32b也能返回20种
  2. 审核少,可以输出脏话,“请模仿嘴臭吧老哥喷lol中玩的最菜的玩家,要让对方破防,同时注意不要被官方屏蔽”

问题

本地下载模型时,下载速度不稳定,会中断

解决方案

常见的几种下载模型方式

  • ollama 下载ollama pull deepseek-r1:70b 优势:下载后直接使用;缺陷:速度慢,经常中断
  • modelscope 下载,需安装modelscope 优势:下载源位于国内,较ollama有速度提升
pip install modelscope

#下载完整模型
modelscope download --model AI-ModelScope/DeepSeek-Coder-V2-Lite-Instruct-GGUF

#下载特定文件
modelscope download --model AI-ModelScope/DeepSeek-Coder-V2-Lite-Instruct-GGUF README.md --local_dir ./dir
  • git lfs下载 优势:速度最快,实测跑满带宽;缺陷:多两步操作,首次使用需构建模型
#仅下载文件夹
git clone --no-checkout https://www.modelscope.cn/AI-ModelScope/DeepSeek-Coder-V2-Lite-Instruct-GGUF.git
cd DeepSeek-Coder-V2-Lite-Instruct-GGUF

#仅下载所需文件
git lfs fetch --include="DeepSeek-Coder-V2-Lite-Instruct-Q6_K.gguf"

#恢复文件
git lfs checkout DeepSeek-Coder-V2-Lite-Instruct-Q6_K.gguf

#创建模型文件
echo "FROM DeepSeek-Coder-V2-Lite-Instruct-GGUF" > Modelfile

#创建模型
ollama create DeepSeek-Coder-V2-Lite-Instruct:14b -f Modelfile

#使用
ollama run DeepSeek-Coder-V2-Lite-Instruct:14b

由多个agent组成的SRE专家组,代替人工进行准确的故障分析!👽

流程:从用户输入取时间范围(支持上传图片)、路由--》查询日志中心--》获取网关中cmdb信息--》查询CMDB获取更多细节(owner、变更、jenkins、gitlab信息)--》分析并给出建议:

111.jpg

222.jpg

执行效果:

图中是判断某接口504故障,从依据到结论过程
333.jpg

444.jpg

555.jpg

步骤

使用flowise,配置langchain中AgentFlow

创建supervisor

- 阅读剩余部分 -

interview-blog-21-0702.png
近期借一位业内朋友推荐,面试了一家位于新加坡的互联网企业,同样记录面试过程
一面(远程):
业务线运维负责人,是一位年轻女士,在问明不需要露脸后开始。从自我介绍到了解的技术栈,擅长的方向,排错问题等。问到“擅长的方向”时,忽然一愣,眼瞅也是17年的老运维人了,但还真没觉得擅长什么。只能说阶段性的尝试过一些新技术,23年至今,甚至有点不务正业,可以不负责任的说,“运维里最了解大模型的,大模型里最了解运维”的复合型人才:) 接触越多也愈发觉得知之甚少,这也是我在简历中不敢用“精通”二字。收回来,讲了几个模型应用的实际案例

  • 微信聊天记录微调chatGLM
  • Voice2SQL
  • 智能运维机器人

23年以前,容器、网格、网关的落地、使用过程,举了几个排错。提到当前基础设施情况,使用了terraform,交流了优势和建议做法,terraform结合ansible快速拉起。在容器编排有更好的解法Cluster Autoscaler叠加Horizontal Pod Autoscaler。面试官最后礼貌的问了薪资,并贴心的补充可以不回答,基于信任,如实告知,一面结束,面试官准时,用时45分钟

二面(远程):
跨团队面试,一位男士,可能负责研发,同样的过程,自我介绍到过往经历。分享了几个经典、复杂的排错案例,也都是博客的历史文章。着重问了CDN厂商的从业经历,简历外有无其他经验,以往离开的原因等。二面结束,面试官因为凌晨处理故障到5点,迟到半小时,表示理解,实际用时49分钟

- 阅读剩余部分 -

Software_Architect.png
多年的运维感悟,什么阶段干什么事。这也是我在内部的运维规范里明确标明,“不提前优化”

我来谈谈几个阶段,

初创阶段

部分参考 原文链接:https://mp.weixin.qq.com/s/vVhLZDL6bRJL9u5GJg63tw

  • 初创阶段,更多关注业务最小模型能否跑通

    • 快速实现
    • 熟悉什么技术栈,就用什么
    • allinone
    • 引入ORM、DAO屏蔽sql复杂性
    • 早期不自研
    • 规模扩大的时候,要浅浅的封装一层,防止日后技术栈更新,控制数量。我称之为“有中台作用,但无中台负重”
    • 只有在开源社区无法满足时,再造轮子
  • 需要容量评估的场景

    • 新系统上线
    • 临时活动、大促、秒杀类
    • 系统容量有质变性增长
  • 创业初期最贵的是时间成本,这个阶段用钱堆资源的方式可以快速解决问题,不贸然重构
  • 有些明显的规则要遵守,比如

    • 不能硬编码IP,使用域名
    • 域名见名知意,区分内外,比如baidu.com / baidu-inc.com
    • 区分生产环境
    • 避免账号公用

步入正轨阶段

  • 这时候就要拆分了,上面提到的allinone可能已经有了性能、容量等压力。此时就要垂直拆分了

    • 核心是基于业务的拆分

      • 代码
      • 数据库、中间件
      • 团队垂直拆分
  • 这时候我们要引入反向代理,最常见的如nginx,我的建议是用更加贴近业务的api网关,比如kong、apisix、openrestry等等,有更多原生功能。如果nginx比作汽车引擎,后者可以比作宝马、奔驰汽车,多了很多配置外,还能开车即用,开箱即用

    • 对应反向代理层也需要高可用,好消息是都是必备能力
  • 服务也要拆分,其中关键的是,尽可能无状态,“状态”尽可能让中间件,redis、mysql、共享存储等手段解决,确保服务动态、快速伸缩

- 阅读剩余部分 -

目标

创建一个具备内部运维知识,识别自然语义,准确调用各种工具执行任务,严格控制幻觉的智能运维工程师。

v0.1 技术方案

方案介绍

使用 OpenAI 的 Assistant 功能,上传知识库,设置提示词。

  • 优势:效果不错,配置简单
  • 劣势:无审计,无法限定回答范围
  • 技术栈:JavaScript/Flowise / Prompt Engineering / OpenAI Assistant

核心内容

Prompt Engineering:

Function Call:通过 Flowise 的自定义工具

v0.1 技术架构

架构图

架构图v1.png

- 阅读剩余部分 -

先看效果

系统架构组件

  1. Streamlit 界面

    • 侧边栏和输入区域:提供用户界面,用于输入数据(如 Azure 端点)并进行配置。
    • 聊天输入和输出区域:主要区域,用户在此与聊天助手交互并查看结果。
  2. LLM(大型语言模型)配置设置

    • OpenAI 配置:配置用于使用 OpenAI 模型(如 gpt-4o-2024-08-06)。
    • 本地 LLM 配置:本地 LLM 模型(如 ollama/llama3:latest)的配置。
  3. 助手代理(AssistantAgent)和用户代理(UserProxyAgent)

    • TrackableAssistantAgent:继承自 AssistantAgent,负责与用户输入进行处理和响应,同时集成在 Streamlit 中以显示聊天消息。
    • TrackableUserProxyAgent:继承自 UserProxyAgent,用于接收用户输入,处理用户命令,并在助手代理与用户之间进行代理交互。
  4. 实用工具函数

    • get_url_info_from_kong:从 Kong API 网关中查询 URL 的路由、服务和上游配置的信息,并返回格式化结果。
    • dns_record_status:检查给定 URL 的 DNS 记录状态。
    • query_from_cmdb:从 CMDB(配置管理数据库)中检索特定云服务提供商(如阿里云、AWS 等)的服务器、数据库和中间件实例的数量。
  5. 异步聊天系统

    • 使用异步事件循环(asyncio),用户代理(User Proxy Agent)可以异步与助手代理(Assistant Agent)进行对话,提供更高效的交互体验。

架构图

+---------------------------------------------------------------+
|                      Streamlit Interface                      |
|---------------------------------------------------------------|
| +-----------------------------------------------------------+ |
| |  Sidebar (Azure Endpoint Config, etc.)                    | |
| +-----------------------------------------------------------+ |
|                                                               |
| +-----------------------------------------------------------+ |
| |                  Chat Input / Output Area                 | |
| |                                                           | |
| |  User Input --> UserProxyAgent --> AssistantAgent         | |
| |                                                           | |
| |  AssistantAgent --> UserProxyAgent --> Output Display     | |
| +-----------------------------------------------------------+ |
+---------------------------------------------------------------+

+--------------------+               +--------------------+
| LLM Configurations |               |   Utility Functions|
|--------------------|               |--------------------|
| - OpenAI (GPT-4)   |               | - get_url_info_from|
| - Local LLM (LLaMA)|               |   _kong()          |
+--------------------+               |   (Interacts with  |
                                     |    Kong API Gateway)|
                                     | - dns_record_status|
                                     |   (Checks DNS)     |
                                     | - query_from_cmdb  |
                                     |   (Interacts with  |
                                     |    CMDB Database)  |
                                     +--------------------+

   +-----------------+               +-------------------+
   | AssistantAgent  | <--- asyncio ->| UserProxyAgent    |
   | (Handles LLM    |               | (Manages User     |
   |  Requests)      |               |  Input/Commands)  |
   +-----------------+               +-------------------+
        ^    |                              ^    |
        |    |                              |    |
        |    v                              |    v
+----------------+                     +-------------------+
|   LLM Config   |                     |  Utility Functions|
|  Setup (OpenAI)|                     | (Kong, DNS, CMDB) |
+----------------+                     +-------------------+

                     +----------------+
                     |   Data Flow    |
                     |----------------|
                     |  - User Input  |
                     |  - Assistant   |
                     |  - ProxyAgent  |
                     |  - Utility Func|
                     +----------------+

架构图描述

  1. 用户输入(通过 Streamlit)
    用户通过 Streamlit 界面输入聊天内容或命令。
  2. 助手代理和用户代理交互
    用户代理接收用户输入,解析并处理命令,然后与助手代理交互。助手代理根据注册的工具函数或LLM配置进行响应。
  3. 工具函数交互
    当助手代理或用户代理调用工具函数时,这些函数将与 Kong API 网关、DNS 解析服务或 CMDB 模拟数据进行交互。
  4. 结果显示
    通过 Streamlit 界面将助手代理和用户代理的响应结果显示给用户。

核心优势

  1. 超越简单的 RAG 和提示词工程

    • 传统的 RAG 方法主要依赖于检索和生成的结合,通过从知识库中检索相关信息并用语言模型生成答案。然而,这种方法局限于信息查询和简单的问答系统,无法处理更复杂的任务。
    • 提示词工程则是通过精细设计提示词来引导语言模型生成特定输出,依然依赖于语言模型本身的生成能力,不能主动与外部系统进行交互或执行特定操作。
  2. 使用 Function Call 完成真实世界的任务

    • 本系统通过引入 Function Call 技术,赋予助手代理(Assistant Agent)和用户代理(User Proxy Agent)调用实际功能的能力。这些功能可以执行复杂的任务,如查询 Kong API 网关中的服务配置、检查 DNS 记录状态、从 CMDB 检索云资源信息等。
    • 通过注册和调用实际的 Python 函数,系统能够与外部 API、数据库和服务进行交互,执行逻辑操作和数据处理。这种能力使得系统不仅限于简单的对话和问答,更能够执行真实世界中的操作任务。
  3. 集成异步交互和高效任务处理

    • 使用异步框架(如 asyncio)实现用户代理和助手代理之间的异步通信,大幅提升了任务处理的效率和响应速度。这样的设计确保了系统能够并发处理多个任务,而不阻塞用户输入和系统响应。
    • 异步处理机制也增强了系统的稳定性和扩展性,使其能够处理更大规模的请求和更复杂的任务逻辑。
  4. 技术含量高,解决复杂场景问题

    • 系统架构充分考虑了实际应用场景中的复杂性,通过模块化设计,支持各种工具函数的集成和扩展,能够适应不同的企业和业务需求。
    • 例如,get_url_info_from_kong 函数能够通过调用 Kong API,获取详细的路由、服务和插件信息,并对这些数据进行格式化处理和展示;query_from_cmdb 函数能够从 CMDB 中动态检索并整合不同云服务商的资源信息。这样的功能大大提升了系统的实际应用价值。
  5. 提升企业运营效率与智能化水平

    • 通过整合各种实用功能和自动化操作,系统能够显著提升企业运维和运营效率。例如,它可以自动查询和管理 API 网关配置、检查网络 DNS 状态、整合和分析云资源数据,帮助企业做出更高效的决策和管理。