关于INTEL 的B70 PRO。
-
想了想还是别另开贴了,搞的好像刷帖一样。
事情是这样的:我想深度的测一下这卡的稳定性。 如果长期去用,去批量跑任务,稳定性就很胆小。 于是就有了这个操作: 朋友让我帮忙处理一批图片,将图片 OCR 出来。 图片都是2K+分辨率的。 图片是一张大概有400-500行/10来列的表格。 用QWEN3.6-27B去反推直接给OCR到excel表格里,我也想看看这卡的能耐咋样,之前有飞浆这些要钱的。也有github上开源的那些,但批量处理这么大的,我没用过。 于是就写了代码,然后试了试这卡的能耐。只用了一张卡,从前天上午不到10点。到刚才。我截图也就是10分钟之前告诉我OK了。 代码如下:
import base64 import os import glob import asyncio import aiohttp from io import BytesIO from PIL import Image API_URL = "http://localhost:8091/v1/chat/completions" IMAGE_DIR = "./cb*.png" OUTPUT_CSV = "./cb_data_full_fixed.csv" # B70 32G 显存并发数 CONCURRENCY = 6 def encode_image_from_bytes(image_bytes): return base64.b64encode(image_bytes).decode('utf-8') def slice_long_image(image_path, slice_height=1500): """ 核心修改:将超长图切片。 slice_height=1500 像素大约包含 30-50 行数据。 """ img = Image.open(image_path) width, height = img.size slices = [] for i in range(0, height, slice_height): # 截取切片区域 (left, upper, right, lower) box = (0, i, width, min(i + slice_height, height)) slice_img = img.crop(box) # 将切片保存在内存中转为 base64 buffered = BytesIO() slice_img.save(buffered, format="PNG") slices.append(buffered.getvalue()) return slices async def fetch_and_process_slice(session, date_str, slice_base64, slice_index, file_lock): payload = { "model": "/model", "messages": [ { "role": "system", "content": "你是一个无情的数据提取机器。直接输出CSV,不要任何多余文字。" }, { "role": "user", "content": [ { "type": "text", "text": "提取图片表格中所有可转债数据。请直接输出CSV格式。每行字段为:转债代码,转债名称,价格,涨幅,正股,正股价,溢价率。注意:不要包含表头,不要使用Markdown代码块(如 ```csv)。如果图片中没有完整数据行,请不要编造。" }, { "type": "image_url", "image_url": { "url": f"data:image/png;base64,{slice_base64}" } } ] } ], "max_tokens": 4096, "temperature": 0.0 } try: async with session.post(API_URL, json=payload) as response: if response.status != 200: print(f"⚠️ {date_str} (切片 {slice_index}) 请求失败") return res_json = await response.json() result = res_json['choices'][0]['message']['content'].strip() async with file_lock: with open(OUTPUT_CSV, "a", encoding="utf-8-sig") as f: for line in result.split('\n'): # 过滤掉可能的空行和重复生成的表头 if line.strip() and "," in line and "代码" not in line: f.write(f"{date_str},{line.strip()}\n") except Exception as e: print(f"❌ 处理 {date_str} (切片 {slice_index}) 发生异常: {e}") async def main(): image_list = sorted(glob.glob(IMAGE_DIR)) if not image_list: print(f"❌ 错误:没有找到符合 {IMAGE_DIR} 的图片!") return print(f"🔥 找到 {len(image_list)} 张超长图,准备进行切片并高并发推断...") if not os.path.exists(OUTPUT_CSV): with open(OUTPUT_CSV, "w", encoding="utf-8-sig") as f: f.write("日期,转债代码,转债名称,价格,涨幅,正股,正股价,溢价率\n") semaphore = asyncio.Semaphore(CONCURRENCY) file_lock = asyncio.Lock() async def sem_task(session, date_str, slice_bytes, index): async with semaphore: slice_b64 = encode_image_from_bytes(slice_bytes) await fetch_and_process_slice(session, date_str, slice_b64, index, file_lock) timeout = aiohttp.ClientTimeout(total=None) async with aiohttp.ClientSession(timeout=timeout) as session: tasks = [] for img_path in image_list: date_str = os.path.basename(img_path).replace("cb", "").replace(".jpg", "").replace(".png", "") # 对超长图进行切片 slices_bytes = slice_long_image(img_path) print(f"✂️ {date_str} 被切分为 {len(slices_bytes)} 块,加入队列...") for index, slice_bytes in enumerate(slices_bytes): tasks.append(sem_task(session, date_str, slice_bytes, index)) # 将所有切片任务并发执行 await asyncio.gather(*tasks) print("🎉 全部长图切片处理完成!去检查数据量吧!") if __name__ == "__main__": asyncio.run(main())具体处理的图片不方便粘贴,但文件夹内的样子可以放一下。两个箭头一个是这个代码文件,一个是需要处理的图片有240多张。每一个图片都是1440宽,大概20000+像素高。




显卡的温度和占用,只用看ID 3就行。:

显卡的占用。不同的命令显示的有所区别。 只用看ID 3就行。

portainer 监控 docker 的截图

模型信息和docker运行的时间

可以看到全程这个GPU的占用率都在95%以上。 时间用了16个小时。 一直没停。 结论是:这卡目前稳定性还是相当NB的,当然,也可能是和我的任务复杂程度有关系?现在是6个并发数,同时处理6个图片。这是第一批。第二批我会尝试加大并发处理量来再跑跑。
-
系统 于 取消固定此主题
-

忘了贴最终的数据量了。 请原谅我的打码效果.... 哇哈哈哈

下边这张,是在linux上的截图,文件的创建时间是昨天上午的11.36,但在创建文件之前,代码已经运行了一个小时了,它得去把这200多个文件全部都截取成一个一个的小块才能读取数据OCR数据。所以文件时间就晚了一个小时。
-
S sirwang 于 引用了 此主题
-
@yhua122 这个帖子正好有两份 B70 PRO 跑 Qwen3.6-27B 的一手数据,直接给你结论:
-
单流速度(你最关心的):B70 PRO 的有效内存带宽约 500GB/s(用帖子里 sirwang 的 Qwen3-8B FP8 实测反推:8.8G 权重 × 57 t/s)。Qwen3.6-27B 量化到 Q4_K_M 约 16-17G 权重,单流解码理论上限约 30 t/s,实际 20-25 t/s 左右。这个速度跑交互式对话能用,但明显不如 R9700/7900XTX 那档。
-
帖子里 kaifan 的单卡 llmscaler 实测(PID:3037):prefill 速度还可以,decode 偏慢,但配合 vLLM 的 continuous batching 并行 token 生成整体很稳,他现在专门拿这张卡给 Hermes 的 delegate 任务用。sirwang 的 8 并发压测能到 ~180 token/s,那是聚合吞吐,不是单流速度。
-
显存要注意:27B FP16 是 55.6G,32G 显存根本塞不下,要么量化(Q4 能装下),要么走共享内存——共享内存带宽差很多,别指望速度。想跑 FP8 的 27B(约 28G)倒是刚好卡在 32G 里,但 decode 会更慢。
如果你手里已经有 7900 XTX(看你发的 H3 速度帖),跑 Qwen3.6-27B 单流能到 80+ t/s(坛里 TID:792 实测同架构 35B-A3B 也是 80+),比 B70 快 3-4 倍。B70 PRO 32G 的价值是"便宜大显存",适合 27B FP8、35B-A3B Q8 这类 24G 装不下的模型,或者多路并发批量任务。只跑 27B Q4 的话,24G 的 7900 XTX 已经够了,B70 的优势发挥不出来。
-