跳转至内容
  • 版块
  • 最新
  • 标签
  • 热门
  • 用户
  • 群组
皮肤
  • 浅色
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • 深色
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • 默认(不使用皮肤)
  • 不使用皮肤
折叠
品牌标识

抡锤者

  1. 主页
  2. AI硬件
  3. 关于INTEL 的B70 PRO。

关于INTEL 的B70 PRO。

已定时 已固定 已锁定 已移动 AI硬件
57 帖子 15 发布者 625 浏览
  • 从旧到新
  • 从新到旧
  • 最多赞同
回复
  • 在新帖中回复
登录后回复
此主题已被删除。只有拥有主题管理权限的用户可以查看。
  • K 离线
    K 离线
    kaifan
    编写于 最后由 编辑
    #46

    分享一下单卡跑llmscaler数据
    周末把 Qwen3.6-27B 调到了一个对于 Agentic Loop 来说还算能接受的状态。比较系统的跑了一下单请求和并行 5 rep的benchmark。pp速度还可以,但 tg还是有点慢。不过配合 vLLM 的 continuous batching,并行 token 生成整体还比较稳定。目前专门用来给Hermes agent的delegate task去收集代码库context打下手

    目前唯一比较大的问题是:KV Cache 必须使用 BF16,才能达到可用的 token generation 速度,但ctx就只有43000了。另外还需要骗 vLLM,让它识别 layer architecture。希望未来能有优化过的 FP8 dequant kernel去支持fp8的kvcache。fp8的dequant比Q8_0慢很多,可惜官方docker的vllm版本还不支持除了fp8和bf16以外的kvcache dtype。可惜它和7900xtx都没有fp8的硬件支持,好像r9700有。另外autoround质量还是稍微比不过Q4的gguf

    硬件比较旧 64g的ddr4 虽然比较慢,但总比 pcie4x16 快。proxmox 9.1

    vLLM 单请求 qwen/qwen3.6-27b(int4 AutoRound):

    PP TTFT:1,685 ms

    PP2048 TPS:1,686 ± 66 tok/s

    TG512:13.7 ± 1.4 tok/s

    并行测试 pp2048 tg512
    Conc: 1
    • TTFT(ms): 1,261
    • Prefill(tok/s): 1,400
    • Decode(tok/s): 13.3
    • Output(tok/s): 12.9

    • Conc: 2
    • TTFT(ms): 1,907
    • Prefill(tok/s): 925
    • Decode(tok/s): 12.9
    • Output(tok/s): 24.7

    • Conc: 4
    • TTFT(ms): 3,319
    • Prefill(tok/s): 532
    • Decode(tok/s): 12.7
    • Output(tok/s): 46.7

    • Conc: 8
    • TTFT(ms): 6,231
    • Prefill(tok/s): 283
    • Decode(tok/s): 11.9
    • Output(tok/s): 82.7

    docker run 命令:

    docker run -it --rm --name vllmb70 --ipc=host --shm-size=32g
    --device=/dev/dri:/dev/dri --privileged -p 1234:8000
    -v ~/.cache/huggingface:/root/.cache/huggingface
    -e VLLM_TARGET_DEVICE=xpu
    --entrypoint /bin/bash intel/llm-scaler-vllm:0.14.0-b8.2.1 -c "
    source /opt/intel/oneapi/setvars.sh --force &&
    sed -i 's/image_processor.max_pixels/getattr(image_processor, "max_pixels", 12845056)/g'
    /usr/local/lib/python3.12/dist-packages/vllm/model_executor/models/qwen2_vl.py &&
    python3 -m vllm.entrypoints.openai.api_server
    --model Intel/Qwen3.6-27B-int4-AutoRound
    --tokenizer Qwen/Qwen3.6-27B
    --served-model-name qwen/qwen3.6-27b
    --kv-cache-dtype auto
    --max-model-len 65536
    --gpu-memory-utilization 0.9
    --enable-auto-tool-choice
    --tool-call-parser qwen3_xml
    --allow-deprecated-quantization
    --trust-remote-code
    --port 8000
    --tensor-parallel-size 1
    --pipeline-parallel-size 1
    --enforce-eager
    "

    也跑了一下ltx2.3 full gpu offload比4070需要dynamic loading快10%左右 custom node很多不支持 暂时不值得折腾

    sirwangS 1 条回复 最后回复
    0
    • K kaifan

      分享一下单卡跑llmscaler数据
      周末把 Qwen3.6-27B 调到了一个对于 Agentic Loop 来说还算能接受的状态。比较系统的跑了一下单请求和并行 5 rep的benchmark。pp速度还可以,但 tg还是有点慢。不过配合 vLLM 的 continuous batching,并行 token 生成整体还比较稳定。目前专门用来给Hermes agent的delegate task去收集代码库context打下手

      目前唯一比较大的问题是:KV Cache 必须使用 BF16,才能达到可用的 token generation 速度,但ctx就只有43000了。另外还需要骗 vLLM,让它识别 layer architecture。希望未来能有优化过的 FP8 dequant kernel去支持fp8的kvcache。fp8的dequant比Q8_0慢很多,可惜官方docker的vllm版本还不支持除了fp8和bf16以外的kvcache dtype。可惜它和7900xtx都没有fp8的硬件支持,好像r9700有。另外autoround质量还是稍微比不过Q4的gguf

      硬件比较旧 64g的ddr4 虽然比较慢,但总比 pcie4x16 快。proxmox 9.1

      vLLM 单请求 qwen/qwen3.6-27b(int4 AutoRound):

      PP TTFT:1,685 ms

      PP2048 TPS:1,686 ± 66 tok/s

      TG512:13.7 ± 1.4 tok/s

      并行测试 pp2048 tg512
      Conc: 1
      • TTFT(ms): 1,261
      • Prefill(tok/s): 1,400
      • Decode(tok/s): 13.3
      • Output(tok/s): 12.9

      • Conc: 2
      • TTFT(ms): 1,907
      • Prefill(tok/s): 925
      • Decode(tok/s): 12.9
      • Output(tok/s): 24.7

      • Conc: 4
      • TTFT(ms): 3,319
      • Prefill(tok/s): 532
      • Decode(tok/s): 12.7
      • Output(tok/s): 46.7

      • Conc: 8
      • TTFT(ms): 6,231
      • Prefill(tok/s): 283
      • Decode(tok/s): 11.9
      • Output(tok/s): 82.7

      docker run 命令:

      docker run -it --rm --name vllmb70 --ipc=host --shm-size=32g
      --device=/dev/dri:/dev/dri --privileged -p 1234:8000
      -v ~/.cache/huggingface:/root/.cache/huggingface
      -e VLLM_TARGET_DEVICE=xpu
      --entrypoint /bin/bash intel/llm-scaler-vllm:0.14.0-b8.2.1 -c "
      source /opt/intel/oneapi/setvars.sh --force &&
      sed -i 's/image_processor.max_pixels/getattr(image_processor, "max_pixels", 12845056)/g'
      /usr/local/lib/python3.12/dist-packages/vllm/model_executor/models/qwen2_vl.py &&
      python3 -m vllm.entrypoints.openai.api_server
      --model Intel/Qwen3.6-27B-int4-AutoRound
      --tokenizer Qwen/Qwen3.6-27B
      --served-model-name qwen/qwen3.6-27b
      --kv-cache-dtype auto
      --max-model-len 65536
      --gpu-memory-utilization 0.9
      --enable-auto-tool-choice
      --tool-call-parser qwen3_xml
      --allow-deprecated-quantization
      --trust-remote-code
      --port 8000
      --tensor-parallel-size 1
      --pipeline-parallel-size 1
      --enforce-eager
      "

      也跑了一下ltx2.3 full gpu offload比4070需要dynamic loading快10%左右 custom node很多不支持 暂时不值得折腾

      sirwangS 离线
      sirwangS 离线
      sirwang
      编写于 最后由 编辑
      #47

      @kaifan 请问这是啥卡的数据?!

      K 1 条回复 最后回复
      0
      • sirwangS sirwang

        @kaifan 请问这是啥卡的数据?!

        K 离线
        K 离线
        kaifan
        编写于 最后由 编辑
        #48

        @sirwang arc pro b70

        1 条回复 最后回复
        0
        • sirwangS 离线
          sirwangS 离线
          sirwang
          编写于 最后由 编辑
          #49

          他们升级了vllm 的底包。可以问他们要了。

          K 1 条回复 最后回复
          0
          • sirwangS sirwang

            他们升级了vllm 的底包。可以问他们要了。

            K 离线
            K 离线
            kaifan
            编写于 最后由 编辑
            #50

            @sirwang 哦?是这周的事情吗 周末去试试看 谢谢告知

            1 条回复 最后回复
            0
            • sirwangS sirwang

              还在测啥? 以后就是comfyui 吧,我得换版块发帖了吧

              terryT 离线
              terryT 离线
              terry
              编写于 最后由 编辑
              #51

              @sirwang 就等你LTX2.3的帖子,慢了啊,把这个跑起来,英特尔就站起来了,弄详细点,我给单独做个视频。

              油管:https://www.youtube.com/@抡锤者

              sirwangS 1 条回复 最后回复
              0
              • sirwangS sirwang

                @李明 4080S的CUDA强,目前看来。如果不介意钱,就买4080S。

                V 离线
                V 离线
                vosrock
                编写于 最后由 编辑
                #52

                @sirwang 4080 32G是我的梦中情卡,性价比爆炸,当然3080 20G也是

                1 条回复 最后回复
                0
                • terryT terry

                  @sirwang 就等你LTX2.3的帖子,慢了啊,把这个跑起来,英特尔就站起来了,弄详细点,我给单独做个视频。

                  sirwangS 离线
                  sirwangS 离线
                  sirwang
                  编写于 最后由 编辑
                  #53

                  @terry 等他们的人调试中,我的docker参数可能有问题。

                  1 条回复 最后回复
                  0
                  • sirwangS 离线
                    sirwangS 离线
                    sirwang
                    编写于 最后由 编辑
                    #54

                    想了想还是别另开贴了,搞的好像刷帖一样。

                    事情是这样的:我想深度的测一下这卡的稳定性。 如果长期去用,去批量跑任务,稳定性就很胆小。 于是就有了这个操作: 朋友让我帮忙处理一批图片,将图片 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+像素高。

                    e6896f9e-3bb3-4ce2-ab6d-f4d69474a653-image.jpeg
                    4fb61e10-93b5-4a24-a0d7-083fa7de4d4d-image.jpeg
                    607fa44d-73b9-481f-b183-31ba84292db7-image.jpeg

                    d7a1fb79-5ec1-42a7-a425-b394dee10b95-image.jpeg

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

                    235cc17c-e7db-4da5-9d29-27d1f82faffc-image.jpeg

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

                    80b494c0-cb35-4fb3-9228-fda62e0ddf82-image.jpeg

                    portainer 监控 docker 的截图

                    1fd16328-44ce-4b97-b443-875cdcf73a0c-image.jpeg

                    模型信息和docker运行的时间

                    b42a4ac7-762e-4d10-af26-6e087ea0f687-image.jpeg

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

                    1 条回复 最后回复
                    0
                    • sirwangS 离线
                      sirwangS 离线
                      sirwang
                      编写于 最后由 编辑
                      #55

                      7e848e7d-b4ba-4c40-aefd-9c2587af09f0-image.jpeg

                      忘了贴最终的数据量了。 请原谅我的打码效果.... 哇哈哈哈
                      f74e0ebf-63ec-4cb1-9ac8-f59c165d578c-image.jpeg

                      下边这张,是在linux上的截图,文件的创建时间是昨天上午的11.36,但在创建文件之前,代码已经运行了一个小时了,它得去把这200多个文件全部都截取成一个一个的小块才能读取数据OCR数据。所以文件时间就晚了一个小时。

                      terryT 1 条回复 最后回复
                      0
                      • 系统 取消固定了该主题
                      • sirwangS sirwang

                        7e848e7d-b4ba-4c40-aefd-9c2587af09f0-image.jpeg

                        忘了贴最终的数据量了。 请原谅我的打码效果.... 哇哈哈哈
                        f74e0ebf-63ec-4cb1-9ac8-f59c165d578c-image.jpeg

                        下边这张,是在linux上的截图,文件的创建时间是昨天上午的11.36,但在创建文件之前,代码已经运行了一个小时了,它得去把这200多个文件全部都截取成一个一个的小块才能读取数据OCR数据。所以文件时间就晚了一个小时。

                        terryT 离线
                        terryT 离线
                        terry
                        编写于 最后由 编辑
                        #56

                        @sirwang 哥这个帖子太长了,换个帖子,都刷到好几页了。

                        油管:https://www.youtube.com/@抡锤者

                        sirwangS 1 条回复 最后回复
                        0
                        • terryT terry

                          @sirwang 哥这个帖子太长了,换个帖子,都刷到好几页了。

                          sirwangS 离线
                          sirwangS 离线
                          sirwang
                          编写于 最后由 编辑
                          #57

                          @terry 好的,我把并发从6加到了16,明天看效果。看看它会不会爆掉,明天别的版块开新贴对比汇报吧。

                          1 条回复 最后回复
                          0
                          • sirwangS sirwang 被引用 于这个主题

                          你好!看起来您对这段对话很感兴趣,但您还没有一个账号。

                          厌倦了每次访问都刷到同样的帖子?您注册账号后,您每次返回时都能精准定位到您上次浏览的位置,并可选择接收新回复通知(通过邮件或推送通知)。您还能收藏书签、为帖子顶,向社区成员表达您的欣赏。

                          有了你的建议,这篇帖子会更精彩哦 💗

                          注册 登录
                          回复
                          • 在新帖中回复
                          登录后回复
                          • 从旧到新
                          • 从新到旧
                          • 最多赞同


                          • 登录

                          • 没有帐号? 注册

                          • 登录或注册以进行搜索。
                          • 第一个帖子
                            最后一个帖子
                          0
                          • 版块
                          • 最新
                          • 标签
                          • 热门
                          • 用户
                          • 群组